[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1455850474.924.9.camel@gmail.com>
Date: Thu, 18 Feb 2016 21:54:34 -0500
From: Daniel Micay <danielmicay@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Address Sanitizer local root
On Thu, 2016-02-18 at 11:08 +0100, Hanno Böck wrote:
> Hi,
>
> Thanks a lot for your analysis.
>
> On Wed, 17 Feb 2016 23:19:21 +0100
> Szabolcs Nagy <nsz@...t70.net> wrote:
>
> >
> > https://blog.hboeck.de/archives/879-Safer-use-of-C-code-running-Gent
> > oo-with-Address-Sanitizer.html
> > (the later was presented at FOSDEM 2016:
> > https://fosdem.org/2016/schedule/event/csafecode/ )
> >
> > While these are interesting projects, ASan should not be
> > used for hardening in production systems in its current form,
> > so at least the language ("hardening", "protection", "safe")
> > should be fixed.
> Given that this is my work (I did the asanized Gentoo and the FOSDEM
> talk) I think I should answer.
>
> I hope I have made it clear that whether using asan for production
> purposes makes any sense was an open question to me. I have placed
> warnings that this is experimental and I didn't recommend any
> production
> use right now.
>
> I was aware about the performance and memory costs of asan, and I was
> aware that there are risks involved, but it appeared to me that
> balancing issues out it would still be a security win and might
> therefore be an option for some highly security sensitive
> environments.
> Your mail makes it clear to me that I was in error and at least in its
> current form asan is probably not suitable for secure use at all.
> I will add a note to my blogpost and the Gentoo wiki with a link to
> your mail to make this clear.
>
>
> Appart from that I wonder whether this should have any consequences
> for
> asan and which ones. Would it be desirable to:
> a) Try to fix security issues like the one you presented with suid
> binaries? (not sure what the best fix would be, maybe detect suid
> binaries and drop privileges back to user [not sure if that's even
> possible]).
> b) Leave issues unfixed and declare that asan is just not good for
> production use. In this case I agree that the asan documentation
> should
> probably include some more obvious warnings / explanations of the
> risks involved.
> c) Some other variant, like splitting asan into two different
> variants.
> One could imagine having a new cflag that would enable asan, but
> disable some of the ASAN_OPTIONS things like logging (however thinking
> about this I don't like it - if I imagine running asan on some kind of
> server I would want to be able to log issues).
Since it's not providing full bounds checking but rather approximate
bounds checking catching most common cases it's not clear how well the
design would work for hardening even with a security-oriented runtime
for ASan. It's also still going to significantly weaken ASLR even with a
hardened runtime. Security features need a clear threat model and ASan
doesn't have a threat model, since it's a debugging feature. It doesn't
provide memory safety but rather detection of common cases of memory
corruption. An approach to memory safety in C without mass rewrites of
code into an annotated subset would need to be drastically different
than the ASan design.
A large part of the quarantine-based hardening for lifetime issues (use-
after-free, double-free) can be provided by a hardened malloc without
the same drawbacks so that part is less interesting from a hardening
perspective. Bounds checking is obviously important, but people aren't
getting what they think they are when they're using ASan as that kind of
mitigation. It can be bypassed in general. It's not simply a matter of
hardening it. You want something else.
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
