[PATCH] Adding diversity for security

[Alp Toker]

On 24/01/2014 03:49, Sean Silva wrote:
>
>
>
> On Thu, Jan 23, 2014 at 10:07 PM, Alp Toker <alp at nuanti.com 
> <mailto:alp at nuanti.com>> wrote:
>
>
>     On 24/01/2014 01:08, Sean Silva wrote:
>
>         Was there ever consensus that we want to maintain this in
>         LLVM? I just looked back at the original thread on llvmdev,
>         and it looked like basically:
>
>         - A number of security folks having an inconclusive,
>         wandering, back-and-forth discussion about various security
>         things that should have been done on a security mailing list.
>         - Lots of "this seems maybe interesting, but ..." with the
>         "but ..." not clearly addressed in any way. Often times the
>         "but ..." was an alternative approach that would be more
>         maintainable, effective, and/or fit in better with existing
>         deployment processes.
>         - No concrete use cases.
>
>
>     It's a killer feature for anyone who has to support copy
>     protection mechanisms in commercial software.
>
>
> This was not brought up in the original discussion thread, and seems 
> outside the scope of what the Irvine team is working on. Per Larsen 
> said that they were working under these two programs 
> <http://www.darpa.mil/Our_Work/I2O/Programs/Clean-slate_design_of_Resilient_Adaptive_Secure_Hosts_(CRASH).aspx 
> <http://www.darpa.mil/Our_Work/I2O/Programs/Clean-slate_design_of_Resilient_Adaptive_Secure_Hosts_%28CRASH%29.aspx>> 
> and 
> <http://www.darpa.mil/Our_Work/I2O/Programs/Mission-oriented_Resilient_Clouds_(MRC).aspx 
> <http://www.darpa.mil/Our_Work/I2O/Programs/Mission-oriented_Resilient_Clouds_%28MRC%29.aspx>> 
> which have no connection with copy protection.

The patch on cfe-commits was pinged without much context or background 
so that's useful to know.

>
>
>     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.
>
>
> I'd be amazed if such a trivial code modification would fool crackers 
> (and you certainly don't need a CSPRNG for that use case). Joe (CC'd), 
> I know you guys at Arxan have a lot of experience with this kind of 
> thing. Can you maybe give some input on this patch from a copy 
> protection perspective?

The feature is sufficient to decisively thwart the recent trend of 
"farming" sites that crawl, scrape and reapply cracks within hours of 
each new point release. These automated attacks will never do 
decompilation or analysis -- they just search and replace byte patterns.

Reverse engineers aren't cheap to hire and these sites are only 
profitable because they're automated.

>
>     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.
>
>
> I'm not saying that you're wrong, but I think that this needs to be 
> discussed; there was a fairly lengthy thread about this "diversity for 
> security" thing a while back, and nobody seemed to bring up this facet 
> of the functionality.
>
>
>
>         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.
>
>
> Maybe such a feature doesn't belong in an open-source project then ;)
>
> Neither of the two use cases you mentioned seem to be even remotely 
> related to the actual intent of this patch as described by its 
> authors. In Stephen's original email he describes it as "This 
> diversity prevents
> code-reuse attacks such as return-oriented-programming (ROP) by
> denying the attacker information about the exact code layout."

Sounds fascinating.

>
> Irvine team, is am I understanding this correctly? Or is the use case 
> Alp is describing something that you are aiming for and would be 
> willing to support?
>
>
>
>
>
>         It seems like basically nobody who participated in the
>         original discussion on llvmdev is participating in this patch
>         review either. Especially the people who had doubts don't seem
>         to be participating; those doubts need to be addressed.
>
>
>     Having spent the day cleaning up dubious code that LLVM developers
>     themselves landed and walked away from, this patch makes a
>     refreshing change: a high quality contribution with responsive
>     author that succinctly implements a "killer feature" for many of
>     our users in very few lines of code.
>
>
>
>         Also, at the very least, adding the RNG should be split out
>         into a separate patch.
>
>
>     Why? We usually land supporting facilities together with the first
>     use for ease of review and testing.
>
>
> Especially for integrating with foreign code, we do separate patches 
> (even sometimes separate discussions on llvmdev), consult e.g. the 
> additions of MD5 and zlib.

The RNG in the patch is a small class with LLVM's existing MD5 
implementation being the only dependency.


>
> Maybe if the "supporting facilities" is a helper function it can be 
> done inline, but for anything larger (i.e. it's its own independent 
> functionality) it's usually best to split out an incremental patch 
> that can get a focused review.

If there if we had crypto experts on the list they'd have taken a look 
by now. We have to trust contributors' domain expertise at some point 
otherwise we'll be limited forever to what we already know.

>
>
>     I think this is ready to go once we hear from the developers that
>     there's a commitment to supporting the new scheduler.
>
>
> This definitely needs more discussion. Please hold back.

I'm not much into these academic discussions but I'll let you guys hash 
it out if you want to discuss the papers :-)

I am into useful features though and I'm satisfied that the "jumble up 
production builds" use mode will benefit a broad section of our users in 
clang.

Alp.

-- 
http://www.nuanti.com
the browser experts