[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160218110831.17429da5@pc1>
Date: Thu, 18 Feb 2016 11:08:31 +0100
From: Hanno Böck <hanno@...eck.de>
To: oss-security@...ts.openwall.com
Subject: Re: Address Sanitizer local root
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-Gentoo-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).
--
Hanno Böck
https://hboeck.de/
mail/jabber: hanno@...eck.de
GPG: BBB51E42
Content of type "application/pgp-signature" skipped
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.
