Path: utzoo!news-server.csri.toronto.edu!rutgers!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw
From: padgett%tccslr.dnet@uvs1.orl.mmc.com (Padgett Peterson)
Newsgroups: comp.virus
Subject: PC MS-DOS vs BIOS protection (PC)
Message-ID: <0003.9103081913.AA10967@ubu.cert.sei.cmu.edu>
Date: 9 Mar 91 15:30:52 GMT
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Lines: 64
Approved: krvw@sei.cmu.edu

(The following is my opinion only and has nothing to do with anyone else)

	I think it is time stand back from the PC and take a fresh
look at how protection can be placed on the system. Too many products
today rely on MS-DOS and its documentation to protect PCs. Since many
functions of DOS and Windows are either mis-documented or
un-documented and since there exist many opportunities for malicious
software to attack before DOS, this is obviously not the place to
start.

	Consequently, I must question any protection scheme that
becomes active only with CONFIG.SYS or AUTOEXEC.BAT, this is too late.
This is not to say that a program that goes resident earlier is going
to be a cure-all, just that it is necessary to have even a chance at
being effective.

	Hardware, in the form of a custom BIOS or ROM-extension, is
the best solution, but in many cases, may not be a cost-effective one.
For most machines, software alone is probably sufficient. It may not
be able to stop everything, but it should be able to at least detect
an exception before MS-DOS loads and stop anything thereafter.

	There are a number of good products out today to fill various
functions (I use several, both home-built and commercial) but as yet I
know of none that do everything necessary.

	Quite often, complaints are made about compatability with
MicroSoft products, that certain functions may be "hidden" from
detection. Again, this is a problem experienced from being layered on
top of DOS or Windows that goes away if operation is performed "under
the rainbow" (no reference to the ex-DEC product, either express or
implied, is intended).

	It is understood that it is somewhat more difficult to
determine from a sector write request at the BIOS level, exactly what
is being written to, than interception of a DOS Int 21 would require,
but requires no knowlege of any windowing, multi-tasking, or
networking software to do so. Even if a program has established an
application interrupt (and there are many available) to handle disk
functions outside of DOS, they still go through the BIOS to do so and
this is both detectable and re-directable.

	There are simply too many ways to "get around" what is
published about MS-DOS (not to mention DR-DOS and several others) for
their calls to be used as a first line of detection, this must be done
at the "choke point" of the BIOS. Certainly DOS or any other O/S can
be used to determine the cause of an exception, once it has been
determined that an exception has occurred (wish I could use italics),
but the important thing is to know that something has occurred (I
can't fix it if I don't know its broke).

	Given this, intelligence can be applied to determine if what
happened was permitted or to be disallowed.

	It is time that some ground rules be established for any
protection scenario. I tried to make a "first pass" with the model a
few issues ago, but it is up to the population to decide what (if
anything) the vendors will produce. Just do not accept any claim that
"it cannot be done". For me, if it does not start with the BIOS, it is
not enough.

			See you in New York folks,

						Padgett