Описание
pbkdf2 returns predictable uninitialized/zero-filled memory for non-normalized or unimplemented algos
Summary
This affects both:
- Unsupported algos (e.g.
sha3-256/sha3-512/sha512-256) - Supported but non-normalized algos (e.g.
Sha256/Sha512/SHA1/sha-1/sha-256/sha-512)
All of those work correctly in Node.js, but this polyfill silently returns highly predictable ouput
Under Node.js (only with pbkdf2/browser import, unlikely) / Bun (pbkdf2 top-level import is affected), the memory is not zero-filled but is uninitialized, as Buffer.allocUnsafe is used
Under browsers, it just returns zero-filled buffers (Which is also critical, those are completely unacceptable as kdf output and ruin security)
Were you affected?
The full list of arguments that were not affected were literal:
'md5''sha1''sha224''sha256''sha384''sha512''rmd160''ripemd160'
Any other arguments, e.g. representation variations of the above ones like 'SHA-1'/'sha-256'/'SHA512' or different algos like 'sha3-512'/'blake2b512', while supported on Node.js crypto module, returned predictable output on pbkdf2 (or crypto browser/bundlers polyfill)
Beware of packages re-exporting this under a different signature, like (abstract):
In this case, the resulting deriveKey method is also affected (to the same extent / conditions as listed here).
Environments
This affects require('crypto') in polyfilled mode (e.g. from crypto-browserify, node-libs-browser, vite-plugin-node-polyfills, node-stdlib-browser, etc. -- basically everything that bundles/polfyills crypto
- In bundled code (e.g. Webpack / Vite / whatever), this affects
require('crypto')andrequire('pbkdf2') - On Node.js, this does not affect
require('pbkdf2')(orrequire('crypto')obviously), but affectsrequire('pbkdf2/browser') - On Bun, this does affect
require('pbkdf2')andrequire('pbkdf2/browser')(and returns uninitialized memory, often zeros / sparse flipped bytes)
PoC
Output (odd lines are Node.js, even is pbkdf2 module / polyfill):
Uninitialized memory
Affected versions
Seems to be since https://github.com/browserify/pbkdf2/commit/9699045c37a07f8319cfb8d44e2ff4252d7a7078
Impact
This is critical, browserifying code might silently generate zero-filled keys instead of proper ones, for code that was working on Node.js or in test environment
Just updating to a fixed version is not enough: if anyone was using pbkdf2 lib (e.g. via crypto-browserify or directly) on algos not from the literal string list (see "were you affected"), recheck where those keys went / how they were used, and take action accordingly
Note
Most likely, you receive this either through a subdep using pbkdf2 module directly (and then it is used), or through crypto-browserify (and the usage depends on whether you or any of your subdeps were calling pbkdf2/pbkdf2Sync methods from Node.js crypto inside your bundle)
When targeting non-Node.js, prever avoiding Node.js crypto polyfill at all, and use crypto.subtle and/or modern/audited cryptography primitives instead
Пакеты
pbkdf2
>= 3.0.10, <= 3.1.2
3.1.3
Связанные уязвимости
Improper Input Validation vulnerability in pbkdf2 allows Signature Spoofing by Improper Validation. This vulnerability is associated with program files lib/to-buffer.Js. This issue affects pbkdf2: from 3.0.10 through 3.1.2.
Improper Input Validation vulnerability in pbkdf2 allows Signature Spoofing by Improper Validation. This vulnerability is associated with program files lib/to-buffer.Js. This issue affects pbkdf2: from 3.0.10 through 3.1.2.
Improper Input Validation vulnerability in pbkdf2 allows Signature Spoofing by Improper Validation. This vulnerability is associated with program files lib/to-buffer.Js. This issue affects pbkdf2: from 3.0.10 through 3.1.2.
Improper Input Validation vulnerability in pbkdf2 allows Signature Spo ...
Уязвимость библиотеки pbkdf2 программной платформы Node.js, позволяющая нарушителю подделать цифровую подпись