WAVM: standalone WebAssembly VM prototype

Re:WAVM: standalone WebAssembly VM prototype by slimsag on Sunday June 05, 2016 @11:33PM (#11844485)

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!

[ Parent | on HN ]

Re:WAVM: standalone WebAssembly VM prototype by stepanhruda on Sunday June 05, 2016 @11:42PM (#11844507)

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

[ Parent | on HN ]

Re:WAVM: standalone WebAssembly VM prototype by akavel on Monday June 06, 2016 @07:38AM (#11845964)

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.

[ Parent | on HN ]

Re:WAVM: standalone WebAssembly VM prototype by azakai on Sunday June 05, 2016 @11:45PM (#11844517)

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.

[ Parent | on HN ]

Re:WAVM: standalone WebAssembly VM prototype by sievebrain on Monday June 06, 2016 @06:13PM (#11850871)

JVM's are a specification.

[ Parent | on HN ]

Re:WAVM: standalone WebAssembly VM prototype by duaneb on Sunday June 05, 2016 @11:43PM (#11844511)

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.

[ Parent | on HN ]

Re:WAVM: standalone WebAssembly VM prototype by arcatek on Monday June 06, 2016 @04:31AM (#11845373)

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

[ Parent | on HN ]

Re:WAVM: standalone WebAssembly VM prototype by colemickens on Sunday June 05, 2016 @11:46PM (#11844519)

>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.

[ Parent | on HN ]

Re:WAVM: standalone WebAssembly VM prototype by fulafel on Monday June 06, 2016 @12:53AM (#11844737)

Implementation level bugs dominate, not spec bugs.

[ Parent | on HN ]

Re:WAVM: standalone WebAssembly VM prototype by espadrine on Monday June 06, 2016 @03:56AM (#11845265)

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.

[ Parent | on HN ]

Re:WAVM: standalone WebAssembly VM prototype by fulafel on Monday June 06, 2016 @04:58AM (#11845437)

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.

[ Parent | on HN ]

Re:WAVM: standalone WebAssembly VM prototype by espadrine on Monday June 06, 2016 @06:38AM (#11845726)

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”.

[ Parent | on HN ]