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

[PaX Team]

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?

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