('binary' encoding is not supported, stored as-is) In-Reply-To: <200305142359.h4ENxLHw004175at_private> >The second aspect is also interesting, but to my view *separate*: if my >above analysis is correct, then the question is, "how much damage can you >cause in various operating systems and with particular C compilers if you >can clobber that one byte off the end of a malloc" [with the answer being >"a widely variable amount of damage, of course..:o)]. And I realize this On a related note, how many ways are there of preventing this sort of error, or at least preventing it from being a security issue? To me that's more interesting than a blow by blow of the impact... 1) Don't make silly mistakes. Obviously this isn't going to happen. 2) Use canaries in the allocator. What's the best way to do this? For one byte overflows a simple value at the end that's difficult to guess would have saved this snippet from being 0wn3d. What about a longer overflow as might have resulted from using strcpy? 3) How could the layout of malloc()s bookeeping info be smarter? Are there any platforms that have allocators that are more robust against overruns? Perhaps this is off-topic for some, but it seems like the most interesting part of a problem like this, to me... Cheers, ~ol
This archive was generated by hypermail 2b30 : Fri May 16 2003 - 00:47:49 PDT