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

[Chandler Carruth]

On Tue, Jan 6, 2015 at 6:06 PM, PaX Team <pageexec at gmail.com> wrote:

> On 6 Jan 2015 at 17:51, Stephen Crane wrote:
>
> > Exactly. That is a solved problem in exploit development. I assumed
> > that the attacker has a copy of the library. Fine-grained diversity
> > prevents an attacker from being able to have this copy, since his
> > version will differ from the target.
>
> this comes down to how binary diversification (not just nop insertion)
> will be deployed in real life. if we're talking about people compiling
> and deploying their own linux distros (think gentoo) without further
> public dissemination then this property can hold more or less. but if
> commercial companies will try this route, all an attacker has to do is
> collect a library of all deployed randomized binaries and we'll be back
> to square one (no, i don't see apple or google ever deploying a billion
> different OS images).


Perhaps you should let folks at Google decide what mitigation strategies
are useful to us? ;] I'm here on the thread saying that this is not without
value.

I would really like to stop debating whether this is worth having. It isn't
productive. Not everyone needs to believe this is worth having, the folks
contributing it and the folks reviewing and maintaining it as part of LLVM
do. It seems quite clear that is the case. Let's move on, and leave the
security experts at various organizations trying to harden various servers
to weigh the benefits of different mitigation techniques.

Do you have specific suggestions to improve this patch? (I know you've
mentioned that there are better ways to implement binary diversification,
but as I mentioned it is an express goal of LLVM to have incremental
development where we start with a simple version and expand on its
functionality iteratively. As a consequence, I don't think the fact that we
need to implement more advanced techniques is really a useful comment about
this patch.)

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150106/93be2093/attachment.html>