3 ms·

It's easy to misunderstand this paper. This is not about breaking out of the wasm sandbox. You can't use these vulnerabilities to take over the browser, execute

It's easy to misunderstand this paper. This is not about breaking out of the wasm sandbox. You can't use these vulnerabilities to take over the browser, execute arbitrary code, install malware, etc. This is only about modifying memory inside the sandbox. By modifying memory you could potentially cause the existing code in a wasm binary to do unexpected and potentially malicious things inside its sandbox. Which can be bad. But no more than that, unless you can chain it with other types of vulnerabilities. And using safe languages for your wasm code helps. The paper also points out that uses of wasm outside the browser, e.g. in node, may not be securely sandboxed. I hope that wasm people are looking at adding mitigations for some of these attacks. Stack overflow in particular seems like something that can be protected against.

chubot 6y ago
That's not an accurate summary. You can take over the browser by chaining exploits. Sections 5.1 and 5.2 show two examples. Needing to chain isn't as bad as a full breakout, but in practice, attackers can and do chain exploits. (pwn2own has some really impressive chains, but those are about breaking out of the sandbox) If you had written the code in JavaScript, this class of vulnerability would be impossible. Also remember that WASM doesn't actually improve peak performance over JS. The asm.js subset of JS has the same performance. WASM does two things 1) it makes performance predictable by ensuring you don't fall off a cliff of the JIT 2) It improves parsing time because it's loading a binary format rather than parsing JS. e.g. notice that the headline here is about load time, not execution time, which would be more important: https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
- modeless 6y ago
  You can't take over the browser without chaining to a browser exploit, which is a much higher bar. If you already have a browser exploit I think you are unlikely to need to chain it from a wasm binary. You can potentially take over the page, but again only if you have vulnerabilities in the JavaScript interfacing with the wasm code. There is only one browser-based example in the paper and the vulnerability is due to using document.write which is always a security no-no.
- infogulch 6y ago
  I disagree with your disagreement. :) "oh but you can chain exploits" in this context is like if a php server takes POST data, passes it through an arbitrary but guaranteed to terminate "safe" function, and calls eval() on the result -- and then attributes potential vulnerabilities to the function. This seems silly, obviously the problem is the eval() at the end.
  - emn13 6y ago
    At the end of the day, if an attacker needs to chain exploits that's still a safer place to be that if they didn't need to do so. Additionally, how relevant is a link in an exploit chain when it's very likely the same overall effect could be had without using that link? Not very. And as you say, the examples given are really poor; they're barely exploits, that's more like a really unwise feature - it's hard to imagine situations like this arising in practice by accident without being more easily exploitable without even using WASM in the first place - I mean, if you're processing data in a some way and your interface with that processing code includes stuff like eval, that's just a disaster waiting to happen - as web exploits over the decades have demonstrated again, and again.
- magicalist 6y ago
  > You can take over the browser by chaining exploits. Sections 5.1 and 5.2 show two examples. 5.1 is XSS due to using document.write with a user provided string. That's not taking over the browser and is very much possible from JS (it's basically the prototypical XSS example from well before there was wasm). 5.2 is more serious but in node, not the browser, and is barely a chain (two exploits?). It's a way to get a string to eval() if eval() is available in one of the indirect functions. I think the authors also overstate the benefits of ASLR in that case. If that same code was running natively in a server and exposed to direct user input like that, it's very possible an RCE could be made to work. These examples are simple by design since they're just demonstrations that it's possible, so more sophisticated attacks are possible, but we also shouldn't over extrapolate from them.
  - chubot 6y ago
    Yeah I wasn't precise enough, I wrote a better summary here: https://news.ycombinator.com/item?id=26996738 https://news.ycombinator.com/item?id=26996738 tl;dr A bad case is if something like Figma stores your credit card info on the server. If they have a buffer overflow + document.write() of HTML derived from wasm code, the person who controls the image data could steal your credit card info. This is basically example 5.1; Figma is a huge chunk of C++ compiled to wasm, which may process images from other users.
- stefan_ 6y ago
  It's a meaningless point in the chain. Browser security is not intended to be only for running "trusted" or known JavaScript or WebAssembly code and hence competitions like Pwn2Own are perfectly happy to have you navigate to your own page that then runs whatever WASM or JS you want. Nobody requires you to first find an XSS on HN for your exploit because getting someone to load a random page is an extremely low barrier.
wernercd 6y ago
"unless you can chain it" Isn't that the GOTO for vulnerabilities these days? Saying "unless" means "when" in reality...
daniellehmann 6y ago
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.
- modeless 6y ago
  Agreed. Wow, Ethereum 2.0 has wasm support? I hope nobody is writing smart contracts in C++...
  - CyberDildonics 6y ago
    You should look at what people actually write 'smart contracts' in. It is so bad it seems like a parody of what you would actually want to do.

chubot 6y ago

That's not an accurate summary. You can take over the browser by chaining exploits. Sections 5.1 and 5.2 show two examples. Needing to chain isn't as bad as a full breakout, but in practice, attackers can and do chain exploits. (pwn2own has some really impressive chains, but those are about breaking out of the sandbox) If you had written the code in JavaScript, this class of vulnerability would be impossible. Also remember that WASM doesn't actually improve peak performance over JS. The asm.js subset of JS has the same performance. WASM does two things 1) it makes performance predictable by ensuring you don't fall off a cliff of the JIT 2) It improves parsing time because it's loading a binary format rather than parsing JS. e.g. notice that the headline here is about load time, not execution time, which would be more important: https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-...

modeless 6y ago
You can't take over the browser without chaining to a browser exploit, which is a much higher bar. If you already have a browser exploit I think you are unlikely to need to chain it from a wasm binary. You can potentially take over the page, but again only if you have vulnerabilities in the JavaScript interfacing with the wasm code. There is only one browser-based example in the paper and the vulnerability is due to using document.write which is always a security no-no.
infogulch 6y ago
I disagree with your disagreement. :) "oh but you can chain exploits" in this context is like if a php server takes POST data, passes it through an arbitrary but guaranteed to terminate "safe" function, and calls eval() on the result -- and then attributes potential vulnerabilities to the function. This seems silly, obviously the problem is the eval() at the end.
- emn13 6y ago
  At the end of the day, if an attacker needs to chain exploits that's still a safer place to be that if they didn't need to do so. Additionally, how relevant is a link in an exploit chain when it's very likely the same overall effect could be had without using that link? Not very. And as you say, the examples given are really poor; they're barely exploits, that's more like a really unwise feature - it's hard to imagine situations like this arising in practice by accident without being more easily exploitable without even using WASM in the first place - I mean, if you're processing data in a some way and your interface with that processing code includes stuff like eval, that's just a disaster waiting to happen - as web exploits over the decades have demonstrated again, and again.
magicalist 6y ago
> You can take over the browser by chaining exploits. Sections 5.1 and 5.2 show two examples. 5.1 is XSS due to using document.write with a user provided string. That's not taking over the browser and is very much possible from JS (it's basically the prototypical XSS example from well before there was wasm). 5.2 is more serious but in node, not the browser, and is barely a chain (two exploits?). It's a way to get a string to eval() if eval() is available in one of the indirect functions. I think the authors also overstate the benefits of ASLR in that case. If that same code was running natively in a server and exposed to direct user input like that, it's very possible an RCE could be made to work. These examples are simple by design since they're just demonstrations that it's possible, so more sophisticated attacks are possible, but we also shouldn't over extrapolate from them.
- chubot 6y ago
  Yeah I wasn't precise enough, I wrote a better summary here: https://news.ycombinator.com/item?id=26996738 https://news.ycombinator.com/item?id=26996738 tl;dr A bad case is if something like Figma stores your credit card info on the server. If they have a buffer overflow + document.write() of HTML derived from wasm code, the person who controls the image data could steal your credit card info. This is basically example 5.1; Figma is a huge chunk of C++ compiled to wasm, which may process images from other users.
stefan_ 6y ago
It's a meaningless point in the chain. Browser security is not intended to be only for running "trusted" or known JavaScript or WebAssembly code and hence competitions like Pwn2Own are perfectly happy to have you navigate to your own page that then runs whatever WASM or JS you want. Nobody requires you to first find an XSS on HN for your exploit because getting someone to load a random page is an extremely low barrier.

wernercd 6y ago

"unless you can chain it" Isn't that the GOTO for vulnerabilities these days? Saying "unless" means "when" in reality...

daniellehmann 6y ago

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.

modeless 6y ago
Agreed. Wow, Ethereum 2.0 has wasm support? I hope nobody is writing smart contracts in C++...
- CyberDildonics 6y ago
  You should look at what people actually write 'smart contracts' in. It is so bad it seems like a parody of what you would actually want to do.