Hacker News new | past | comments | ask | show | jobs | submit login

This is kind of neat but it's not clear how to think about what WebAssembly is doing, since the output is native code. I guess it's essentially a safe compiler for C++ code?

For a language whose compiler already outputs safe binaries, this step would be redundant.

It's not that easy to write a safe compiler though. Would a compile toolchain that uses WebAssembly for all compilation be useful?




It's not a safe compiler for C/C++, the compiled wasm code can still be compromised, it just cannot touch the rest of the process except indirectly via returned values.


And, to be clear, people could still do bad stuff with compromised WASM.

The big difference is that the WASM sandbox significantly reduces the surface area of what bad stuff can be done.

Today, a compromise in the browser means the attacker can do whatever the browser can do (which is usually a LOT). With the sandbox, a compromise can only really affect what the sandbox has available to it. That means, if your sandbox only exposes a single method which takes in a string and returns a string, the worst thing an attacker can do is return a malformed string.

Of course, if you mishandle that returned string then bad stuff will happen but it's a far cry from the input string being able to potentially cause arbitrary code execution which installs a virus on your machine.

To really do something evil you have to not only compromise the code running in WASM, you have to find a way to break out of WASM. That's a lot harder to do.


WebAssembly still suffers from possible internal memory corruption , so it is only safe to the extent that the C++ standard library with bounds checking enabled gets used.

Alternatively WASM could eventually support memory tagging like SPARC and ARMv8.


No, the goal is to constrain "internal memory corruption" to the WASM sandbox itself and values returned from it.


In the occurrence of internal memory corruption the values returned by public functions exposed in a WASM module can be anything.

For example, a WASM based security module can just start logging-in everyone as admin, because the user metadata got corrupted.


The claimed advantage is not that wasm-compiled modules are more resilient to bugs or exploits, but that those exploit are easier to contain.

Nobody is surprised that an exploit in the authentication module can be used to log in as admin. It is different if an exploit in the font rendering module lets you log in as admin.

They are just two (equally important but) orthogonal facets of security


Maybe the question I should have asked is what sort of protection does it provide beyond a normal compile and how useful is it?

It seems like there is some kind of cross-module memory protection? Maybe Erlang would be an interesting comparison?


It prevents a bug in your text rendering module from logging you in as admin, which is usually not the case inside a single process.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: