> From: Chris Ren [mailto:crenat_private] > The protection afforded by the new feature allows developers > to continue to use vulnerable string functions such as > strcpy() as usual and still be "protected" against some forms > of stack smashing. This isn't an accurate representation of what it's meant to do. I'll quote from a passage Michael Howard wrote in our book, "Writing Secure Code", pg 343: ... Microsoft Visual C++ .NET includes a new feature that helps mitigate ***some*** kinds of exploitable buffer overruns. ****That said, there is simply no substitute for good, secure progamming practices.**** Emphasis mine. It is absolutely NOT meant to allow programmers to continue to use unsafe functions and poor programming practices and somehow get saved from all their problems. I think of it as seat belts. Seat belts do not save your life in all crashes. They do save your life sometimes, and it's worthwhile to use them in case they do. It's not a good idea to drive like a lunatic just because you've got your seatbelts fastened. I think the limitations of protecting the return address with a canary are extremely well documented, both in this forum and elsewhere. Again, I'll quote from "Writing Secure Code", pg 70: "Tools exist to make static buffer overruns more difficult to exploit. [...] Similar tools do not currently exist to protect against heap overruns." Please note that I said "more difficult". This is a very important point. BTW, this section cites a paper by Matt Conover that was very helpful and I thought was the best documentation on heap overflows that I could find when I wrote that chapter. Note that the code example I used to demonstrate how a heap overflow could be exploited could also occur with variables declared on the stack. I personally find it best to practice defense in depth - do your best to write solid, secure code, avoid unsafe functions, AND use the tools I have available to help me both catch mistakes and make the effects of some of those mistakes less disastrous. David LeBlanc dleblancat_private
This archive was generated by hypermail 2b30 : Thu Feb 14 2002 - 14:37:42 PST