Sebery J.Cryptography.An introduction to computer security.1989

has a mechanism by which a TLS implementation can run SSLv3.0 (but not vice versa). The di erences between TLS and SSL are speci ed in [488].

18.3 Computer Viruses

Discovery of computer viruses was one of the most important factors that put network security issues in the spotlight. It turns out that users of personal computers are all at risk from computer virus infections. Recent developments in the computer virus technology, in particular the macro virus that spreads through the exchange of documents prepared using, for example, certain word processing packages, mean that more computer users than ever before will be a ected at some time by a computer virus.

The reader who wishes to further study the topic is referred to [101, 425]. While working on this chapter, the authors were helped by Je Horton who made accessible a draft of his PhD thesis [246]. He also read this part and corrected the text. The authors gratefully acknowledge this.

18.3.1 What is a Computer Virus?

Computer viruses, computer worms, and Trojan horses are all di erent forms of malicious software or malware. Cohen in [99] informally de nes a computer virus as

a program that can \infect" other programs by modifying them to include a possibly evolved copy of itself.

Viruses infect computer programs by changing their structure. The change can take di erent forms, including:

{Destroying data { The Brain virus [241] targeted the IBM PC and was capable destroying of data describing the location of sectors making up les on a diskette and might even overwrite part of a le in the process of infection.

{Stealing CPU time { Consider a virus that asks permissions before infecting an executable le. The creator of the virus can see it as a useful tool while users whose work is interrupted by the virus, can perceive it as a time-wasting nuisance.

{Reducing the functionality of the infected program.

612 18 NETWORK SECURITY

{Adding new, not necessarily, malicious capabilities to the infected program { Cohen in [99] discusses a virus that compresses executable les on infection and which decompresses the le on execution.

There is increased research activity related to the problem of detection and removal of computer viruses. Detection of viruses is not easy, as viruses tend to mutate after infection. That is why Cohen used possibly evolved in his de nition. Designers of computer viruses intentionally create viruses that are able to mutate after infection to make detection of viruses by anti-virus software more diÆcult.

Cohen's de nition is too restrictive, as it fails to include a program that is able to attach itself to a host program by some means other than altering the code of the host program, but otherwise would seem well-described by the tag of \computer virus." The companion strategy of infection is an excellent example of this. For this reason, the above de nition can be extended as follows:

A computer \virus" is a program that can \infect" other programs by modifying either host programs or the environment in which host programs exist. A possibly mutated copy of the virus gets attached to host programs.

The above de nition can be further extended by requiring viruses to be capable of further replication. A formal de nition of a computer virus is given in [100].

18.3.2 Worms and Trojan Horses

Informally, a computer worm can be de ned as

a self-replicating and self-contained program that is capable of spreading itself to other machines.

Unlike a virus, a worm does not infect or otherwise depend on a host program. It is self-contained.

The Internet Worm unleashed in November 1988 is probably the most famous example of a worm. The worm exploited a number of known security holes in the UNIX operating system. It consisted of two programs: a grappling hook (or bootstrap) program and the main program [470]. The grappling hook was a short C program. Once established in a foreign machine, the grappling hook compiled and executed. During the execution, it connected to the machine from

which it had originated and uploaded a copy of the main program. The task of the main program was to search the Internet for other machines that could be easy victims, i.e. machines that would allow remote execution of the grappling hook without proper authorization.

Recently, the Autostart worm for the Macintosh was reported and is described in [258]. The worm exploited the ability to designate a program on a diskette or hard disk to be executed when the disk was mounted by the operating system. Unlike the Internet Worm, it spread via the transfer of infected disks from one machine to another.

A Trojan horse program can be de ned as

a program that claims to perform a particular function suÆciently attractive to the computer user to ensure that the user executes the program. Instead of, or perhaps in addition, to performing this function, the Trojan horse takes some form of undocumented action, often malicious, that was intended by the programmer.

Note that this de nition excludes programs that cause destruction as a result of bugs in the program. Trojan horses, unlike viruses and worms, do not replicate themselves. Malicious actions undertaken by a Trojan horse can range from a relatively simple action, such as deleting les, to more subtle activities such as gathering private information about users. It is not diÆcult to imagine a Trojan horse that collects secret session keys from a user`s hard disk and sends this information out over the Internet for collection at a remote site.

18.3.3 Taxonomy of Viruses

The risk of infection greatly depends on the hardware platform in use. Consider the three following platforms:

{IBM PC { users of this platform are the worst a ected. It is reported in [364] that more than 10,000 DOS-based computer viruses have been created as at November 1996.

{Macintosh { users have also been a ected by the computer virus problem, but not to the same degree as users of IBM PCs. Estimates vary, but there are certainly fewer than 100 viruses speci cally designed for the Macintosh platform.

614 18 NETWORK SECURITY

{UNIX { users are fortunate, as there is no common virus threats against this platform. However, the potential exists for viruses to be written for this platform [99, 101, 162, 332].

Any computer platform where programs are stored on modi able media is subject to attack by computer viruses. In general, viruses can be divided into two broad classes,

{platform dependent, and

{platform independent.

Platform-dependent viruses normally exploit a speci c hardware/software con-guration characteristic for the platform. Macro viruses are a newcomer in the area and are platform independent. Macro viruses are written in interpreted languages supplied by some common programs (applications) that are available across multiple platforms. A good example such an application is Microsoft Word. It is available for both IBM PC and Macintosh computers.

Viruses infect only executable les. To activate them, the host program must be executed. A virus can be either

{Memory resident { the virus remains active even after its host program has terminated.

{Non-memory resident { the virus becomes active only if its host program is executing.

Writers of computer viruses use two main strategies to make the detection of viruses more diÆcult. The strategies are:

{Polymorphism { a virus changes its form using variety of techniques including encryption.

{Stealth { a virus tries to conceal its presence in infected objects when executing.

A sequence of bytes considered characteristic of a virus is called the virus signature. To detect a virus, it is enough to scan the program for a virus signature. Polymorphism attempts to minimize the number of bytes available for use in a virus signature. There are two parts to the strategy.

{The virus encrypts the main body of the virus code using a variable key when infecting. A range of di erent simple schemes would be used. Before the encrypted virus can be executed, it must be decrypted.

1. Program before infection by overwriting virus.

Program Code

2. Program after infection by overwriting virus.

0000011111Viral Code Program Code

00001111

Fig. 18.5. Host program before and after infection by overwriting virus

{In addition to choosing between a variety of di erent encryption and, hence, decryption schemes, the virus applies equivalent machine instructions, reordering instructions (if the new order of instructions leads to equivalent operation), inserting dummy instructions (for instance, no operation instruction), building up a code during runtime (once constructed, the code performs the required task), and using intermixing operations [101].

18.3.4 IBM-PC Viruses

This class of viruses is the biggest and can be divided into three groups,

{le infecting viruses,

{boot sector infecting viruses, and

{multipartite viruses (infecting both executable les and boot sectors).

File infecting viruses. The simplest type of le infecting virus overwrites part of the host program and does not store the code that was overwritten. The host program before and after infection is illustrated in Figure 18.5. The virus overwrites the beginning of the le so the virus will get executed every time the host program is invoked. The host program is likely to be so badly damaged that it is unable to function correctly. The viral code may also be placed elsewhere in the le hoping that it gets executed every time the host program is called leaving most of the host program functions intact.

More sophisticated viruses attach to a host program in such a way that the host program is repairable by the virus. A simple way of infecting an executablele so that any changes made are repairable is to append the virus code to the end of the le, save the rst few bytes of code for later restoration, and replace them with a jump to the appended viral code. When the host program

616 18 NETWORK SECURITY

1. Program before infection by appending virus.

Program Code

2. Program after infection by appending virus.

Jump to start of viral code

3. On execution, control passes to viral code. Virus repairs program code.

Program Code 000000111111Viral Code

0000011111

4. Virus executes original program.

Fig. 18.6. An appending virus

1a. Program before infection by prepending virus.

Program Code

2a. Viral code prepended, program code shifted.

000000111111Viral Code Program Code

0000011111

Fig. 18.7. A prepending virus

is executed, the viral code receives control rst, can repair the code of its host and call it Figure 18.6. It is also possible to prepend the viral code to the hostle Figure 18.7.

If a virus avoids overwriting, it means that the infected program (the host with the virus) has increased its size. This fact can be noticed by a user or a program monitoring the sizes of executable les. There are, however, ways in which a le can be infected without changing its size, yet the host code can be repaired by the virus at time of execution.

{A cavity virus nds an area of constant data within the host program that is large enough to accommodate itself, records the value that was originally stored there and replaces the constant data with itself. The Lehigh virus [101] operated in this way.

{A cavity virus might also store itself inside unused spaces within an executablele that exist as a consequence of the format of the le. The CIH virus applies this technique [521].

{A compression virus compresses all or part of the host le contents so it can hide inside the host program without changing the size of the le. The compressed component can be uncompressed at runtime.

Boot sector infecting viruses. Every time a computer is switched on, the operating system is loaded from a oppy or hard disk. This process is called bootstrapping. The bootstrapping process proceeds in several stages. When the operating system is loaded from a oppy disk, the rst sector on the disk, referred to as the boot sector or DOS boot sector, consists of a small program that is responsible for starting the next stage. If the disk does not contain an operating system, this sector includes a program which informs the user that this is not bootable disk prompting for the insertion of another disk.

Hard disks are, because of their large size, often divided into a number of smaller logical parts called partitions. The rst physical sector of a hard disk is referred to as the master boot record (MBR) or master boot sector (MBS) and contains a record of the partitions into which the disk has been divided, together with a small program responsible for locating a bootable partition and booting from that partition. The rst logical sector of a bootable partition is then the boot sector that is used to load the operating system (Figure 18.8).

Boot sector viruses infect the code found in the master boot record for hard disks or in the DOS boot sector for oppy and hard disks. The infection process normally looks like this. A virus

{nds the target sector and stores it elsewhere so the virus can continue the boot process,

618 18 NETWORK SECURITY

Floppy Disk Startup:

Hard Disk Startup:

Fig. 18.8. Boot process for oppy and hard disks

{loads a copy of itself into the sector. Examples of this type of viruses are

{AntiCMOS viruses { a virus from this family discards the code from the infected sector and attempts to perform the boot functions itself [270].

{Brain viruses { a virus infects oppy disks only [241].

{Monkey viruses { they infect boot sector and store the partition tables elsewhere so that infected hard disks are inaccessible if computers are not booted from the virus-infected hard disk [351].

{Hare Krisna { they tamper with location of the partition tables [526].

Companion viruses .

Companion viruses do not modify host programs they infect. Instead, they create their copies as separate executable les. There are two basic types of companion viruses under MS-DOS [49, 247, 319].

{Regular companion { a virus of this type create a le in the same directory as the host program but with a lename extension that usually gets executed before the extension used by the host program. For example, a .COM le with the same name as an .EXE le and in the same directory is executed before the .EXE le if the le extension is not speci ed.

{Path companion { a virus creates a le with any executable extension in a directory that is searched for executable les before the directory containing the host program.

{Surrogate companion { a virus renames the host program and replaces it with a copy of itself.

18.3.5 Macintosh Operating System

To discuss viruses a ecting Macintosh platform, we rst need to introduce necessary background about Macintosh operating system. For more details the reader is referred to [250, 251, 252, 253].

Any Macintosh le has two components,

{data fork,

{resource fork (or resource le).

A characteristic feature of the Macintosh OS is that each le has its

{type, for example, application (APPL) or ASCII text (TEXT),

{creator or the application program which owns the le.

Resources within a resource le are described by

{a resource type (four letter code),

{an ID number (two-byte integer),

{a name (string of characters).

To identify a particular resource, it is enough to specify a resource type and either an ID number or a resource name. An application resource le stores a variety of information including:

MENU stores information about the list of options in a particular application menu.

MBAR lists the menus that are present in an application's menu bar.

WIND describes the dimensions and other characteristics of a window created by an application.

CNTL de nes a control which is a user interface element such as a button or scrollbar created by an application.

CODE contains main components of an application executable code.

Loading resource may involve many resource forks. A search path is followed to locate requested resources. The starting point is always the current resourcele and the search ends in the System le that contains resources which are part of the operating system.

Consider the graphical user interface presented by an application. Many of the interface elements such as menus, windows, buttons, etc. are drawn by de nition procedure (DP). The executable code of a de nition procedure is

620 18 NETWORK SECURITY

stored in a resource and loaded by the OS when required to draw a user interface element. The OS provides a default implementation and it can be customized by a user. Examples of de nition procedures include

{Menu DP { is stored in an MDEF resource and is responsible for drawing menu items within a menu.

{Menu bar DP { is stored in an MBDF resources and is responsible for drawing activities related to the display of menus.

{Window DP { is stored in a WDEF resource and is responsible for such tasks as drawing frame or resizing a window.

{Control DP { is stored in a CDEF resource and is responsible among many tasks for drawing the control and testing for where the mouse has been clicked by the user within a control.

The INIT is another important type of resource containing executable code. These are resources that contain code that is intended to be executed at system startup. INIT resources can be located within the System le itself or in les of particular types.

The Finder is an application which is a part of the Macintosh operating system. The Finder

{manages the display of the user desktop,

{keeps track of the location (both on the screen and on the disk directory structure) of les and folders,

{ensures that the appropriate application is used to work with a le created when the le is double-clicked by the user.

Under Macintosh system software prior to System 7 (System 6), \Finder" refers to a version of the software that would permit only one application at a time to execute. That is, users could run the Finder or some other application but not both at once. MultiFinder was a re nement of the Finder that would permit more than one application, including MultiFinder itself, to execute at a time. System 7 and later use Finder to refer to a version of the software descended from MultiFinder { more than one application at a time, including the Finder, may be executed.

Application developers are able to designate an icon for each type of le that is created or owned by the application. These icons will be displayed by the Finder to represent the user documents. Icon information is given by resources from the application resource fork. The Finder extracts this and other