bootstrap: unfreeze console under --frozen-intrinsics

[guybedford]

This fixes the bug pointed out by @jdalton in #25685 (comment).

I haven't included an explicit test, because for all intensive purposes we could be testing EVERY global that it works under this flag. Rather the fix is by exclusion.

At the same time I've also added some documentation on how to handle the common errors, which are really only these two cases.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• documentation is changed or added
• commit message follows commit guidelines

[nodejs-github-bot]

Lite-CI: https://ci.nodejs.org/job/node-test-pull-request-lite-pipeline/3495

[guybedford]

CI failure seems to be that bootstrap is not a valid subsystem for some reason?. Fixed.

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[sam-github]

The doc fix is great, though since its unrelated to the code fix, I think it would be better as a seperate commit, if you are comfortable with splitting it.

As for the code fix, you are just excluding console from the global objects that are frozen? That seems an odd fix, it means that an attacker can do console.log = () => { /* do evil */ }, right? I'm OK with it, and the experimental option doesn't say what does or does not get frozen, or what is an "intrinsic". console is defined by WhatWG and browsers, but maybe not the JS spec, so it doesn't need freezing? I think a seperate commit with a bit more justtification would be valuable. Also, is the root cause not fixable? I.e., is it not possible for the Console constructor to use one of the patterns you documented to make console construction work even with console frozen?

[guybedford]

@sam-github the fix for subclassing console if it were a frozen intrinsics would actually be to use ES6 classes and then define all the properties as undefined class properties:

class ConsoleSubclass extends Console {
  // all properties would need to be explicitly defined as class properties
  log = undefined;
}

I think turning Console into a class like the above might also provide a fix in core.

We could explore these directions further, I just didn't want to get right into the weeds on this right now. Although we could and perhaps now is the best time to do that too instead of kicking it down the road.

[joyeecheung]

console.Console is non-standard. Off the top of my head an intuitive way to work around this is to skip these non-standard stuff when deep-freezing builtins. For console that means we need to create a whitelist of things to freeze for it since there are a lot of non-standard stuff there.

IIUC what is proposed in #27663 (comment), that means users can no longer do const { log } = console; log(1);? I think that probably cannot be broken at this point (and that's also part of the behavior tested by WPT)

[devsnek]

what does standardization have to do with security? the issue is whether it exists or not right? am i missing the point of frozen intrinsics?

[joyeecheung]

@devsnek Being non-standard means there is no explicit guarantee about whether it makes sense to freeze something, because the behavior of it is..well, not standardized. e.g. console._stdout and console._stderr are not supposed to be frozen or otherwise they would not function, but then users may not even know what that is supposed to do.

[nodejs-github-bot]

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

[guybedford]

Just cancelled the new CI as this has already run at https://ci.nodejs.org/job/node-test-pull-request/23085/. Apologies for noise!

[guybedford]

Was just going to land this, but git node metadata tells me I should wait another 40 hours given the single approval, so will come back around on it Monday unless anyone else wants to approve here.

[guybedford]

Landed in 1a9a577.