> We just saw how trivial it is to stitch together shreds of existing code to do our dirty work. We barely scratched the surface: with just a few gadgets, any computation is possible. Furthermore, there are tools that mine libraries for gadgets, and compilers that convert an input language into a series of addresses, ready for use on an unsuspecting non-executable stack. A well-armed attacker may as well forget executable space protection even exists.
> Therefore, I argue executable space protection is worse than nothing. Aside from being high-cost and low-benefit, it segregates code from data. As Rob Pike puts it:
> This flies in the face of the theories of Turing and von Neumann, which define the basic principles of the stored-program computer. Code and data are the same, or at least they can be.
> Executable space protection interferes with self-modifying code, which is invaluable for just-in-time compiling, and for miraculously breathing new life into ancient calling conventions set in stone.
This is an absolutely unnecessary and totally specious line of reasoning. I worked for 6.5 years on V8 and can say with strong confidence that 99.9% of remote execution vulnerabilities that we saw in the field were because of RW executable memory. We did a lot of work to make write-execute exclusion fly in V8 for JavaScript code, without a major performance penalty, and that massively reduced this attack surface. That only works because we could totally quiesce JavaScript code while the JIT modified executable memory and flipped permissions from RW to RX. Yet other attack surfaces remain. In particular, V8 still needs RWX JIT code for Wasm, because tiering and parallel compilation. Guess where attackers learned to get the one remaining source of RWX memory? Yeah, just make an empty Wasm module. And for the record, that doesn't mean they were exploiting bugs in the Wasm engine, just using it to get some memory that is RWX that they can overwrite through some other bug.
This article, though great on specific technical details about ROP, is terrible security advice. It is not theater to reduce attack surfaces. Take away an attack surface and yeah, attackers will find a new one. But it acts like a filter; if you make it 10x harder, you get 10x fewer exploits. It raises the bar.
And for the record, though I didn't look at every single one, I never did, in fact, see a ROP exploit against Chrome except as part of some hackathon or pwn-to-own. Attackers were just walking in the front door when you have RWX!