[PATCH] Adding diversity for security

[Alp Toker]

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.

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