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

[PaX Team]

On 5 Jan 2015 at 21:23, Stephen Crane wrote:

> 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).

how do you measure 'harder'? also you realize that 'restarting service'
describes about all remote services and 'client side scripting' describes
about all browsers, in other words, two of the most relevant real life
attack surfaces?

> If the requirements for blind probing or memory disclosure are not
> possible, then diversity is a strong protection.

yes but in those cases ASLR is strong enough (in fact ASLR by definition
has to prevent brute force), nop insertion doesn't add significant security
yet it costs performance.

> Additionally, utilizing fine-grained diversity significantly increases
> the workload for a successful attack, which I think is worthwhile for
> some use-cases. 

how do you measure workload? if you mean the entropy that has to be
recovered for a successful attack then ASLR has already more than enough.

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

ASLR is not vulnerable to a single pointer disclosure (since you repeated
this twice at least, i wonder where this myth comes from...).

what ASLR is vulnerable to (more precisely, wasn't designed to protect
against) are attacks that can also leak addresses *and* memory content
at those addresses (or when exploiting the bug doesn't even need an
address of course).

> Fine-grained diversity requires disclosure (or probing) of the code
> segment, which is significantly harder. 
[...]
> 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.

all this is true for ASLR already...

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

if i were you, i'd have submitted those other methods instead, especially
those without a performance impact.

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

ok, so this is the closest description so far for the situation where
your work makes a difference and my comment then is to concentrate on
methods that have no performance impact for practical purposes (i.e.,
not nop insertion but stuff like randomized register allocation, random
gaps between functions, basic blocks, stack variables, etc).

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

i know this paper and unfortunately it's not without faults either but
let's save that discussion for another time&place ;).