<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 5/25/12 2:13 AM, Kostya Serebryany wrote:
<blockquote
cite="mid:CAN=P9pgBqvoTX3EVkg+sD6FpGNUm4YoGrJ6kBTo5Yd5jRuU0bw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<br>
<div class="gmail_quote">On Thu, May 24, 2012 at 9:23 PM, John
Criswell <span dir="ltr"><<a moz-do-not-send="true"
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. <br>
</div>
</div>
</blockquote>
<br>
While I agree that you're probably correct about the bounds checking
covering a tiny portion of buffer overflows, I don't think we really
know that for certain. An experiment to find the percentage of
pointer arithmetic operations that can be checked in this way would
be interesting.<br>
<br>
<blockquote
cite="mid:CAN=P9pgBqvoTX3EVkg+sD6FpGNUm4YoGrJ6kBTo5Yd5jRuU0bw@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<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. <br>
</div>
</div>
</blockquote>
<br>
I agree that any future documentation on any added security attack
mitigation features should be clear on which attacks are prevented
and which are not.<br>
<br>
Having a security solution that prevents some attacks but not others
is okay. Defeating all memory safety attacks with acceptable
performance is still an open research question. What I think is
important is knowing which attacks a technique defeats and at what
cost; you essentially want to know what you're buying and for how
much.<br>
<br>
My concern with Nuno's approach is that it is not clear which
exploits it will prevent and which it will not. Alternatively, if
we implemented CFI, we know *exactly* which types of attacks are
prevented and which are not (and, I think, we'd mitigate a large
number of attacks). I also suspect that the overhead of CFI may
actually be lower than Nuno's proposed solution, although we'll need
some experiments to be sure.<br>
<br>
<blockquote
cite="mid:CAN=P9pgBqvoTX3EVkg+sD6FpGNUm4YoGrJ6kBTo5Yd5jRuU0bw@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<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). <br>
</div>
</div>
</blockquote>
<br>
Actually, Native Client is a sandboxing technique: it ensures that a
plugin does not accidentally or intentionally read or write data
from a program's "core" (the "thing" that the plugin plugs into).
Native Client doesn't prevent attackers from taking over and
controlling the behavior of the plugin, and it doesn't prevent
direct attacks on the core. Some of the techniques used in Native
Client (and PNaCL in particular) could be of interest, though.<br>
<br>
There are some memory safety techniques (or combinations of
techniques) that could provide what I guess you would call full
memory safety. However, they all either rely upon garbage
collection (which is conservative for C) or dangling pointer
detection (which is too expensive at run-time) (2).<br>
<br>
I think the next best thing is SAFECode with its automatic pool
allocation technique(1). With automatic pool allocation, SAFECode
can optimize away type-safe loads and stores while ensuring that
danging pointer dereferences through type-safe pointers do not
violate the memory safety guarantees. It even gets you sound
points-to analysis results, which I don't think any other technique
(except those I listed above) gives you.<br>
<br>
The challenge is that the automatic pool allocation transform and
its prerequisite points-to analysis and type-inference analysis are
relatively sophisticated pieces of code. While I think the benefit
is great, the required investment to make these pieces of code
robust is not insignificant.<br>
<br>
While I'd like LLVM to someday have a very strong memory safety
attack mitigation feature, I also think that having a simpler
mitigation technique that is fast and easier to implement is also
valuable (as long as it's effective). CFI appears to be a good
candidate for these reasons.<br>
<br>
-- John T.<br>
<br>
(1) <a class="moz-txt-link-freetext" href="http://llvm.org/pubs/2006-06-12-PLDI-SAFECode.html">http://llvm.org/pubs/2006-06-12-PLDI-SAFECode.html</a><br>
(2) One of these solutions is SoftBound + CETS which has been built
into the SAFECode Clang compiler.<br>
<br>
<blockquote
cite="mid:CAN=P9pgBqvoTX3EVkg+sD6FpGNUm4YoGrJ6kBTo5Yd5jRuU0bw@mail.gmail.com"
type="cite">
<div class="gmail_quote"><br>
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>