VIRUS-L Digest Friday, 1 Nov 1991 Volume 4 : Issue 207
Today's Topics:
Furtivity
Real User
Re: Taxonomy and Nomenclature
Virus Families (Was: Taxonomy and Nomenclature) (PC)
Re: Cascade
NCSA (Was: Request for standards)
Problems with McAfee's scanv84 (PC)
Re: Hardware forever!
Re: Seeking Info on stoned virus (PC)
Courses on Viri for teenagers, (General)
Keyboard shift key problem (PC)
Re: McAfee84 fails to remove Cascade (PC)
Re: Running circles around (PC)
VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed. Contributions should be relevant, concise,
polite, etc. Please sign submissions with your real name. Send
contributions to
[email protected] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list. Administrative mail (comments, suggestions,
and so forth) should be sent to me at:
[email protected].
Ken van Wyk
----------------------------------------------------------------------
Date: Thu, 31 Oct 91 19:48:43 -0800
>From:
[email protected] (Fred Waller)
Subject: Furtivity
Writes
[email protected] (David.M.Chess):
> Most widespread viruses are not stealthed, most stealthed
> viruses are not widespread...
Furtive ("stealth") viruses are relatively new and have had less
chance to spread. So, speaking of "most" stealthed viruses may be
a little misleading, as is speaking of "most" viruses in general,
since the non-furtive ones haven't had equal time...
Also, the one and only `old' furtive virus, the Pakistani Brain,
has spread quite a bit, thank you... so that's a widespread furtive
("stealth") virus. (But one might not consider it a true furtive
virus because most varieties show the Volume-Label mark).
Conversely, I must admit the Brain has had more time than all others
to spread.
> So even if an interpreter-virus couldn't be stealthed, all that
> that means is that it could only become as widespread as other
> non-stealthed viruses.
I don't think so. We have to take into account that, if furtive
viruses become an impossibility, and many of the tricks they now
use become more difficult for them, then it will be that much easier
to design effective software defenses against such debilitated
attackers. :-)
Fred
[email protected]
(actually, I think it's "furtiveness"...)
------------------------------
Date: Thu, 31 Oct 91 19:47:19 -0800
>From:
[email protected] (Fred Waller)
Subject: Real User
Writes
[email protected] (David.M.Chess):
> I was just pointing out that your test against existing viruses
> with you as the user wasn't good evidence for how the system would
> work against existing viruses
Well, it was initial evidence. Sort of useful.
> ....on machines used by Real users, or against nonexistent-
> but-obviously-possible viruses (like database or spreadsheet
> infectors).
I'm a Real User, I swear! Opinionated, maybe. But Real, to be
sure... real to the core. When those nonexistent-but-obviously-
possible viruses become existent-and-available ones, I'll test
them too.
> It might work very well with real users, and database/
> spreadsheet/etc viruses might in fact not be something we
> need to worry about!
And that would be nice. Worth a try?
> But I don't think you can criticize people *too* strongly for
> not taking your word for it. *8)
Depends on how it is done. If the rejection is made on purely
theoretical grounds, then I'd be criticizing them fairly strongly,
and with good reason. If someone were to try such system, and
discover it doesn't work, then reject it, I couldn't criticize them
at all. Until then, I would expect a more open mind (and a more
candid and less defensive reception) from people who are ostensibly
dedicated to combating viruses.
> But there can be differences of opinion about the extrapolation.
There almost always are such differences.
> But again, market one, and we'll see if you get rich! *8)
This may come as a surprise to some, but I'm actually a very frugal
and ascetic person who requires Puilly-Fuisse' only twice a year,
and only in moderate quantities. My intervention here is not
market-motivated. Nor, in the final analysis, is wealth a gauge
of rightfulness. But it was very interesting to see that Dave
Chess seemed to start digging into the patent literature dealing
with hardware protection just a short time after I brought up the
subject here... :-)
Fred Waller
------------------------------
Date: Fri, 01 Nov 91 10:33:35 +0000
>From: Fridrik Skulason <
[email protected]>
Subject: Re: Taxonomy and Nomenclature
In Message 27 Oct 91 02:15:02 GMT,
[email protected] (Fred Waller) writes:
> was known. Does this mean that SVC 5.0 is related to... the Devil's
> Dance, which NOVI also cures? Of course not!
This is not what was being said - the analogy is totally irrelevant.
The program in question is able to determine that the Fu Manchu virus is
related to Jerusalem, that it is structurally very similar, and that it
can be removed in a similar way.
Of course it is not alway easy to determine how related two viruses are,
but in general it does not pose a serious problem. There are cases where
a series of viuses has been developed, and where the last viruses hardly
resemble the original one, but the evolution can easily be traced by studying
the available intermediate steps.
> course). It's the only way to have a practical taxonomy of viruses.
> Otherwise, it will continue being just about anybody's mess, as
> it is now.
Well, the current situation could be improved somewhat, I admit. At the
moment we have around 300 well-defined families of viruses, 3-4 families
which may or may not be split in two, and somewhere in the range of
800-1200 virus variants, depending on how you count. We use terms
such as "group" or "sub-group", somewhat loosely, usually referring
to a group of similar viruses, which belong to the same family, and are
sufficiently distinct from other members of the same family - an ideal
example are the AntiCad/Plastique viruses, which belong to the
Jerusalem family.
Researchers generally agree on whether (and how closely) two viruses are
related to each other - but I doubt we can ever formalize the classification
like the botanists do. In fact I doubt we need to.
> 2. Paralell with the development of such taxonomy, a suitable
> NOMENCLATURE should also be developed.
Some good systems of nomenklature exist - personally I am in favour of the
NIST proposal, where each virus has a one-, two- or three-part name.
name (if the family only has one member) "Agiplan"
family-variant "Jerusalem-Fu Manchu"
family-variant-minor variant "Jerusalem-Anticad-4096A"
Other systems have been discussed, but this one is clear and has few real
problems - I have more-or-less adopted it in my anti-virus program, and
I stronly encourage others to do so too.
The only drawback is that it practically requires a central database of
viruses (to reduce the chances of the same virus receiving multiple names),
and virus information - something which not all anti-virus companies are
willing to participate in.
Anyhow - work is progressing in this area on several fronts, both in Europe
and USA, and hopefully a working system will be in place soon.
- -frisk
------------------------------
Date: Fri, 01 Nov 91 10:54:59 +0000
>From: Fridrik Skulason <
[email protected]>
Subject: Virus Families (Was: Taxonomy and Nomenclature) (PC)
Maybe the following may start some useful discussion.....here is a list
of the PC virus families I currently recognize - in alphabetical order.
Maybe we can standardize on which families exist soon - even if we
can't agree what to name them - whiich is not nearly as important.
In some cases the families have only a numeric name, which indicate a
permanent "temporary" name (sigh).
Perhaps only a handful of people will be interested in this list,
but I would welcome any input. Don't expect a reply right away, though -
I have a lot of E-mail waiting for a reply at the moment.
08/15, 10 past 3, 1024PrScr, 1049, 1067, 13J, 1600, 1876, 200, 2144,
217, 268-plus, 337, 3445, 417, 440, 483, 4870 Overwriting, 492, 5120,
516, 555, 696, 699, 707, 7808, 789, 7th son, 8-tunes, 800, 864, 905,
948, Agiplan, AIDS, AIDS II, Aircop, Akuku, Alabama, Alameda, Ambulance,
Amoeba, Anthrax, AntiPascal, AntiPascal-2, Arab, Armagedon, AT-144, Attention
Australian 403, BackTime, Bad Boy, Bebe, Beijing, Best Wishes, Big Joke,
Black Monday, Bljec, Blood, Boys, Brain, Bulgarian 123, Bulgarian Tiny,
Burger, CARA, Carioca, Cascade, Casino, Christmas in Japan, Cinderella,
Copyright, Crazy Eddie, Crew-2480, CSL, Danish Tiny, Darth Vader,
DataCrime, DataCrime II, Datalock, dBASE, DBF blank, Deicide, Demon,
Den Zuk, Destructor, Devil's Dance, Dewdz, Diamond, DIR, DIR-II,
Disk Killer, DM, Doom2, Doteater, Durban , E.D.V., Eddie, Eddie-2, Empire,
ETC, Europe, F709, Fake-VirX, Faust, Fellowship, Fichv, Filler, Fish 6,
Flash, Flip, Form, Frodo, Frog's Alley, Fumble, G-virus, Gergana, Gosia,
Gotcha, Green Caterpillar, Guppy, Halloechen, Hary Anto, Hate, Hero,
Hey You, Horse, Hungarian 482, Hybryd, Icelandic, Incom, Int 13, Internal,
Iron Maiden, Itavir, Jabberwocky, Jeff, Jerk, Jerusalem (including Slow and
Plastique), Jihuu, Joker, Joker-01, Joshi, Justice, Kamikaze, Kemerovo,
Keypress, Kiev, Korea, Kuku, Lazy, Leech, Lehigh, Leningrad, Leprosy,
Liberty, Little Brother, Little Pieces, Lovechild, Lozinsky, Magnitogorsk,
Mardi Bros, MG, MGTU, Micro-128, Microbes, Milan, Milous, Minimal, Mirror,
Mix2, MLTI, Mono, Mosquito, MPS-OPC, MSTU, Mule, Murphy, Musicbug, Mutant,
Nina, Nomenklatura, Number 1, Number of the Beast, Ohio, Old Yankee, Omega,
Ontario, Oropax, Parity, Par !Is, Path, PC-Flu, PcVrsDs, Phantom, Phoenix,
Ping-Pong, Piter, Pixel, Plovdiv, Polimer, Polish Color, Possessed,
Pretoria, PrScr, Prudents, Rape, Rat, Raubkopi, Revenge Attacker,
Russian mirror, Semtex, Sentinel, Sept 18., Shadowbyte, Shake, Simulate,
Socha, Solano, Something, South African, Spanz, Sparse, Squeaker, Staf,
Stardot, StinkFoot, Stoned, Striker #1, Stupid, Suomi, Suriv 1, Suriv 2,
SVC, Sverdlov, Svir, Swap, Swedish, Swiss-143, Sylvia, SysLock, Taiwan,
Telecom, Tenbyte, Tequila, Terror, Testvirus, Thursday 12., Tony,
Traceback, Traveller, Tumen, TUQ, Turbo, Twin, USSR-1594, USSR-311, V-1,
Vacsina, Vcomm, VCS, VFSI, Victor, Vienna, Virdem, Virus-101, Virus-90,
Voronezh, VP, Vriest, W-13, Warrior, Whale, Wisconsin, Witcode, Wolfman,
Words, WWT, X-boot, XA1, Yankee, Yaunch, Yukon, Zero Bug, Zero Hunt, ZK-900
------------------------------
Date: Fri, 01 Nov 91 11:14:35 +0000
>From: Fridrik Skulason <
[email protected]>
Subject: Re: Cascade <---> Yap (same family?) (PC)
>This leads to my question:
> What is the relationship between these two???
There are two different viruses which have been distributed among virus
researchers as YAP.COM - please don't ask my about the origin of the name.
I have no idea.
One is 1701 bytes, and is closely related to the original Cascade-1701.
virus. This is the one my program recognizes as "Yap".
The other one is 6258 bytes, but I identify that as "Cascade-Formiche",
as the sample I originally received was named FORMICHE.COM. This one
seems to be based on Cascade, but modified somewhat - I have not had
time to examine it in detail.
Several variants of Cascade have been described in the past, but no
researcher seems to have copies of some of them - those 14 which I am
aware of are:
1701-A, 1701-B, 1701-Chic,1701-YAP
1704-A, 1704-B, 1704-C, 1704-D, 1704-Format, 1704-Multi,17Y4
Jojo-1701, Jojo-1703
Formiche
>Vcopy and Clean identified Yap in a file of 2114 bytes (413 wo/Cascade).
Which is an obvious indication that the virus cannot be 6258 bytes long :-)
- -frisk
------------------------------
Date: Fri, 01 Nov 91 13:57:48 +0000
>From: Fridrik Skulason <
[email protected]>
Subject: NCSA (Was: Request for standards)
In Message 31 Oct 91 15:25:20 GMT,
[email protected] (Vesselin writes:
>What? NCSA will test other people's scanners against their
>collection?! God forbid, unless they have gained signifficant amount
>of expertise recently. I'd like very much to see someone form the NCSA
>to comment this.
Well, they have been running my scanner against their "collection" for
some time now - I received a disk full of stuff that I did not detect
- - most of it for the simple reason that it was not infected, contained
Trojans, not viruses but there were two new viruses in there.
In their latest set they have done quite a bit of "cleaning-up" -
gotten rid of most of the duplicates, the non standard samples
(Vienna-infected files, which have been "inoculated" against Jerusalem
after infection) and so on.
The problem is just that they accept collections of infected (?) files
from a lot of people, and combine them all, instead of analysing and
classifying..
But well, I find this quite useful - after I sort out the "garbage"....
- -frisk
------------------------------
Date: 01 Nov 91 13:18:17 +0000
>From:
[email protected] ( )
Subject: Problems with McAfee's scanv84 (PC)
Has anyone else had problems with V84 of McAffee's scan program?
Yesterday I found a third PC that won't run this version of the
program - it hangs up and must be rebooted. Another PC gives a
message saying the scan.exe program has been damaged - not true since
the program works fine on most of our PCs. A third machine gave a
parity error message when I tried to scan the disk.
Most of our PCs have no problem with this version, and all of them
will run V82 successfully.
Kate Wilson
Network Mgr, UT School of Public Health
Houston
------------------------------
Date: Fri, 01 Nov 91 14:23:58 +0000
>From: Fridrik Skulason <
[email protected]>
Subject: Re: Hardware forever!
In Message 31 Oct 91 06:27:30 GMT,
[email protected] (Fred Waller) writes:
> Hardware is not _absolutely_ necessary, but I hold that it is the
> most practical, least expensive and most effective solution. It
> is also one that will not require updating.
Correct - and this hardware already exists - it is known as the "off
switch" - simply leave the computer off at all times, and it is 100%
secure against viruses.
> Protected mode, secure? Says who?
Protected mode is dependent on hardware capabilities - sure it can be
circumvented, just as any hardware "solution". If the computer is not
an embedded system, if it ever runs programs "from the outside" and is
designed to allow "useful stuff", like program development, it is
possible to write a virus for that system, REGARDLESS OF ANY
ANTI-VIRUS HARDWARE ON THAT SYSTEM!
> There is NO software defense that's fully reliable.
Correct.
> There IS hardware defense that is fully reliable.
Only the "off switch". :-)
- -frisk
------------------------------
Date: 01 Nov 91 10:53:03 -0500
>From: "David.M.Chess" <
[email protected]>
Subject: Re: Seeking Info on stoned virus (PC)
> From:
[email protected] (Hylton Boothroyd)
> * my machine became infected during a rebuild of the hard disk,
> * for a few days I did not know that,
> * each interruption of reading the special format PCTools set of backup
> disks from which I was rebuilding the disk led to that disk becoming
> unreadable to PCTools. Not just infected! Unreadable.
Good point! I should also have mentioned that, due to the assumption
it makes about a certain part of a disk(ette) being unused by anyone,
and safe to overlay, it can cause data loss and other problems on any
disk(ette)s that aren't formatted the way it expects. This includes
hard disks FDISK'd under DOS 2, or with certain other (old and/or
non-IBM) verions of FDISK, as well as diskettes in various special
formats.
DC
------------------------------
Date: Fri, 01 Nov 91 12:03:53 -0400
>From: 00073040%
[email protected]
Subject: Courses on Viri for teenagers, (General)
> From: Rotan <
[email protected]>
>
> Colleagues...
> very things that so many of us are fighting against. However, when I
> think of the audience of such a course (teenagers!) I worry. In fact,
> I am very worried.
This is not a flame. However, one of our responsibilities is to treat
others with respect. Categorizing groups of people (teenagers) and
suggesting that such a category is high-risk, therefore not privy to
information, poses a great problem to me. Now if I quote out of
context or such is NOT your point, I appologize ahead of time (let me
know). Two points for consideration: 1) it wasn't that long ago that
I was a part of this group, 2) MORE IMPORTANT - some of the more
gifted people I have met over the past number of years are (or were at
that time) still teenagers. Certaintly, the people in this group would
be an asset to future efforts in virus protection. Brian d'Auriol
Standard disclaimers apply: my opinions may (or may not) coincide with
my employer or colligues.
------------------------------
Date: Fri, 01 Nov 91 11:42:00 -0500
>From: James Jay Morgan <
[email protected]>
Subject: Keyboard shift key problem (PC)
Almost every morning several of our 7 public access pcs (All IBM PS/2 model
30-286s) will have a shift key problem - Typing any letter produces the
upper case; typing any number or shift key produces the shifted equivalent,
i.e. typing 2 produces @. Our only cure is to check the machines each
morning and reboot those that have the problem. We use a great variety of
software (network, cd-rom and other applications) on these stations, but
have not been able to trace the problem. I was wondering if it is a known
sympton of any pc virus.
Jim Morgan
RUTH LILLY MEDICAL LIBRARY
INDIANA UNIVERSITY SCHOOL OF MEDICINE
[email protected] [email protected]
------------------------------
Date: 01 Nov 91 17:06:42 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: McAfee84 fails to remove Cascade (PC)
[email protected] (McAfee Associates) writes:
> CLEAN-UP removes all samples of the 1701/1704 (alias Cascade) virus in
> our library. I would suspect that you either have files that have
I can confirm this. I tested Clean 84 agains our collection of Cascade
variants and it successfully removed all of them that were recognized
as 170X by Scan 84.
It was unable to remove two of the Cascade variants, which Scan calls
Jojo and Yap respectively, but the documantation never stated that it
can.
Hope the above helps.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 01 Nov 91 17:17:22 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Running circles around (PC)
padgett%
[email protected] (A. Padgett Peterson) writes:
> Given that programs MUST begin on sector boundaries, it is possible
> that a future SCANning technique (particularly when a scan of all
> files is requested) might involve a direct examination of each cluster
> with a file name track/ display only if something is found. Such a
But "something" might be found in the free disk space... What then?
> program might first load the FAT and then "walk the FAT" for extra
> speed. Given direct disk controller access and exact sector counts, on
Aha, this is better, since it will walk only those sectors that belong
to occupied clusters. However, there is still a problem. Since the
files always occupy an integer number of clusters, the last cluster of
the file is usually not used up to the end. So, there is still "dead"
space, which actually does not belong to the file.
There is also another problem. The method, described above will not be
compatible with volumes, which are accessed via device drivers. These
include mainly networks, Disk Manager volumes, Stacker volumes, etc.
> a modern machine it could be quick enough to avoid the long coffee
> breaks and limited validation we often use today.
Most of the current scanners begin to slow down not because of the
involved disk operations (which the method, proposed by you will speed
up), but by the fact that they have to look for a huge number of
strings. What is needed now, is a technique for faster string
searching, e.g., using some kind of hash tables or the Boyer-Moor
method. There are at least two scanners - HTScan and TbScan, which use
such techniques (the first uses the Boyer-Moor method and the second
uses hash tables), and they are quite fast (-much- faster than SCAN),
but not the fastest around.
Anyway, with the huge number of new viruses popping up every day, the
scanners will be useful only during the very near future (one year?
two years?). Scanning on-the-fly (only when the programs are executed)
is more time-effective, but it is still not cost-effective, because
constant updating is necessary. This has been pointed out by Fred
Cohen in his excellent "Short Course on Computer Viruses", where he
suggests that the integrity shells are the most cost-effective
solution.
> Of course use of compression like that might blow away scanners that
> use BIOS to scan the disks since the retrieved data would still be
> compressed. So the next. next generation scanner would have to be able
> to determine if compression is in use.... Oh well, nice thought.
Oh, no! It is enough that the users are trying to force the producers
of virus scanners to scan inside self-compressed executable files.
(There are currently at least 13 different self-compressing
techniques, according to Jim Bates. Who is able to handle all of them?
In fact, who is able to handle more than LZEXE and PKLite?) They
really don't need to be forced to handle also Stacker/SuperStore/DoubleDisk,
etc. formats!
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 207]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
