[eyelidlessness]

> V8 is a sandboxed language

False, V8 is a JS runtime with sandboxing built into its core design. It’s not a language and it doesn’t guarantee sandboxing the JS runtime.

> that makes it impossible

False, breaking out of the sandbox is trivial in environments which allow native addons.

[nexuist]

I am very interested in this. Are there existing exploits for deno? Using a stock out of the box configuration, can you execute some code that breaks its permission model?

Has deno undergone some kind of security audit to verify its claims irt security?

EDIT: I see some referenced issues in comments down below involving the --allow-read/write flag. I'm not interested in that. I'm interested in if anyone can prove that with no permissions granted at all, they can break out of the sandbox and achieve ACE.

[eyelidlessness]

I think you’d need to either grant permissions (eg allow-ffi) or find a privilege escalation bug in V8 or Deno’s Rust bindings. The latter is less likely for sure. But being realistic, most people using Deno are granting some privileges, because most use cases at minimum do some I/O.

I’m academically interested if there are other such exploits, too. But I’d expect if they’re found they’ll be patched before they’re disclosed (or they’ll be exploited in the wild).

[cookiengineer]

Technically correct.

Also related: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...

Most Browser exploits these days use Heap Spraying attacks that try to corrupt the state of the sandbox in between bindings and native libraries (or their data structures that are transferred between contexts). So technically, a JIT VM always leads to possibilities for breakouts when there is a discrepancy between the optimizer and deoptimizer's assumptions (e.g. in regards to callstack, garbage, memory ownership etc).

Also: There's a legacy navigator.plugins C-Bridge based API which hasn't been maintained or redesigned/refactored since the late 90s yet it is still active in most Browsers.