Secure Coding mailing list archives
heap protection in glibc - some questions
From: yyounan at fort-knox.org (Yves Younan)
Date: Sun, 22 Jan 2006 10:11:18 +0100
On 19 Jan 2006, at 21:53, Gadi Evron wrote:
A friend of mine grabbed my attention to this today. I sent this to another list earlier and decided it may be more fitting here on Ken's list. In version 2.3.4 of glibc...
Actually glibc2.3.4 was the first to get these checks, but glibc 2.3.5 has a lot more checks. The nice part about these checks is that they are very cheap.
This seems effective to me. In retrospect, how effective did it prove to be over the past year, in your experience? Is it too early to tell?
Phantasmal Phantasmagoria has released a paper detailing how to bypass these checks (in 2.3.5): http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/ 2005-10/0127.html
Heard of this? http://www.cs.ucsb.edu/~wkr/projects/heap_protection/ What's your take on it, and how do you compare the two?
I've looked at both, they are both interesting techniques, the robertson protection however relies on a global secret number. If an attacker is able to discover what the value is, he could bypass the protection. If he could print out the management information for any chunk, he could calculate the checksum value for that chunk and xor it with the magic for that chunk and then retrieve the global random value. He could then use this global random value to calculate a correct magic value for a different chunk (one that he can overwrite). We've also released a paper in which we describe a new technique to protect the memory management information from heap-based buffer overflows. It does not suffer from the randomness problem. The paper is at http://fort-knox.org/CW419.pdf. The implementation of our allocator (based on Doug Lea's memory allocator) is available from: http://fort-knox.org/dnmalloc-1.0.beta4.tar.gz. I'll be releasing beta5 at the beginning of february though. The main idea is to store the management information in a different part of memory and then ensuring that there's a mapping from one to another, this means that the management information is safe from attack. However as with both the other protection techniques, it does not protect the contents of the chunks, but only the management information. What's also nice about our solution is that it could be combined with the secret number technique by storing a secret number at the top of the chunk and mirror that secret number in the management information, this would allow for a per-chunk random number. The random number could then be used to detect an attack, but the security of the allocator would not rely on this number remaining secret, it would be in addition. I'll be adding this to beta6 some time during february. Any comments you may have on our proposed countermeasure are, of course, very welcome. - YY -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://krvw.com/pipermail/sc-l/attachments/20060122/8a804455/attachment.bin
Current thread:
- heap protection in glibc - some questions Gadi Evron (Jan 19)
- heap protection in glibc - some questions Yves Younan (Jan 22)