[LLVMdev] Adding diversity for security (and testing)

[Stephen Crane]

Thanks for all the feedback! It seems there is some interest, so I thought I'd try to summarize discussions so far, and provide patches for closer inspection. I'm not sure if patches should end up here or on a different list in this instance, so if I should instead send this to a different list, I'm happy to do so.

- Is diversity needed, or are existing protections sufficient? As several people have mentioned, industry adopters need very low overhead in many situations, and diversity might be a good fit here. Ultimately diversity is just one piece of the whole security puzzle, and could be combined with other techniques for increased assurance. There did not seem to be a strong consensus in this discussion about whether diversity is critical, although it appears that existing static analysis tools are insufficient to cover all cases.

- Distribution. Distributing large numbers of randomized variants to end-users could be difficult. Prelink diversification was mentioned, which may be a good direction to go with this for the future. However, a basic implementation in LLVM would provide a good starting point for future improvements. This implementation would also provide a useful security measure now for users who are already compiling their own software.

- Security. As was pointed out, diversity is not a perfect solution, and could be bypassed through the use of memory disclosures and scripting. However, this is certainly much harder for the attacker to pull off. In addition, existing security techniques should be used alongside diversity for defense-in-depth.

- Random number generation. Discussions established that the use of some sort of an internal RNG is required for reproducibility. The use of a cryptographically secure RNG is considered best-practice for any randomness used for security purposes. Since the RNG we are proposing is still very fast, there doesn't appear to be a significant disadvantage to using it. We do need a fallback RNG when OpenSSL is unavailable, and have therefore included a simple LCG as well.

I have attached our current patches against r190882, as well as a bit of documentation. Not sure what the next steps here are, but feel free to test out the code and let us know how it goes.

- stephen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: USAGE
Type: application/octet-stream
Size: 995 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130919/65136070/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm_diversity.diff
Type: application/octet-stream
Size: 58397 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130919/65136070/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang_diversity.diff
Type: application/octet-stream
Size: 7036 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130919/65136070/attachment-0002.obj>