|
|
|
|
|
|
by afiori
2131 days ago
|
|
|
To my understanding one of the design constraints behind webassembly semantics where given by wanting to keep implementation burden low for browsers. In particular my understanding is that most of MVP WebAssembly almost a subset of asm.js in term of expressivity. Do some of the safety measures you consider translate well in this model? |
|
|
Yes, I think several mitigations could be deployed without requiring a change to the language, only by changing compilers and runtime libraries:
* Stack canaries on the unmanaged stack: For storing the reference canary value, you need some "safe" location that cannot be overwritten by regular memory writes. I believe in x86, thread local storage (TLS) / the fs segment register is used. In WebAssembly, one could use a non-mutable global scalar variable, which could only be overwritten by a matching global.set instruction (which cannot be inserted by an attacker). Then, before returning from a function (or really at any point you want to check the integrity of linear memory), you could compare the canary value against this global, as you would in native architectures.
* Allocator hardening, e.g., safe unlinking doesn't require any language support, the allocator just needs to do it (and live with the slightly increased code size cost).
Other mitigations would require language extensions. E.g., for finer grained control-flow integrity (taking source types into account, not just WebAssembly primitive types), one would require multiple table (part of the reference types proposal). Then, only functions with compatible types should be stored in the same indirect call table.
ASLR, unmapped pages, and constants in linear memory are harder, I believe. For ASLR, WebAssembly's 32-bit pointers will most likely provide too little entropy. Unmapped pages and "true constants" would require some host API to make portions of the memory non-writable/readable, but I don't know of any proposal to do so.
> wanting to keep implementation burden low for browsers
> WebAssembly almost a subset of asm.js
Yes, that is also my understanding as to why we are at the current situation. (But I did not take part in WebAssembly's design, so I cannot claim any authority.)