Re: [ANNOUNCE] glibc heap protection patch
In-Reply-To: <3FCDDEB3.8050006@xxxxxxxxxxx>
>heap attacks that try to make use of the unlink macro (and this are the
>most out there). I know that modifying unlink does not protect against
>frontlink attacks. But most heap exploiters do not even know that there
>is anything else than unlink. I never said that the unlink macro is the
>ultimate solution to all heap problems, but it is certainly securer to
>check the pointers on unlink than protecting it only with magic numbers.
>The best solution would be a combination of both.
>
Forgive my ignorance, I've been doing other things for the last two years,
but isn't this precisely the advantage of magic numbers. If you only consider
unlink exploits, then your macro is adequate protection. However if it's
demonstratable that there are other ways to exploit heap corruption which do
not require unlink() then your macro is equivalent to using a really poorly
generated magic number for these other cases. There are demonstratable ways to
exploit heap corruption that do not require unlink() therefore your macro would
seem to be inadequate.
It seems to me that if an attacker can overwrite p->fd and p->bk, then
satisfying p->fd->bk == p->bk->fd == p is not very difficult, you could
overwrite fd and bk with the value of p, or with an address you control.
The real question, then, is if an attacker who has passed the test in your
macro is also left in a situation where exploiting frontlink() or some other
possibly unknown technique is possible. Whether or not she can use an unlink()
exploit at this point seems only as relevant as whether or not she can use any
other exploitation technique. Otherwise you would be basing the security of
your system on how many attackers have figured out how to break it, and you
might as well be designing a heap protection mechanism for Redmond.
This question seems more complex than 'Feel free to demonstrate me an unlink
exploit that works while my unlink macro is in place'. But I have to admit my
own ignorance here, I can't say for certain whether an attacker who passes the
test in your macro is left in a situation where an exploit is possible.
You're right that the best bet would seem to be using both approaches. Doing
sanity checks on data, and using canaries to make sure the data hasn't been
modified seem quite complementary, one attempts to ensure the validity of the
data, the other attempts to ensure it's integrity.
And William's using srand( time( NULL ) ) was just goofy <tsk-tsk>.
Cheers,
~x