1028 lines
50 KiB
Plaintext
1028 lines
50 KiB
Plaintext
|
|
|
|
|
|
Virus Detection Alternatives
|
|
|
|
|
|
Patrick Min
|
|
|
|
Leiden University
|
|
Department of Computer Science
|
|
Niels Bohrweg 1
|
|
2333 CA Leiden
|
|
The Netherlands
|
|
|
|
Email : Min@rulcri.LeidenUniv.nl
|
|
fidonet : 2:512/2.24
|
|
|
|
|
|
|
|
An evaluation of different techniques for virus
|
|
detection. The discussion is sufficiently general to
|
|
be applicable to a substantial number of computing
|
|
platforms. All mentioned practical issues concern
|
|
the MS DOS operating system. Improvement of the
|
|
operating system is presented as the most
|
|
fundamental and therefore effective way to tackle
|
|
the virus problem.
|
|
|
|
|
|
|
|
|
|
Published July 1992 by the Dutch National Criminal Intelligence Service (CRI),
|
|
Computer Crime Unit, PO Box 20304, 2500 EH, The Hague, The Netherlands.
|
|
|
|
|
|
Contents
|
|
|
|
|
|
I. Introduction 2
|
|
|
|
|
|
II. Theoretical implications 3
|
|
|
|
|
|
III. Signature Scanning 4
|
|
III.1. Description 4
|
|
III.2. Capacity Problems 4
|
|
III.3. Update Requirement 4
|
|
III.4. Polymorphic viruses 5
|
|
|
|
|
|
IV. Heuristical Scanning 7
|
|
IV.1. Description 7
|
|
IV.2. Discussion 7
|
|
|
|
|
|
V. Integrity Checking 9
|
|
V.1. Description 9
|
|
V.2. Discussion 9
|
|
|
|
|
|
VI. Monitoring 11
|
|
VI.1. Description 11
|
|
VI.2. Discussion 11
|
|
|
|
|
|
VII. Hardware Protection 12
|
|
VII.1. Description 12
|
|
VII.2. Discussion 12
|
|
|
|
|
|
VIII. Miscellaneous Methods 14
|
|
VIII.1. Software Write Protection 14
|
|
VIII.2. Vaccination 14
|
|
VIII.3. Bait Programs 14
|
|
|
|
|
|
IX. Operating System Improvement 15
|
|
IX.1. Present Situation 15
|
|
IX.2. The Responsibility of an Operating System 15
|
|
IX.3. Suggestions for Improvement 16
|
|
IX.4. Conclusion 16
|
|
|
|
|
|
X. Conclusion 18
|
|
|
|
Notes 19
|
|
|
|
Bibliography 21
|
|
|
|
Proof Readers 23
|
|
|
|
|
|
Part I
|
|
Introduction and Problem Definition
|
|
|
|
|
|
-2-
|
|
I. Introduction
|
|
|
|
|
|
The phenomenon computer virus poses a threat to the
|
|
reliability of automated systems. Considerable research effort
|
|
has been put into the issue of how to detect and erase a
|
|
virus. As a result, there are now several sophisticated anti-
|
|
virus programs available. The most widely used detection
|
|
method of these anti-virus programs is the so-called
|
|
"signature scanning".
|
|
|
|
Recently, a new problem has arisen: for several reasons, the
|
|
signature scanning detection method is rapidly becoming
|
|
inadequate, and will eventually become obsolete. Therefore,
|
|
alternative methods must be devised.
|
|
|
|
In this paper we will attempt to evaluate different approaches
|
|
that currently are in an early stage of development compared
|
|
to signature scanning. In the next chapter, some theoretical
|
|
background is provided on virus detection in general. After
|
|
that, signature scanning and its drawbacks will be examined.
|
|
In chapter four to seven four main other anti-virus methods
|
|
are discussed, namely heuristical scanning, integrity
|
|
checking, monitoring and hardware protection. After treatment
|
|
of some miscellaneous methods in chapter eight, chapter nine
|
|
addresses the issue of operating system improvement, and
|
|
investigates in what ways the previously mentioned methods fit
|
|
into the operating system.
|
|
|
|
-3-
|
|
II. Theoretical implications
|
|
|
|
|
|
In this chapter we will try to discuss some theoretical
|
|
implications with respect to virus detection. This includes
|
|
defining a virus and discussing virus detection from a general
|
|
point of view.
|
|
|
|
First, a definition of a computer virus, originally given by
|
|
Cohen:
|
|
|
|
"A computer virus is a program that can 'infect' other
|
|
programs by modifying them to include a, possibly
|
|
evolved, copy of itself." [1]
|
|
|
|
As we are looking for a way to see if a specific program is a
|
|
virus, we will have to examine the actions, or behaviour, of
|
|
this program. Of course an expert can analyze the instructions
|
|
of a specific program and prove it is a virus, but that is not
|
|
the issue here. The actual question is if there exists a
|
|
general method, an algorithm, that when given a program as
|
|
input, outputs "yes" if this program is a virus, and "no"
|
|
otherwise. In practice, one would want to implement this
|
|
algorithm to produce a perfect virus scanner.
|
|
|
|
An informal reasoning about the detectability of viruses is
|
|
given by A. Padgett Peterson, in which he uses the fact that
|
|
the behaviour of viruses includes attempts to make changes:
|
|
|
|
"Computers are designed to run programs. Viruses are
|
|
programs. e.g. Computers are designed to run viruses. -
|
|
Old Adage. Viruses perform actions which SHOULDN'T occur
|
|
during normal computer operation except in special cases.
|
|
- My thought. Viruses cause changes - its in their
|
|
charter. Therefore, viruses ARE detectable by looking for
|
|
changes (or attempted changes) that should not occur." [2]
|
|
|
|
This does not solve our problem: in fact it has become the
|
|
problem of how to determine that a change should not occur.
|
|
|
|
Cohen proved that the problem "Is a virus recognizable by its
|
|
appearance?" is undecidable.[3] In a virus' appearance there
|
|
will be attempts to make changes. The proof of Cohen does not
|
|
imply that, after one sees a virus' appearance, one cannot
|
|
conclude that it is a virus. The proof tells us there is no
|
|
automated way, no algorithm, that is able to always come to
|
|
such a conclusion. In other words, a perfect virus scanner is
|
|
impossible.
|
|
|
|
-4-
|
|
III. Signature Scanning
|
|
|
|
|
|
III.1. Description
|
|
|
|
A computer virus is a program, which means it consists of
|
|
instructions and data. Certain parts of it are highly likely
|
|
to be unique, meaning these will not be found in any other
|
|
program. So when one would find such a specific part of a
|
|
virus in a file, one can conclude it almost certainly contains
|
|
the virus.
|
|
|
|
All instructions and data of a program are stored as numbers.
|
|
Consequently the unique part of a virus used to identify it is
|
|
a sequence of numbers. This identification sequence is called
|
|
a signature. A signature scanner merely checks all the files
|
|
on a disk for the presence of virus signatures.
|
|
|
|
|
|
III.2. Capacity Problems
|
|
|
|
The number of viruses that are discovered is growing at an
|
|
ever increasing rate. In 1991 there were twenty times as many
|
|
virus specimens available than in 1989. The number of reported
|
|
infections increased by a factor of seven.[4]
|
|
|
|
Every new virus causes a signature to be added to the list of
|
|
all known signatures. Hence a signature scanner will need more
|
|
time after every signature list update.[5] Users will become
|
|
less inclined to use a certain scanner if they will have to
|
|
wait for it longer. In general, there is an obvious trade-off
|
|
between the user-friendliness of a system and its level of
|
|
protection.
|
|
|
|
|
|
III.3. Update Requirement
|
|
|
|
In order for a virus to be detected by a signature scanner it
|
|
must first have been discovered. Only then a signature can be
|
|
determined and included in scanner updates.
|
|
|
|
One would want to discover a virus before it activates and,
|
|
for instance, destroys a harddisk. There are several known
|
|
cases of viruses that have not been discovered before their
|
|
activation.[6]
|
|
|
|
The question arises whether or not there is a significant
|
|
number of undiscovered viruses. It is our belief that as long
|
|
as signature scanning is the most often used detection method,
|
|
a well written virus has a considerable chance of remaining
|
|
unnoticed until it activates.
|
|
|
|
Even after a virus has been discovered, and its signature has
|
|
been included in scanning package updates, it will still
|
|
continue to spread until everyone whose disks are infected
|
|
with it has obtained an update. This requirement to obtain
|
|
|
|
-5-
|
|
|
|
updates on a regular basis lays a burden on users: in order
|
|
for the scanner to remain valuable, not a single update must
|
|
be missed. Again, this reduces a system's user-friendliness.
|
|
|
|
III.4. Polymorphic viruses
|
|
|
|
Several particular viruses modify themselves in such a way
|
|
that identification using a signature becomes more difficult
|
|
or even impossible. This can be done for instance by
|
|
encrypting the virus, and adding a different decryption
|
|
routine each time it copies itself. Such viruses are called
|
|
polymorphic, or mutating viruses.
|
|
|
|
In order to identify a polymorphic virus, it has to be
|
|
analyzed, and a specific detection algorithm has to be
|
|
written. This extra complicates the task of writing scanning
|
|
software. Eighteen months after it was discovered, the until
|
|
recently most sophisticated polymorphic virus could be
|
|
detected in all its forms by about half of the available
|
|
scanners.[7] This virus is evaluated as being orders of
|
|
magnitude simpler than the scheme used by the "Mutation
|
|
Engine", which will now be discussed.[8]
|
|
|
|
|
|
III.4.1. The Mutation Engine, A Polymorphic Virus Generator
|
|
|
|
A Bulgarian virus writer has written a utility, called
|
|
"mutation engine" (mte for short), which can be used to turn a
|
|
virus into a polymorphic one. This virus can either be a newly
|
|
written virus, or a modified existing virus. In the latter
|
|
case, an existing virus would have to be substantially
|
|
modified.
|
|
|
|
The utility consists of an object module that has to be linked
|
|
to the virus, and contains a subroutine which the virus has to
|
|
call each time before it copies itself. The subroutine
|
|
encrypts the virus using a random key, and generates a
|
|
randomly formatted decryption routine, which is prepended to
|
|
the encrypted virus. The length of the resulting module is
|
|
variable as well. The degree of mutation is much higher than
|
|
anything like it seen before.
|
|
|
|
A method to detect mte-based viruses could involve measuring
|
|
instruction frequencies and their contact frequency with other
|
|
instructions. Before an algorithm can be written that reliably
|
|
detects every possible mte-based infection, the mte code has
|
|
to be thoroughly analyzed.
|
|
|
|
Anti-virus researchers agree that the engine itself is not the
|
|
most significant, but the fact that it is widely available,
|
|
and that it is fairly easy to use. Furthermore, according to
|
|
Fridrik Skulason, a renowned anti-virus researcher, there are
|
|
numerous ways to improve it. So in the worst scenario the
|
|
computer world would be flooded with viruses utilizing various
|
|
versions of the engine.
|
|
|
|
|
|
Part II
|
|
Other Methods
|
|
|
|
|
|
-7-
|
|
IV. Heuristical Scanning
|
|
|
|
|
|
|
|
IV.1. Description
|
|
|
|
Instead of trying to detect every virus by means of a unique
|
|
signature, a scanner could also attempt to find them by
|
|
looking for operations that are characteristic of viruses.
|
|
This kind of scanning is called heuristical scanning.
|
|
|
|
A heuristical scanner contains a set of rules describing
|
|
possible virus operations. Examples of such rules are:
|
|
|
|
"Programs are suspicious if
|
|
- they start with a jump instruction to almost the end of
|
|
the file
|
|
- they intercept an execute request for a certain
|
|
process, and then open its program file in read/write
|
|
mode"
|
|
|
|
|
|
IV.2. Discussion
|
|
|
|
At present, this method is not sufficiently reliable to be a
|
|
real alternative: the main problems are false positives and
|
|
false negatives.
|
|
|
|
A false positive occurs when the scanner reports suspicious
|
|
code which is in fact not part of a virus. If a scanner
|
|
produces many false positives, a user will tend to disbelieve
|
|
its results.
|
|
|
|
A false negative occurs when the scanner determines a file to
|
|
be "clean", if in fact it has been infected by a virus. At
|
|
present, the heuristical scanning method is not capable of
|
|
achieving the same detection rates as the currently best
|
|
signature scanners.
|
|
|
|
And even if it does produce a true positive, the message given
|
|
to the user is not as definite as a signature scanner would
|
|
produce. The following messages were generated by the F-PROT
|
|
anti-virus program (version 2.03a), the first using its
|
|
heuristical scanner, the second using its signature scanner.
|
|
Both messages apply to the same infected program.
|
|
|
|
heuristical scan:
|
|
"This program modifies itself in a highly suspicious way.
|
|
It is either infected, or a badly written program which
|
|
overwrites code with data."
|
|
|
|
signature scan:
|
|
"Infection: New or modified variant of Vienna"
|
|
|
|
If a user had just used the heuristical scanner, he would
|
|
perhaps notify a system operator after reading the above
|
|
|
|
-8-
|
|
|
|
message. If done so, the operator would not be able to
|
|
identify or remove the virus: for that he would need a
|
|
signature scanner.
|
|
|
|
Writers of heuristical scanners are maintaining a list of
|
|
programs that cause false positives, to be able to recognize
|
|
them as true negatives in the future. It is very important
|
|
that for such programs the exact context is defined in which
|
|
an operation is allowed. If for example the DOS FORMAT program
|
|
simply would be allowed to format, a virus could infect it and
|
|
legitimately contain code that formats the harddisk.
|
|
|
|
In our opinion the heuristical rulebase will become more
|
|
comprehensive, and consequently heuristical scanners will
|
|
achieve better detection rates. In fact, as of May 1992,
|
|
heuristical scanners have an 80-95 % detection rate. It is our
|
|
expectation that this rate will be over 95 % by the end of
|
|
this year. However, it still does not eliminate the problem of
|
|
false positives: at present, these rates are about 1-10 %.[9]
|
|
|
|
The main advantage of the heuristical scanning method is its
|
|
ability to detect viruses that cannot be found by signature
|
|
scanners. These include viruses using something like the
|
|
mutation engine, still undiscovered viruses, and viruses that
|
|
are yet to be written. So when the method has been improved,
|
|
and especially the false positive rate is significantly
|
|
reduced, it may serve as a method which is used first: after
|
|
it would report a suspect program, a signature scanner would
|
|
be used to see if the virus can be identified. If the
|
|
signature scanner then fails to produce an identification, at
|
|
least one can be quite sure that the suspicious program needs
|
|
to be examined further.
|
|
|
|
-9-
|
|
V. Integrity Checking
|
|
|
|
|
|
|
|
V.1. Description
|
|
|
|
Integrity checking utilities compute a virtually unique value
|
|
for every file in a system. The first time this is done, these
|
|
authentication values (as we will call them) are stored either
|
|
in a separate file or in the checksummed files itself. Once in
|
|
a while the checker is rerun, to see if any changes were made
|
|
to a file. The checker recalculates the values for every file,
|
|
and compares them to the stored values.
|
|
|
|
Such values can be calculated using a method called the cyclic
|
|
redundancy check (CRC). This method ensures a sufficiently
|
|
reliable check to see whether or not a file has been changed:
|
|
when using a 32 bits CRC value, the odds are one to over four
|
|
milliard that a change remains unnoticed, i.e. that the CRC
|
|
value is the same for a file before and after it has been
|
|
changed.
|
|
|
|
Another way to construct an authentication value for a file is
|
|
to use a cryptographic checksum. Such a checksum is created by
|
|
a complex algorithm, using as input a secret number and the
|
|
file that has to be checksummed.
|
|
|
|
|
|
V.2. Discussion
|
|
|
|
There are viruses which attempt to circumvent integrity
|
|
checkers. They reside in memory and detect when a checker (or
|
|
any other program) opens an executable file in read mode.
|
|
Before such a read is allowed, the virus first disinfects the
|
|
file. After the integrity of the file is confirmed, the file
|
|
is again infected. This type of virus is called a "stealth
|
|
virus".
|
|
|
|
So before an integrity check is run, one has to be absolutely
|
|
sure there exists a secure link between disk and memory: e.g.
|
|
when requesting a specific part of a disk to be read, the
|
|
exact contents of that part should be stored in memory after
|
|
the read. A way to almost ensure this is to boot a system with
|
|
a write-protected, original system disk. Assuming the files on
|
|
this disk are not infected, no stealth viruses will be in
|
|
memory after the boot. However, the system disk could have
|
|
been infected, either at the manufacturer or during a time
|
|
when for some reason it was not write-protected. So this
|
|
strategy does not provide perfect assurance, but something
|
|
very close to it.
|
|
|
|
After a reliable link between disk and memory is established,
|
|
a virus could still have tampered with a file in such a way
|
|
that its authentication value remains the same, or it could
|
|
have recalculated it. For example, if a virus writer had
|
|
access to the polynomial that was used to calculate a CRC
|
|
|
|
-10-
|
|
|
|
value, this would be fairly easy. Especially values that are
|
|
stored inside the files themselves are vulnerable.[10] A
|
|
solution could be to generate a random polynomial when the
|
|
anti-virus software is installed. In general, a virus should
|
|
have as less as possible access to any additional input the
|
|
integrity checker uses.
|
|
|
|
|
|
With respect to the strength of integrity checking, Vesselin
|
|
Bontchev wrote in VIRUS-L:
|
|
|
|
"Besides, it is not correct that a virus can be written
|
|
to evade any given detection scheme it knows about. A
|
|
well implemented integrity check should be able to resist
|
|
to any virus, even if the author [of a virus, PM] has the
|
|
full source code of the program. This is why integrity
|
|
checkers are stronger than monitors and scanners in the
|
|
first place! They can be bypassed only by one kind of
|
|
attack, but this is an attack against the integrity
|
|
checkers in general and does not require the virus author
|
|
to know how exactly a particular integrity checker is
|
|
implemented."[11]
|
|
|
|
Using a reliable integrity checker, that always informs the
|
|
user when a change has taken place, does not guarantee that no
|
|
virus will ever again infect one's system. There are viruses
|
|
that infect an executable exactly at the time when it is being
|
|
changed. Although the integrity checker would report the
|
|
change, the user obviously would permit it. This is the kind
|
|
of attack Bontchev is referring to in the above quote.
|
|
|
|
-11-
|
|
VI. Monitoring
|
|
|
|
|
|
|
|
VI.1. Description
|
|
|
|
A monitor program is invoked during startup, and stays
|
|
resident in memory. It monitors interrupts that usually are
|
|
called by viruses, and asks the user to confirm any action
|
|
that could have originated from a virus.
|
|
|
|
|
|
VI.2. Discussion
|
|
|
|
A difficulty here is how to determine which actions are virus-
|
|
like and which are not. Just as with heuristical scanning,
|
|
this causes many false positives. Thus a monitor should also
|
|
maintain a list of known false positives and be careful to
|
|
precisely store what a program is allowed to do and what it is
|
|
not.
|
|
|
|
The user is alerted if a monitor detects a virus-like action.
|
|
The monitor then offers the possibility to abort the action,
|
|
or to permit it. Due to the often technical nature of these
|
|
actions, only a skilled user can make a responsible decision
|
|
as to whether or not to allow the action.[12]
|
|
|
|
Several existing viruses attack specific anti-virus products,
|
|
in an attempt to disable or evade them. Of all discussed
|
|
methods, monitoring is the weakest in that it is the most
|
|
vulnerable to such attacks.[13] A virus can detect the
|
|
presence of a monitoring program and for instance refrain from
|
|
any virus-like actions while it is active. In general, because
|
|
there is no hardware supported memory protection under MS DOS,
|
|
a virus can always manipulate a monitor. A virus can also
|
|
bypass a monitor completely by directly calling the ROM BIOS:
|
|
the monitor just intercepts interrupt calls.
|
|
|
|
-12-
|
|
VII. Hardware Protection
|
|
|
|
|
|
|
|
VII.1. Description
|
|
|
|
Hardware virus protection usually comes as an add-on card
|
|
which is plugged into a free expansion slot inside the
|
|
computer. An anti-virus program, stored in ROM on the card, is
|
|
invoked at startup, before the system is allowed to boot.
|
|
|
|
|
|
VII.2. Discussion
|
|
|
|
The primary advantage of using hardware protection is that one
|
|
can be certain that the code on the card is executed before
|
|
any possibly infected boot sector or program. So the results
|
|
from any scanning or integrity checking done cannot be
|
|
tampered with. Software protection always appears after the
|
|
boot process, i.e. the execution of the boot sector, the
|
|
loading of system files, device drivers, etcetera.
|
|
|
|
Additional benefits of hardware protection are the fact that
|
|
its program will always be executed, at every startup, that
|
|
the code resides in ROM and thus cannot be modified, and the
|
|
facility to include password protection.
|
|
|
|
However, the monitoring program on the hardware card faces the
|
|
same problem as the software monitor or heuristical scanner:
|
|
how to determine what actions could have originated from a
|
|
virus, in other words what is virus-like behaviour. With
|
|
respect to this issue, Bontchev wrote in VIRUS-L:
|
|
|
|
"There are lots of ways in which such cards can be
|
|
bypassed. The key thought here is that in order not to be
|
|
too obtrusive, the card must try to decide what is
|
|
"legitimate" access to the disk and stop only access that
|
|
it thinks is non-legitimate. Unfortunately, this problem
|
|
is undecidable and a virus can always mask its access as
|
|
legitimate."[14]
|
|
|
|
Just as a virus can bypass a software monitor by directly
|
|
calling the BIOS, it can also bypass a hardware card by
|
|
directly calling it:
|
|
|
|
"A simpler idea is to call the program on the card
|
|
directly at the point at which it decides to pass the
|
|
control to the disk... In order to prevent such attacks,
|
|
ThunderByte has a different variant of the program with
|
|
every different example of the card... Unfortunately,
|
|
this does not completely prevent the virus from looking
|
|
for some characteristic patterns..."[14]
|
|
|
|
-13-
|
|
|
|
The program on the hardware card resides in the address space
|
|
of a PC. This means it can be called at any location. At some
|
|
stage in the checking program it is decided that a disk
|
|
request is allowed. If a virus would call the program at
|
|
exactly that point, its disk access would falsely be
|
|
authorized.
|
|
|
|
"It can't [prevent a virus from directly calling the
|
|
card, PM]. Unless it has its own CPU and its program is
|
|
completely unreachable from the address space of the PC.
|
|
But this will make it quite expensive."
|
|
"The current versions of such cards are no more expensive
|
|
than an expensive anti-virus program, but they are not
|
|
much more secure. A more secure version is possible, but
|
|
it will be much more expensive."[14]
|
|
|
|
-14-
|
|
VIII. Miscellaneous Methods
|
|
|
|
|
|
|
|
VIII.1. Software Write Protection
|
|
|
|
Files may be marked to signify that they should not be
|
|
modified or deleted. If this is implemented in software, the
|
|
mark can be removed in software. The program managing the
|
|
write protection is faced with the problem whether or not to
|
|
allow a request to remove a mark. This is the same kind of
|
|
problem as the ones presented to a monitoring program.
|
|
|
|
|
|
VIII.2. Vaccination
|
|
|
|
Many viruses mark the files they have infected, because they
|
|
only need to infect them once. Also, memory-resident viruses
|
|
obviously check if they are not already resident: these are
|
|
the so-called "are you there?" calls. The idea behind
|
|
vaccination is to put as many "infected" marks on all files as
|
|
possible, and to implement as many "yes" responses to "are you
|
|
there?" calls as possible. This to make many viruses believe
|
|
they have already infected a system, which in fact they have
|
|
not.
|
|
|
|
This method has several drawbacks. First, not all viruses
|
|
check their presence in such an easy way. Second, several
|
|
viruses have conflicting presence tests. And third, this kind
|
|
of protection is very easily circumvented. As an example,
|
|
consider a memory-resident virus checking its presence by
|
|
calling a DOS interrupt, using an unused function number. If
|
|
for example the number 100 is returned in a certain register,
|
|
the virus assumes it is already memory-resident. A vaccination
|
|
program for this virus would do exactly the same thing. A way
|
|
to circumvent it would for instance just involve returning
|
|
another number (e.g. 101) as the number indicating presence,
|
|
in future versions of the virus.
|
|
|
|
|
|
VIII.3. Bait Programs
|
|
|
|
An anti-virus program using bait programs creates several
|
|
dummy executables throughout the file system, attempts to
|
|
execute them, and then compares the executables with the ones
|
|
originally created. If any change occured, it is likely due to
|
|
a virus.
|
|
|
|
Drawbacks of this method include the fact that not all viruses
|
|
spread when executables are created or executed, and the
|
|
requirement of a secure link between disk and memory, just as
|
|
when using integrity checkers. The method can provide some
|
|
detection support to a package using other strategies as well.
|
|
It is a kind of heuristical method, applied in a relatively
|
|
safe environment.
|
|
|
|
-15-
|
|
IX. Operating System Improvement
|
|
|
|
|
|
|
|
IX.1. Present Situation
|
|
|
|
From reading the previous chapters, one can conclude that
|
|
viruses in fact exploit the weaknesses of an operating system.
|
|
Anti-virus software tries to neutralize these weaknesses as
|
|
much as possible. But, to restate an essential flaw:
|
|
|
|
"The basic problem with most anti-virus defenses is that
|
|
they are layered on top of the operating system while
|
|
according to industry reports most infections occur
|
|
before the operating system is loaded."[15]
|
|
|
|
In the latest popular operating systems (MS DOS 5.0, OS/2 2.0
|
|
and DR DOS 6.0) not even the most elementary provisions for
|
|
data protection are implemented (except for a password
|
|
protection scheme in DR DOS which can easily be bypassed).
|
|
|
|
|
|
IX.2. The Responsibility of an Operating System
|
|
|
|
An operating system provides an interface between the user and
|
|
the computer's resources, together with a library of interface
|
|
and supporting functions for the applications programmer.
|
|
|
|
Naturally a user wants to be protected from misuse. This can
|
|
be another user, or a program misusing the system's resources,
|
|
either intentionally (abuse) or unintentionally (errors).
|
|
Viruses are programs intentionally misusing the system.
|
|
|
|
In Operating System Concepts, the authors name as a motivation
|
|
for operating system protection:
|
|
|
|
"the need to ensure that each program component active in
|
|
a system uses system resources only in ways consistent
|
|
with the stated policies for the uses of these
|
|
resources." [16]
|
|
|
|
For example, a compiler invoked by a process is only allowed
|
|
access to certain files, usually source files that need to be
|
|
compiled. Conversely, private files of the compiler cannot be
|
|
accessed by the invoking process. An active virus infected
|
|
process usually does not use resources in ways consistent with
|
|
stated policies for its usage.
|
|
|
|
To be able to pursue usage policies the operating system
|
|
should provide general mechanisms for applications
|
|
programmers, that will allow them to implement safer programs.
|
|
The operating system should also use these mechanisms to
|
|
ensure its own integrity. This means that resource access
|
|
should become controlled: under MS DOS _all_ access is
|
|
uncontrolled.
|
|
|
|
-16-
|
|
|
|
IX.3. Suggestions for Improvement
|
|
|
|
To enforce usage policies the operating system has to
|
|
administrate which resources every process is allowed to use.
|
|
For example, a text editor is allowed to read and write text
|
|
files, and read any additional files private to the editor,
|
|
but is not allowed to format a disk. Obviously the mechanism
|
|
used to store each process' privileges has to be carefully
|
|
protected from virus manipulations. Also a facility to analyze
|
|
and log the resource requirements of new software should be
|
|
provided.
|
|
|
|
In fact every file that is of importance with respect to the
|
|
functioning of the operating system must be protected:
|
|
thorough, robust integrity checking should be applied to all
|
|
system files. Especially important are all the files needed to
|
|
boot an operating system.
|
|
|
|
If the operating system contains well implemented integrity
|
|
checking utilities, then they could be relied upon to check
|
|
the integrity of applications as well. Every application could
|
|
use a different variant of the same method. The exact method
|
|
used can be determined during installation, which would mean a
|
|
virus could never rely on a certain application using a
|
|
certain integrity checking method. This scheme can also be
|
|
employed when installing the operating system itself. The
|
|
procedure could even include installing a random "mutation" of
|
|
the operating system, comparable to viruses using the mutation
|
|
engine.
|
|
|
|
If hardware supported memory protection is available, each
|
|
executing process can be assigned its own, restricted memory
|
|
area. This means read and/or write access to other areas is
|
|
disabled. In hardware, priviliged instructions can be
|
|
implemented. The set of instructions an application is allowed
|
|
to execute would be a subset of the operating system's set.
|
|
Finally, hardware could enforce the write protection of
|
|
important files.
|
|
|
|
|
|
IX.4. Conclusion
|
|
|
|
If the current operating systems were revised to include
|
|
considerably more protection facilities, it would at least
|
|
require much more effort to write a virus. As a result less
|
|
new viruses would be written. The viruses that still appear
|
|
will be larger to be able to circumvent the extra protection
|
|
measures, and hence easier to detect.
|
|
|
|
An essential advantage of such a revision is that all current
|
|
viruses, and their derivations, will become disabled. Virus
|
|
writers will have to start from scratch, and will face a much
|
|
harder task. Unfortunately, application programmers will also
|
|
have to substantially rewrite existing software.
|
|
|
|
-17-
|
|
|
|
Instead of providing downward compatibility for previous
|
|
operating systems in a new one, applications running on
|
|
previous operating systems should be rewritten. This can be
|
|
facilitated by providing at least the functions of the
|
|
previous system, all of course well documented and optimized
|
|
to meet the new performance and security requirements.
|
|
|
|
The operating system is the only software package that _has_ to
|
|
be used. So when improved, the operating system actually
|
|
becomes an anti-virus tool the user _always_ installs.
|
|
|
|
-18-
|
|
X. Conclusion
|
|
|
|
|
|
|
|
In this paper we have looked at various methods for virus
|
|
detection. It has become clear that each has its advantages
|
|
and disadvantages: as it stands each method on its own is not
|
|
capable of providing complete virus protection. Therefore a
|
|
successful protection scheme would combine several methods
|
|
into one, multi-layered package. Each layer of the operating
|
|
system would have its own protection method.
|
|
|
|
With respect to today's operating systems the following setup
|
|
can be considered mandatory:
|
|
- a good integrity checker
|
|
- when they are sufficiently improved: a heuristical
|
|
scanner
|
|
- for virus identification: a signature scanner, which is
|
|
also able to detect viruses algorithmically. "Virus
|
|
identifier" is a more appropriate name for such a program
|
|
in this case.
|
|
|
|
Bontchev gives two reasons why this is not a setup that is
|
|
expected to gain widespread usage:
|
|
|
|
"Unfortunately, it seems to be that the scanners will be
|
|
with us at least for the next two years... It's still
|
|
easier to write and maintain a good scanner (which simply
|
|
does not try to detect anything it can't with wildcard
|
|
strings) than a good integrity checker... And the
|
|
polymorphic viruses are not that many right now. They are
|
|
just a trend - a dangerous trend - and I am trying to
|
|
tell all those who produce or rely on known-virus
|
|
scanning that they should look a bit more far than their
|
|
noses..."[17]
|
|
|
|
Nowadays it seems as if virus and anti-virus writers are
|
|
battling over who will gain the most control over the
|
|
operating system. In our opinion the problem should be tackled
|
|
in a more fundamental way, i.e. the operating system itself
|
|
must change. No downward compatibility should be provided, as
|
|
to completely cut off every current virus. Although the
|
|
transfer to another operating system will be harder at first,
|
|
users will benefit in the long run from the increased level of
|
|
protection.
|
|
|
|
We do not expect such an operating system to become standard,
|
|
however. The performance of anti-virus software, downward
|
|
compatability of operating systems, and user-friendliness of
|
|
both are all issues of great commercial value. As long as
|
|
potentially commercial benefits and information concerning
|
|
virus detection and protection cause conflicts of interest,
|
|
one cannot expect the average computer user to be objectively
|
|
informed, and consequently demand better protection methods
|
|
from software and hardware manufacturers. It is a consumer
|
|
demand that really would induce them to improve their
|
|
protection standards.
|
|
|
|
-19-
|
|
Notes
|
|
|
|
|
|
1. Fred Cohen, "Computational Aspects of Computer
|
|
Viruses", Computers & Security, volume 8 (1989), p.
|
|
325.
|
|
|
|
2. A. Padgett Peterson, VIRUS-L, volume 5, issue 20, 30
|
|
January 1992.
|
|
|
|
3. This proof only holds for Turing machines with
|
|
infinite memory, not for real computers. The number
|
|
of possible programs on a real computer is finite,
|
|
yet large enough to be called "practically
|
|
infinite".
|
|
|
|
4. Mark Drew, "A Practical Approach in reducing the
|
|
risk of 'Infection' as an aid to Detection, Recovery
|
|
& Containment of COMPUTER VIRUSES", part of the IBM
|
|
course Defenses against Malicious Programs, February
|
|
1992, p. 48.
|
|
|
|
5. If an advanced signature search algorithm is used,
|
|
the scanning time can be made constant. However,
|
|
memory requirements will then be proportional to the
|
|
number of signatures.
|
|
|
|
6. "It Slipped Through the Net", Virus Bulletin,
|
|
December 1991, pp. 13-14.
|
|
|
|
7. This virus is called V2P6, and was written by Mark
|
|
A. Washburn, who claims it to be a "research virus".
|
|
|
|
8. "Mutation Engine, the final nail?", by Fridrik
|
|
Skulason, Virus Bulletin, April 1992, pp. 11-12.
|
|
|
|
9. "Heuristics - The Way Ahead?", Virus Bulletin, May
|
|
1992, p. 9.
|
|
|
|
10. "In order for a virus to infect any program that
|
|
uses this method [of storing the CRC value inside
|
|
the file, PM], it must somehow find the location of
|
|
the CRC within the file and recalculate the CRC
|
|
using the following data stream:
|
|
|
|
+------------------------+-----------------------+------------+
|
|
| <- Program part 1 -> | <- Program part 2 -> | <-Virus -> |
|
|
+------------------------+-----------------------+------------+
|
|
|
|
It must then overwrite the old CRC with the new one.
|
|
I won't explain how (I don't want to give any virus-
|
|
writers any ideas), but with the right technique the
|
|
CRC can be found, recalculated, and rewritten in
|
|
under 30 seconds.", Kevin Dean, "Stealth Bomber"
|
|
version 2.02 documentation file, 1992.
|
|
|
|
11. Vesselin Bontchev, VIRUS-L, volume 5, issue 97, 28
|
|
April 1992.
|
|
|
|
-20-
|
|
|
|
12. Fridrik Skulason, "Virus Monitoring Software - An
|
|
Endless Battle", Virus Bulletin, July 1990, pp.
|
|
15-16.
|
|
|
|
13. "However, due to the total lack of memory protection
|
|
under MS-DOS, a clever virus is able to disable the
|
|
monitoring program if it detects it in memory, or
|
|
even invoke the "dangerous" functions in a way that
|
|
cannot be intercepted (e.g. using CALLs to the ROM
|
|
BIOS). Viruses which are able to do this are called
|
|
"tunneling"... If correctly implemented, these
|
|
techniques are able to bypass -any- monitoring
|
|
program, and therefore the monitoring programs (like
|
|
FluShot+) are the weakest line in the antivirus
|
|
defense (even weaker than the scanners).", Vesselin
|
|
Bontchev, VIRUS-L, volume 5, issue 86, 22 April
|
|
1992.
|
|
|
|
14. Vesselin Bontchev, VIRUS-L, volume 5, issue 101, 7
|
|
May 1992.
|
|
|
|
15. A. Padgett Peterson, VIRUS-L, volume 5, issue 20, 30
|
|
January 1992.
|
|
|
|
16. Abraham Silberschatz and James L. Peterson,
|
|
Operating System Concepts, p. 380.
|
|
|
|
17. Vesselin Bontchev, VIRUS-L, volume 5, issue 89, 13
|
|
April 1992.
|
|
|
|
-21-
|
|
Bibliography
|
|
|
|
|
|
|
|
- Books -
|
|
|
|
David Ferbrache, A Pathology of Computer Viruses, Springer-
|
|
Verlag, 1992.
|
|
|
|
Harold Joseph Highland, Computer Virus Handbook, Elsevier
|
|
Advanced Technology, 1990.
|
|
|
|
Abraham Silberschatz and James L. Peterson, Operating System
|
|
Concepts, Addison-Wesley, Alternate edition, 1983.
|
|
|
|
|
|
- Articles -
|
|
|
|
Fred Cohen, "Models of Practical Defense Against Computer
|
|
Viruses", Computers & Security, volume 8 (1989), pp.
|
|
149-160
|
|
|
|
Fred Cohen, "Computational Aspects of Computer Viruses",
|
|
Computers & Security, volume 8 (1989), pp. 325-344.
|
|
|
|
Fridrik Skulason, "Mutation Engine, the final nail?", Virus
|
|
Bulletin, April 1992, pp. 11-12.
|
|
|
|
Fridrik Skulason, "Virus Monitoring Software - An Endless
|
|
Battle", Virus Bulletin, July 1990, pp. 15-16.
|
|
|
|
"Heuristics - The Way Ahead?", Virus Bulletin, May 1992, p. 9.
|
|
|
|
"Intelligent Scanning", Virus Bulletin, September 1991, p. 3.
|
|
|
|
"It Slipped Through the Net", Virus Bulletin, December 1991,
|
|
pp. 13-14.
|
|
|
|
"Virus Warfare", Virus Bulletin, May 1992, pp. 6-7.
|
|
|
|
|
|
- Electronic Mail -
|
|
|
|
VIRUS-L, the mail forum for discussing computer virus issues
|
|
of Lehigh university, volume 5 (1992), issues 1-127,
|
|
moderated by Kenneth R. van Wijk
|
|
|
|
VIRUS-L FAQ (Frequently Asked Questions) list, 19 March 1992,
|
|
moderated by Kenneth R. van Wijk
|
|
|
|
-22-
|
|
- Product Documentation -
|
|
|
|
Fixutils, including FixMBR version 2.4, (c) 1992 by A. Padgett
|
|
Peterson
|
|
|
|
F-Prot version 2.03a, (c) 1992 by Fridrik Skulason
|
|
|
|
Integrity Master version 1.13a, (c) 1992 by Wolfgang Stiller
|
|
|
|
Mutation Engine version 0.90 , written in 1991 by "Crazysoft,
|
|
Inc."
|
|
|
|
Stealth Bomber version 2.2, (c) 1992 by Kevin Dean
|
|
|
|
-23-
|
|
Proof Readers
|
|
|
|
|
|
|
|
I would like to thank the following proof readers for their
|
|
valuable comments:
|
|
|
|
|
|
Vesselin Bontchev
|
|
researcher at the Virus Test Center of the University of Hamburg
|
|
|
|
Luuk Groenewegen
|
|
associate professor Computer Science at Leiden University
|
|
|
|
Peter de Nies
|
|
virus specialist at the Computer Crime Unit of the CRI
|
|
|
|
Henk Pauwels
|
|
head of the Computer Crime Unit of the CRI
|
|
|
|
Righard Zwienenberg
|
|
research manager at Computer Security Engineers, Ltd.
|
|
|
|
|
|
|
|
|
|
Murphy's first law on computer viruses:
|
|
If a computer virus can be written, it will be written.
|
|
|
|
Murphy's second law on computer viruses:
|
|
If a computer virus just cannot be written, it will be
|
|
written anyway. It will just take a little bit longer.
|