Password security (Section 5.4.5) pre-hashing attack decoy login attack network sniffing attack using OS bugs Viruses (Section 5.4.3) types of viruses countermeasures countercountermeasures
Every virus has a payload, which is some sort of thing it wants to do. Typically, this is either a prank or something more malicious. Additionally, a virus needs some way of reproducing itself. A well-written virus will hide its tracks as much as possible. Generally, it has to hook itself in so that once the user inadvertently starts the virus-containing program, the virus actually executes the program the user requested.
There are many sorts of viruses.
For example, many Unix programmers like to have ``.'' first in their path, so that the shell will always look in the current working directory for their executable. That way, they can type ``a.out'' at the command line, instead of having to laboriously type ``./a.out''. This, however, can cause problems if user A changes into user B's directory, if user B has created an ls executable file in that directory. If user A to execute ``ls'', the computer would execute user B's program instead of the system command. User B's program could do malicious things like delete user A's file (compromising data integrity) or copy user A's files into a publicly readable directory (compromising data confidentiality).
For this reason, Unix system administrators concerned about security set up the default path so that ``.'' isn't included.
+---------+ | data | +---------+ | segment | | data | +---------+ | segment | | virus | +---------+ + - - - - + | text | | text | | segment | | segment | +---------+ +---------+ | header | | header | +---------+ +---------+ original infected executable executable file file
A boot sector virus overwrites the boot sector with a new version, which does whatever the virus wants and then continues with loading the operating system. This way, the virus will run every time the computer starts. Moreover, it gets to run with unlimited access to hardware, since at boot-up time, everything runs in unprotected mode, and it's the OS's job to eventually switch into protected mode.
A skillfully written boot sector virus will find some way to get itself installed as an interrupt handler. Getting it so that it will override the OS's later requests for installing interrupt handlers is a bit of a trick. But, if the virus can successfully do this, then the virus is in a situation where it can execute on a regular basis.
Here we're concerned mostly with countermeasures for parasitic viruses, since they're technically the most interesting. There are two approaches to viruses: prevention and detection.
Unix takes the prevention route. Unix systems generally don't run virus protection, because they're just not necessary. This is because Unix processes work in a very restricted environment: They can only mess with files created by the owner. Since a good Unix user only uses the unrestricted root account when absolutely necessary, and the root account owns all the important binaries, this means that a virus can't get to the good stuff.
This doesn't mean that you can't write a virus for Unix. It's just that it can't do any serious damage to the system, beyond infecting the files of the person who happens to execute it. (Unless, of course, there's a bug in the OS. But the OS writers will release a bug fix just as quickly as a virus scanner team would release a virus scanning fix. And the bug fix will be better, since it will make the system impervious to similar future attacks.)
PC operating systems (pre-NT and MacOS X, at least) always ran in very permissive mode, so that any program can access anywhere on the hard drive. This was convenient, since it enables programs to run more efficiently (instead of always going through the OS), and anyway generally only one user was using the system. So they didn't take the prevention route.
Instead, the industry of virus scanning arose. There are several things that a virus scanner can do.
How can the virus scanner detect changes in the boot sector or in executable files? Typically, it would sum up all the bytes in the boot sector, and store that sum somewhere on the disk. And for each executable file, it could sum up the bytes and store that sum. Whenever the computer boots up (or when the user requests a scan), the scanner goes through the boot sector to check whether the sum of the bytes differs from the sum it has stored. And then it goes through all the executable files to check the sums it has stored for them. (You might think the scanner might just look at the modification date for each executable file, but that's inadequate, since a decent virus would also change the directory entry for the executable file so it appears the file hasn't changed.)
This scheme has several problems: First, all this file scanning takes a significant amount of time. Due to the inefficiency of completely scanning the disk, it would only be done relatively rarely (maybe once a day). Second, it only identifies the virus after it has infected something. (It's like waiting for the murder to take place before apprehending the person plotting a murder. It's too late by then.) Coupled with the fact that the scans are rare, this means that the virus can do a lot of damage before anything happens. Finally, virus scans tend to give false negatives, since sometimes executable files change legitimately (as when the user updates to a new version). Naive users will quickly learn to simply click through any reports of viruses, rather than bother with unlikely reports.
Nonetheless, this technique is a popular piece of virus scanning programs, for one simple reason: It's reliably detects a virus, regardless of what it is.
The database of fingerprints has to grow regularly, as new viruses become widely distributed and so become worth adding into the code. While the database remains stale, of course any new viruses can infiltrate the system without any problems (modulo detection via the previous technique).
Of course, once you go down the road of trying to detect viruses rathre than prevent them, you've opened up a can of worms: Virus writers will simply try to find ways of beating the system. And, after they find a way, the virus scanner writer will have to find a way of beating their solution, and we find ourselves in a vicious circle.
For example, a virus program can work itself around the checksum detection in three ways: First, it can make sure it modifies the executable file in such a way that the checksum isn't modified. (If the checksum is just the sum of all the bytes, the virus first finds the checksum, then infects itself, then adds another byte so that the sum is the same as before.) Second, the virus might infect the file not doing anything, but then it would go off and find where the virus scanner software stores the checksum and modify that. Finally, the virus could simply remove the file that contains all those checksums.
Of course, the virus scanner programmer isn't going take this lying down. The virus scanner might possibly use cryptography to (a) compute a hard-to-invert checksum and (b) encrypt the file containing the checksums. That doesn't solve the problem of a virus removing the file, though if the file disappears, that's at least a detectable problem.
Thwarting the fingerprint database is more complex. But the virus program can basically encrypt itself each time it spreads, so that there's no consistent fingerprint in the virus code that can be searched. In order to execute the code, though, the virus code would have to be decrypted, and so the decryption code would have to be part of the infected file. This decryption code can in fact be the virus's fingerprint searched for by the database.
The virus writer can thwart this, though, by using different code at different times. After all, there are many ways of computing the same thing - for example, you might switch the order in which things are added, or you might switch the order of some instructions that don't interfere, or you might change the register allocation. The virus can be written so that, each time it writes down the decryption code, it writes down a different version that accomplishes the same decryption. Scuh a virus is a polymorphic virus.
The virus scanner writer may be able to find ways to get around this, but you have to keep in mind that the virus scanner writer has the harder job, since the time constraints for the virus scanner are much more severe: Since the virus scanner runs every time any executable file is run, it has to run quite quickly. The virus has more leeway, since it is run only occassionally.
Besides, it's generally easier to hide than to find. When you play hide and seek, does the game spend more time in the hiding phase (while the seeker is counting to 10) or in the seeking phase (when you eventually get bored with sitting still)? Things don't look good for the virus scanners.