Re:WebAssembly doesn’t make unsafe languages safe
by pjmlp on Sunday November 25, 2018 @04:48PM
(#18529274)
If WebAssembly had tagged pointers that could be avoided, as proven by Solaris for SPARC with ADI in production.
Because when something is possible in security attacks, it will eventually be exploited.
Re:WebAssembly doesn’t make unsafe languages safe
by pcwalton on Sunday November 25, 2018 @04:55PM
(#18529304)
ADI doesn't seem to me to have enough bits to effectively protect against vtable type confusion.
Besides, nothing stops a wasm compiler from emitting such checks itself, if it wants to.
Re:WebAssembly doesn’t make unsafe languages safe
by pjmlp on Monday November 26, 2018 @12:08AM
(#18531210)
Not sure about that, it does seem quite effective, though.
Having the compiler emiting it wouldn't be an option, as hardware enabled solutions seem to be the only ones accepted by C devs, as shown by SPARC and now ARM.
Re:WebAssembly doesn’t make unsafe languages safe
by sitkack on Friday November 30, 2018 @08:23PM
(#18574362)
I think there is the possibility of integrating the source maps and the WASM with special purpose execution envs to apply these checks.
Re:WebAssembly doesn’t make unsafe languages safe
by indolering on Monday November 26, 2018 @11:48PM
(#18539468)
Wouldn't this require hardware support in the underlying chip or (inevitably) slow emulation of tagged pointers?
Re:WebAssembly doesn’t make unsafe languages safe
by hackcasual on Sunday November 25, 2018 @07:33PM
(#18530054)
You can overwrite vtable pointers, but you're further restricted to calling another function of the same type signature.
* ROP should be impossible in Web Assembly, because the call stack is a separate stack, inaccessible from the heap and effectively invisible to the program.
* For the same reason, classic buffer overflow attacks involving attacker-supplied machine code are impossible. In addition, Web Assembly bytecode is never mapped into the heap, so attackers cannot inject shellcode via the usual methods.
* Mmap functionality is proposed for the future [1], which would allow for the implementation of guard pages. (Guard pages are fairly weak defenses anyway...)
I'm sure that it's possible to attack a Web Assembly program's control flow by overwriting vtables and function pointers and taking advantage of the resulting type confusion. But it's significantly more difficult than it is in native code.
[1]: https://github.com/WebAssembly/design/blob/master/FutureFeat...