
Secure EcmaScript, a runtime for running third-party code safely - rewq4321
https://github.com/Agoric/SES
======
scottfr
"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/how-we-built-the-figma-plugin-system/)

[https://www.figma.com/blog/an-update-on-plugin-
security/](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.

~~~
tyingq
_" 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 :)

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

------
teh
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...](https://github.com/google/caja/wiki/SES#current-date-and-time)

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

~~~
colejohnson66
> ...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?

~~~
blattimwind
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).

------
CharlesW
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/](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._

------
lioeters
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](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.

