Secure EcmaScript, a runtime for running third-party code safely | Hacker News Reader

Secure EcmaScript, a runtime for running third-party code safely

github.com

45 pointsrewq432110 comments

"Still under development: do not use for production systems yet, there are known security holes that need to be closed."

Also note the experience of Figma who used the realms shim I think this project is using to secure Figma's JS based plug-ins system, only to promptly take a different approach when compromises were identified:

https://www.figma.com/blog/how-we-built-the-figma-plugin-sys...

https://www.figma.com/blog/an-update-on-plugin-security/

I am looking forward to Realms. Until then, I am doubtful of attempts to fully secure third party JS execution in the browser's engine.

"Since we published this blog post, we decided to change our sandbox implementation to an alternative approach: compiling a JavaScript VM written in C to WebAssembly"

That's a fairly good indictment of browser sandboxing :)

Not really, since this is about creating new sandboxes within the the browser sandbox, not about the browser sandbox itself.

I've had a few arguments with the person who leads SES over the past couple years, stemming from the idea that the realm shim is able to be attacked by new language features it doesn't know about. (for example, dynamic import exposing the outside environment).

I'd probably stick to a WASM VM unless JS exposed the ability to spin up a separate VM like that on its own (which is very unlikely to ever happen).

The original SES doesn't seem to do anything to prevent meltdown/spectre attacks [1]

This version removed direct access "Date" [2] but I'm not sure I'd trust any code running in the same process space given how hard it is to fix spectre in general.

[1] https://github.com/google/caja/wiki/SES#current-date-and-tim...

[2] https://github.com/Agoric/SES/tree/master/demo#taming-dateno...

> ...but I'm not sure I'd trust any code running in the same process space...

Can someone ELI5 how a separate process would fix Spectre/Meltdown?

Spectre relies on being able to speculatively access data and extracting information about said data through a side channel despite the speculative execution not committing. A separate process means address spaces are separate, which means speculative execution cannot access the data.

Meltdown is similar, but because a CPU affected by Meltdown does not perform permission checks during speculative execution, you can read memory that the execution environment doesn't even have permissions for. E.g. kernel memory.

The fix for Spectre is thus to only consider address spaces a security boundary; interpreters or JITs cannot be considerd security boundaries any more (in general).

What I really want is a JavaScript API--doesn't need to be a "VM": just a wrapper for an existing one--that makes it trivial to manipulate JavaScript engine spaces but where instead of them merely being separate memory allocators (as would be the case if you allocated two JavaScriptCore runtimes or engines or whatever they were called) the code is run in a separate process that doesn't contain any others memory or information and all communication with it is done via some kind of IPC (which you would then minimize using).

FYI, Moddable's XS JavaScript engine already includes a native preliminary implementation for anyone who wants to play. As a contributor to the standard, their announcement post is also interesting: https://blog.moddable.com/blog/secureprivate/

> SES is not a security model or a security policy. SES is a way to build these using standard JavaScript. By taking this more general approach, SES allows each host to define its own approach to security (including the option to have no restrictions at all). This is important because a security policy that makes sense for scripts running on a lightbulb is unlikely to apply equally well to scripts running on a web server or scripts in a web page. SES provides tools in the language to build secure systems, but it is not a security system.

On a related note, a new project was posted here a couple days ago, that runs an entirely separate JavaScript runtime (Duktape or QuickJS) in WASM:

https://github.com/maple3142/wasm-jseval

I've been playing with this, exploring its potential for running user scripts.

As noted in another comment, Figma used a Realms polyfill for their plugins, similar to SES, then migrated to using WASM-ized QuickJS as a safer sandbox.

Reply on news.ycombinator.com