[PATCH] Adding diversity for security
Sean Silva
silvas at purdue.edu
Fri Jan 24 21:04:00 PST 2014
On Fri, Jan 24, 2014 at 10:30 PM, Alp Toker <alp at nuanti.com> wrote:
>
> 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.
>
C'mon man. Nadav, DannyB, and Joe all pretty much said "this isn't going to
work" for copy protection.
>
> 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.
>
It seems that for the use case you describe, there are so many simple ways
to accomplish what you want that it is almost meaningless to represent this
use case as a compelling motivation for adding this feature. I'm sure we
can e.g. have LLD add a build ID or even develop a simple purpose-built
feature to steganographically encode certain information in the binary, or
shuffle sections/functions (35 functions or sections can be ordered in 35!
(> 2^128) ways). I mean even GNU LD embeds a .note.gnu.build-id in all the
binaries it creates.
>
> 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.
>
This is really not the case. I don't feel like I have enough information to
make an informed opinion about whether the use case you describe even
*exists*, let alone whether this is the best way to approach it. At this
point you seem to be the only person participating in this discussion that
sees a threat consisting of (from what I can gather):
- "farms", which
- just blindly apply binary patches
- the cracks that they apply are basically just naive "sed"-style
replacements that are trivially fooled by almost any modification of the
binary
- that are a major source of lost revenue
-- Sean Silva
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140125/1d93c6a3/attachment.html>
More information about the llvm-commits
mailing list