|
Good summary and clarification. Yes, we do not aim to break out of the (browser) sandbox, and yes the example exploits only use functions that are already imported into the vulnerable WebAssembly module. However, I would draw a bit more attention to the consequences when memory vulnerabilities in a WebAssembly binary are exploited: (1) Not every WebAssembly binary is running in a browser or in a sandboxed environment. The language is small, cool, and so more people are trying to use it outside of those "safe" environments. E.g., "serverless" cloud computing, smart contract systems (Ethereum 2.0, EOS.IO), Node.js, standalone VMs, and even Wasm Linux kernel modules. With different hosts and sandboxing models, memory vulnerabilities inside a WebAssembly binary can become dangerous. (2) Even if an attacker can "only" call every function imported into the binary, it depends on those imported functions how powerful the attack can be. Currently, yes, most WebAssembly modules are relatively small and import little "dangerous" functionality from the host. I believe this will change, once people start using it, e.g, for frontend development -- then you have DOM access in WebAssembly, potentially causing XSS. Or access to network functions. Or when the binary is a multi-megabyte program, containing sensitive data inside its memory. Sure, the warning is early, but I'd rather fix these issues before they become a common problem in the wild. |