<div dir="ltr">On 26 August 2013 11:39, Stephen Crane <span dir="ltr"><<a href="mailto:sjcrane@uci.edu" target="_blank">sjcrane@uci.edu</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Greetings LLVM Devs!<br>
<br>
I am a PhD student in the Secure Systems and Software Lab at UC<br>
Irvine. We have been working on adding randomness into code generation<br>
to create a diverse population of binaries. This diversity prevents<br>
code-reuse attacks such as return-oriented-programming (ROP) by<br>
denying the attacker information about the exact code layout. ROP has<br>
been used is several high-profile recent attacks, and has also been<br>
used as a jailbreaking avenue. We believe our transformations would<br>
provide a significant security benefit for LLVM users who choose to<br>
use diversity. For more details see [1] (although we are currently<br>
proposing to upstream only a simplified subset of our work).<br>
<br>
We would like to contribute some of our work back to the community,<br>
and are preparing a small patch adding two new features: NOP insertion<br>
and schedule randomization. The NOP insertion pass randomly adds NOPs<br>
after each MachineInstr according to a command-line<br>
parameter. Currently NOP insertion is implemented for X86, and we are<br>
adding support for ARM. The schedule randomizer randomly picks a valid<br>
instruction to schedule at every point, bypassing the scheduling<br>
heuristics. These passes result in a binary which, while slightly<br>
slower, is far more secure against code-reuse attacks. In addition,<br>
schedule randomization may be useful for randomized compiler and<br>
micro-architecture testing.<br>
<br>
We would also include a secure random number generator which links<br>
against OpenSSL. This would of course be an optional module disabled<br>
by default, but is necessary so the randomization is cryptographically<br>
secure and useful in security applications.<br>
<br>
We are in the process of writing test cases and double checking<br>
formatting to produce a useful patch, but would like to solicit<br>
feedback on our proposed changes before submitting patches for<br>
detailed consideration.<br></blockquote><div><br></div><div>Thanks. This is really interesting -- it's hard to find good protections against ROP attacks, and this is promising. However, I'm going to start with the "bad news" first. I have a few questions as to whether this is useful for our (llvm's) users in the real world:</div>
<div><br></div><div>1. I'm concerned about the deployment problem. I realize that being in the compiler means you can transform the program in more exciting ways, but it gives you a much worse deployment story than something which modifies the program on disk like "prelink".</div>
<div><br></div><div><div>2. Does this actually fill a gap in our protections? How do we ever get into the situation where the user is able to deploy a ROP attack against us, without tripping asan or ubsan or something caught by our warnings or the static analyzer or any of the other protections offered by clang and llvm? It may suffice that there exists a niche which can't afford the performance penalty from asan or other things, but then we'll need to discuss what the performance impact is.</div>
</div><div><br></div><div>3. Reproducible builds are a must. GCC has a -frandom-seed=text flag and you should use that here too. Given the same random seed, the compiler shall produce the same output.</div><div><br></div>
<div>Ultimately my concern here derives from the fact that I do use clang warnings today and I do use asan and ubsan today. If this ROP-protection were added, I don't immediately see how I would use it. Just being I'm not inside the target audience doesn't mean the target audience doesn't exist, but I am asking for a little justification.</div>
<div><br></div><div>And one issue for us, the llvm developers. If we're going to accept this feature, own it and maintain it, how can we test it? We know how to test for correctness and measure performance, we even understand what protections -fstack-protector or ASAN offer and can write spot-tests for them, but how can we measure the effectiveness of probability-based ROP-protections? We don't need an answer to this right now, but over time we'll be maintaining it, and it seems plausible that we could accept a patch which accidentally diminishes the actual security provided (image us maintaining a random number generator -- it's possible to add a weakness which isn't easily noticed).</div>
<div><br></div><div>There's a "good news" side to this too. Over lunch I talked with one of our security guys, and he's excited. He tells me that diversity for ROP-protection is entirely the way to go, and speculates that it ought to be deployable by other vendors. Furthermore, we expect that rotating the register allocation is going to be especially painful on the exploit authors.</div>
<div><br></div><div>Looking forward to seeing patches!</div><div><br></div><div>Nick</div></div></div></div>