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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <8DDADADF-25DF-11D8-8B1F-000A95675F0E@cs.ucsb.edu>
Date: Wed, 3 Dec 2003 14:25:09 -0800
From: William Robertson <wkr@...ucsb.edu>
To: Stefan Esser <se@...iracy.de>
Cc: sectools@...urityfocus.com, bugtraq@...urityfocus.com
Subject: Re: [ANNOUNCE] glibc heap protection patch

On Dec 03, 2003, at 05:01, Stefan Esser wrote:
> The last time I checked there was no such check in the unlink macro 
> (no matter if debug mode or not).

Ah, ok, I see what you meant.  The check I was referring to wasn't in 
the unlink macro, but in one of dlmalloc's debugging routines.  If you 
move it into unlink itself, then it does indeed prevent all unlink 
exploits, as you say.  I agree that a combination of the two techniques 
would theoretically be stronger than each on its own, but I also 
believe that using properly randomized magic numbers in practice 
guarantees that chunk headers cannot be tampered with.  However, you do 
get a lot for this simple check, so it makes sense to include it.

Thanks for pointing that out.

> Stefan Esser

--
William Robertson
Reliable Software Group, UC Santa Barbara
http://www.cs.ucsb.edu/~wkr/