8. The Bootstrap Integrity Checker (IVINIT).

Most integrity checkers use one and the same program to check the
integrity of the files and of the boot sectors. InVircible has those
two functions separated. While IVB takes care (inadequately, as we
saw) of the file integrity check, another program - IVINIT - is
designed to perform a somewhat more thorough check of the system
startup process.

The exact sequence of the checks performed by IVINIT has been
already described in the section about the self-checking techniques
used by InVircible. The problem that IVINIT saves copies of the
boot sectors at fixed and easily locatable (and modifiable) places
was also already mentioned as a serious security hole elsewhere in
this paper. Here we shall describe the algorithm InterpreterCheck.
It consists of the following:

Algorithm InterpreterCheck:

1) Locate the file pointed to by the variable COMSPEC from the
environment and remember its extension.

2) Rename this file to a file with no extension.

3) Check that the renaming is successful by trying to locate
(using the function FindFirst) the newly renamed file.

4) Open the renamed file, read the first 3 bytes of the renamed
file and compare them with the bytes stored in the file C:IV.INI,
then close the file.

5) Rename the file back to its original extension. Done.

It is important to note that if any of the data files that IVINIT
uses (C:PART.NTZ, C:BOOT.NTZ, CMOS.NTZ, C:IV.INI) is missing,
the program simply re-creates it and saves in it the current
contents of the respective object. That is, if the virus has
modified one of those objects and has simply deleted the respective
data file that contains information about the object, IVINIT will
simply re-create the data file with the new information (about the
already infected object), thus "conserving" the infection. The user
is never informed that such an action (re-creation of the data
files) has taken place.

Another serious problem is the aggressive way the program uses to
treat the user's command interpreter. Messing with the user's files
without requesting a permission - or even without informing the
user what is happening - is in general a very bad idea. But what
else can be expected from a program which intentionally destroys
some of the user's data files?! Anyway, imagine that a power
failure happens after step 2 of the algorithm InterpreterCheck. The
user's hard disk will become non-bootable, since the bootstrapping
process will be unable to find the command interpreter. We had at
least one report from a user of InVircible that exactly this has
happened to his computer. A similar problem can - and does - occur
with some anti-virus programs of the behavior blocking kind (e.g.,
TbFile). InVircible is incompatible with them and using it on a
system protected with them can lead to unpredictable, and often
damaging results.

Bookmark/Search this post with:

delicious | digg | reddit | newsvine | furl | google | yahoo | technorati