"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? 


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...


Nick FitzGerald

Secure Coding mailing list (SC-L)
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Reply via email to