[llvm-dev] Random nop insertion pass

[Robinson, Paul via llvm-dev]

Hi folks!

At some point I had read a paper (which appears to have gotten lost in my last move) regarding NOP insertion to disrupt gadgets.  It identified gadgets in some lump of software, then rebuilt the software with random NOPs enabled, and proudly pointed to X% of the previous gadgets no longer being present, or usable, or something.
(To my mind this is not the right question; not “were previous gadgets disrupted” but “how many gadgets are there in the rebuilt software compared to the previous version?” If it’s known that the answer is “there is still an abundance of gadgets no matter what you do” then I’m answered, and thank you!)

I don’t know whether this would lead to any practical uses within Sony, but if we didn’t have a pass at all, there would be nothing to pursue. We had an intern on the compiler team who was also interested in security.  I remembered the NOP insertion pass that had been committed upstream but later reverted, so we gave him that pass to play with.  I was casually interested in my question above, of course, but there are plenty of software bits that we distribute online rather than on disks, so in principle there is potential for a possible use-case.  I may be stating that too strongly.
In the end, the intern didn’t quite get it working well enough, and I’ve had too many other things going on to want to pick it up myself.

So that’s where things stand today: one of those spare-time things that might be worth real resources someday.
And thanks for the pointer to the multicompiler project!
--paulr


From: Per Larsen <perl at immunant.com>
Sent: Thursday, November 21, 2019 7:26 PM
To: Stephen Checkoway <s at pahtak.org>
Cc: Robinson, Paul <paul.robinson at sony.com>; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Random nop insertion pass

Hi all,

To elaborate on what Stephen said, compile-time nop insertion is only effective if the adversary and victim have different versions of the same binary. This obviously creates difficulties w.r.t. binary distribution and subsequent updates*. That said, my colleagues and I at UCI did attempt to upstream a nop insertion pass into LLVM a couple of years ago. You can find patches for LLVM 3.8.1 that allow nop insertion and many other randomizing transformations here: https://github.com/securesystemslab/multicompiler (Some of these have been forward ported to LLVM 7 as well but I don't believe the code has been made public yet.)

Thanks,
Per

*We built a robust load-time randomizer that does function shuffling that works with off the shelf compilers and loaders, not sure if that's of interest in your case: https://github.com/immunant/selfrando

On Thu, Nov 21, 2019 at 4:01 PM Stephen Checkoway via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:


> On Nov 21, 2019, at 14:23, Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
>
> Some years ago there was a random-nop-insertion pass (for ROP gadget removal) proposed, which didn't stick; we recently had a summer intern work on it but did not get to proper quality; I'd like to revive that.

Hi Paul,

I'm curious about what the use case for this was. In the normal course of binary distribution of programs, the addition of nops doesn't affect ROP in any significant way. (For a while, inserting a nop before a ret broke ROPgadget's [1] ability to find interesting code sequences since it was looking for fixed sequences of instructions.)

I could imagine it being used for JITted code. If that was the use case in mind, did you happen to compare it to other randomized codegen?

I'm only curious because this has historically been an area of research of mine [2,3,4], not any sort of pressing matter.

Thank you,

Steve


1. https://github.com/JonathanSalwan/ROPgadget
2. https://checkoway.net/papers/evt2009/evt2009.pdf
3. https://checkoway.net/papers/noret_ccs2010/noret_ccs2010.pdf
4. https://checkoway.net/papers/fcfi2014/fcfi2014.pdf

--
Stephen Checkoway





_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191122/1cee0127/attachment.html>