"Gary McGraw" <[EMAIL PROTECTED]> wrote: > To cycle this all back around to the original posting, lets talk about > the WMF flaw in particular. Do we believe that the best way for > Microsoft to find similar design problems is to do code review? Or > should they use a higher level approach?
I'll leave that to those with relevant specification/design/ implementation/review experiences... > Were they correct in saying (officially) that flaws such as WMF are hard > to anticipate? No. That claim is totally bogus on its face. It is an very well-established "rule" that you commingle code and data _at extreme risk_. We have also known for a very long time that our historically preferred use of (simple) von Neumann architectures make maintaining that distinction rather tricky. However, neither absolves us of the duty of care to be aware of these issues and to take suitable measures to ensure we don't design systems apparently intent on shooting themselves in the feet. I'd wager that even way back then, some designer and/or developer at MS, when doing the WMF design/implementation back in Win16 days (Win 3.0, no?) experienced one of those "We really shouldn't be doing that like this..." moments, but then dismissed it as an unnecessary concern "because it's only for a personal computer" (or some other cosmically shallow reason -- "if I get this done by Friday I'll have a weekend for a change", "if I get this done by Friday I'll make a nice bonus", "usability is more important than anything else", "performance is more important than anything else", etc, etc, etc). Given the intended userbase and extant computing environment at that time, the design probably was "quite acceptable". The real fault is that it was then, repeatedly and apparently largely unquestioningly, ported into new implementations (Win 3.1, NT3x, Win9x, NT4, ME, Win2K, XP, XPSP2, W2K3) _including_ the ones done after Billy Boy's "security is now more important than anything" memo. At some point in that evolution, several someone's should have been raising their hands and saying, "You know, now is the time we should fix this...". Someone on one of the the IE teams obviously noticed and flagged the issue, but why didn't that flag get raised bigger, higher, brighter? ... It is bogus for another reason too -- some of the people at MS making that official claim also said "this is the first such flaw of this kind", and that's just BS. Long before WM/Concept.A (or its forerunner, the oft-forgotten WM/DMV.A) many security and antivirus folk were warning that embedding the more powerful, complex programming language and architecture macros (such as WordBasic, VBA and AccessBasic) into their associated "document" files was an inherently flawed design and would only lead to trouble. So, not only have we long-understood the theoretical reasons for why the underlying causes of WMF are inherently bad design and best avoided if at all possible, BUT MS has had its own, self-inflicted stupidities of exactly the same kind. If MS truly could not anticipate, at some point along the Win3x to W2K3 development timeline earlier than 28 Dec 2005, that this WMF design "feature" would cause trouble, one has to ask if MS should be allowed to make software for general consumption... Regards, Nick FitzGerald _______________________________________________ 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