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

[Mehdi Amini]

> On Jan 5, 2015, at 7:13 PM, PaX Team <pageexec at gmail.com> wrote:
> 
> On 5 Jan 2015 at 19:04, Chandler Carruth wrote:
> 
>> On Mon, Jan 5, 2015 at 6:53 PM, PaX Team <pageexec at gmail.com> wrote:
>> 
>>> On 5 Jan 2015 at 16:32, Stephen Crane wrote:
>>> 
>>>> In a nutshell, the idea is to create functionally equivalent copies of
>>>> the software with different code layouts to prevent attackers from
>>>> knowing where the code they want to reuse is located.
>>> 
>>> isn't it defeated by BROP and other techniques?
>>> 
>>> http://crypto.stanford.edu/~dabo/pubs/abstracts/brop.html
>>> http://www.scs.stanford.edu/~sorbo/brop/bittau-brop.pdf
>>> http://www.ieee-security.org/TC/SP2013/papers/4977a574.pdf
>> 
>> 
>> I'll let Stephen and others speak for themselves, but to throw out my 2
>> cents -- this still seems to be a reasonable component of a
>> defense-in-depth approach. In particular, it is another hurdle that must be
>> cleared, raising the bar for any potential attacker.
>> 
>> Put another way, just because stack canaries can be defeated doesn't, IMO,
>> remove their value. I put this in the same bucket. This makes a certain
>> class of attacks substantially more difficult or expensive to carry out.
> 
> that's exactly what i'm wondering about: what is that class of attacks?
> blind ROP can discover gadgets remotely without knowing the exact code
> content. in-browser exploits can leak the same information and construct
> exploits on-the-fly. so where does the added random padding help exactly?

I don’t know the statistics on gadget presence in software in general, but something that I found interesting in https://www.ics.uci.edu/~ahomescu/multicompiler_cgo13.pdf is how figure 2 shows that inserting a nop between instructions reduce the possibility of finding gadgets on x86 because of the variable-length encoding.
This is orthogonal to the randomization part of the process, and could be done for all potential gadgets by the way (could be an option for this pass in LLVM).

— 
Mehdi

> 
> speaking of stack canaries, they haven't proven to be that useful in practice
> since even if we just consider straight stack buffer overflow bugs, there're
> general techniques to discover the random cookie (byte-by-byte brute forcing,
> infoleaks). if there's a saving grace for cookies then it's application specific
> input filtering that prevents the exploit payload from faking a necessary byte
> in the cookie...
>