<br><br><div class="gmail_quote">On Thu, May 24, 2012 at 9:23 PM, John Criswell <span dir="ltr"><<a href="mailto:criswell@illinois.edu" target="_blank">criswell@illinois.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 5/24/12 5:41 AM, Duncan Sands wrote:<br>
> Hi Kostya, I'm also curious to know where Nuno is going with this, and the<br>
> details of his design. I'm worried he might be reinventing the wheel. I'm<br>
> also worried that he may be inventing a square wheel :)<br>
<br>
</div>I believe Nuno's goal is to prevent run-time exploitation of software.<br></blockquote><div><br></div><div>If that's the goal, the solution is likely to be wrong. </div><div>The proposed bounds-checking will cover a tiny portion of buffer overflows and will not cover use-after-free or stack corruption at all. </div>
<div>If the documentation will say something like "it prevents run-time exploitation", users may get a false sense of safety which will make matter worse. </div><div><br></div><div>Note that asan does not claim to "prevent run-time exploitation", because in general case it does not. </div>
<div>If we want full prevention, we need to use another kind of sandbox (e.g. Native Client). </div><div><br></div><div>--kcc </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Nuno, please correct me if I'm wrong.<br>
<br>
And with all due respect to Nuno, I think he's reinventing the wheel. I<br>
implemented what he described using SAFECode in an evening by writing<br>
two specialized passes that are needed to adjust SAFECode's<br>
instrumentation to what Nuno needs (one pass removes checks that are too<br>
expensive; the other inlines the fast checks to remove function call<br>
overhead). That code can still be found at<br>
<a href="http://sva.cs.illinois.edu/fastsc-llvm.tar.gz" target="_blank">http://sva.cs.illinois.edu/fastsc-llvm.tar.gz</a>.<br>
<br>
I wrote a proposal for a common memory safety instrumentation<br>
infrastructure and sent it to llvm-commits. Would it be useful to send<br>
it to llvmdev as well for discussion, or has everyone who's already<br>
interested seen it?<br>
<br>
Having said all this, if exploit mitigation is the goal, I think it<br>
might be worth taking a step back and first determining *which* safety<br>
properties one wants to enforce and what the expected overheads might<br>
be. IMHO, if I wanted a technique that could provide the most security<br>
for the least code complexity and least run-time overhead, I would<br>
implement control-flow integrity (CFI). As far as I understand, nearly<br>
all memory safety exploitation today is done by diverting<br>
control-flow(*); CFI prevents that and is faster than any other<br>
non-probabilistic mitigation in the literature.<br>
<br>
There's a paper on CFI by Abadi et. al.<br>
(<a href="http://dl.acm.org/citation.cfm?id=1609956.1609960" target="_blank">http://dl.acm.org/citation.cfm?id=1609956.1609960</a>). However, I don't<br>
think we'd want to implement it in the same way they do; I'd recommend<br>
run-time checks on indirect function calls and a split-stack approach<br>
that allows checks on stores to just mask off bits in the pointer<br>
address to prevent them from overwriting the return address on the stack.<br>
<br>
As an aside, I have a web site called the Memory Safety Menagerie<br>
(<a href="http://sva.cs.illinois.edu/menagerie/index.html" target="_blank">http://sva.cs.illinois.edu/menagerie/index.html</a>) that lists papers on<br>
the topic of memory safety attack mitigation. Those interested in<br>
exploring the mitigation options might find it useful.<br>
<br>
-- John T.<br>
<br>
(*) Attacks that only change data-flow are possible and practical, but I<br>
think these are a minority of attacks in the wild. Attacks that divert<br>
control-flow are not only common, but researchers have now built tools<br>
to automate the creation of such attacks.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br>