[LLVMdev] -fbounds-checking vs {SAFECode,ASan}

[Kostya Serebryany]

On Thu, May 24, 2012 at 9:23 PM, John Criswell <criswell at illinois.edu>wrote:

> On 5/24/12 5:41 AM, Duncan Sands wrote:
> > Hi Kostya, I'm also curious to know where Nuno is going with this, and
> the
> > details of his design.  I'm worried he might be reinventing the wheel.
>  I'm
> > also worried that he may be inventing a square wheel :)
>
> I believe Nuno's goal is to prevent run-time exploitation of software.
>

If that's the goal, the solution is likely to be wrong.
The proposed bounds-checking will cover a tiny portion of buffer overflows
and will not cover use-after-free or stack corruption at all.
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.

Note that asan does not claim to "prevent run-time exploitation", because
in general case it does not.
If we want full prevention, we need to use another kind of sandbox (e.g.
Native Client).

--kcc


> Nuno, please correct me if I'm wrong.
>
> And with all due respect to Nuno, I think he's reinventing the wheel.  I
> implemented what he described using SAFECode in an evening by writing
> two specialized passes that are needed to adjust SAFECode's
> instrumentation to what Nuno needs (one pass removes checks that are too
> expensive; the other inlines the fast checks to remove function call
> overhead).  That code can still be found at
> http://sva.cs.illinois.edu/fastsc-llvm.tar.gz.
>
> I wrote a proposal for a common memory safety instrumentation
> infrastructure and sent it to llvm-commits.  Would it be useful to send
> it to llvmdev as well for discussion, or has everyone who's already
> interested seen it?
>
> Having said all this, if exploit mitigation is the goal, I think it
> might be worth taking a step back and first determining *which* safety
> properties one wants to enforce and what the expected overheads might
> be.  IMHO, if I wanted a technique that could provide the most security
> for the least code complexity and least run-time overhead, I would
> implement control-flow integrity (CFI).  As far as I understand, nearly
> all memory safety exploitation today is done by diverting
> control-flow(*); CFI prevents that and is faster than any other
> non-probabilistic mitigation in the literature.
>
> There's a paper on CFI by Abadi et. al.
> (http://dl.acm.org/citation.cfm?id=1609956.1609960).  However, I don't
> think we'd want to implement it in the same way they do; I'd recommend
> run-time checks on indirect function calls and a split-stack approach
> that allows checks on stores to just mask off bits in the pointer
> address to prevent them from overwriting the return address on the stack.
>
> As an aside, I have a web site called the Memory Safety Menagerie
> (http://sva.cs.illinois.edu/menagerie/index.html) that lists papers on
> the topic of memory safety attack mitigation.  Those interested in
> exploring the mitigation options might find it useful.
>
> -- John T.
>
> (*) Attacks that only change data-flow are possible and practical, but I
> think these are a minority of attacks in the wild.  Attacks that divert
> control-flow are not only common, but researchers have now built tools
> to automate the creation of such attacks.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120525/c4a3bcf4/attachment.html>