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

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.

From that section that you linked:

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

It doesn't matter if the host remains untouched, when its behaviour depends on outputs from WASM functions.

So you can get upgraded security credentials, while the host remains 100% safe, as a possible attack scenario.

Security is only effective as the weakest link.

WA's goal posts are "protect the host from the program, not the program from itself"; the program is assumed to be malicious in this context. If you want to turn around and eval the output of a potentially malicious program in the context of the host, that's on you. You haven't 'broken' the WA memory barrier and blaming WA is an attempt to move the goal posts. WA adds a specific (hitherto unbroken) security layer; intentionally poking a hole in it and prancing about like you've found something is just crying wolf.

Edit to add that I agree that whole-program security is obviously still important when a WA-sandbox is part of the whole program, but WA is not advertised to be a solution to the halting problem, it's still just a tool. Be aware of the capabilities of the tools you use, wishing that your tools are made of magic does not make them more capable than what they were designed for.