Hacker News Reader

Comment by slimsag | Hacker News Reader

Am I correct that WebAssembly is the first browser language VM (like JVM, Flash, etc) that is developed as a specification and not an implementation? If so, I wonder how security will fare in comparison to JVM/Flash/etc, I imagine it'll be much better. WebAssembly is gonna be huge, esp. with languages like Rust supporting it!

View on HN

I assume there will be no more security holes than there are in javascript, since it's effectively a sibling to it, implementing the exact same APIs

It's also being run using the same VMs as JavaScript. There is some new code, but overall it's the same JITs, so similar security risks.

I suspect it (the WASM VM) will "bubble out" from inside the JS VM in browsers sooner or later, as a distinct entity in browsers. To enable better optimizations, if only. And especially better optimizations means closer to metal, which I think makes it harder not to introduce security holes.

Also, brand new external WASM VMs will be created (as in the OP link), and possibly used in future (or current but new versions?) browsers, again allowing for brand new security holes.

So, I'm not very convinced by this argument as of now.

JVM's are a specification.

If there are N implementations, there are N times more chance for a security vulnerability. Roughly, anyway. I don't think the reference material matters as much as the rigor that goes into defining it.

>If there are N implementations, there are N times more chance for a security vulnerability.

I don't even understand what this is supposed to mean. Do you mean that a hole in the spec means that a sec vuln would occur in every implementation? Or that 5 implementations means 5 code bases to review?

Either way, it seems like a sentence that is meant to carry weight but is ultimately nearly completely meaningless. N different desktop apps on my computer have N chances for sec vulns. I don't see what that statement is supposed to mean regarding WebAssembly.

Implementation level bugs dominate, not spec bugs.

In this instance, WASM shares JS' sandbox and security model down to the implementation, so the added risk is extremely limited. The only part that could be dangerous is the parser.

From WAVM's Github README: "This is a prototype of a simple standalone VM for WebAssembly"

So it doesn't share code with a JS implementation in this case.

Browsers have their security model. On the other hand, when you install an executable binary or a Node.js program, you don't expect to have the same security model.

This project fits in the latter category. It does not claim that downloaded binaries are protected by a sandbox, and the only security claim it makes is the following weak one: “The generated code should be unable to access any memory outside of the addresses allocated to it”.

N different implementations can also mean that any single implementation vulnerability will only affect 1/N of the total user base. Using a single implementation isn't always the best way to achieve security (cf OpenSSL).

Reply on news.ycombinator.com