[PATCH] Adding diversity for security
Per Larsen
per.larsen at gmail.com
Thu Jan 23 20:11:45 PST 2014
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 :)
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. a
secondary effect of nop insertion is that the resulting binary has an
unique pattern that facilitates tracing pirated software back to the
source. (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/20140123/2cfa1b1c/attachment.html>
More information about the llvm-commits
mailing list