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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 03 Dec 2003 14:01:39 +0100
From: Stefan Esser <se@...iracy.de>
To: William Robertson <wkr@...ucsb.edu>
Cc: Stefan Esser <stefan@...pekt.org>, sectools@...urityfocus.com,
	bugtraq@...urityfocus.com, focus-ids@...urityfocus.com
Subject: Re: [ANNOUNCE] glibc heap protection patch


William Robertson wrote:

> This is true in the case of the fd and bk pointers, and in fact this 
> is one of the checks that dlmalloc's debugging code performs.  
> However, as we also demonstrated in the paper, you are still open to 
> other heap-related attacks, such as overwriting size fields and 
> setting up fake chunk headers.  So, unfortunately I don't think that 
> check alone is sufficient.

The last time I checked there was no such check in the unlink macro (no 
matter if debug mode or not). Overwriting size fields and setting up 
fake chunk headers are the standard way to exploit malloc()/free() 
structures. And you should rethink about my unlink macro. It perfectly 
stops ALL
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.

Ohh btw... Feel free to demonstrate me an unlink exploit that works 
while my unlink macro
is in place... In the last two years I nearly only concentrated on heap 
exploits on a various
number of platforms. glibc/bsd/solaris/windows and I even exploited the 
heap on XBOX
with my dashboard-font exploit. So I very much doubt that my statement 
was incorrect.

Stefan Esser




Powered by blists - more mailing lists