Bugtraq mailing list archives

RE: Microsoft C++ feature against buffer overflows itself vulnerable


From: "David LeBlanc" <dleblanc () mindspring com>
Date: Thu, 14 Feb 2002 10:46:29 -0800



From: Chris Ren [mailto:cren () cigital com] 
 
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
dleblanc () mindspring com 


Current thread: