Bugtraq: Re: [ANNOUNCE] glibc heap protection patch

[xenophi1e <oliver.lavery () sympatico ca>]

In-Reply-To: <3FCDDEB3.8050006 () nopiracy de>

> 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