('binary' encoding is not supported, stored as-is) In-Reply-To: <20030516014931.GB564at_private> 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. >
This archive was generated by hypermail 2b30 : Fri May 16 2003 - 15:55:34 PDT