[PATCH] Insert random noops to increase security against ROP attacks (llvm)

[Stephen Crane]

Hi all,

I completely agree that Blind ROP and JIT-ROP have the potential to
bypass diversity. However, these attacks are significantly harder than
conventional ROP and have additional requirements (restarting service
and client-side scripting respectively). If the requirements for blind
probing or memory disclosure are not possible, then diversity is a
strong protection. Additionally, utilizing fine-grained diversity
significantly increases the workload for a successful attack, which I
think is worthwhile for some use-cases.

In general, I think fine-grained diversity is a necessary and gradual
evolution of ASLR. ASLR raises the bar for an attack, but since ASLR
is vulnerable to a single pointer disclosure, it has been successfully
bypassed in the wild. Fine-grained diversity requires disclosure (or
probing) of the code segment, which is significantly harder.

On Mon, Jan 5, 2015 at 8:27 PM, PaX Team <pageexec at gmail.com> wrote:
> 1. nop insertion affects gadgets (=removes them) that would use unintended
> byte sequences (i.e., where the sequence starts in the middle of an intended
> insn, not at its first byte) *and* that cross the boundary of intended insns.
>
> this is a subset of all gadgets present in the binary and i didn't see the
> case made that this subset is substantial to the point that the remaining
> gadgets are not enough to perform an exploit (in fact the paper kinda admits
> that that is not the case in fact). combine it with BROP or in-process browser
> exploits and you see that nop insertion didn't add much security in general.

I agree. But the fact that an attack must now include a (complex, imo)
memory disclosure step raises the bar for attackers. Diversity isn't
secure in the face of full memory disclosure, but it does shuffle the
locations of gadgets, forcing this memory disclosure, when that's even
possible.

NOP insertion is just a simple start to fine-grained diversity. We've
implemented more involved randomizations, such as function/BB
shuffling and register allocation randomization, and will be cleaning
up and reviewing these techniques if people are interested.

> 2. i'm not sure what combinations you meant but whatever i can think of
> (ASLR, NX pages, CFI, etc) are all already strong (or weak) enough on their
> own, nop insertion doesn't change the cost/benefit equation in any significant
> way (again i refer to the BROP paper that describes how much it takes to
> perform the BROP attack).

I think the middle spot we're aiming against is attacks which can
disclose a pointer and therefore bypass ASLR, but are unable (or
unwilling due to difficulty) to disclose or brute-force the entire
code segment. The utility of this defense relies not in making all
attacks impossible, but in making them significantly harder, just like
ASLR.

Finally, as a side benefit, we're hoping that emitting randomized
machine code might be useful for teasing out performance and
correctness bugs in both the compiler and less mature target
architectures.

(completely shameless plug, but might actually be useful:) For anyone
who's interested in this area and looking for an in-depth overview of
the topic, I would also recommend a paper that several of my
colleagues published in IEEE S&P last year:
http://www.ics.uci.edu/~perl/automated_software_diversity.pdf

- stephen