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

information from the application resource fork and stores it in a database for easy access. The location of the application on disk is also stored.

To display the icon for a document, the Finder checks its database for an icon corresponding to the document type provided by the application with the same creator code as the document. When a document is double-clicked, the Finder searches its database for an application whose creator code is the same as the document creator code. If found, the Finder executes that application to process the document.

Macintosh hardware. The rst Macintosh models were based on Motorola 68000 microprocessors. We collectively name Macintoshes based on the 680x0 series of microprocessors as \68K Macintoshes" and code intended to run on these microprocessors as \68K code." The PowerPC series of microprocessors replaced 680x0 microprocessors in new Macintosh models. Models with the PowerPC microprocessor are collectively referred to as \PPC Macintoshes" and code, \PPC code." Needless to say, the machine code for the 680x0 microprocessors is not compatible with the newer PowerPC microprocessors. Apple has addressed this problem by supplying a 68LC040 emulator as a part of the operating system for PPC Macintoshes.

The executable of an application can be stored within the application le using the following three basic methods:

{Application based on 68K code is split into a number of code segments. These applications can run under emulation on a PPC Macintosh.

{Application based on 68K code is split into code fragments and also contains a small code segments responsible for starting up the code fragment component on versions of the OS that are not able to automatically perform this task. These applications cannot run under emulation on a PPC Macintosh.

{Application based on PPC code is split into code fragments.

Macintosh viruses known so far work by modifying an application based on 68K code segments. This, however, also makes PPC Macintoshes vulnerable as

{Most PPC applications contain at least a small component based on 68K code which informs a user that the application cannot be run on a 68K Macintosh,

{Not all viruses attempt to modify the application code directly. Some viruses add executable resources like the MDEF resource to an application. 68K de -

622 18 NETWORK SECURITY

CODE

Resource #0

(Jump Table)

0011

0011

CODE Resource #1

CODE Resource #2

CODE Resource #3

Fig. 18.9. Code segment based 68K application

nition procedures added to a PPC application by a virus will still work in a PPC environment.

{ There is every reason to expect that such viruses will be written in the future.

Code fragments are typically stored in the data fork of an application le but may also be stored in resources in the resource fork. A resource known as the code fragment resource or cfrg resource with identity 0 is used to index the fragments. Applications based on code fragments can also import shared libraries. The code fragments within a shared library could potentially be infected by a virus (although no such viruses for the Macintosh are currently known). A code fragment based environment is much more exible and programmer friendly than the 68K code segment environment.

The structure of an application based on code segments is much simpler (Figure 18.9). The executable code of a 68K application is divided into a number of segments and each segment is stored in a CODE resource and may contain one or more routines (note that the second entry of Jump Table in Figure 18.9 contains the address of the second routine stored in the CODE resource #1). This has the advantage that not all resources are required in memory at a particular time to execute programs.

A mechanism is needed to enable a routine located in one code segment to call another routine. Intersegment calls are handled with the aid of a so-called jump table. To invoke a routine in another segment, a jump is executed to the jump table where the addresses of routines are stored. The jump table is stored

in the CODE resource with ID 0. The rst entry in the table contains the address of the routine which gets executed rst. Not all compilers maintain the entire jump table in the CODE 0 resource. Instead, a jump table is constructed in memory on execution.

18.3.6 Macintosh Viruses

Most Macintosh viruses modify the executable code of an application program in some way so that when the program is run, the viral code gets executed. There are two major techniques to achieve this:

{A virus modi es the code segments of the application.

{A virus adds new resources containing de nition procedure that will be invoked implicitly during application execution.

Consider a typical 68K application illustrated in Figure 18.9. A virus can infect the application by changing the code segments in three ways.

{The virus adds a code segment to the application in the form of an additional CODE resource modifying the rst entry of the jump table so it refers to the viral CODE resource. In result, the viral code gets control when the application starts executing. The original rst jump table entry is saved by the virus so that it can return control to the application once it has completed its task. The application original code segments are not modi ed except from the jump table. The infection process is illustrated in Figure 18.10. The viruses: nVIR [174], and the INIT29 [173] are good examples of viruses of this type [175].

{Rather than adding a new code segment to the application, the virus adds its code to the end of an existing CODE resource. The virus need not touch the jump table. Instead, it modi es the rst few bytes of a routine in the CODE resource so that when the routine is invoked, the viral code is called. The bytes replaced by the virus can be saved and restored after execution of the viral code. Figure 18.11 presents how the virus works.

{The virus appends its body to an existing CODE resource and modi es the jump table. When the application is executed, the viral code gains controlrst. The original jump table entry is saved so that control can be returned to the application. This strategy of infection is depicted in Figure 18.12.

There are several ways in which an application can be infected by the addition of a resource containing the code for a de nition procedure. A typical

624 18 NETWORK SECURITY

Jump Table

CODE Resource #1

CODE Resource #2

CODE Resource #3

111111000000 10

Viral Code 10

111111000000 10

10

Original entry point saved.

Fig. 18.10. Modi cations made by virus that adds an additional CODE resource to an application

Jump Table

0011

0011

Fig. 18.11. Modi cations made by virus that adds its code to an existing CODE resource and modi es a routine to jump to the viral code

relationship of an application menu with a default de nition procedure is given in Figure 18.13. Consider the following infection strategies for this case:

{The virus adds a viral de nition procedure with the same type and identity as a standard DP resource from the System le (Figure 18.14).

{The virus adds a viral de nition procedure with a changed identity (Figure 18.15).

The WDEF virus [176] deserves a special attention. This virus infects using a de nition resource. However, the de nition resource is not added to an executable le! The WDEF virus adds a WDEF 0 resource containing the viral code to the resource le on each disk in which the Finder stores its desktop database,

Jump Table

01

CODE Resource #1 000000111111Viral Code 01

00000011111101

01

Original entry point saved

CODE Resource #2

CODE Resource #3

Fig. 18.12. Modi cations made by virus that adds its code to an existing CODE resource and modi es a jump table entry

Fig. 18.13. Typical relationship of application MENU and System MDEF

the Desktop le. This le is opened by the Finder when a disk is mounted. When the user subsequently opens a window within the Finder, the operating system will search for a WDEF 0 resource to perform drawing operation. As the most recently opened resource les are searched rst for resources, the viral WDEF 0 resource stored within the Desktop le will be found and executed in place of the original WDEF 0 resource. All operating systems since System 7 are immune to this attack.

Viral

MDEF 0

Fig. 18.14. Relationship between an application MENU, viral MDEF and System MDEF

626 18 NETWORK SECURITY

Viral

MDEF 16

Fig. 18.15. Relationship between an application MENU, viral MDEF and System MDEF

18.3.7 Macro Viruses

A macro is a collection of statements in some language that performs a task when interpreted. Many application packages allow users to automate tasks which are common and repetitive, by de ning their own macros. Some application packages provide not only a simple scripting language that can be used to control the application usage but also supply an interpreter for a complete programming language. Microsoft Word is probably the best-known of these applications. Microsoft Word 6 provided as its macro language a version of BASIC that was called WordBasic. Microsoft Word 6 was the rst multiplatform implementation for both Macintosh and IBM PC.

The concept of macro virus { a virus written in the macro language { is not new. The possibility of a macro virus was predicted by Highland in 1989 [242]. It was not until 1995 that the rst of macro viruses, Concept, emerged. In March 1999, researchers at Virus Test Center, University of Hamburg reported almost 600 known macro virus strains (for details contact ftp://agn-www.informatik.uni-hamburg.de/pub/texts/macro). Most of these macro viruses target versions of Microsoft Word.

Macro viruses are typically embedded within a document le as a viral macro. Because the macros are interpreted by the application package rather than compiled into machine-speci c executable code, they can execute within their host application on any computer hardware platform to which the application package has been ported. Macro viruses are potentially more infectious than other viruses especially when the infected documents are distributed via e-mail.

18.3.8 Protection Against Viruses

There are two main strategies to combat viruses:

{preventing viruses from becoming established in a computer system,

{detecting and removing them.

There are many nontechnical solutions to reduce the risk of virus infection and hopefully limit the consequences should it occur, including [243]

{careful design of sequence in which the operating system looks for a bootable device,

{recon guration of e-mail system so an received mail item is opened \safely,"

{removal of all executable programs that have been received from untrusted sources (without executing them),

{systematic backups of the system.

The anti-virus techniques can be classi ed into three major categories,

{scanners,

{integrity checkers,

{behavior blockers or activity monitors.

Scanners. A virus scanner tries to detect the presence of a virus in a le by looking for the signature of the virus. As a virus tends to change its code, scanners need to search a le for parts of the signature which are characteristic for the virus. Once a virus is detected, scanners may attempt to disinfect the infected le by removing the virus. However, in some cases, the original form of the le cannot be restored (when the virus destroyed a part of the le, for example). A better way is to replace the infected le from a backup. Scanners exhibit some drawbacks including [101]:

{They can only detect viruses with known signatures.

{Scanners have to be updated every time a new virus is released.

{Polymorphic viruses are diÆcult to detect by scanners.

{Users must regularly run scanners to check disks for infection.

{Large number of false positives when the scanner deals with les written in a foreign language.

628 18 NETWORK SECURITY

The rst weakness can be partially eliminated by the introduction of heuristic analysis [223]. Heuristics are a set of rules that can be applied to executable code to determine whether or not it is infected by a virus. Heuristics can be

{positive { code performing operations suggestive to a virus,

{negative { code performing operations not likely to occur in virus code.

The diÆculties with the detection of polymorphic viruses can be addressed by customising scanners so they work well for a speci c family of polymorphic viruses. A better approach seems to be the application of so-called generic decryption [364]. This approach works for viruses which use encryption to change their form. Such a virus must decrypt the main body of its code before execution. Generic decryption attempts to emulate the program under investigation past the point at which the virus code has been decrypted so the virus can be identi ed from its signature.

To relieve users from the burden of running scanners at regular intervals, a memory-resident scanner component might be provided. This component scans automatically les and disks for viruses when accessed.

Integrity checkers. It is reasonable to assume that a virus must change something when it infects a le. Hashing can be used for integrity checking. Once a le has been created, its hash value is computed. Any modi cation to it will cause a change of the hash value. Note that integrity checkers detect any change in a le not only this created by a virus. So if the hash value has changed, ale may be infected. Obvious limitations of integrity checkers are as follows:

{Viruses introduced before an integrity checker computed hash values for les, will not be detected.

{Integrity checkers fail to detect infection if a le was at the same time modi ed by the user and infected by a virus.

{Viruses can only be detected after they have spread and in icted some damage.

The main advantage of integrity checkers seems to be that they are able to detect unknown viral infections including notorious polymorphic viruses. The reader who wishes to pursue this topic, is referred to [49, 101, 425].

Behaviour blockers and activity monitors. These anti-virus programs monitor the computer activity and attempt to detect the presence of a virus.

The rationale behind behaviour blockers and activity monitors is the hope that it is possible to distinguish somehow between abnormal (viral) and normal behaviour. Clearly, this approach has the following drawbacks:

{Most viruses perform entirely legitimate actions rather than exploiting operating system weaknesses.

{Some viruses may try to bypass the anti-virus programs. For instance, some Macintosh viruses contain code which redirects traps generated by the virus to ROM code. If successful, the anti-virus program will be bypassed, that is, it fails to detect the virus.

{Blocking a suspicious action may result in undesired consequences. For example, les may be left in inconsistent states after a suspicious operation.

{After detecting a suspicious activity, the anti-virus program may leave the decision about what needs to be done to the user. This can be irritating especially when it happens frequently.