relationship. Developers must consider the trade-offs between usability and security when designing or developing a new system. In this article, I argue that macro viruses show how important it is to consider both sides of this trade-off, and also that, in some cases, security is usability.
A "macro," in this context, refers to a small program generally used for automating frequent tasks. Many programs provide some form of scripting language, especially office suite software, such as Microsoft Word or StarOffice. Macro viruses are programs (generally actually worms, not viruses, say the security people) contained within a document and run automatically as part of opening this document. When run, the macro embeds itself in other documents, or otherwise infests the new target system. Some earlier viruses did nothing but spread themselves, or perhaps play a prank. One previous virus simply occasionally replaced words with "Wazoo!".
In response to these early macro viruses, virus software companies began introducing simple filters to scan documents and eliminate viruses before they caused considerable damage, which generally had not been necessary before.
The first macro virus to gain really widespread fame was doubtless the virus named "Melissa," which sent out email containing a Microsoft word attachment and "I love you" in the subject field. The virus spread amazingly quickly, because it took advantage of the scriptability of Microsoft Outlook to harvest more e-mail addresses and send itself to many more users. This virus did a substantial amount of damage. Estimates vary, but many companies had to shut down their corporate e-mail system to keep it from melting down under load and infecting every computer in the company. A month or so later, a similar virus called "LOVELETTER" spread itself the same way sending millions and millions of messages worldwide with the subject "ILOVEYOU". In fact, this wasn't a macro virus; just a worm. But the same technique (using Outlook and attaching the virus to a document) was used. The default execution of anything executable, without prompting, led to a widespread epidemic.
Once again, virus software companies continued to react by scanning for more viruses. Microsoft has gradually introduced features to try to contain the damage, but new macro viruses show up, and each finds a new hole to exploit.
The problem, however, is not that we aren't updating our virus databases often enough. The problem lies in the automatic execution of a script. If the user had to consciously choose to activate the macro, then the vast majority of users would probably not spread the virus. The difference, in a geometric growth curve, could mean fewer machines to scan for a new virus, and fewer corporate mail servers shut down for a day.
A particularly bad design only offered "Open this file and execute any attached scripts" or "Don't open this file" as options for users, which is spectacularly wrong. The best choice is to make it easier for the user to look at the file itself, rather than execute the attached code. Various arguments have been made about files that "might not look right if the macro isn't run." But in that case, the user can always choose to run the macro later -- that is, if the file looks like one he was expecting, which needs to be updated. Although not completely reliable, this option would still decrease the risks of substantial damage to corporate systems.
The most interesting part of this, though, is the question of when the first programmers realized that automatic execution of commands in a data file could be a security risk. Early versions of the UNIX editor vi had an option called modeline, which allowed the first few lines of a file to contain instructions for vi -- originally, this was used to set tab stops and other editor features. Unfortunately, instructions varied greatly, and a few machines sustained malicious attacks. When the nvi editor (a mostly backward-compatible clone of vi) was released, the documentation contained the simple statement that "the modeline option will never be implemented." To this day, it hasn't been implemented. In another vi clone, vim (the modeline option) has been implemented, but with restrictions to keep it from being used for trojan horses.
Keith Bostic, the developer of nvi, explained it this way: "The problem is that people can't use those features anyway, because they know it's an ongoing security problem, and as [Microsoft] fixes more and more problems, the functionality that is available will continue to decrease -- they're cutting off the dog's tail an inch at a time, hoping it will hurt less." So rather than gradually building fences around the option, he simply removed it, and the security hole with it.
The difference in the response is notable. The security problem -- even though it probably didn't affect most users -- was seen as a serious problem to which developers responded. However, the dangers in executing code out of possibly untrustworthy data files were analyzed and understood more than a decade before Microsoft's products started having the problem.
One of the most surprising secondary effects of macro viruses has been the policies that have been adopted to protect against them. Since, in practice, it is impossible for many programs to be functionally secure, many companies have adopted a policy of refusing e-mail with any sort of attachment in it, no matter what that attachment is. This policy is probably the only way companies can avoid virus infection -- as long as they're using tools which have the same vulnerabilities, and in which those holes haven't been closed.
Thus, apart from the obvious damage done (and it has been quite impressive, with whole weekends during which many companies were unable to use their mail systems at all), macro viruses have crippled the use of e-mail as a mechanism for exchanging data. While many companies accept attachments, a sufficient number of these companies denies them to avoid the possibility of impeding daily work routines. Meanwhile, the additional costs of research, development, and constant updates to anti-virus software are hardly trivial. Before macro viruses, very few people perceived a need for daily updates to anti-virus databases.
The key to preventing damages from macro viruses is the tradeoff from usability to security. Empirically, macro viruses have done an amazing amount of damage, both directly and indirectly. The question is, what usability would we lose by closing these holes? The answer to this question is debated back and forth endlessly. After all, can we really expect end users to know what a macro is, or why they should execute it? In fact, this argument can be turned around. If we are concerned that some users may not be able to activate a macro when they should, why would we think they will know when they shouldn't? Given the huge costs inflicted on everyone by macro viruses, perhaps we should opt for the safer default.
It is interesting to observe that comparable attacks are not found for many other software suites. Market share may explain this difference, making Microsoft's products more obvious targets. But it seems as though there ought to be some problems with other products -- unless the other products are, in fact, more secure.
In practice, most users never intentionally use any kind of editor macro and never miss such a feature. Furthermore, if the default settings did not allow the execution of macro viruses, users might have never heard of them. The problem is not related to a lack of virus software updates; the problem is the total lack of basic security in a specific suite of applications. In this case, the usability vs. security tradeoff doesn't play out. Better security would have preserved important functionality for a great number of users and prevented damages estimated at anywhere from millions to billions of dollars.
This month's action item: Try to estimate how much time you've personally lost to programs which are too willing to run code you didn't want them to.
author Peter Seebach has been having trouble navigating through badly designed pages since before frames and JavaScript existed. He continues to believe that, some day, pages will be designed to be usable, rather than being designed to look impressive. You can reach him at [file://localhost/home/seebs/ic/crankynew/crankyuser@seebs.plethora.net] crankyuser@seebs.plethora.net.