Hacker News Reader

Comment by speed_spread | Hacker News Reader

WASM started making is way into browsers just as we removed the last remnants of Java Applets. Now we have too re-secure a whole new stack.

View on HN

At least WASM is first-party code written by the browser developers. I'll take that any day over a pile of third-party plugins.

the WASM people knew that going in and it's part of the design.

it's also why WASM is so slow compared to native executables; security guarantees have a performance cost.

Yet several security issues still aren't taken care of,

https://www.usenix.org/conference/usenixsecurity20/presentat...

https://www.usenix.org/conference/usenixsecurity21/presentat...

well it's not perfect, no.

my point stands though. WASM is not ActiveX where the whole applet has admin permission on the computer.

In abstract, in practice it depends on which runtime is being used.

Hum... You are aware that those are one where the attacker gains execution capabilities inside the sandbox and one hardware vulnerability that affects every single language, right?

Gaining execution capabilities inside the sandbox is already good enough to compromise its behaviour, e.g. everyone gets true back when is_admin() gets called.

More devs should get security trainings.

Yes, but it's a complete mischaracterization to claim it's a failure of the sandbox.

On this specific case, it is quite a big deal to add write and execute controls to the WASM memory, so it requires further justification than "I can do stack underflow attacks on my C code". Even though "I can do stack underflow attacks on my C code" is relevant information.

Reply on news.ycombinator.com