Re: The Morris worm to Nimda, how little we've learned or gained

[Rich Kulawiec <rsk () magpage com>]

On Thu, Jan 03, 2002 at 04:10:58AM -0500, R. DuFresne wrote:
> There is not a security practitioner in the IT industry that could read
> this without shrugging, shaking their head in acknowledgment, and
> wondering when code writers producing applications might well wakeup and
> take note.  It prompted us to review once again Eugene H. Spafford's
> analysis of the Morris worm, and it's aftermath.  A document recommended
> to all security related folks in the IT industry and administrators in
> general, if for nothing more then an eye-opener.

<chuckle>  I still remember how that day began -- a very early-morning
phone call from the operations desk at the Purdue University Computing
Center (where I was employed and was "on call" that day) telling me
that "all the Vaxes are really, really slow and we don't know why".

[Insert many, many hours of frantic research and hastily-convened meetings
and incorrect hypotheses and XORing of data and much excitement, with
a coda a few days later when a Large Nameless Government Agency demanded
that removal of the dissassembled worm from the FTP site I'd placed it on.]

It was, actually, kinda fun.  The *first* time.  It's not fun now that
it's a monthly occurence on the 'net, even if the total absence of
Microsoft products here means that our reaction is mostly bemusement.
It's not fun because we have learned enough to avoid most of these
problems, but we (as a community) have chosen not to solve them.
Instead, we've chosen convenience, interoperability, cost, and other
desirable attributes of software instead.

We have voted with our decisions and our dollars.

Convenience is nice.  Interoperability is nice.  All these things are nice.
But there comes a point when elevating them above the level of all
other evaluation criteria is counter-productive.  Or to be somewhat glib,
are we really gaining anything by having an HTML and Javascript-cognizant
mail client when its primary use is to spread viruses/worms?

Our vote was short-sighted.  The long-term cost in dollars (and lost trust,
and other more difficult-to-quantify items) outweighs what we might like
to think we've saved.

> In the very
> least, jobs should be on the line when companies are compromised by code
> that could have long been prevented by patching of applications and OS's,
> especially when those patches have been widely available and publicly
> announced.  Even an arson victim faces penalties if they have violated
> building codes that contributed to the disaster forced upon them by a
> criminal.  And we have not even broached the topic here of vendor
> responsibility...

Thus we enter the tangled swamp of litigation.  The problem is that *I* think
a vendor should reasonably be held accountable for isn't what *you* think
they should, isn't what their lawyer says they should, isn't what...
And somewhere, years later, this squabble ends with the attorneys on both
sides collecting fees sufficient to fund their vacation condos in Ocean City,
and we probably haven't done much to make software better.

<chuckle> It's bad enough when we see expert witnesses like metallurgists
disagreeing over whether or not a rotor failed because of a manufacturing
defect or because it wasn't properly maintained.  It's only going to get
worse if we have programmers debating whether or not J. Random Program
should been written in a language with strict typing rules and inherent
array bounds checking and whether it was obviously negligent not to do so. ;-)

Two other observations which your article spurs me to make:

1. The Kernighan and Plauger "Software Tools" book and related titles
should still be on everyone's reading list.  The philosophy that a tool
should do one thing and do it really well is not only a viable way to
build large software systems; it's also a way to compartmentalize
functionality and mitigate the consequences of holes.  (As well as making
it easier to find and fix them.)  Do-it-all tools are very slick, but they
expose us to much larger consequences once holes are found in them.

2. There's a lot to be said for peer review, which in turn means open
source.  Other professions (medicine, science, engineering, law, etc.) rely
on peer review to detect problems with experimental methods, data analysis,
reasoning, and all the other components that combine to represent
intellectual progress in the field.  So should we.  It's *not* a panacea:
after all, holes are still found in sendmail, all these years later.
Just as scientific conclusions are sometimes found to be in error, years later.
But it's the best methodology that any of these professions have come
up with, and so unless we have something better to try, I think we
might as well use it.  [...as he edges carefully away from the question
of how software vendors will be convinced to buy into this...]

        "One bozo manages to waste the time of thousands and thousands of
        people. On purpose! For kicks!"

                -David L. Stevens (then also at Purdue, mostly known
                for TCP/IP books), mail message of 11/3/1988, 8:42 AM.

---Rsk
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards