CVE-2022-23923 about jailed

[marke-apexit]

Is this post suggesting this security issue is only relevant if you export alert() to 'jailed?' And the security vulnerability can be managed by not allowing user-defined exports, only user-defined code?

Could 'jailed' fix the CVE by scrubbing the exports and failing if alert() is in the exports?

[eric-hemasystems]

Is this post suggesting this security issue is only relevant if you export alert() to 'jailed?'

No. See above where it says:

The alert was just used to present the exfiltrated data for demonstration purposes and has nothing to do really with the vulnerability.

---

And the security vulnerability can be managed by not allowing user-defined exports, only user-defined code?

No. See above where it says:

I don't think the proposed fix to @gpascualg did in #37 would be sufficient as the Function constructor is not gained via one of the exposed objects passed to the new vm context.

---

Could 'jailed' fix the CVE by scrubbing the exports and failing if alert() is in the exports?

Since the sandbox escape uses a built-in Node object, this.constructor, and therefore there is nothing we are passing in I don't think there is a way to prevent the escape. Node.js would have to be changed itself.

---

Final result is:

• The isolation provided by jailed when used with Node.js is broken.
• This has been true for a while and was documented on the README. The only thing CVE-2022-23923 did was demonstrate a variant of the original that makes the previous attempts to fix it not workable.
• jailed is still useful and a sandbox secure when executed in the browser

If you need to run JavaScript server-side I might suggest try using a different JS engine such as Spidermonkey compiled to wasm run via wasmer. You can either just use the wasmer bin directly or use library bindings to it. Here is a module I made in Ruby that allows me to safely execute JS code server-side.