© Conrad Weisert, Information Disciplines, Inc.
February, 1999
NOTE: This document may be circulated or quoted from freely, as long as the copyright credit is included.
Press accounts of the recent worldwide dissemination of the "Melissa virus" failed both to identify the real victims and to assign full blame for the damage.
A week seldom goes by without some URGENT E-mail message, warning of a malevolent virus program embedded in some innocent-looking piece of E-mail. The sender claims that the virus will infect my computer and seriously damage my files if I should look at or even retrieve that other E-mail message. One such warning even claimed that the virus would destroy my hardware!
Knowledgeable computer users recognize such warnings as hoaxes, either originated by pranksters or passed on by the gullible. Opening a data file and displaying its contents can hardly launch a virus program. You have to execute something, i.e. deliberately launch a program before a virus can do anything.
The Melissa virus came not in an actual E-mail message but in a file attachment. Recipients who simply read the message and disregarded the attachment neither suffered themselves nor passed on the virus program. That's exactly what we should always do when someone sends us an unsolicited and unexpected file attachment.
E-mail is for messages. On those occasions when we want to use E-mail to move some other kind of file we ought to make prior arrangements, so that we're expecting it when it comes and can trust the source.
Those who naively opened the attached files were not Melissa's victims but Melissa's accomplices. The real victims were the next hundreds of further recipients to whom the virus forwarded additional copies, as well as dozens of overloaded E-mail servers.
The wise policy, then, is just to ignore unexpected file attachments to E-mail messages.
But if the attachment itself is just a data file, how can opening it possibly launch a virus? Read on.
Return to IDI home page.
We know that the author of the Melissa virus was identified and is being charged with serious crimes. That's reassuring, but the virus author wasn't the only villain in this case.
The Melissa attachment didn't look like a program. A file-name suffix of
.EXE would have tipped off most recipients
to the danger. But the file was not an executable program, but a
word-processor file. How could the act of opening a file under control of
a mainstream word processor launch any program?
The culprit was a word-processor executable script (sometimes historically and erroneously called a "macro"), not just any script but specifically one that executes automatically whenever the file is opened. A script is a program; it executes; it gets control.
Older scripting and macro languages were limited to mimicking keystrokes, but modern ones have the power of a full programming language. Obviously, perpetrators of virus programs were delighted to discover and exploit this enhanced capability.
The danger of such virus transmission is avoided if we can open the file and look at it while suppressing execution of any automatic macros. An obvious and basic software design principle is:
Any software product that supports AutoOpen or AutoLoad scripts must also provide a simple open-without-script-execution option. That option must be easy to invoke both for specific files as a standard default. (This principle not only protects users from viruses, but also shields developers from frustration when trying to debug a new script that loses control.)
Obvious as that principle is, some mainstream word-processors and spreadsheet processors violate it. IDI strongly recommends to its clients a firm corporate policy prohibiting the purchase, installation, or use on their networks of any software product that violates that principle. After a few large corporations or government agencies start enforcing that policy, the software vendors will get the message. Some of the guilty vendors, in response to irate customers, have already added the open-without-macros option to their latest versions.
The Microsoft Windows environments are especially vulnerable to virus programs of all kinds, due to their lack of disciplined control over access to system resources. We see evidence of this whenever we install some new software product that insists on stuffing components into the operating system directories and updating various libraries and control files. (This anarchic approach has, in turn, necessitated the nototious Registry facility.)
Thirty-five years ago IBM's new OS/360 was designed around appropriate protections against either accidental or malevolent damage. Specifically:
To be sure there were some bugs and oversights in that scheme. It was discovered, for example, that you could store information in an accessible control block that would later trick the operating system itself into violating the protection model in some diabolical way. Some of those flaws got fixed in later versions, while others never did, but both the vendor and the users understood and accepted the principle that application programs could not control the whole hardware/software configuration and do anything they pleased.
The designers of today's mainstream desktop and network operating systems (which have grown larger and more complicated than their mainframe precedessors) failed to learn basic lessons from the immense body of established operating system principles and experience. Aren't they as much to blame for the impact of virus programs as the authors?
Return to IDI home page.