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";constassert=require('assert');constvm=require('vm');(functionpatchProto(){constprotoThrow=()=>{thrownewError(`Illegal __proto__ access`)}Object.defineProperty(Object.prototype,'__proto__',{get: protoThrow,set: protoThrow,enumerable: false,configurable: false});})();functiongetCrossRealmObject(){constctx=vm.createContext({});vm.runInContext('value = {"foreign":1}',ctx);returnctx.value;}functiontestProto(){constpayload='{"__proto__": {"evil": true}}';constx=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