64-Bit Linux Return-Oriented Programming

This is much more impressive: http://www.scs.stanford.edu/brop/bittau-brop.pdf

> Abstract—We show that it is possible to write remote stack buffer overflow exploits without possessing a copy of the target binary or source code, against services that restart after a crash. This makes it possible to hack proprietary closed-binary services, or open-source servers manually compiled and installed from source where the binary remains unknown to the attacker. Tra- ditional techniques are usually paired against a particular binary and distribution where the hacker knows the location of useful gadgets for Return Oriented Programming (ROP). Our Blind ROP (BROP) attack instead remotely finds enough ROP gadgets to perform a write system call and transfers the vulnerable binary over the network, after which an exploit can be completed using known techniques. This is accomplished by leaking a single bit of information based on whether a process crashed or not when given a particular input string. BROP requires a stack vulnerability and a service that restarts after a crash. We implemented Braille, a fully automated exploit that yielded a shell in under 4,000 requests (20 minutes) against a contemporary nginx vulnerability, yaSSL + MySQL, and a toy proprietary server written by a colleague. The attack works against modern 64-bit Linux with address space layout randomization (ASLR), no-execute page protection (NX) and stack canaries.

Seems to be a fairly reasonable introduction to binary exploitation, but at the end it concludes with the dubious “NX is counterproductive”. Turning off execution for regions that you really didn’t intend to be code is a good idea in general; JIT code generation is a rare case and warrants extra consideration. There’s multiple reasons why we do it: the first is that it’s cheap, but it also prevents you from straight-up writing code and instead having to rely on ROP (which, these days, is protected against by CFI). It’s even more useful in the presence of ASLR, as a “relative stack jump” without knowing the full slide is often easier than locating libc. It’s certainly not security theater like the article suggests; there is a reason why we have been investigating in further protections (shadow stacks, pointer authentication, etc) to further segregate code from data and even data from different kinds of data.

> Executable space protection requires special hardware (the NX bit) or expensive software emulation.

"Special hardware" is literally everywhere. It's more accurate to call it "special" if it doesn't support NX.

> Somebody must have thought so, because it is so prevalent now.

FWIW, those people (pippac iirc/ paxteam?) were well aware of ROP when they created it. It's sad how hard it is to find the original sources these days, the docs are all so old - someone can maybe find security.txt?

> One may ask: if executable space protection is so easily circumvented, is it worth having? > Somebody must have thought so, because it is so prevalent now. Perhaps it’s time to ask: is executable space protection worth removing? Is executable space protection better than nothing?

> 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!

Worth adding a (2012) here. The original ROP paper is also from 2012, I think.

This is black magic of the very highest level. Chaos magic if you will.

This article is obsolete, evidently written before 2016.

Don’t signed pointers in ARMv8.3 kill RoP chains or have we found ways around that?