[PATCH] Adding diversity for security

Stephen Crane sjcrane at uci.edu
Fri Jan 24 12:20:55 PST 2014


On Fri, Jan 24, 2014 at 10:58 AM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
> On Thu, Jan 23, 2014 at 7:07 PM, Alp Toker <alp at nuanti.com> wrote:
> > It's a killer feature for anyone who has to support copy protection
> > mechanisms in commercial software.
>
> For exactly how many seconds will that last? :)
>
> >
> > Software "cracks" are smart enough to find and patch patterns even when
> > binaries change between releases, but nops and register shuffling will block
> > the kind of automated "farming" organised criminals use.
> >
> > A feature that's so easy to deploy (just switch compiler flag every point
> > release) is a valuable tool in giving the edge back to individuals and
> > companies who have to earn some or all of their living through commercial
> > software.
>
> Honestly, I think you are seriously overselling it, but that's not the
> main point i want to address:
> >
> >
> >> Who is going to be deploying this? If nobody is deploying, then how do we
> >> know it will be maintained? It seems like the initial patch submitter has
> >> already jumped ship on this patch; doesn't exactly inspire confidence.
> >
> >
> > Clearly the two use cases are copy protection and security through obscurity
> > so genuine users aren't going to be at liberty to join an open debate here.
>
> This I seriously disagree with.  Even on the GCC mailing lists, there
> were plenty of people who were copy protection folks who spoke up
> about features that were going to be deprecated or added.  The idea
> that "there are plenty of users, but they can't speak here" seems a
> bit suspect to me.  Saying "this feature would be useful to us" is not
> something that harms either of the sets of users you are talking
> about, since it's completely and totally obvious that they are doing
> it anyway. There is no obscurity at all

I think copy protection is a bit off-topic, but an interesting idea. I
would like to point out that we were originally not targeting this at
copy protection, and I think defending against code-reuse attacks is a
much stronger use case and a better fit. Creating differing binaries
could have interesting uses for watermarking, but we really haven't
thought about that much. However, by creating unpredictable binaries,
we can defend against code-reuse attacks since these attacks require
detailed knowledge of the attacked binary. This is not security
through obscurity, since the attacker cannot exploit our defenses even
if he knows to expect it. Instead, it more resembles protection by
blinding or encrypting secret values (in this case, the binary
layout).

As such, users who are interested in protecting against code-reuse
attacks such as return-oriented programming should be free to discuss
and promote diversity, since it is a legitimate defense.

- stephen



More information about the llvm-commits mailing list