[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