[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