Sm0ke & Mirrorz

[Update-6/6/2008]: A friend pointed out that this post is only relevant for Visual Studio 2003. Newer implementations of the /GS flag, (in Visual Studio 2005, etc) XOR the EIP with the canary. This implementation is a lot sexier and makes the description by Micahel Howard accurate. It should be noted that if there is more than one pointer that an attacker can use to perform a read and a write, it may still be possible to subvert EIP without triggering /GS.


All the pretty lies tickle me pink.

Remember when..

- "You won't get owned if you don't open the email."
- "You can't get owned just from viewing a picture."
- "An overflow? Oh but it's on the heap, we're ok."
- "Our WiFi has the SSID hidden + WEP, so unless you know about it.."

Time and time again the false sense of security shared by technology users gets shattered with the publication of a total-pwnage proof-of-concept. With their faces hitting a rough pavement of truth, eventually you would think that they learn. But really, SHIT NEVER CHANGES. Presently, you have these dumb-f^cK$ running around, acting like ASLR + Stack Canary + DEP means they can let their guard down and resume smoking crayola rock. It gets worse when a trusted information security source provides incorrect information that gets turned into a Bible reference.

Take Writing Secure Code, 2nd Edition by Michael Howard, for example. This book is relatively well written with a lot of accurate information intended to help developers understand and write secure code. Before I say anything else, I would also like to give Michael his props -- he knows his stuff. The problem is that even the slightest technical mishap in the description a coding bug or protection mechanism can result in a cult of ignant developers. Yes, I said ignant. Especially when the book is dubbed 'required reading' within a corporation.

Page 168, in the context of describing buffer-overflow mitigation, outlines the security-add offered by the protection mechanism within Visual Studio's /GS flag. (For those *nix people out there who won't/don't/can't touch MS Visual Studio, the /GS option implements stack cookies/canaries similar to those of Crispin Cowan's Stackguard, with a little more voodoo. For those of you who are not familiar with the stack canary/cookie concept, might I recommend a career in Basket Weaving.) On each point listed on page 168, a known attack method (stack smashing, heap overruns, etc) is given with a description of if/how the mechanism can be used to prevent exploitation. For 'Pointer Subterfuge' the following description is given:

"Overwriting a local pointer in order to later place data at a specific location--/GS can't stop this, unless the specific location is a return address."

This description would be 100% correct if it were just 7 words shorter; stopping at "/GS can't stop this". If an attacker controls a pointer directly pointed to the return address, and touching nothing else, there is absolutely nothing to trigger /GS. I mean this is pretty obvious, please don't think im saying this is something new -- it's just textually incorrect. Am I just being a pedantic asshole? You bet. Does my asshole-like nature inhibit developers from mangling security with this information? Not at all...

Again I should note that Michael Howard knows his shit, and he alerts developers not to place blind faith in the protection mechanisms described. I am by no means categorizing him with the idiots who unknowingly perpetuate stupidity on a grandiose scale.. My concern is that in a world where "Oh its on the heap, we're okay" was the mantra for years, the most minute inconsistency could ultimately lead to a slew of mayhem. These inconsistencies are everywhere, and they allow people to believe in smoke and mirrors.. Tickles me pink.