Gary McGraw wrote: > If the WMF vulnerability teaches us anything, it teaches us that we need > to pay more attention to flaws. The "flaw" in question seems to be "validate inputs", i.e. don't just trust network input (esp. from an untrusted source) to be well-formed.
Of special importance to the Windows family of platforms seems to be the propensity to do security controls based on the file type extension (the letters after the dot in the file name, such as .wmf) but to choose the application to interpret the data based on some magic file typing based on looking at the content. My favorite ancient form of this flaw: .rtf files are much safer than doc files, because the RTF standard does not allow you to attach VBscript (where "VB" stands for "Virus Broadcast" :) while .doc files do. Unfortunately, this safety feature is nearly useless, because if you take an infected whatever.doc file, and just *rename* it to whatever.rtf and send it, then MS Word will cheerfully open the file for you when you double click on the attachment, ignore the mismatch between the file extension and the actual file type, and run the fscking VB embedded within. I am less familiar with the WMF flaw, but it smells like the same thing. Validate your inputs. There are automatic tools (taint and equivalent) that will check whether you have validated your inputs. But they do *not* check the *quality* of your validation of the input. Doing a consistency check on the file name extension and the data interpreter type for the file is beyond (most?) such checkers. > We spend lots of time talking about > bugs in software security (witness the perpetual flogging of the buffer > overflow), but architectural problems are just as important and deserve > just as much airplay. > IMHO the difference between "bugs" and "architecture" is just a continuous grey scale of degree. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Olympic Games: The Bi-Annual Festival of Corruption _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
