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

[PaX Team]

On 5 Jan 2015 at 20:05, JF Bastien wrote:

> > this is only true for gadgets that are composed of unintended byte
> > sequences (i.e,
> > where the redirected control flow jumps into the middle of intended insns)
> > and only
> > if such sequences cross intended insn boundaries. as you can see in the
> > paper, there's
> > no case where gadgets are eliminated altogether, only their numbers are
> > reduced and
> > that means that blind ROP will work against these binaries.
> 
> 
> Sorry, I'm kind of lost as to what you're arguing for/against. Could we
> back up a bit?
> 
> Do you think nop insertion is a poor mitigation on its own? Or do you think
> it's not useful even when combined with other mitigations?

yes for both. to elaborate:

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.

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'm also not clear on what kind of attack you're making assertions for:
> LLVM is used in many different situations, and adding tools such as this
> may be thoroughly useless in some situations and really useful in others.

i thought the attack model was clear from the paper: we're talking about the
exploitation of memory corruption bugs that give an attacker control over
some code pointer to redirect control flow at least once to a location of
her choosing. this location can be existing code in which case we're talking
about exploits based on code-reuse (née ret2libc) and nop insertion is supposed
to make that 'harder'. what i question is whether this 'harder' property exists
at all, and even if it does, in what situation it holds exactly.