lib: Add option to disable __proto__ accessors

[devsnek]

Adds --disable-proto CLI option which can be set to delete or
throw.

Fixes #31951

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[addaleax]

Maybe clarify somewhere that this only affects the main Context?

[mcollina]

lgtm

Does this also impact worker threads? I think it should and we could also add an option there.

I'm also perfectly fine in landing this as this and opening an issue for worker threads etc.

[addaleax]

Does this also impact worker threads? I think it should and we could also add an option there.

Worker threads inherit their execArgv from the parent thread, unless specified otherwise. I would not add a separate option for this.

[legendecas]

Does it feasible to add an option to ignore the __proto__ field rather than throwing? If the engine does ignore the __proto__s there is no reason for users to handle these errors.

[addaleax]

@legendecas How would that differ from --disable-proto=delete? Are you suggesting that a.__proto__ = {}; does nothing, including not setting __proto__ as a regular property? That would seem more surprising to me…

[legendecas]

@addaleax I tried the PR locally, it doesn't seem to be effective on the case of delete since only Object.prototype.__proto__ is deleted in the PR:

$ node --disable-proto=delete -p '({ __proto__: Array.prototype }).push === Array.prototype.push'
true

What I'm understanding/expecting is:

$ node --disable-proto=delete -p '({ __proto__: Array.prototype }).push'
undefined

[bmeck]

@legendecas object literals do not use the getter/setter and are a special case of syntax. They are not problematic for assignment like the accessors and not part of the CVEs in question

[cjihrig]

This should update doc/node.1 too.

[devsnek]

@cjihrig can you verify i did the node.1 change correctly? i just kind of guessed based on other entries...

[cjihrig]

@devsnek you can run man doc/node.1 to look at the finished product.

EDIT: It looks good at a quick glance, but I don't really know the format and need to view it with man.

[Slayer95]

The given solution might not provide protection against the following test case:

"use strict";

const assert = require('assert');
const vm = require('vm');

(function patchProto() {
	const protoThrow = () => {throw new Error(`Illegal __proto__ access`)}
	Object.defineProperty(Object.prototype, '__proto__', {get: protoThrow, set: protoThrow, enumerable: false, configurable: false});
})();

function getCrossRealmObject() {
	const ctx = vm.createContext({});
	vm.runInContext('value = {"foreign":1}', ctx);
	return ctx.value;
}

function testProto() {
	const payload = '{"__proto__": {"evil": true}}';

	const x = getCrossRealmObject();
	try {
		Object.assign(x, JSON.parse(payload));
	} catch (err) {}
	assert(!x.evil);
}

testProto();

If it does, please add such a test!

[tniessen]

@Slayer95 See @addaleax's #32279 (comment):

this only affects the main Context

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/29877/