[SC-L] heap protection in glibc - some questions

[Yves Younan]

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