[pcwalton]

> Of course that's not what anyone actually means by a "memory safe" language, but as soon as you go plop malloc/free on top of a single webasm allocation you're back to all the same memory-unsafeness of C despite the "memory safe" claims of webasm anyway.

That's not true. Web Assembly semantics don't allow interpreting data as code or explicitly messing with the machine stack. This guarantees control flow integrity, preventing problems like ROP or traditional buffer overflows.

[andromeduck]

While webasm isn't vulnurable to traditional ROP attacks, it will also lose at least as much performance penalty as IR + g-free/indirect return.

Memory protection in terms of r/w/x been solved for at least about 3 decades now. It would be absolutely trivial to enforce via binary/IR distribution.

At the end of the day webasm is just a shitty IR that only exists because it's the path of least resistance on the web. There's really no point in going from lang-> llvm -> webasm -> llvm -> exec when you can just go from lang -> llvm -> asm.

[pcwalton]

RWX doesn't prevent ROP!

[andromeduck]

Sure but I brought up rwx for their data execution point and g-free/indirect return for ROP mitigation.

[comex]

However, it only partially addresses JOP (jump-oriented programming, i.e. hijacking calls to function pointers and virtual methods). And there are CFI designs that provide equivalent or better guarantees for native code, such as Clang CFI + SafeStack. In fact, I expect Clang CFI to be more widely adopted in the future… However, the main obstacle to increased adoption has always been overhead, yet WebAssembly has significantly higher overhead.

edit: not to mention that WebAssembly is currently missing security mitigations that long have been standard in native code, such as ASLR, and… maybe stack overflow protection? (It looks like emscripten handles the latter manually by checking STACKTOP against STACK_MAX, but I'm not sure LLVM's native WebAssembly target does.) Maybe these will be addressed in the future, but for now there are some interesting exploitation opportunities.

[pcwalton]

> However, the main obstacle to increased adoption has always been overhead, yet WebAssembly has significantly higher overhead.

But you get a lot more than security for your trouble using Web Assembly. So the performance-vs.-security tradeoff isn't the only part of the calculus here.

> And there are CFI designs that provide equivalent or better guarantees for native code, such as Clang CFI + SafeStack.

Clang CFI only protects indirect calls. And SafeStack looks like it has issues, according to the Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=505015

"No. We are currently looking at other alternatives (all look grim, though). Before trying to proceed with SafeStack please get the agreement from security folks, since SafeStack doesn't actually sounds too secure any more :("

[comex]

Indirect calls as opposed to what? C++ virtual method calls are supported by Clang CFI. Direct calls are always safe because the destination address is fixed. (That is, unless you mess with the PLT, but that's what RELRO is for.)

Not sure what's up with SafeStack - though I bet it has to do with more hardware timing attacks, in this case to leak the address. The whole design is a bit of a hack since the only thing preventing the attacker from accessing the safe stack is their (theoretical) inability to guess the address. If only x86-64 hadn't gotten rid of segmentation, so normal memory accesses and stack accesses could actually use entirely separate memory regions… On the other hand, Intel CET should allow for some subset of that functionality on future hardware.

But again, to be fair, one should note that "grim" has a different meaning when the budget for acceptable performance loss is perhaps 1-5%, not 30-50% :P