[LLVMdev] Adding diversity for security (and testing)

Stephen Crane sjcrane at uci.edu
Mon Aug 26 22:41:24 PDT 2013


On 08/26/2013 10:16 PM, Stephen Checkoway wrote:
> Putting on my security hat (as opposed to my 
> lurking-on-compiler-mailing-lists hat), note that artificial software 
> heterogeneity doesn't actually prevent ROP, it makes it harder in a 
> qualitatively similar way to ASLR. With ASLR, the attacker needs to 
> discover a single memory address in order to construct a 
> return-oriented program. What you're proposing requires reading out 
> more of the address space. A recent paper at Oakland proposed a 
> "just-in-time code reuse" attack that repeatedly uses a memory 
> disclosure and JITs an attack based on the results [1]. So while it 
> does make the attackers job harder, it doesn't prevent such attacks. 
> 1. Kevin Z. Snow, Fabian Monrose, Lucas Davi, Alexandra Dmitrienko, 
> Christopher Liebchen, and Ahmad-Reza Sadeghi. Just-In-Time Code 
> Resule: On the Effectiveness of Find-Grained Address Space Layout 
> Randomization. In Proceedings of the IEEE Symposium on Security and 
> Privacy ("Oakland") 2013. 
> <http://cs.unc.edu/~fabian/papers/oakland2013.pdf> 

Hi Stephen,

Great to see a fellow security researcher lurking on this list as well!

You raise a very valid point here. I quite agree that diversity is not 
guaranteed to prevent ROP. Very sorry -- I wasn't as careful in my 
original wording as I certainly should have been. In practice, we 
believe introducing variation significantly raises the bar for 
attackers, which is a big step in the right direction. For many 
applications this may be more than sufficient. However, diversity may 
not be good enough for all applications, particularly in the presence of 
possible remote memory disclosures.

- stephen



More information about the llvm-dev mailing list