Описание
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, связанная с недостатками механизма проверки входных данных, позволяющая нарушителю подделать цифровую подпись