User`s guide

VIRUS BULLETIN ©1991 Virus Bulletin Ltd, 21 The Quadrant, Abingdon Science Park, Oxon, OX14 3YS, England. Tel [phone].
/90/$0.00+2.50 This bulletin is available only to qualified subscribers. No part of this publication may be reproduced, stored in a retrieval system, or transmitted
by any form or by any means, electronic, magnetic, optical or photocopying, without the prior written permission of the publishers.
Page 5
VIRUS BULLETINAugust 1991
LETTERS
Sir,
I am writing to try to clear up a rather surprising confusion
that I have evidently caused. In a reply to a letter in the July
1991 VB, the editor reprints a posting of mine to VIRUS-L and
attributes to me by implication the opinion that, among other
things, virus scanners should not scan for viruses not known
to be in the wild, or thought to be extinct. I would like to state
that this is not my opinion, and that I did not intend to give
the impression in my posting (which in fact consists mostly of
questions, not of statements or opinions). The fact that the
IBM Anti-Virus product scans for at least as many ‘research’
or ‘collector only’ viruses should serve as evidence to the
contrary. In fact, I doubt that any other anti-virus workers who
have taken part in the discussion would agree to the theory of
‘selectivity’ as the editor states it.
On the other hand, I would like to take this opportunity to
outline a view that I would support, which I hope is suffi-
ciently far from the naive ‘selectivity’ view to avoid confu-
sion. As the anti-virus field moves beyond the butterfly
collector stage and into a more mature and responsible era,
anti-virus workers will quite naturally move beyond the
simple questions of how many viruses they can find, and the
details of what a specific virus does. To be of the maximum
service to our customers and the community, we have to say
more than ‘we know of these 400 viruses and only if you buy
the product can you be saved; the Snorfler virus, for instance,
will erase all your data on alternate Thursdays.’ We must also
be able to give some idea of which viruses are in fact the most
serious threat, which are likely to become threats in the future
and what anti-virus measures are likely to be most effective
(after all, any VB reader knows how to protect a single
machine against all the most common viruses; the difficulty
now seems to be to figure out how to protect an entire
community or organization.)
In order to do accurate threat-estimation, and research into
how viruses behave at the organizational or societal level, we
need to know new kinds of things about viruses. We need to
know what software sharing patterns are like, what causes
some viruses to be common and others not, and which viruses
are in fact common in the real world today. It is toward the
answers to these sorts of questions that our most interesting
current work is focused, and it was in an attempt to attack
some of these questions that I made my posting to VIRUS-L. I
think that we in the anti-virus community do need to be
selective, but not by simply ignoring viruses that are not in the
wild. We need to be selective, instead, about where we
concentrate our research, and to be sure that we don’t ignore
the important large scale questions because we are using all of
our resources on just gathering all the viruses we can find.
It’s perfectly acceptable, and accepted, for an anti-virus
worker today to say to the press ‘there are over six hundred
viruses in the world’, for a software maker to advertise the
product primarily on the number of viruses it detects, and for
a publication to rate products primarily on that number. In the
future, though, I would hope that a responsible researcher
would at least add ‘ although only about 10 percent of them
are actual threats’, that a responsible software maker would at
least say ‘including the 10 percent known to be in active
circulation’, and that a responsible publication would give the
reader some idea of how a product performed against the most
important subset of their complete test-set. Similarly, it would
be very nice if collectors exchanging viruses with trusted
peers would also exchange anything they know about the
history or current status of the viruses involved, and not
simply binary samples. I trust that as the industry continues to
mature, all these good things will happen.
One statement in the editor’s reply with which I would
definitely disagree: he states that no functioning virus can be
classified as a ‘non-threat’. That is not the case: anyone with
much experience in the anti-virus field can say with confi-
dence that the MGTU virus, while it is technically a function-
ing virus, will never become more widespread than a non-
trivial ‘arf-arf’ style Trojan horse would; the virus is just too
slow-spreading and obvious. To claim that we can always tell
which viruses are the dangerous ones would of course be
foolish; but to claim that we have no idea and that all viruses
must be treated the same way because they are all threats,
would be equally inadvisable and I am sure that the editor did
not mean to make that claim.
Thanks for the chance to clear this up!
David M. Chess
IBM T J Watson Research Center, New York
[Apologies to David Chess for any misinterpretation arising
from the editor’s alcoholic rantings about ‘selectivity’.
There’s much food for thought in this letter which may well
stimulate further debate. Ed.]
Sir,
Having just read with interest the tutorial concerning boot
sector viruses and recovery, in July 1991 edition of VB, I
thought you or your readers may be interested to read the
following corrections/amplifications.
The article was informative and suitably clear, however I did
notice that it suggested that FDISK could be used to remove a
Master Boot Sector virus. Unfortunately I have found this not
to be the case. FDISK (or at least all of the many versions I
have used), is a Partition Table editor. It allows you to create
and delete logical partitions. If it detects what it thinks is a
valid boot sector program in residence it will not replace it,
but it will just allow you to edit the Partition Table element.