Brandon Bray claims that Microsoft Visual C++ compiler team "invented" the idea of placing a canary on the stack to try to prevent certain kinds of buffer overflows. Mr. Bray should familiarize himself with Crispin Cowan's StackGuard [Cowan]. Also of interest are various attacks against the original technique, most notably the Emsi vulnerability explained in Phrack 56 [Phrack]. We never made a claim that the use of the flawed /GS feature exposes code to "more attacks" as suggested in a bugtraq post. All we have done is point out that the /GS feature is itself susceptible to attack and should not be relied on to improve software security. The short term solution is quite simple: don't use the feature, or if you insist on using the feature at least know the risks! In other words, developers should be made aware of problems with the /GS feature so they know the risks they run if they choose to use it. Perhaps future versions of the /GS feature will be better constructed. Why might developers rely on the broken /GS feature to protect their code? We refer you to Mr. Bray's article "How Visual C++.NET can Prevent Buffer Overruns" [Bray], where the title itself says it all. Also note that in Chapter 13 of Mike Howard and David LaBlanc's book is the important qualifying statement (p. 346) "doing so catches only stack-based buffer overruns that overwrite the function return address." That it does. But as our toy program shows, simply getting caught by killing the canary is not sufficient. We can "get caught" and still go on to carry out an attack. Two stage attacks are both possible and dangerous. By now, everyone should know this. To be fair, Mike Howard has always been very careful in his claims about the /GS option. Good for Mike. There are well known ways to prevent a two stage attack. In our technical writeup, we mention three [Cigital], one prominent one being work done by IBM [IBM]. Also see Crispin's new work on PointGuard. (We expect these will be "invented" soon too.) With regard to feature performance, a classic criticism against Microsoft is that there is a tendency to make hard tradeoffs like "efficiency versus security" rather poorly. Mr. Gates promises to change this when he says "So now, when we face a choice between adding features and resolving security issues, we need to choose security." We applaud this sea change and wish Microsoft the best in this endeavor. Unfortunately, Mr. Bray's claim "if the security checks perturbed the code such that it was noticeably slower, I truly doubt anyone would use [it]." demonstrates the wrong attitude. Our hope is that cooler minds will prevail (go Mike!). There is clearly room for improvement in the /GS feature. We believe that you should make use of some of the "extremely well documented" ways of protecting the canary, or just drop the whole idea. If you could "easily change" the /GS architecture to thwart our attack, then why the heck didn't you? This is not really rocket science. Don't make performance against security tradeoffs without informing the people who end up using your feature. Just for the record, we agree with your stated position that the real solution is to educate developers about security. The book "Building Secure Software" by Viega and McGraw is one decent place to start. [BSS] Instead of worrying about protecting flawed native code from exploit, we think that Microsoft should take this opportunity to emphasize "managed code" and encourage people to adopt this approach. Java intruduced the world to the power of type safe languages. .NET "managed code" can help make this modern approach more pervasive. (BTW, this from the guy who wrote "Java Security" in 1996). Code Safely, Gary McGraw and Chris Ren REFERENCES [Cowan] Automatic Detection and Prevention of Buffer-Overflow Attacks", Crispin Cowan, Calton Pu, David Maier, Heather Hinton, Peat Bakke, Steve Beattie, Aaron Grier, Perry Wagle, and Qian Zhang, in the 7th USENIX Security Symposium, San Antonio, TX. January 1998. <http://www.immunix.org/stackguard.html> [Phrack] Bypassing Stackguard And Stackshield <http://www.phrack.org/show.php?p=56&a=5> [Bray] How Visual C++ .NET Can Prevent Buffer Overruns <http://www.codeproject.com/tips/gsoption.asp> [Cigital] Microsoft Compiler Flaw Technical Note <http://www.cigital.com/news/mscompiler-tech.html> [IBM] GCC Extension For Protecting Applications From Stack-Smashing Attacks <http://www.trl.ibm.com/projects/security/ssp/> [BSS] John Viega and Gary McGraw "Building Secure Software", Addison-Wesley 2001. <http://www.buildingsecuresoftware.com>
