|
BugTraq
[ANNOUNCE] glibc heap protection patch Dec 01 2003 07:31PM William Robertson (wkr cs ucsb edu) (2 replies) Re: [ANNOUNCE] glibc heap protection patch Dec 02 2003 02:03PM Stefan Esser (stefan suspekt org) (1 replies) Re: [ANNOUNCE] glibc heap protection patch Dec 02 2003 05:16PM William Robertson (wkr cs ucsb edu) (1 replies) Re: [ANNOUNCE] glibc heap protection patch Dec 03 2003 01:01PM Stefan Esser (se nopiracy de) (1 replies) Re: [ANNOUNCE] glibc heap protection patch Dec 02 2003 11:27AM Eugene Tsyrklevich (eugene securityarchitects com) (1 replies) Re: [ANNOUNCE] glibc heap protection patch Dec 02 2003 07:33PM William Robertson (wkr cs ucsb edu) (1 replies) Re: [ANNOUNCE] glibc heap protection patch Dec 03 2003 07:54AM Han Boetes (han mijncomputer nl) (1 replies) Re: [ANNOUNCE] glibc heap protection patch Dec 04 2003 05:42PM Adam Shostack (adam homeport org) (1 replies) |
|
Privacy Statement |
> 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/
[ reply ]