[PATCH] Adding diversity for security

[Per Larsen]

hi nadav,

if i understand correctly, you are thinking of an offensive scenario where
nops are used to camouflage malware. i agree that its easy to generate
signatures by simply filtering nops out of the instruction stream. however
this is not so in defensive scenarios where the goal is to detect piracy or
thwart automated reversing/cracking. in particular, removing nops from a
binary requires disassembly which to my knowledge creates a non-negligible
overhead versus the performance of the original binary.

the security properties of nop insertion is well established in the
security community. modern attacks rely on code reuse rather than code
injection. code reuse attacks typically uses so called gadgets which are
short instruction sequences ending in a return. the attacker must know the
address of the gadgets for the attack to work. if we think about the first
gadget in a binary you are right that nop insertion may just create a sled
before it. however, subsequent gadget addresses are displaced by an amount
equal to the sum of all preceding nops; in other words, the more nops
inserted in front of a gadget, the greater the uncertainty in its location.
secondly, some gadgets are composed of unintended instructions (i.e.,
jumping into the middle of an instruction generated by the compiler) and
these gadgets are typically "broken/mutated" by nop insertion. our research
group, and others, have performed detailed studies using a set of purpose
built binary analyses to verify these effects. i recommend section 3 and
5.2 in [1] if you are interested in the gory details.

best,
per

[1] http://www.ics.uci.edu/~ahomescu/multicompiler_cgo13.pdf


On Thu, Jan 23, 2014 at 10:19 PM, Nadav Rotem <nrotem at apple.com> wrote:

>
> On Jan 23, 2014, at 9:57 PM, Alp Toker <alp at nuanti.com> wrote:
>
>
> The feature is sufficient to decisively thwart the recent trend of
> "farming" sites that crawl, scrape and reapply cracks within hours of each
> new point release. These automated attacks will never do decompilation or
> analysis -- they just search and replace byte patterns.
>
>
> Reverse engineers aren't cheap to hire and these sites are only profitable
> because they're automated.
>
>
> The original intent of the patch was to prevent Return-to-Program attacks,
> so this is slightly off-topic.  The security industry is a lot mode
> advanced than what you describe. It is really easy to remove NOPs in order
> to get signatures, and modern anti viruses do stuff like that. Actually,
> even if you completely change register allocation and scheduling other
> techniques would identify the code. For example tracking the order of
> system calls and/or library calls. Personally, I don't think that adding
> NOPs to the instruction stream is as useful as changing scheduling or
> register allocation because removing NOPs is easy. Also, by introducing
> NOPs you are increasing the landing area for ROP attacks. You simply have
> more code to jump into.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140123/b1db847f/attachment.html>