[Am-info] Fwd: FC: Richard Forno: Forget California, it's time to recall Microsoft

[Gene Gaines]

No comment needed.

Gene Gaines


This is a forwarded message
From:  Declan McCullagh <declan@well.com>
To:    politech@politechbot.com
Date:  Sunday, August 17, 2003, 7:23:09 PM
Subject: FC: Richard Forno: Forget California, it's time to recall Microsoft
=================Original message text===============



---------- Forwarded message ----------
Date: Wed, 13 Aug 2003 19:01:16 -0400
From: Richard Forno <rforno@infowarrior.org>
To: declan@well.com
Subject: For Politech if you want....


Article on MSBlaster from today.  Cheers, rf


http://www.infowarrior.org/articles/2003-01.html

Forget California, It's Time to Recall Microsoft
Richard Forno <www.infowarrior.org>
(c) 2003 Richard Forno.
Permission granted to reproduce in entirety with credit to author.


A sign on a Trenton, NJ railroad bridge says "Trenton Makes, The World
Takes."  In light of recent history, a sign at Sea-Tac airport should
probably read "Microsoft Makes, The World Quakes."

For the second time this year, Microsoft is the source of a major internet
security event. First was Slammer/Sapphire in January that seriously
impacted networks and corporations around the world, including shutting
down ATM machines at some large banks. And now, we've got MSBlaster taking
advantage of a years-old vulnerability in Microsoft Windows operating
systems. But unlike Slammer that only targeted servers, this one goes
after desktop computers as well - meaning that ninety percent of the
world's computers are potential targets and victims this week.  Consumer
desktops are significantly more plentiful than corporate ones but
less-protected against viruses, worms, and other attacks. As low-hanging
fruit goes, they're a perfect target of opportunity for cyber-mischief.

According to a Wired
(http://www.wired.com/news/infostructure/0,1377,59994,00.html) story
today, Microsoft is confused why these worms continue plaguing users when
the company's made great effort to improve the patch delivery process.
Microsoft says it's working with federal law enforcement to find out who's
behind the dastardly deed that's giving the software monopoly yet another
embarrassing black eye in the media. This is a typical Microsoft response
full of proactive sound of fury, but signifying nothing helpful.  And the
media's full of reporting about the pervasiveness of MSBlaster and what
people can do to protect themselves against this "latest" cyber-threat.

Yet Microsoft says third-party software accounts for
(http://www.zdnet.com.au/newstech/security/story/0,2000048600,20277185,00.ht
m)>half
of all Windows crashes. Funny, it also blamed the competing DR-DOS for
Windows 3.1 crashes in an (http://news.com.com/2100-1001-225129.html)
attempt to get people to buy MS-DOS back in the 1980s. (It was later
discovered that Microsoft had engineered false error messages to trick
users into buying MS-DOS.) It also said Internet Explorer couldn't be
removed from Windows 95 without crippling the operating system, and was
proven wrong by enterprising researchers. So Microsoft's track record for
veracity isn't exactly stellar when it comes to its products and business
practices.

But, few if any are mentioning the real issues here:  MSBlaster's ability
to affect practically all versions of Windows shows that despite
Microsoft's marketing flacks, there is still significant code shared
between all versions of Windows. Anyone who thinks DOS is dead, or Windows
XP's code internals have little in-common with Windows NT 4 should think
again. MSBlaster proves it.

Also, MSBlaster takes advantage of known vulnerable network ports in
Windows, ports that any competent network administrator or internet
provider should have closed long, long ago. In fact, there's probably no
good reason why these ports should be enabled on consumer versions of
Windows or supported by ISP networks, for that matter. In other words, it
baffles the mind why these well-known ports continue to be a major
security vulnerability in Windows.

Of course, Microsoft pledges to continue working on its patch distribution
process as part of its larger "Trustworthy Computing" initiative. That's
all well and good, but does this mean the security of our networked
systems has been reduced to the repeated mantra of "run the patch" and
then sit back to wait for the next pair (exploit and fix - a matched set!)
to be released? Hopefully not. Security is a two-part process requiring
the network staff to administer their resources appropriately and the
software vendors to produce code that's much more reliable than it is now.

As it did with the Slammer worm in January, Microsoft proudly says it made
available a patch for Windows far in advance of the vulnerability being
exploited on a massive scale.  But many users didn't get the message or
download the patch - either because home users didn't realize that the
automatic Windows Update process was designed for just that reason (or
would "do it later") or, in the case of large companies, network
administrators likely were too busy installing any number of other patches
required (at least 30, according to the number of security bulletins so
far in 2003) to keep their Microsoft systems operating in a somewhat more
secure manner from week to week. (And we wonder why help desk staffs burn
out so quickly.)

If Microsoft really wanted to resolve its software problems, it would take
greater care to ensure such problems were fixed before its products went
on sale - and thus reverse the way it traditionally conducts business.
Doing so means less resources wasted by its customers each year patching
and re-patching their systems, hopefully meaning more is available for
effective network planning, design, and management to support a robust
defense-in-depth security strategy. Customers shouldn't be forced to spend
their money cleaning up after Microsoft's mistakes, laziness, or general
complacency, but on improving their information environments to take full
advantage of the many benefits of the Information Age.

More importantly, why are we - users, administrators, media, and the
government - praising Microsoft for their response to this critical
problem? If something's wrong with a product, responsible companies are
obligated to fix it as a matter of good business practice. A responsible
adult knows that if you make a mess, you're expected to clean it up,
regardless if anyone compliments you for your efforts. Did anyone expect
widespread praise to be heaped on Ford Motors after its Explorer fiasco a
few years back? Hardly - there was a serious problem with one of its
products, and the company fixed it, albeit under the threat of lawsuits
from victims or their families.

But that's not the case with software, from Microsoft or anyone else. When
you acquire software, you don't really "buy" it, but rather purchase a
license to use it "as is" for a period of time, and the vendor is under no
obligation to fix anything wrong with its product. If you take the time to
read the thousands of words in a typical software End User License
Agreement (EULA) - and many people don't -- you'll see that by installing
and using the software, you indemnify the vendor against any claims,
losses, or problems resulting from using its software, even if the vendor
knew about the problem before it sold the product. In some cases, as this
Register (http://www.theregister.co.uk/content/4/26517.html) article
notes, you agree to let Microsoft remotely modify your software and you
can't hold it liable if something breaks as a result.

Code Red, Love Bug, Slammer, Nimda, Pretty Park, BubbleBoy, Melissa, Code
Red II, MSBlaster, and numerous other high-profile Microsoft-sponsored
incidents...many view them as "the price of doing business in the
Information Age" and cheerfully spend (or lose) increasing amounts of
money with each new incident arising from poorly designed software. But
rather than face reality by conducting a dollars-and-sense risk assessment
of their IT operation to see how much Microsoft's vulnerabilities cost
their enterprise annually, these sheeple - at all levels of government,
industry, and society -- prefer tolerating mediocrity to efficiency and
reliability in their software assets, because they're either too lazy to
investigate alternatives or don't want to propose changes to the
comfortable status quo.

What recourse do you have in such cases?  You can't just sue the software
vendor for problems with their product like you can the maker of a vehicle
or appliance since you've given up those rights by using the product under
the terms of its license agreement. The only option you have is continue
using the software in question and scrambling to update your systems
whenever a new problem presents a danger to your information assets. In
other words, when Microsoft says "patch" you salute and say "how soon?"

Or, you can vote with your pocketbook and move to an alternative software
product that works better, costs less to buy and maintain, and won't burn
out your network support staff.  Nobody's saying you must use any one
particular product or operating system, and they all tend to perform the
same basic functions needed in today's working society - although some are
better at it than others. It may take a little bit of effort to switch and
get used to the new product, but the long-term payoff will be worth it.

After all, in the real world, if you don't like Ford trucks, you can buy a
Jeep instead.







-------------------------------------------------------------------------
POLITECH -- Declan McCullagh's politics and technology mailing list
You may redistribute this message freely if you include this notice.
-------------------------------------------------------------------------
To subscribe to Politech: http://www.politechbot.com/info/subscribe.html
This message is archived at http://www.politechbot.com/
Declan McCullagh's photographs are at http://www.mccullagh.org/
Like Politech? Make a donation here: http://www.politechbot.com/donate/
-------------------------------------------------------------------------


==============End of original message text===========


-- 
Gene Gaines
gene.gaines@gainesgroup.com