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>