<div dir="ltr">On 29 August 2013 15:29, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 08/28/2013 02:37 PM, Nick Lewycky wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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".<br>
</blockquote>
<br></div>
Yes, definitely. Deployment is an issue which users will need to consider when deciding whether to use compiler-based diversity. However there are certainly use-cases which could benefit, especially in small deployments. Additionally, the benefits may outweigh the increase in deployment costs for larger deployments.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></div>
Briefly looking at ASAN again, I saw a performance penalty of 2x mentioned. Diversity could act as both defense in depth, and as a lower-impact defense for performance critical code.</blockquote><div><br></div><div>Okay, I've been thinking about what I wanted answered here, and I've decided that what I want to know is too complex for this discussion. It boils down to: given we have all the power of clang and llvm for very complex analysis, both static and dynamic, why is randomizing the best we can do? Can't we somehow use all that static and dynamic analysis to shrink the problem down to something we can solve more cleverly than randomizing the program across a lot of axes, such as proving (or arranging for) certain properties which reduce how much we need to randomize, etc? And if not *why can't we*? It's that last part which I think is hardest to answer, so I've decided I'll leave this to the security-trained folks -- if they think this is the right approach, they're probably right.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">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.<br>
<br></div>
Completely agree, and that's exactly what we have done.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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).<br>
</blockquote>
<br></div>
Unfortunately testing for security is a difficult problem. We have currently been evaluating our work by comparing a population of randomized variants to make sure that no gadgets are the same across variants. While this is reasonable for research evaluation, I'm not sure that would be practical (or useful) for the compiler test suite. To prevent regressions, I think the test suite will need to test at least 3 major areas: making sure that RNG results are consistent and deterministic, testing that NOPs are actually inserted and scheduling decisions randomized, and verifying that different seeds result in entirely different binaries with approximately equal amounts of diversifications.<br>
</blockquote><div><br></div><div>I really like the idea of verifying that ROP gadgets work across different variants. Even if it doesn't fit in the regression test suite, it should be set up as an integration test.</div>
<div><br></div><div>The other three areas you identified largely fit in the regression suite. Thanks!</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Speaking of maintenance, we plan to continue work on this in our lab. We can certainly maintain these features at least for the next year and a half, and possibly longer.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></div>
As mentioned, we have an implementation of register randomization, although it will require some reworking to be ready for prime-time. We can definitely look into getting that polished.</blockquote><div><br></div><div>Fantastic!</div>
<div><br></div><div>Nick</div></div></div></div>