[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1455916403.769.9.camel@gmail.com>
Date: Fri, 19 Feb 2016 16:13:23 -0500
From: Daniel Micay <danielmicay@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Address Sanitizer local root
> As long as the aborts/faults happen at the earliest point where the
> wrong program behavior can be detected, I see no way they are "more
> painful to debug" than having ASan or similar introspectively print
> crash info. Attaching a debugger should get you equally useful
> information.
The aborts and faults tend to happen later than the ASan detection would
kick in though, other than the double-free case. For example, writes to
freed memory only get detected when the junk data is validated later on
(i.e. when an allocation is flushed from the FIFO quarantine), and it
can be quite hard to debug from there. Use of freed memory often crashes
right away with junk filling (pointer accesses) but it can end up
causing subtler issues or crashes far away from the source.
It's much easier to find the bugs than it would be without this, but if
your goal is implementing hardening features, it's not very fun to need
hundreds of fixes for use-after-frees across common software. It makes
sense to go at it with ASan or Valgrind first to clear out the obvious
problems and then worry about exploit mitigations. A surprising amount
of software has all kinds of memory corruption in the *common* code
paths.
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.
