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.
|