I understand that virus mail tricks the email system into opening it and starting it executing, as though it were an intended executable.
What I don’t understand is when was there ever an intended executable in email?
Surely, the email system is primarily treating the email as data, not as an executable. At what point does it say, Ok now I’m turning control over to something else, not just keeping control myself.
Who would have invented it? And why isn’t it simply blocked now as a mistaken “feature”?
Your basis premise is incorrect. Most viruses don’t “trick the e-mail system” into running them. They trick the user. The recipient clicks on the infected attachment and gets infected.
There were some viruses that supposedly could run on Outlook without any user intervention. The most famous of these was “bubbleboy,” but that was never a serious threat and was barely seen in the wild. In cases like that, they would take advantage of a security flaw. The flaws are patched as they are discovered, so this is not usually the way e-mail viruses are spread.
I don’t know of any e-mail client that automatically runs executables (the ones that had their flaws exploited were running scripts). It makes little sense – it’s such a bit security hole that even Microsoft could see it, and even if the file is legit, it’d be up to the user to decide when to run it, not the e-mail.
If you want to ask about the scripts, MS put that feature in for convenience, and didn’t really consider the security aspect.
these aren’t really viruses in any real way… they are just programs… and it would be a real design flaw if windows could not run programs… I mean why would you own windows if it couldn’t open programs?
Apparently “scripts” run without specific action.
That’s according to RealityChuck.
So what are these scripts and why would they have been used to start with?
IIRC, the big problem with “instant-infect” viruses (virii?) was the Preview Mode. Basically you could take a quick look at the message before actually opening it… but doing so, um, opened it, and ran the code. Oops.
There is one way to set up Outlook to automatically run certain types of code when you open an email - that’s if you set it to use MS Word to read your email, you do not set Word to disable macros in unfamiliar documents, and someone emails you a .DOC file with a Word macro virus in it. This one is such a strange security hole that I’m sure more people simply opened the attached document than had Outlook automatically run it.
A script embedded in an HTML email could reach out to a server to retrieve new content (say, a stock quote) or could provide some interactive element on the email.
VBA is used extensively to add programming capabilities within apps. For example, an Access database can have a pretty front-end that includes a lot of pre- and post-processing of the data held in the back-end tables. An Excel spreadsheet might contain a complicated calculation in VBA instead of simply in spreadsheet formulas if it needed to be called from various places as a subroutine or needed more functionality that basic spreadsheet functions allowed.
ActiveX is just a method for calling external code. It may be embedded content, analogous to a Flash movie or a Java applet, or it may be an external resource like a DLL. The VBA code you embed in a spreadsheet might reach out to an ActiveX DLL for a certain calculation so you could access that calculation easily from multiple spreadsheets without duplicating the code.
A macro might perform a specific reformat operation multiple times so the user didn’t have to do repetitive things, such as setting up unformatted data to print as mailing labels.
To oversimplify things a tad, on a typical Windows installation, the user is given “root” (or “superuser”) privileges. In short, the user is God, and can do anything he damn well wants to with the PC. Which is fine and dandy most of the time, until he runs a program that includes commands like “erase everything on the hard disk” or “install secret spyware program.” There are mechanisms to create user accounts with limited privileges, but most home users won’t even be aware of the matter, much less set them up.
In contrast, other platforms will use limited privileges to reduce this kind of damage. Java applets, for instance, run in a “sandbox”, and any damage is limited to the sandbox alone, isolated from the rest of the system. With MacOS X, any attempts to change or delete important files or change critical computer settings requires the user to enter his username and password for authorization, even for the highest-privileged “Administrator” accounts. At worst, the user might mess up his own account space, but the rest of the computer will be untouched.
micco - Thanks for the examples. I see what’s happening now.
I tend to forget that people compute with computers, since I only process words.
My personal use is really something would never have to leave rjung’s “sandbox”.
Let me clarify – the scripts only ran without you opening the message if they exploited the security flaw.
It isn’t the scripts that are convenient – it’s the display feature that lets you see the message in a window without clicking on the e-mail. Due to a flaw, these displays could be tricked into executing a script.
)