When Microsoft told the world on July 16 that all versions of Windows NT and later possessed a security hole large enough to drive an ostrich through, it didn't take divination of that bird's entrails to know that we'd soon see a worm exploiting that hole. So I suspect that the MSBlaster worm's arrival didn't surprise many Windows & .NET Magazine UPDATE readers. But now that the worm has come (and with any luck, gone), I want to do a little finger-pointing and ask what we might do to avert the next worm.
I'd been preaching to people for weeks and pleading with them to install the patch associated with Microsoft Security Bulletin MS03-026 (Buffer Overrun in RPC Could Allow Code Execution). Microsoft, the Department of Homeland Security (DHS), and many other experts and organizations had been sending the same message. Many people told me they weren't worried because they had already used a firewall to secure port 135 and were going to test the security patch before rolling it out.
But as I explained to these people, if I wanted to create a worm to exploit the vulnerability, I'd create it to get inside the firewall through an email attachment. I'd write it as a Trojan horse and send it to the world through an anonymous mailer in the hopes that at least one user per organization would lack both up-to-date antivirus software and a working brain. After it got inside, the Trojan horse would exploit the MS03-026-related flaw and seize control of every system inside the firewall. But then the real fun would begin. I could publish users' .pst files on the Internet, send embarrassing email messages in the victim's name, install about 50 hard-to-find backdoors on the servers, and stealthily negate the value of the firewall from the inside. And given that many folks wouldn't have yet patched their systems against the vulnerability, I might well have brought down the Windows world.
Ah, but my evil plan to destroy the computing universe was foiled. Some idiot wrote a worm that called a lot of attention to itself and did little actual damage (except for the vast number of hours of time that support people wasted), but that scared those people who hadn't patched their systems. I'd guess that if 60 percent of the systems were patched before the MSBlaster worm, 99.9 percent are now patched.
Now it's time for finger-pointing. The fault lies with Microsoft, right? Well, Microsoft shares some responsibility, but not all. My fellow columnist Paul Thurrott has already done a fine job opining on the matter at his WinInfo site ( http://www.wininformant.com ), so let me briefly agree with him. This threat wasn't one of the typical "if you do this unlikely sequence of actions and don't have the patch then bad things might happen" threats. Nope, this threat was one of those once-a-year, red-alert, DEFCON 5 threats that negates all Windows security if you don't apply the patch. Microsoft alerted the public and offered a patch. Yes, patches can be unreliable and can have bad side effects, but what side effect is worse than having an attacker assume complete control of your system?
So in this case, Redmond is off the hook a bit. No, the MS03-026 bug wasn't fun, but stuff happens. When a hurricane is coming toward my home, I have to stop whatever I'm doing and batten down the hatches. The work takes time and is irritating, but I have to do it. Likewise, the MS03-026 bug was an e-hurricane. We saw it coming and had plenty of plywood and nails around.
But Microsoft does merit some of the blame. This bug has been sitting in the OS for 7 years, and Microsoft has been doing security code reviews for the past year and half and missed it. According to Microsoft, the flaw was yet another buffer overflow, and that's incredibly annoying.
For those who aren't familiar with buffer overflows, they're a common type of bug. A programmer sets aside some number of bytes in memory (aka a buffer) to receive incoming data. (Data delivered through a Web form is an example of incoming data.) As the data comes in, the program puts the data in the buffer. A buffer overflow arises when the programmer hasn't allocated enough space. For example, the program diligently accepts and stores 300 bytes of information, but the programmer only put aside 100 bytes' worth of space. As a result, the extra 200 bytes of data overwrites other data in an adjoining buffer. The shame is that programmers can easily avoid buffer overflows by writing a little extra code that checks for adequate space before placing a byte. If enough space isn't available, the program discards the byte. Programmers don't always add that check because the extra code can slow down a program. I've always been willing to trade speed for reliability, but not everyone agrees with me.
What can be done to keep this from happening again? Microsoft's answer is to turn on Windows XP's Internet Connection Firewall (ICF), but I'm not sure it's a good solution. Running ICF on members of a domain can play havoc--at least it did when I accidentally ran it on my network a few years ago. Why not reduce the risk by just using a bit of security common sense that many of us talk about but don't always get around to--namely, shutting off services. Both the NT 4.0 bug that I wrote about in this column a few months ago ( http://www.winnetmag.com/articles/index.cfm?articleid=38824 ) and the MS03-026 bug become powerless if you shut down the Server service. The Server service is turned on by default on every version of every Microsoft OS. Microsoft has taken great strides in 2003 to shut off nonessential services--why not shut off the Server service, which has been the entryway for a number of exploits, as well?
Most people don't need or use much more than 10 percent of an OS's functionality. Perhaps it's time for Microsoft to make the process of protecting ourselves from the side effects of the other 90 percent of the OS a bit easier. Microsoft apparently agrees, as you'll see with the release of Windows Server 2003's upcoming Service Pack 1 (SP1) and the Security Configuration Wizard--but that's another column.
