🚀 go-pugleaf

chess@watson.ibm.com (David M. Chess) writes:

> Glad you liked the program!   We're pretty proud of it.  I think
> it's still the only OS/2 anti-virus program that has disinfection
> features, an easy GUI interface, and all the rest.  Brag, brag!  *8)

Uh, I don't have OS/2, so I cannot provide a competent opinion, but
have you looked at Dr. Solomon's Anti-Virus ToolKit for OS/2?

> The short answer to this is that it's an anti-virus program, not
> a change-management or integrity-management program.  But that's
> a cop-out.  We did test internally a program that showed you every
> file that had changed (with hints as to which changes were most
> likely to be a virus).  A few people liked it a lot, but most people
> found it basically just noise.  Since programs change a *lot*, and
> very very few of those changes are caused by viruses, people got
> very tired of reading the change reports.  Most users didn't want
> to know about a change unless it was caused by a virus.  They

So much for the integrity checking... I disagree with Dave here, but
it is not very relevant, because IBM has much more experience with
users than me. Lots of products are providing you the "ultimate
solution to the virus problem" (integrity checking), "no updates
necessary", etc. IBM says that users don't want integrity checking. We
all know that known-virus scanners are useless against new viruses and
monitoring programs can be easily bypassed. Somebody is deadly wrong;
the question is - who?...

> didn't want to be told that SETVER.EXE had changed (because they

If the checksum of a file has changed, but (a) its size didn't change,
(b) its entry point didn't change, and (c) the code at which the entry
point points to didn't change, then chances are that the cause of the
change is not a virus. An intelligent heuristic should be able to
detect that and inform the user properly...

> added a SETVER entry), or that 123.EXE had changed (because they
> upgraded),

If the checksum of a file has changed, but (a) its size has also
changed, (b) its date/time has also changed, (c) the entry point does
not point after the previous end of the file, (d) lots of things in
the EXE header (e.g., the relocation items) have changed too, (e) the
file cannot be restored to its previous state, using several generic
disinfection algorithms, (f) no other (or very few other) files have
changed in the same way, then chances are that the cause of the change
is not a virus. Not 100% reliable, of course, but it's quite difficult
to make a virus that will pass the above test. An intelligent
heuristic should be able to detect that and to inform the user
properly.

> or that their boot record had changed (because they
> changed a volume serial number).

Hey, they should be really power users, if they know how to do that!
For instance, I don't know how it can be done, without reformatting
the disk, or using a sector editor... And anybody who is competent
enough to mess with a sector editor in the boot sector, should not be
surprised by a message that the said sector has been modified
afterwards...

> If enough people tell us that they want their anti-virus program
> to also help with change management, we'll certainly consider
> how to do that.  But in general change management and virus

The perfect solution is to provide the -flexibility-. Just put it
there (but make it s really good integrity checker!) and turn it off
by default. The docs should tell the user how to use it, if s/he wants
to. If s/he doesn't want to use it - no problem, it is turned off by
default anyway. The problem with the current situation is that you
don't allow the user to use integrity checking, even if s/he wants to!

> protection seems to be mostly distinct; the vast majority of
> changes are non-viral, and if you want to know about them
> anyway it's probably because you have some other interest
> besides viruses.

Verifying the integrity of my programs or data seems important enough
to me, even if you are not interested in finding viruses... Besides,
the vast majority of the non-viral changes can be detected as such,
with the proper use if intelligently designed heuristics.

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