bugtraq - Re: [ANNOUNCE] glibc heap protection patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20031203221916.6056.qmail@sf-www1-symnsj.securityfocus.com>
Date: 3 Dec 2003 22:19:16 -0000
From: xenophi1e <oliver.lavery@...patico.ca>
To: bugtraq@...urityfocus.com
Subject: Re: [ANNOUNCE] glibc heap protection patch

In-Reply-To: <3FCDDEB3.8050006@...iracy.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