🚀 go-pugleaf

padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) writes:

> Seems like we should be about due for some "next generation" products,
> products that can detect a one-byte change in any program but are smart
> emough to know that a one byte change is not likely to be a virus.

Hmm... Wasn't that you who explained me once how a one-byte change in
a particular data area might mean a virus infection?... :-)

> 1) Multilevel validation - secondary programs that validate whether or not
>    the protection program is working properly.

We already have something like that - most self-respecting integrity
checkers perform a self-check when executed.

> 2) TSR awareness - what programs are expected to change memory allocations
>    and which are not.

I think that Jim Bates' anti-virus package has a program that does
something similar, but I have never seen it, so I am unable to provide
more information.

> 4) DOS locations, sizes, and expected values specific to the particular PC.

At least some packages do that already. (I.e., location, and size
checks. The "expected values" are a bit difficult, due to the lots of
different versions of DOS that are around - e.g., the German version
of COMMAND.COM has a different length than the English version of the
same file, even for one and the same version of DOS.)

> 5) Ability to temporarily disengage certain functions for maintenance without
>    having to remove the entire package.

Again, most full-blown anti-virus packages allow you to use only some
of their functions.

> 6) Partitioning support.

What is this?

> 7) Ability to detect an attempt to write to an executable

You mean, a monitoring program? Well, they are so easy to be
bypassed... OK, maybe they should be there as a protection at least
against the stupid viruses, but then such programs tend to be rather
obtrusive...

> >As far as I know, Prof. Eugene Spafford and a few others from Purdue
> >University are working on a platform-independent user-programmable
> >scanner. It will be released in source, free of charge. Initially it
> >will have routines to access Unix file systems, but since it will be
> >written in C++, nothing will prevent other people from writing the
> >appropriate interface to DOS, MacOS, AmigaDOS, or whatever. As you see
> >- - no deep secrets.

> The problem is that a platform independent management program is going to have
> a hard time detecting platform-dependent low-level attacks. Consider
> for a moment malicious software that tries to go resident in the disk buffers.
> To work it must recognize the differences between buffers used by DOS 3.x
> and those of higher versions. So must an integrity management routine.

Three objections. First, I was speaking (in this particular case) about
a platform-independent -scanner-, not about an integrity checker.
Second, it is supposed to run without a virus being active in memory,
so there is no reason to check the buffers and other such stuff.
Third, as I said, it will be platform-independent. In order to port it
to another platform, you'll have to write the platform-specific I/O
routines. If you want to scan the memory, you'll just have to write
routines that provide access to it as a file. Not difficult at all.

> Gene & Co. at Purdue are doing important work but it must be realized that
> you cannot get all of the way with a platform-independant solution. A
> long way certainly & would work on a PC with Jerusalem & Sunday, but how 
> about a low-level infection such as MICHELANGELO or FORM ? These depend on
> the platform.

First, Michelangelo is not that much platform-dependent... I mean, it
can perfectly infect a Unix-only system, if it runs on an IBM PC
compatible... (The fact that it will also crash the system and prevent
it from booting is a completely different story.) Second, in order to
use that scanner on such a platform, you'll just have to write the I/O
routines that provide access to the boot sectors - as simple as that.

> Of course the real answer might be for a generic "kernel" with attachable
> platform-specific modules that are assembled on installation. Not difficult,
> just different.

Why different? As far as I understand, this is exactly what they are
doing (maybe Prof. Spafford can comment on this?). Just instead of the
ugly assembly language solution, they are using an object-oriented
approach and are implementing it in C++. :-)

> I agree but take it one step further, again the algorithm should be
> tailored to the specific machine and use a different seed on each - this
> in no way weakens the algorithm but gives each PC a different signature
> for a particular file. Break one machine and "malware" must start all over 
> again on the next.

In fact, it depends on the algorithm used. If you are using a CRC,
just using a different seed for the checksum does not make it secure -
you must change the polynomial each time. If you are using something
cryptographically strong as DES, MD4, MD5, MD2, or some such, then
just changing the seed is enough.

Regards,
Vesselin
- -- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany