[steveklabnik]

> I gave in another comment

Yeah, sorry about the duplication here, I'm extremely interested in this specific topic.

> Now someone finds a png decoder exploit that works against my build.

I think this is the part I don't get. Specifically, how would an exploit work within wasm? That is, in the wasm environment is different than in native; the memory is bounds checked, for example. Basically, I 100% agree that some security bugs are logic bugs, but take the above stack smash, for example: that can't happen, in my understanding. Again, modulo interpreter bugs, like any sandboxing technique.

> it's hard for me to imagine how a JS PNG decoder would end up with the same sort of attack possible on it since it's parsing binary data into pixel buffers. At worst, you'd crash it.

It's hard for me to imagine how wasm is any different than JS here.

[standupstandup]

How does wasm stop stack smashes? I can see that if it's not a von Neumann machine i.e. code is in a different memory space to data, it'd be harder, but that doesn't seem really compatible with C/C++?

Just in general if I have an arbitrary memory write primitive inside the wasm memory space, how much control over the program can I obtain?

[kevingadd]

wasm does some stack isolation so that the function's local stack variables are not next to things like the return value in memory and loads to/from stack slots are special instructions that reference slot identifiers. Most stack operations aren't arbitrary memory reads/writes from addresses so it's not possible to overflow them and corrupt other values.

The caveat is that not everything native apps put on the stack can currently be stored in wasm's safe stack, so applications often put a secondary stack inside their heap. This will also happen if you're - for example - passing large structs around as arguments. You can smash the heap stack if you manage to find an exploit, and if function pointers or other important data are stored there, you can turn that into an attack.

It's absolutely the case that a large subset of stack smashing attacks don't work on wasm, because of the safety properties. Some of them will still work though. The way function pointers work in wasm raises the risk profile a bit if you manage to get control over the value of a function pointer, since function pointer values are extremely easy to predict.

[standupstandup]

Thanks.

I am curious how JIT compilation policies will affect this. Wasm is a new bytecode form that has no mature JIT compilers. I wonder how many safety properties the compilers will assume. For instance if the wasm VM only really tries to stop wasm code escaping its own sandbox, then I guess compiling all stack ops down to a unified stack, C style, is a perfectly legitimate approach as long as the sandbox properties can be maintained. I don't think wasm is claiming it will make all C/C++ hackproof code.

[steveklabnik]

Yup, and thanks for this; this helps me understand what I was missing, specifically "applications often put a secondary stack inside their heap".