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

[PaX Team]

On 5 Jan 2015 at 20:40, Chandler Carruth wrote:

> On Mon, Jan 5, 2015 at 8:27 PM, PaX Team <pageexec at gmail.com> wrote:
> 
> > what i question is whether this 'harder' property exists
> > at all, and even if it does, in what situation it holds exactly.
> >
> 
> You have already stated at least one circumstance where it exists: where
> things are not restartable (above some limit) or where the other
> requirements of BROP aren't satisfied.

in those situations it's not the property of nop insertion but that of
the attacked system. put another way, other methods as simple as ASLR
also achieve the same level of security in those cases. if you want to
show that nop insertion has some security benefit then you'd have to
show a bug/exploit situation where the following two conditions hold:

1. the bug is exploitable without nop insertion in the attacked program
2. the bug is not exploitable with nop insertion in the attacked program

so far nobody described such an example. once that's done we can then
evaluate two more conditions:

3. is the situation relevant enough in real life?

4. is nop insertion the most performant way to achieve the claimed
security benefit?

i also said that for such cases there were better (=smaller performance
impact) ways to achieve the same level of security. in other words, i
don't see in what situation nop insertion beats or helps other methods.

> I don't understand why we shouldn't add a nice, working mitigation strategy
> that at least some security folks have found value in to the set of tools
> available with the compiler

i obviously won't tell you or anyone what to do or not do ;), but i'll
raise questions about what i think is a misunderstanding of benefits. you
just called nop insertion a 'nice, working mitigation strategy' but so
far noone described a situation where that's true (see my above points).

and i'm not sure what 'security folks' you're thinking of but i don't
recall anyone in the industrial circus of security (=the people who actually
write the exploits) who agrees with this assessment.

> I also don't see why we should reject this form of diversified binary
> production because there might some day be a contribution of a better
> strategy. That sounds like perfection being the enemy of the good here.

if i'm not mistaken the very folks behind nop insertion have already created
that better method (they called it 'schedule randomization' in their original
mail back in 2013) so the better question to ask is why that method was not
submitted instead of nop insertion.