[PATCH] Adding diversity for security

[Sean Silva]

On Fri, Jan 24, 2014 at 3:33 PM, Alp Toker <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>
>> 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
>>
>
>
> 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. 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.

-- 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
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140124/189d9eac/attachment.html>