This seems to simply be rehashing known problems - an incorrect program compiled to wasm won’t lose any of its security bugs.
The important restriction is that a totally compromised wasm application cannot compromise the browser, because wasm is designed on the assumption that all wasm programs are malicious, so that even an intentionally malicious app can’t break the browser sandbox.
So its wrong to think that wasm will make your own application secure, all you can say is that it should not be able to compromise the host environment.
How much is this shifting the goal posts in attributing missing defences to WASM when the problems are more inherent to the unsafe languages that are compiled to WASM and how this is done? What promises that WASM is making are being broken?
WebAssembly describes a memory-safe, sandboxed execution environment that may even be implemented inside existing JavaScript virtual machines. When embedded in the web, WebAssembly will enforce the same-origin and permissions security policies of the browser.
The FAQ on security makes it feel like your C/C++ apps will suddenly be more secure:
Memory Safety
Compared to traditional C/C++ programs, these semantics obviate certain classes of memory safety bugs in WebAssembly. Buffer overflows, which occur when data exceeds the boundaries of an object and accesses adjacent memory regions, cannot affect local or global variables stored in index space, they are fixed-size and addressed by index. Data stored in linear memory can overwrite adjacent objects, since bounds checking is performed at linear memory region granularity and is not context-sensitive. However, the presence of control-flow integrity and protected call stacks prevents direct code injection attacks. Thus, common mitigations such as data execution prevention (DEP) and stack smashing protection (SSP) are not needed by WebAssembly programs.
It does go on to say:
Nevertheless, other classes of bugs are not obviated by the semantics of WebAssembly.
My takeaway is basically: Are programs written in unsafe languages unsafe when running on WASM? Yes, but now you have an entirely new set of attack vectors (XSS for example) that you need to worry about. And you have to worry about them in spite of the security claims made by the WASM docs.
My takeaway is basically: Are programs written in unsafe languages unsafe when running on WASM? Yes, but now you have an entirely new set of attack vectors (XSS for example) that you need to worry about. And you have to worry about them in spite of the security claims made by the WASM docs.
I agree with you that this shows that unsafe applications can still be unsafe in WASM. However, due to the design of WASM there are a number of vulnerabilities that no longer exist. My takeaway from this paper is that the design decisions in WASM are just a tradeoff, since certain vulnerabilities are opened up again which are “solved” with native applications.
From my (potentially naive) point of view, it seems easy enough for future iterations of WASM to include segmented memory with protection bits. That would seem to eliminate a number of the now exposed vulnerabilities in current WASM. The stack overflow vulnerabilities also seem solvable in future iterations. Some of the other issues might be more inherent to having a linear memory space, so we might need alternative solutions.
It is concerning that the security claims made by the WASM docs don’t include warning of these potential issues. In general, however, I do think WASM stands by its promise of a (fairly) safe, sandboxed environment. This shows that you do still have to be careful, and imo exposing something like eval to a WASM module is a serious mistake in the first place.
This is actually a pretty cool writeup. IMO the safety of webassembly comes mainly from the VM being sandboxed and API letting wasm programs reach outside of it being deny-by-default and heavily capability-based (in the case of WASI at least). That hopefully limits the impact of attacks more than the capability to commit an attack itself. In terms of the file write attack in section 5.3, that would translate to the program having a (very) limited choice of which files it can actually write to; overwriting "file.txt" with "/root/.ssh/authorized_keys" would not give you access to that file unless the VM permits it to you.
That said, this is neat ‘cause hopefully we can harden wasm against some of these attacks now that we know what’s possible. I’d particularly like multiple memory spaces for stack and heap, and the ability to set them read-only.
I agree with you here. It seems that multiple memory segments are in the pipeline for WASM, but I wasn’t able to find anything about protection bits. If the next iteration of WASM had multiple segments which can be set to read-only, that seems like it would address most of the vulnerabilities in the paper.
This seems to simply be rehashing known problems - an incorrect program compiled to wasm won’t lose any of its security bugs.
The important restriction is that a totally compromised wasm application cannot compromise the browser, because wasm is designed on the assumption that all wasm programs are malicious, so that even an intentionally malicious app can’t break the browser sandbox.
So its wrong to think that wasm will make your own application secure, all you can say is that it should not be able to compromise the host environment.
How much is this shifting the goal posts in attributing missing defences to WASM when the problems are more inherent to the unsafe languages that are compiled to WASM and how this is done? What promises that WASM is making are being broken?
I don’t really see it as goal post shifting. IMO it’s more of a cautionary tale: Unsafe applications still unsafe in WASM.
Front and center on the wasm site:
The FAQ on security makes it feel like your C/C++ apps will suddenly be more secure:
It does go on to say:
My takeaway is basically: Are programs written in unsafe languages unsafe when running on WASM? Yes, but now you have an entirely new set of attack vectors (XSS for example) that you need to worry about. And you have to worry about them in spite of the security claims made by the WASM docs.
I agree with you that this shows that unsafe applications can still be unsafe in WASM. However, due to the design of WASM there are a number of vulnerabilities that no longer exist. My takeaway from this paper is that the design decisions in WASM are just a tradeoff, since certain vulnerabilities are opened up again which are “solved” with native applications.
From my (potentially naive) point of view, it seems easy enough for future iterations of WASM to include segmented memory with protection bits. That would seem to eliminate a number of the now exposed vulnerabilities in current WASM. The stack overflow vulnerabilities also seem solvable in future iterations. Some of the other issues might be more inherent to having a linear memory space, so we might need alternative solutions.
It is concerning that the security claims made by the WASM docs don’t include warning of these potential issues. In general, however, I do think WASM stands by its promise of a (fairly) safe, sandboxed environment. This shows that you do still have to be careful, and imo exposing something like
evalto a WASM module is a serious mistake in the first place.This is actually a pretty cool writeup. IMO the safety of webassembly comes mainly from the VM being sandboxed and API letting wasm programs reach outside of it being deny-by-default and heavily capability-based (in the case of WASI at least). That hopefully limits the impact of attacks more than the capability to commit an attack itself. In terms of the file write attack in section 5.3, that would translate to the program having a (very) limited choice of which files it can actually write to; overwriting
"file.txt"with"/root/.ssh/authorized_keys"would not give you access to that file unless the VM permits it to you.That said, this is neat ‘cause hopefully we can harden wasm against some of these attacks now that we know what’s possible. I’d particularly like multiple memory spaces for stack and heap, and the ability to set them read-only.
I agree with you here. It seems that multiple memory segments are in the pipeline for WASM, but I wasn’t able to find anything about protection bits. If the next iteration of WASM had multiple segments which can be set to read-only, that seems like it would address most of the vulnerabilities in the paper.