Re: safe mallocs (was Re: vulndev-1 and a suggestion about the ensuing discussion)

[xenophi1e <oliver.lavery () sympatico ca>]

In-Reply-To: <20030516014931.GB564 () rahul net>


Interesting. How much would you need to do to expand this to prevent 
hacking as opposed to just programming errors? Provided the canary was 
hard to guess, it would be pretty good, I think. Perhaps you could also 
checksum the bookeeping info and XOR it with the canary and perhaps the 
allocated address. These three pieces of information seem like they would 
be quite difficult to fake. Especially if the canary was randomly 
generated each time the application started, or even more frequently.

A static canary and the size alone would be easy to guess, it seems to me.

There are probably better schemes, but this has the nice property of 
being something you could retrofit without breaking the world. Well, at 
least something you could kinda retrofit if it weren't for some nasty 
implementation details. Are there any products like StackGuard that do 
something like this?

Cheers,
~x

> When I got around to wrapping malloc, I decided to get a smigeon
> cleverer. I wrapped so emalloc returned a char *, just like malloc,
> but the char* it returned was the result of mallocing the original
> size(rounded up to pessimal alignment) + 2*sizeof(somestruct), where
> somestruct was constructed to be pessimally aligned, and had a
> canary, as well as a length field. The original malloc request
> length got stuffed into the length field in the struct at the
> beginning and end, and both structs had their canary fields
> initialized as well.