


                           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.
