-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
child_process: harden against prototype pollution #48726
child_process: harden against prototype pollution #48726
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
@@ -136,7 +136,7 @@ function fork(modulePath, args = [], options) { | |||
if (options != null) { | |||
validateObject(options, 'options'); | |||
} | |||
options = { ...options, shell: false }; | |||
options = { __proto__: null, ...options, shell: false }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not related to this PR, but I wonder if we should use { __proto__: options, shell: false }
and let users decide if they want prototype pollution or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it make this object affected by subsequent mutations outside?
In fact, I wonder if we should use structuredClone()
or at least make copies of object properties like .env
to avoid race conditions if multiple fork()
s are called with reused options.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it make this object affected by subsequent mutations outside?
I guess it depends if we read the properties in the same tick or not (which I expect we do most of the time, but I haven't checked).
In fact, I wonder if we should use
structuredClone()
That wouldn't help with inconsistency of our API: sometimes, we dismiss inherited properties, sometimes we don't. But it's clearly not a big deal as I don't think we ever received any bug report regarding that.
or at least make copies of object properties like
.env
to avoid race conditions if multiplefork()
s are called with reused options.
but wouldn't folks expect the same env to be shared if they supply the same object? The fact that no one complains makes me think we're overthinking it 😅
Landed in 6a88926 |
PR-URL: nodejs#48726 Reviewed-By: Matthew Aitken <[email protected]> Reviewed-By: Mohammed Keyvanzadeh <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>
PR-URL: nodejs#48726 Reviewed-By: Matthew Aitken <[email protected]> Reviewed-By: Mohammed Keyvanzadeh <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>
PR-URL: nodejs#48726 Reviewed-By: Matthew Aitken <[email protected]> Reviewed-By: Mohammed Keyvanzadeh <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>
PR-URL: #48726 Reviewed-By: Matthew Aitken <[email protected]> Reviewed-By: Mohammed Keyvanzadeh <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>
PR-URL: #48726 Reviewed-By: Matthew Aitken <[email protected]> Reviewed-By: Mohammed Keyvanzadeh <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>
PR-URL: #48726 Reviewed-By: Matthew Aitken <[email protected]> Reviewed-By: Mohammed Keyvanzadeh <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>
PR-URL: #48726 Reviewed-By: Matthew Aitken <[email protected]> Reviewed-By: Mohammed Keyvanzadeh <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]>
* chore: bump node in DEPS to v18.18.0 * child_process: harden against prototype pollution nodejs/node#48726 * deps: upgrade to libuv 1.46.0 nodejs/node#49591 * module: reduce url invocations in esm/load.js nodejs/node#48337 * Revert "test: remove test-crypto-keygen flaky designation" nodejs/node#48652 * fix: FTBTFS in ada dep ada-url/ada#464 ada-url/idna#31 * fix: force_colors snapshot line number * chore: fixup patch indices * chore: update filenames.json --------- Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com> Co-authored-by: Shelley Vohr <[email protected]>
* chore: bump node in DEPS to v18.18.0 * child_process: harden against prototype pollution nodejs/node#48726 * deps: upgrade to libuv 1.46.0 nodejs/node#49591 * module: reduce url invocations in esm/load.js nodejs/node#48337 * Revert "test: remove test-crypto-keygen flaky designation" nodejs/node#48652 * fix: FTBTFS in ada dep ada-url/ada#464 ada-url/idna#31 * fix: force_colors snapshot line number * chore: fixup patch indices * chore: update filenames.json --------- Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com> Co-authored-by: Shelley Vohr <[email protected]>
Prior pull request (nodejs#48726) hardened against prototype pollution vulnerabilities but effectively missed some use-cases which opened a window for prototype pollution for some child_process functions such as spawn(), spawnSync(), and execFileSync().
Prior pull request (nodejs#48726) hardened against prototype pollution vulnerabilities but effectively missed some use-cases which opened a window for prototype pollution for some child_process functions such as spawn(), spawnSync(), and execFileSync().
Prior pull request (nodejs#48726) hardened against prototype pollution vulnerabilities but effectively missed some use-cases which opened a window for prototype pollution for some child_process functions such as spawn(), spawnSync(), and execFileSync().
Prior pull request (nodejs#48726) hardened against prototype pollution vulnerabilities but effectively missed some use-cases which opened a window for prototype pollution for some child_process functions such as spawn(), spawnSync(), and execFileSync().
Prior pull request (nodejs#48726) hardened against prototype pollution vulnerabilities but effectively missed some use-cases which opened a window for prototype pollution for some child_process functions such as spawn(), spawnSync(), and execFileSync().
Prior pull request (nodejs#48726) hardened against prototype pollution vulnerabilities but effectively missed some use-cases which opened a window for prototype pollution for some child_process functions such as spawn(), spawnSync(), and execFileSync().
Prior pull request (nodejs#48726) hardened against prototype pollution vulnerabilities but effectively missed some use-cases which opened a window for prototype pollution for some child_process functions such as spawn(), spawnSync(), and execFileSync().
Prior pull request (#48726) hardened against prototype pollution vulnerabilities but effectively missed some use-cases which opened a window for prototype pollution for some child_process functions such as spawn(), spawnSync(), and execFileSync(). PR-URL: #53781 Reviewed-By: Vinícius Lourenço Claro Cardoso <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Rafael Gonzaga <[email protected]>
Prior pull request (#48726) hardened against prototype pollution vulnerabilities but effectively missed some use-cases which opened a window for prototype pollution for some child_process functions such as spawn(), spawnSync(), and execFileSync(). PR-URL: #53781 Reviewed-By: Vinícius Lourenço Claro Cardoso <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Rafael Gonzaga <[email protected]>
Prior pull request (#48726) hardened against prototype pollution vulnerabilities but effectively missed some use-cases which opened a window for prototype pollution for some child_process functions such as spawn(), spawnSync(), and execFileSync(). PR-URL: #53781 Reviewed-By: Vinícius Lourenço Claro Cardoso <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Rafael Gonzaga <[email protected]>
Prior pull request (#48726) hardened against prototype pollution vulnerabilities but effectively missed some use-cases which opened a window for prototype pollution for some child_process functions such as spawn(), spawnSync(), and execFileSync(). PR-URL: #53781 Reviewed-By: Vinícius Lourenço Claro Cardoso <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Rafael Gonzaga <[email protected]>
Prior pull request (#48726) hardened against prototype pollution vulnerabilities but effectively missed some use-cases which opened a window for prototype pollution for some child_process functions such as spawn(), spawnSync(), and execFileSync(). PR-URL: #53781 Reviewed-By: Vinícius Lourenço Claro Cardoso <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Rafael Gonzaga <[email protected]>
Prior pull request (#48726) hardened against prototype pollution vulnerabilities but effectively missed some use-cases which opened a window for prototype pollution for some child_process functions such as spawn(), spawnSync(), and execFileSync(). PR-URL: #53781 Reviewed-By: Vinícius Lourenço Claro Cardoso <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Rafael Gonzaga <[email protected]>
Improve robustness against something like