[PATCH] Adding diversity for security

[Sean Silva]

On Thu, Jan 23, 2014 at 11:11 PM, Per Larsen <per.larsen at gmail.com> wrote:

> re. integrating with the community: this is certainly something we're
> willing to do. when i mentioned that we have funding through 2015, what i
> wanted to communicate is that we're not going to dump this patch and
> disappear from the llvm community :)
>

Great. It will definitely be beneficial to get your feet wet with some
smaller patches; at the end of the day patches speak louder than words ;)

>
> re. copyright protection: diversity has indeed been positioned against a
> defense against piracy [1]. that being said, i think the current diversity
> patch will make complicate cracking but certainly not make it impossible.
>

Alp seems to be suggesting that this patch is worth committing solely on
the basis of the copy-protection/obfuscation use case, do you agree with
that? It seemed like you guys had a pretty specific (and different) use
case in mind.


> a secondary effect of nop insertion is that the resulting binary has an
> unique pattern that facilitates tracing pirated software back to the source.
>

This seems to suggest that every download is individually "watermarked" by
a nop pattern. It seems extremely impractical to have to go through CodeGen
to generate each one though. Or am I misunderstanding how this is meant to
be used/deployed? Alp's use case seems to be that the seed is varied
per-release, rather than per-deployment (per-"download").

-- Sean Silva



> (note that removing the nop pattern without breaking or slowing down the
> program is very hard due to the difficulties of disassembly.) we'll
> certainly support this use case if need be.
>
> beyond the two above mentioned uses, diversity complicates/protects patch
> reverse engineering [2] and attacks against just-in-time compilers too [3].
> again, i'm not claiming that nop insertion is ideal in these cases, my
> point is rather that diversity is indeed a multi-pronged defense.
>
> cheers,
> per
>
> [1] http://dl.acm.org/citation.cfm?id=1029157
> [2] http://dl.acm.org/citation.cfm?id=2400683 <http://dl.acm.org/citation.cfm?id=2400683>
> [3] http://dl.acm.org/citation.cfm?id=2516675
> (if you cannot access these articles through acm, google for the title to
> download them from the author's home page.)
>
>
> On Thu, Jan 23, 2014 at 7:49 PM, Sean Silva <silvas at purdue.edu> wrote:
>
>>
>>
>>
>> On Thu, Jan 23, 2014 at 10:07 PM, Alp Toker <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>
>> and <
>> http://www.darpa.mil/Our_Work/I2O/Programs/Mission-oriented_Resilient_Clouds_(MRC).aspx>
>> which have no connection with copy protection.
>>
>>
>>> 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?
>>
>>>
>>> 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."
>>
>> 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.
>>
>> 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.
>>
>>
>>> 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.
>>
>> -- Sean Silva
>>
>>
>>>
>>> Alp.
>>>
>>>
>>>
>>>> -- Sean Silva
>>>>
>>>>
>>>>
>>>> On Thu, Jan 23, 2014 at 6:08 PM, Julian Lettner <
>>>> julian.lettner at gmail.com <mailto:julian.lettner at gmail.com>> wrote:
>>>>
>>>>       Move patch forward to ToT.
>>>>
>>>>     Hi rinon, ahomescu,
>>>>
>>>>     http://llvm-reviews.chandlerc.com/D1802
>>>>
>>>>     CHANGE SINCE LAST DIFF
>>>>     http://llvm-reviews.chandlerc.com/D1802?vs=6581&id=6621#toc
>>>>
>>>>     Files:
>>>>       include/llvm/CodeGen/CommandFlags.h
>>>>       include/llvm/MC/MCRegisterInfo.h
>>>>       include/llvm/Support/RandomNumberGenerator.h
>>>>       include/llvm/Target/TargetOptions.h
>>>>       lib/CodeGen/LLVMBuild.txt
>>>>     lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp
>>>>       lib/LTO/LTOCodeGenerator.cpp
>>>>       lib/LTO/LTOModule.cpp
>>>>       lib/Support/CMakeLists.txt
>>>>       lib/Support/RandomNumberGenerator.cpp
>>>>       lib/Target/X86/CMakeLists.txt
>>>>       lib/Target/X86/NOPInsertion.cpp
>>>>       lib/Target/X86/X86.h
>>>>       lib/Target/X86/X86TargetMachine.cpp
>>>>       test/CodeGen/X86/nop-insert-percentage.ll
>>>>       test/CodeGen/X86/nop-insert.ll
>>>>       test/CodeGen/X86/sched-rnd-test.ll
>>>>       tools/llc/llc.cpp
>>>>       tools/llvm-lto/llvm-lto.cpp
>>>>       tools/lto/lto.cpp
>>>>       tools/opt/opt.cpp
>>>>
>>>>     _______________________________________________
>>>>     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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> llvm-commits mailing list
>>>> 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/20140124/b8bae594/attachment.html>