[LLVMdev] Adding diversity for security (and testing)

Stephen Crane sjcrane at uci.edu
Wed Aug 28 14:36:11 PDT 2013


On 08/28/2013 12:01 PM, Stephen Checkoway wrote:
> 2. Local attacker who cannot read the contents of the binary. (This is a pretty strange one, but it's possible.) The attacker is forced to rely on side channel information such as timing channels in an attempt to discover the length of the inserted NOP sleds. This sounds like an extraordinarily difficult task, but possibly doable. With a weak PRNG like a LCG, for example, you may have sufficient information to break it [2] (I believe there are better attacks, but this is the first that came up with a quick search).
Hi Stephen,

Thanks for spelling out the possible attack models in detail. This is 
pretty much the way we were thinking. However, I wanted to make a minor 
clarification on our proposed implementation, just to be clear. Rather 
than inserting NOP sleds before functions, we actually insert various 
NOP-like instructions randomly between existing MachineInstrs, in order 
to provide more fine-grained diversity. This gives the attacker as 
little information as possible about the exact layout of the final 
binary. In terms of RNG selection, we were especially concerned about 
partial leakage of binary contents (or leakage of some but not all 
binary files from a build sharing the same seed) revealing the initial 
seed and therefore, by recompilation, the entire binary.

- Stephen Crane



More information about the llvm-dev mailing list