> so this doesn't really say much about the WebAssembly spec from a host security perspective
To be clear, it does. WebAssembly does attempt to ensure that it compiles and executes programs in such a way that they are resistant to memory unsafety.
Webassembly advertises itself as more or less solving the "insecure C is still insecure" problem. In reality it's missing a lot of memory safety mitigations you'd find in a C program compiled with a modern compiler.
> Nevertheless, other classes of bugs are not obviated by the semantics of WebAssembly. Although attackers cannot perform direct code injection attacks, it is possible to hijack the control flow of a module using code reuse attacks against indirect calls. However, conventional return-oriented programming (ROP) attacks using short sequences of instructions (“gadgets”) are not possible in WebAssembly, because control-flow integrity ensures that call targets are valid functions declared at load time. ...
The paper is just a long-winded restatement of this paragraph.
And to be clear it doesn't. I said:
> ... Notably, they don't appear to even try to break the WA-host memory barrier ...
To which the paper's author themselves directly replied:
> ... I do agree with you, however, that our findings do not invalidate the overall design of WebAssembly. ... I also think "host security" (which we are not really looking into) is solid, with two qualifications: ...
To be clear, it does. WebAssembly does attempt to ensure that it compiles and executes programs in such a way that they are resistant to memory unsafety.
From webassembly.org, section "Memory Safety":
https://webassembly.org/docs/security/
Webassembly advertises itself as more or less solving the "insecure C is still insecure" problem. In reality it's missing a lot of memory safety mitigations you'd find in a C program compiled with a modern compiler.