Writing viruses to fix security gaps is a lousy idea.
The latest tale of security gaps in Microsoft Corp.'s (Nasdaq:MSFT - news) software is a complicated story, and there are a lot of lessons to take away ... so let's take it chronologically.
On June 27, Georgi Guninski discovered a new vulnerability in Internet Explorer (4.0 or higher) and Microsoft Access (97 or 2000) running on Windows 95, 98, NT 4.0 or 2000. An attacker can compromise a user's system by getting the user to read an HTML e-mail message (not an attachment) or visit a Web site.
This is a serious problem, and it could result in new and virulent mailware. But it requires Microsoft Access to be installed on the victim's computer, which, while common, is by no means universal. A virus that exploits this vulnerability will not spread as widely as, say, Melissa. In any case, Microsoft published a fix on July 14, and I urge everyone to install it.
I can't really figure this e-mail out; it seems to be primarily a grab for press coverage. Some of it is suspiciously vague: "We developed this exploit further and realized that this is one of the most serious exploits of Windows workstations in the last several years" "Developed"? How? No one says.
Some of it brags: "Microsoft asked us not to release the details until they had a fix." "Release the details"? But the original Bugtraq posting was pretty explanatory, and SANS has not released anything new.
Still, the SANS e-mail received a lot more publicity than the Bugtraq announcement or the Microsoft patch, so it's hard to complain too much.
But the SANS announcement had a much more disturbing section: "It may be possible to fix this vulnerability automatically, via an e-mail without asking every user to take action. The concept is similar to using a slightly modified version of a virus to provide immunity against infection. SANS is offering a $500 prize (and a few minutes of fame) to the first person who sends us a practical automated solution that companies can use, quickly, easily, and (relatively) painlessly to protect all vulnerable systems." (This paragraph is no longer on the Web site, which claims that "winning entries have been received.")
First, there's no audit trail of the patch. No system administrator wants to say: "Well, I did try and infect our systems with a virus to fix the problem, but I don't know if it worked in every case."
Second, there's no way to test that the virus will work properly on the Internet. Would it clog up mail servers and shut down networks? Would it properly self-destruct when all mail clients were patched? How would it deal with multiple copies of itself?
And third, it would be easy to get wrong and hard to recover from. Experimentation, most of it involuntary, proves that viruses are very hard to debug successfully.
Some viruses were written to propagate harmlessly but did damage because of bugs in their code. Perfectly intentional experimentation proves that in your average office environment, the code that successfully patches one machine won't work on another, sometimes with fatal results.
Combining the two is fraught with danger. Every system administrator who's ever automated software distribution has had the "I just automatically, with the press of a button, destroyed the software on hundreds of machines at once!" experience. And that's with systems that you can stop; self-propagating systems don't even let you shut them down when you find the problem.
A buffer overflow in Microsoft Outlook or Outlook Express allows an attacker to execute arbitrary code on a victim's machine just by sending him an e-mail. In Outlook Express, the victim doesn't even have to open the e-mail or preview it. All he has to do is download it. In Outlook, he has to read it.
That's the bad news. The good news is that it only is a vulnerability for users who have POP or IMAP installed; those using Outlook's default corporate configuration are not vulnerable. (Home users who link to commercial ISPs are much more likely to be vulnerable.) So again, a virus that exploits this vulnerability would be dangerous and unpleasant, but would not spread unchecked.
Microsoft has a fix. The original one, released July 18, required you to upgrade your version of Outlook or Outlook Express, but two days later Microsoft did the right thing and issued a patch for all versions.
SANS issued another e-mail on July 21st, with more dire warnings: "Please fix this before you go home today. And if you have gone home, go back to the office and fix it." In my opinion, this warning blew the threat completely out of proportion and was irresponsible to send. SANS made it sound like a virus attack already in progress, not a new vulnerability that someday might be exploited.
And right on the heels of the previous warning, it got lost in the noise. When I received the second SANS e-mail, I thought it was another reminder for the first vulnerability. I'll bet that many users were similarly confused and ignored it as well.
Computer programs have two sorts of vulnerabilities, nicely illustrated by these two attacks. First, they have vulnerabilities connected to the basic design of the operating system they run on and the way it chooses to interlink programs; the Access attack demonstrates this. Second, they have vulnerabilities based on coding mistakes; the buffer-overflow problem is an example.
It's not enough to release a patch. The press often gets this wrong. They think the sequence is: vulnerability publicized, patch released, security restored. In reality, it doesn't work that way. You don't regain security until you install the patch. Even though both of these vulnerabilities have been patched, I predict attack tools that use them. Many users just won't bother installing these patches. For publicizing the two vulnerabilities, SANS is to be commended.
Sensationalizing vulnerabilities will backfire. Both of these vulnerabilities are serious, but neither is monumental. Calling something "the most dangerous flaw" leads people to trivialize other flaws. I worry about the public being completely unable to determine what is important. We've seen viruses that fizzle, and others that run rampant. We've seen vulnerabilities that look serious but don't amount to anything, and ones that are trivial and exploited again and again. SANS needs to be a voice of reason, not of hyperbole.
Writing a virus to exploit a vulnerability is a bad idea, even if the goal of that virus is to close that vulnerability. Viruses, by their very nature, spread in a chaotic and unchecked manner; good system administration is anything but.
There are still lots of serious vulnerabilities in Microsoft products, and the interactions between products, that are waiting to be discovered.
Security technologist and author Bruce Schneier is founder and chief technical officer of Counterpane Internet Security Inc., which provides monitoring and response for Internet sites.