[PATCH] Adding diversity for security
Alp Toker
alp at nuanti.com
Fri Jan 24 19:30:36 PST 2014
On 25/01/2014 02:54, Sean Silva wrote:
>
>
>
> On Fri, Jan 24, 2014 at 3:33 PM, Alp Toker <alp at nuanti.com
> <mailto:alp at nuanti.com>> wrote:
>
>
> On 24/01/2014 20:20, Stephen Crane wrote:
>
> On Fri, Jan 24, 2014 at 10:58 AM, Daniel Berlin
> <dberlin at dberlin.org <mailto:dberlin at dberlin.org>> wrote:
>
> On Thu, Jan 23, 2014 at 7:07 PM, Alp Toker <alp at nuanti.com
> <mailto: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
>
>
>
> Hi Stephen,
>
> That's a good observation. Clearly there are multiple use cases
> for the feature which is a good indicator that it has a place in a
> general-purpose backend like LLVM.
>
> I don't want to trivialise your work and its significance in the
> security field, but if I can get a few nops out of it that's
> already something that makes my life easier so I'm willing to
> support the effort and put in resource from our end (both as a
> commercial entity, and personally as a developer on the project)
> if we decide to go with this.
>
> There's every indication that a little unpredictability will go a
> long way to preventing the simplistic binary patching used in
> production-line software piracy operations. If we save 100 units
> from now to 2015 that already justifies the time we'd put into
> helping maintain the code with you upstream.
>
>
> Hi Alp,
>
> There seems to be significant disagreement whether what you describe
> is actually a real threat at all.
Yours is the first disagreement I've seen.
If the contents of two similar builds A and B are made to vary then the
binary patch developed for A will fail to apply to B without some degree
of effort or analysis.
Similarly if I share a developer preview of A with a third party and it
shows up online, this gives me a good shot at guessing who did it and
not trusting them next time round.
These aren't about copy protection -- they're simple properties that
appear to have real world uses that exceed the original intent. They
apply equally to Open Source, mixed and proprietary builds.
As I see it, the gold standard for a feature is one that has use cases
exceeding the original specification and intent. It's an indication that
the feature will serve as a building block for other facilities.
> Could you maybe provide some references or rope in another interested
> party? At this point you seem to be the only person getting behind
> this patch as a "killer feature" for copy protection.
I think either the statements above are trivially valid and make sense,
or we've missed something and the use case doesn't hold, in which case
the patches are blocked again.
I could rope in plenty of people but that doesn't seem like a good way
to answer the question at hand. We have all the facts and we should be
able to figure it out for ourselves.
Alp.
>
> -- Sean Silva
>
>
> The patches look tidy and I feel it'll be a pleasure to work on.
>
> Alp.
>
>
>
>
> ,
> 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
>
>
> --
> http://www.nuanti.com
> the browser experts
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
--
http://www.nuanti.com
the browser experts
More information about the llvm-commits
mailing list