Return-Path: <VIRUS-L@ibm1.cc.lehigh.edu>

Return-Path: <[email protected]>
Received: from csmes.ncsl.nist.gov (MACBETH.NCSL.NIST.GOV) by csrc.ncsl.nist.gov (4.1/NIST)
id AA11030; Fri, 5 Jun 92 07:39:26 EDT
Posted-Date: Fri, 5 Jun 1992 07:26:20 EDT
Received-Date: Fri, 5 Jun 92 07:39:26 EDT
Received: from IBM1.CC.Lehigh.EDU by csmes.ncsl.nist.gov (4.1/NIST(rbj/dougm))
id AA04109; Fri, 5 Jun 92 07:34:27 EDT
Message-Id: <[email protected]>
Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 1965; Fri, 05 Jun 92 07:27:38 EDT
Received: from LEHIIBM1.BITNET by LEHIIBM1.BITNET (Mailer R2.08) with BSMTP id
6264; Fri, 05 Jun 92 07:27:13 EDT
Date: Fri, 5 Jun 1992 07:26:20 EDT
Reply-To: [email protected]
Sender: Virus Discussion List <[email protected]>
From: "The Moderator Kenneth R. van Wyk" <[email protected]>
Subject: VIRUS-L Digest V5 #114
Comments: To: [email protected]
To: Multiple recipients of list VIRUS-L <[email protected]>
Status: R
VIRUS-L Digest Friday, 5 Jun 1992 Volume 5 : Issue 114

Today's Topics:

Re: Zipped Viruses (PC)
information needed on v4 [f4] (PC)
Re: (Primative ?) Question (PC)
Re: McAfee VIRUSCAN V91 uploaded to SIMTEL20 (PC)
Re: ISPNews and why 100% is the only good enough solution (PC)
Re: How effective can TSR scanners be vs new viruses? (PC)
Famous Last Words (re
Scan91 for Windows (PC)
Re: VIRx version 2.3 released (PC)
re: OS2 Viruses (OS/2)
Re: OS2 Viruses (OS/2)
MVS Virii (IBM MVS)
Re: Taxonomy of viruses
re: Virus informational databases
Re: how to evolve
Contents of a talk on viruses
Reply to Jim Bates' article in Virus Bulletin
re: re:Clarifications -2
Related historical programs (CVP)
NETSC9191B.ZIP from McAfee at garbo, SIMTEL20, etc (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. (The complete set of posting guidelines is available by
FTP on cert.sei.cmu.edu or upon request.) 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. A FAQ (Frequently
Asked Questions) document and all of the back-issues are available by
anonymous FTP on cert.org (192.88.209.5). Administrative mail
(comments, suggestions, and so forth) should be sent to me at:
<[email protected]>.

Ken van Wyk

----------------------------------------------------------------------

Date: 01 Jun 92 17:07:36 +0000
>From: [email protected] (Vesselin Bontchev)
Subject: Re: Zipped Viruses (PC)

[email protected] (Magnus Olsson) writes:

> At least McAfee's scanner doesn't only check files on the disk and
> make a self-check, but also scans memory for viruses before doing
> anything else. Doesn't this cure the above problem, as the
> memory-resident stealth virus would be detected in memory?

It does - for the known viruses. If it is a new virus (unknown to
SCAN), it will not be found by the memory check; SCAN's self-check
will not detect it either; and if it is a fast infector (it almost has
to be, if it is a stealth virus), it will infect all the files that
you are scanning...

Now suppose that it has a damaging payload that says something like
"IF Number_of_infections >= 100 THEN Do_Random_Damage"...

No, when dealing with viruses it is always better to make sure that no
virus is present in memory. The only 100 % foolproof method for doing
this is to cold boot from a non-infected write-protected system
diskette.

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 public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected] D-2000 Hamburg 54, Germany

------------------------------

Date: Tue, 02 Jun 92 05:12:17 -0500
>From: Anthony Di Nardo <EENG6719%[email protected]>
Subject: information needed on v4 [f4] (PC)

Can someone please supply with information on the virus V4. SCANV91
recently reported finding this virus. I checked in the virus list
file supplied with scan and also vsum but could not find any
information.

------------------------------

Date: Mon, 01 Jun 92 20:48:29 +0000
>From: [email protected] (Paul Ducklin)
Subject: Re: (Primative ?) Question (PC)

Thus spake [email protected] (Vesselin Bontchev):

>> Well, for DOS PCs, one can create a "fairly secure channel" by the
>> tried-and-tested expedient of a clean boot. One of the delights of

>Don't forget that we are speaking about self-checking programs. If
>such program gets infected, the clean boot doesn't help a lot, since
>you must execute it in order to activate the self-checking code. And
>once you execute it, the virus will get control -before- the
>self-checking code. From that point on it can do just -anything- with
>the self-checking code - disable it, remove it, circumvent it, etc.

OK. But if one can arrange a "clean boot", one can (hopefully) arrange
a clean copy of one's favourite AV stuff too -- on the same write-
protected disc as the kernel, COMMAND.COM and so forth. We're talking
about a "fairly" secure channel, of course.

But you're right to point a paranoid finger at the proverbial clean
boot. I've dealt with many support calls (amongst colleagues who
ought to know better) which go along the line of "I found the XYZ
virus in memory. So I booted clean and scanned again: it survived
the boot!". They had indeed clean booted, then run IPX and NETx off
their local drives to connect to the network to run the AV stuff!

So much, indeed, for secure channels..

Paul Ducklin
Lounging in the City of Pretoria, South Africa

------------------------------

Date: Tue, 02 Jun 92 14:13:00 +0200
>From: "Jean-Pierre Engel (CMU Geneva)" <ENGEL%[email protected]>
Subject: Re: McAfee VIRUSCAN V91 uploaded to SIMTEL20 (PC)

[email protected] (McAfee Associates) writes:
> I have uploaded to WSMR-SIMTEL20.Army.Mil:
>...
> VALIDATE VALUES FOR VERSION 91:
> CLEAN-UP V91 (CLEAN.EXE) S:96,570 D:05-27-92 M1: D0F7 M2: 1AA1
> NETSCAN V91 (NETSCAN.EXE) S:75,050 D:05-27-92 M1: 33DA M2: 1AD1
> VIRUSCAN SCANV91 (SCAN.EXE) S:75,801 D:05-27-92 M1: 18FA M2: 127D
> VSHIELD VSHLD91 (VSHIELD.EXE) S:41,005 D:05-27-92 M1: 194F M2: 11CF
>...

I have Uploaded from SIMTEL20: NETSC91B, CLEAN91, SCANV91, VSHLD91. I
have found the following value with the validation prog.:

netsc91b.zip S: 116,543 D: 6-2-1992 M1: 16DC M2: 12FC
clean91.zip S: 141,577 D: 6-2-1992 M1: FD45 M2: 0101
scanv91.zip S: 129,268 D: 6-2-1992 M1: F2C3 M2: 0AC7
vshld91.zip S: 107,574 D: 6-2-1992 M1: 71B7 M2: 190B

Where is the probleme?
Thak you for your reply and best regards.
Jean-Pierre
+----------------------+------------------------------------+
| Jean-Pierre ENGEL | |
| Univ. Med. Center | Bitnet: [email protected] |
| University of Geneva | Internet: [email protected] |
| 1, Michel-Servet | Phone: +4122 229340 |
| CH-1211 Geneva 4 | FAX: +4122 473334 |
| Switzerland | Tx: 421330 cmu ch |
| ~~~~~~~~~~~ | |
+----------------------+------------------------------------+

------------------------------

Date: 02 Jun 92 11:40:57 +0000
>From: [email protected] (Vesselin Bontchev)
Subject: Re: ISPNews and why 100% is the only good enough solution (PC)

[email protected] (fc) writes:

> If you read ISPNews this month, the article with my name on it is not
> even close to the article I submitted - so if you are following my
> writings, throw that one out.

Hmm... I don't read ISPNews, but I sent an article there - I'm
wondering what will come out... :-)

> I have 500 EXE files, MtE gets 500, scanner catches+cleans 495. Next

The currently existing MtE-based viruses are able to infect only COM
files, but this is not essential, since the MtE itself can be used for
any kind of virus - including EXE infectors, boot/master boot sector
infectors, viruses written in a high level language...

> morning, I have 5 old MtE viruses and 495 new ones, scanner catches
> 490... After a few weeks, every file is infected, and scanner detects
> no infections!!!

Yes, this is exactly why I said in my posting that all the tested
scanners failed the test - even SCAN which missed only 4 mutations of
9,867...

Meanwhile we got three more "100 % MtE detectors", so we are going to
test them. One of them says it is based on the complete analysis of
what MtE is able to produce (an analysis of the code, no heuristics).

BTW, recently it was announced that the new version of VirX (2.3) is
able to detect the MtE-based viruses. BEWARE! In my -very- preliminary
tests, it missed 7 out of 27 Fear mutations! Don't use this scanner
for detecting MtE-based viruses! It is unreliable!!!

> I can just hear it now - "The infection was pretty bad - At
> first all of the files were infected, but after a few weeks of cleaning
> the systems every day, we completely eliminated the virus. Gee, what's
> that ping pong ball on the screen?"

BTW, we discussed the problem with David Chess and agreed that
- -disinfection- of MtE-based viruses is even more difficult than
- -detecting- them! So, if a system is found to be infected by such a
virus, the recomended solution is to remove all executable files and
to replace them with clean copies.

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 public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected] D-2000 Hamburg 54, Germany

------------------------------

Date: 02 Jun 92 10:57:12 +0000
>From: [email protected] (Vesselin Bontchev)
Subject: Re: How effective can TSR scanners be vs new viruses? (PC)

[email protected], writes:

> I've seen several TSR programs lately that claim that they will detect
> and viruses on your system even if they are new viruses. Now I
> understand that many viruses use the same methods but how reliable is
> this claim? Most new viruses that aren't just reworks of an old virus
> won't be caught will they?

It depends. If the programs that you refer to are really nothing more
than scanners, then you are correct - they will not detect new
viruses, regardless what their authors claim.

However, nowdays products that claim to "detect all viruses -
including the unknown ones" are usually not scanners but integrity
checkers. A resident integrity checker is perfectly possible - it is
in fact sometimes called "integrity shell". There are already several
such products: ASP Integrity Toolkit, VDS, and others. All of them are
able to catch unknown viruses. Whether they are able to catch all
possible viruses - no they are not, regardless what their authors are
claiming. But they offer a very good protection - much, much better
than the simple scanners.

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 public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected] D-2000 Hamburg 54, Germany

------------------------------

Date: Tue, 02 Jun 92 08:48:16 -0400
>From: [email protected] (A. Padgett Peterson)
Subject: Famous Last Words (re <100% MTE detection) (PC)

>From: fc <[email protected]>
>Subject: ISPNews and why 100% is the only good enough solution

>I can just hear it now - "The infection was pretty bad - At
>first all of the files were infected, but after a few weeks of cleaning
>the systems every day, we completely eliminated the virus. Gee, what's
>that ping pong ball on the screen?"

Heard much the same thing some time ago - received a call from another
company with a massive Jerusalem infection on their network (at 9 pm
and they needed help *now* 100 miles away natch). Once there overheard
a conference call between the local manager and the "Head Office".
H.O. did not understand why I was there, they had their own experts,
after all their people had already cleaned the Jeru-B off the H.O.
network three times in the last quarter ! 8*)

Not all bad, that evening paid for my laptop and was the start of
"active network defenses using login scripting" (see lots of previous
postings).

Of course today with most anti-virus programs permitting login
validation (the .DOCs for McAfee v91 even includes a sample Novell
login script) things are much easier and all major corporations now
use active techniques, right ?

Oh well, I could use a 486...
Warmly,

Padgett
<[email protected]>
Obviously my own opinions and not necessarily my employer's (working on it).

------------------------------

Date: Tue, 02 Jun 92 15:46:38 -0400
>From: Alfredo Pinheiro <[email protected]>
Subject: Scan91 for Windows (PC)

Greetings,

Please, could anyone upload Scan91 for Windows?

Thanks in advance,

Alfredo Pinheiro - CPDSBD04@FGVRJ
Database Administrator
Fundacao Getulio Vargas - Rio

------------------------------

Date: 01 Jun 92 16:56:10 +0000
>From: [email protected] (Vesselin Bontchev)
Subject: Re: VIRx version 2.3 released (PC)

[email protected] (C. Glenn Jordan -- Virex-PC Development Team) writes:

> 2. VIRx now detects all files encrypted with the "Mutating Engine"
> attributed to the Dark Avenger that are not already destroyed by the
> Engine's attempts to encrypt them (and most of those, as well).

This requires a bit of clarification. No files are "destroyed by the
Engine's attempts to encrypt them". However, the MtE sometimes (a bit
too often, IMHO) generates something that I call a "zero-key
decryptor". It does not encrypt the body of the virus and generates a
decryptor which essentially does nothing else than juggling a few
constants around some registers. No attempt to perform decryption is
present in these cases.

The files are not destroyed - they work perfectly and are able to
spread the virus. However, since the decryptor is almost non-existent,
it is very difficult to detect it... :-) Therefore, the scanners
include a scan string for the non-encrypted virus in order to cover
these cases. This is true for SCAN (it calls these cases "Mutating",
instead of "DAME"), F-Prot (it calls them "Dedicated", instead of
"MtE"), and obviously for VirX.

However, if somebody writes a new virus using the MtE, these special
cases will not be detected by the scanners - since the non-encrypted
virus will not contain the old scan strings (unless they are taken
from the body of the MtE itself - not from the virus). However, all
encrypted variants of this new virus will still be detected by the
scanners... Well, with a reliability that I reported.

> If you find executable programs with MtE encryption that we miss,
> please advise us at Microcom. As always, the BBS number is:

:-) Yet another scanner that performs 100 % detection of the MtE...
OK, I'll get it and perform some tests.

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 public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected] D-2000 Hamburg 54, Germany

------------------------------

Date: 02 Jun 92 08:39:18 -0400
>From: "David.M.Chess" <[email protected]>
Subject: re: OS2 Viruses (OS/2)

A few comments and clarifications on Fred Cohen's OS/2 posting:

> From: fc <[email protected]>

> Unfortunately for the scanner people, OS2 will not run DOS
>type scanners on OS2 files with long filenames...

That's OK; OS/2 will also not allow DOS type viruses to see those
files, so they won't get infected anyway! Assuming that by "DOS type"
you mean "runs in DOS sessions, not in OS/2 itself". Also, if your
scanner is in C (say), it's reasonably easy to port to OS/2; IBM's
Virus Scanning Program works in OS/2 itself as well as in DOS and DOS
sessions, and when run in OS/2 it can see files with long filenames.
(Despite my comforting words above, it's possible to have an infected
file with a long filename, if it had a short filename when infected
and someone has renamed it in the meantime; so a scanner that can see
long filenames is a nice thing to have.)

>(i.e. virus writers tend not to be rich)

I will once again have to say that we don't know this, or have
anything but intuition and very sparse anecdotal evidence to support
it. Virus writers have access to computers, which right away puts
them in the top 1% or so of the world's population. I would guess a
good number of them could afford a simple OS/2 system with enough
memory and disk to write a virus. It certainly doesn't require 120M!

>Partition table infectors work, but if they use memory, they get
>mangled by OS2 pretty fast.

Also, the existing ones never spread, since they rely on hooking INT13
to get control, and OS/2 never calls INT13 for diskette I/O.

>Boot block infectors and DIR viruses only work on FAT file systems.

That's not entirely true; the FORM virus, for instance, can infect an
HPFS-formatted partition. But the infected file system may no longer
be reliable, and data loss is likely.

>File infectors work

As you point out later, you mean "some file-infectors work". In
particular, "well-behaved" ones that use only documented DOS calls
(and some of the more popular undocumented ones) work.

>Low level viruses have to be OS2 customized to survive the OS2 memory
>mangement process.

And, for that matter, to be able to do -anything-. Low level viruses
currently do INTs of various kinds (13, 21) to change files and disk
areas; INTs don't work under OS/2 itself (although they do work in DOS
sessions).

>Evolutionary file infectors will continue to be a problem except for
>those with integrity shells.

At the moment, "evolutionary file infectors" are a problem only
for anti-virus developers. From the end user's point of view,
they're no more of a pain than any other virus, since all the
good anti-virus products detect them just as well as non-"evolutionary"
viruses. So I wouldn't have used the word "continue"! *8)
Integrity shells and similar things are certainly a good idea,
since we may reach a point where simpler methods no longer
work; but we aren't there yet ("Death of Scanners Predicted;
Film at 11").

>higher level viruses, such as spreadsheet viruses will operate
>unchanged.

Good point; OS/2 tries to be quite source-compatible with DOS, so
viruses at the source or interpreter level that worked under DOS will
likely work under OS/2 with little or no change. Note, though, that
no such viruses are currently a problem for real users.

>Conclusions - OS2 helps, but we're not out of the woods yet.

Definitely true, and a good summary. Thanks, Fred!

DC

------------------------------

Date: 02 Jun 92 12:06:38 +0000
>From: [email protected] (Vesselin Bontchev)
Subject: Re: OS2 Viruses (OS/2)

[email protected] (fc) writes:

> which is a version of the Integrity Toolkit for OS2. OS2 hase some
> very nice advantages over DOS protection, in that the operating system
> actually protects itself from arbitrary modification by user
> processes!!! The access control package from IT will work far better
> under OS2, and the protection from modifying executables will no
> longer be bypassed by direct IO to the disk. In short, OS2 makes
> sound techniques far more effective and removes all of the painful
> restrictions of DOS (e.g. fitting the resident protection intto under

Unfortunately, OS/2 also provides some excellent possibilities to the
virus writer... Just to list a few: stealth technologies using the
installable file systems feature, more executable objects to infect, a
richer batch language (REXX) which makes batch viruses perfectly
possible, ability to spawn even a non-resident virus to infect files
in the background, viruses which install themselves as device
monitors, the ability to directly execute files on another OS/2
machine connected via an Ethernet link (makes worms easy)... Have you
taken into account all those possible attacks? I have to agree,
however, than protection is much more easier added to OS/2 than to
MS-DOS...

> 3K, etc.) Unfortunately for the scanner people, OS2 will not run DOS
> type scanners on OS2 files with long filenames, but on the good side,

Ah, but this is not true. Some of them will run, if the files (even
the ones on the HPFS partitions) comply to the 8.3 convention. And
there are at least two scanners (IBM's VIRSCAN and Dr. Solomon's
Anti-Virus ToolKit) which run perfectly under OS/2...

> Partition table infectors work, but if they use memory, they get
> mangled by OS2 pretty fast.

The currently existing ones - yes. But it seems pretty easy to me to
make an MBR infector OS/2-aware...

> Boot block infectors and DIR viruses only work on FAT file systems.

Correct, although most boot sector infectors might have problems and
the DIR II virus itself might not work (I have not tested this).
However, Dir II-type viruses will work perfectly in the FAT files
systems.

> File infectors work

Only if they don't use too much tricks... In general, a virus which is
able to spread under Novell (with loosy set protection rights) will be
able to spread on the FAT partitions too...

> Viruses that require more than 8086 CPUs don't work.

Hmm, some of these require more than 8086 just because they use PUSHA
or PUSH immediate... Don't all these instructions work under OS/2?

> Stealth viruses aren't very stealthy, since OS2 is not bypassed, only
> DOS IO is forged.

Yeah, OS/2 is wonderful for examinig live stealth viruses. I mean -
viruses that are using the current stealth technology... However, it
should be possible to achieve wonders using the IFS technology - you
can make the disk look almost in any way you want to...

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 public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected] D-2000 Hamburg 54, Germany

------------------------------

Date: 02 Jun 92 10:46:58 +0000
>From: "Tim Hare" <[email protected]>
Subject: MVS Virii (IBM MVS)

While I have been following this group for only three or four months, I have
seen no mention of virii, bombs, trojans or the like which have targeted large
mainframe systems like MVS (which I work on as a systems programmer), or VM. I
would like to know if such programs exist, if anyone out there knows.
Because of the many security safeguards in MVS, I know it would be difficult
for a bomb or trojan to operate, but I don't believe it to be impossible. I've
read the logic manuals some, and I don't see ways to prevent the equivalent of
a "boot sector infection" on a 370 platform (i.e. something infecting either
the IPL bootstrap program, or the IPL program itself) - however I might be
overlooking something. Anyone out there want to discuss this with me? I know
there will be less interest (after all there are far fewer mainframes than
PC's), but the issue is still important, since one mainframe bomb could
conceivably affect many people.
If you need to limit your discussion to private mail, because of the way I
reach BITNET, you will need to send a message to register yourself into a
Soft-Switch mail re-router before you can successfully reach me. You do this
by sending a message containing FN=<your_first_name> LN=<your_last_name> to
[email protected]

Regards,
Tim Hare

------------------------------

Date: 01 Jun 92 16:38:45 +0000
>From: [email protected] (Vesselin Bontchev)
Subject: Re: Taxonomy of viruses

[email protected] (Mary K. Kuhner) writes:

> 1. Distance methods. One can find some measure of bit-by-bit distance
> between two viruses, and use any one of several algorithms to combine
> these into a tree.

> Advantages: This can be completely automated--there is no judgement
> involved in assessing the similarity of two viruses. It is also similar

It is not so simple. A virus is not just a bit stream. It contains
code areas, constant data fields, variable data fileds... The binary
image of the virus in two different files may be (and usually is)
different is compared on a byte-by-byte basis - becase of the
different contents of the variable data fields.

What you propose is theoretically possible if you have a detailed
analisys of the virus - its breakdown into code, constants, text,
data, and junk fields. Even the code parts must be further broken down
further into routines. Only then you can apply some kind of cluster
analysis. However, this is too effort-expensive and cannot be
automated, so it is of no signifficant practical interest.

> 2. Parsimony methods. Viruses can be hand-scored for the presence or
> absence of various features--file types infected, stealth, encoding,
> polymorphism, file destruction, etc.--and this data can be used to draw
> a phylogenetic tree via parsimony. The assumption is that these traits
> are not often changed by virus writers, so that viruses which share many
> of them are likely to be related.

> Advantages: The tree produced is likely to reflect intuitive ideas of
> virus relationships, since it's based on traits that are felt to be
> important. It won't be misled by such things as different literals in
> the payload.

Well, this is essentially what we are doing now... Unfortunately, it
cannot be automated or even formalized - as you said, it reflects our
intuitive ideas about virus relationship.

> It would be possible to classify a virus based on a report of its
> behavior, given enough detail, without having to examine an actual copy
> of the virus.

Indeed. Very often, if you describe detally a new virus to an expert,
he would be able to tell you 'Aha, yet another Jerusalem/Stoned/Vienna
variant'...

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 public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected] D-2000 Hamburg 54, Germany

------------------------------

Date: Tue, 02 Jun 92 00:56:00 +0100
>From: Anthony Naggs <[email protected]>
Subject: re: Virus informational databases

Julian Leong ([email protected]) brings up an interesting subject:
> During the last 6-8 months that I've been reading the VIRUS-L
> group I've noticed that no one has given a favorable review to any of
> the virus databases -- particularly Patricia Hoffman's VSUM. Has any
> effort been made to make any of the databases better? ...

I haven't seen VSUM in a while, the phone connect time for download is
l..o..n..g, but I was underwhelmed by the accuracy last time I looked.
The virus catalogues from Hamburg are accurate, but rather terse and not
really a database in the cross-referenced - easy to use sense. I don't
know of anything better, the ideal author of such a database must have a
number of skills or resources:
* accurate technical information about each virus, preferably first
hand so that (s)he can vouch for the quality of research.
* communication skills so that the content is relevant & helpful.
* understanding of Human Computer Interfaces so that presentation is
of greatest help to users, (without the messy, rainbow coloured,
confusion of some 'friendly' interfaces).
* sensible judgement as to which features of viruses should be given
most emphasis.
* an appreciation of the different situations when the database is used
so that an appropriate selection of operations can be provided.

(I can think of one person with most of these, :-), but how do I pay
my bills while writing/compiling the database? Constructive criticisms of
my abilities in any of these areas are always welcome (see below), otherwise
please complain to /dev/null).

> ... To me such a
> database would be an invaluable tool for the average computer user
> that believes a virus has his computer under siege. ...
[stuff deleted]
> ... I am aware
> that the FAQ mentions several sources of information but they also
> exercise a hefty toll on one's pocketbook. I realize that many may be
> hard-pressed for spare to devote to such a project, but doesn't it
> seem worthwhile?

Definitely, although pricing may be difficult: ideally it would be
cheap and readily available for home users, students, etc..., but for
large businesses such a database would be equivalent to a $1000 business
directory - ie something that it is necessary to help assure the continued
smooth running of the business.

A high price would be necessary to meet the original development costs,
and maintenance overheads, eg examining all new viruses submitted, possibly
cataloging A-V products for effective detection, ...

Regards, Anthony Naggs

Internet: [email protected] or Janet: [email protected]
Interesting offers? Phone: +44 273 589701
or write: P O Box 1080, Peacehaven, East Sussex BN10 8PZ, Great Britain

++ Profound message #182: What happened to my .sig?

------------------------------

Date: 02 Jun 92 11:16:24 +0000
>From: [email protected] (Vesselin Bontchev)
Subject: Re: how to evolve

[email protected] (fc) writes:

> In the addendum to my short course book, several types of evolution are
> shown. It turns out pretty ueasy to make detection of evolved programs
> NP-complete (or even exponential in same cases). Here's a simple
> example:

> a, b, ...., x, y, z Original program ja,r,js,f,jg,a,jb,...,j,jk Evolved
> program, where j* is a jump to the location of instruction *.

Ah, this is an old idea which we expected that will appear in some
virus, but it actually didn't... Using it it is possible to write a
polymorphic virus which is not encrypted. However, it is much more
difficult than just to use variable encryption and modify the
decryptor. Why do you think that detecting such viruses will be a
NP-complete problem? One can easily follow the JMPs and record
("trace") the execution flow in order to obtain a good scan string. It
can be done much easily than to detect V2P6, for instance...

> How about another?

> j=j+14 k=j+120-(58*2);j=k;

This is essentially what the Mutation Engine does; only it uses more
complex expressions. Can you show that detecting it is an NP-complete
problem?

> Another?

> a;
> b;
> c;
> d; is replaced by:
> a;
> call bb;
> c;
> call dd; dd: d
> return bb: b
> return

Ah, this seems to be a new idea...

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 public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected] D-2000 Hamburg 54, Germany

------------------------------

Date: Tue, 26 May 92 17:23:31 +0000
>From: [email protected] (Raphael Finkel)
Subject: Contents of a talk on viruses

I am a professor of computer science. Every so often, I am asked to
talk about computer viruses. Much of my knowledge comes from reading
this newsgroup on an irregular basis. I would like to share the notes
for my talk with the newsgroup in the hopes that the members can
improve the content and accuracy of the talk. Please send notes
directly to me ([email protected] or @ukma.bitnet); if the talk
changes substantially and there is interest, I will repost later.

Feel free to use this material yourself, if you want. I can send
troff source to anyone who is interested; it looks better formatted
for overhead slides.

- ---- talk follows

[Moderator's note: Thank you, Raphael. The complete text of the talk
has been placed in the VIRUS-L/comp.virus archives; it is available by
anonymous FTP from cert.org (192.88.209.5) in
pub/virus-l/docs/finkel.presentation]

------------------------------

Date: 01 Jun 92 17:18:56 +0000
>From: [email protected] (Vesselin Bontchev)
Subject: Reply to Jim Bates' article in Virus Bulletin

Hello, everybody!

In the May issue of Virus Bulletin there was an article about the
Vacsina viruses. The article was by Jim Bates and is partially based
on an information which I published on Virus-L about four years ago.
Therefore, I considered that it will be fair to forward a copy of my
reply to this article here. Sorry for the wasted bandwidth.

Regards,
Vesselin

To: Mr. Edward Wilding
Editor-in-chief of Virus Bulletin
Virus Bulletin Ltd.
21 The Quadrant
Abingdon Science Park
Abingdon
OX14 3YS
England

CC: Virus News International, Virus News and Reviews, Virus Telex,
Virus-L/comp.virus

>From: Vesselin Bontchev
Virus Test Center
University of Hamburg
Fachbereich Informatik - AGN
Vogt-Koelln-Strasse 30, rm. 107C
2000 Hamburg 54
Germany

29 May 1992

To be published in full or not at all.

Dear Mr. Wilding,

I read with mixed feelings the article "The Vacsina Development Path"
by Jim Bates, published in the May issue of Virus Bulletin. Mr. Bates
is a person whose capabilities as a technical virus expert I estimate
very much, so I was quite upset to notice what I understood as
non-objective personal attacks against me in his article mentioned
above.

First, if you don't know it already, let me inform you that I am the
"Storyteller" refered in the article. This is quite well known, since
I have published what Mr. Bates calls "the Story" in the elctronic
computer virus related forum Virus-L/comp.virus in December 1989. "The
Story" is true and regardless of some technical mistakes which it
contains, I am not ashamed to put my name under it. The technical
mistakes are due to the fact that I was not an experienced virus
expert at that time and some of the information which I presented was
obtained from what the author of the viruses had told me, instead of
from my own disassemblies of the viruses.

Nevertheless, I admit the technical mistakes and would like just to
notice that Mr. Bates' own articles are not totally free of them too
- - even if we just consider his article about the GP1 virus...
However, this does not give to Mr. Bates the right to refer to me as
a suspicious "Storyteller", who is "a Bulgarian himself". Regardless
of being a Bulgarian, I have devoted all my efforts to inform the
people all over the world about the virus threat and to help them to
combat it.

But let me consider the different points in Mr. Bates' article and my
objections against them.

1) Mr. Bates writes:

"The Storyteller, a Bulgarian himself, claimed to know the author,
whose initials he gave as TP."

Yes, I claimed to know the author of these viruses personally and am
still claiming this. We have been together for two years in the army,
together for four years in the computer science department in one and
the same university (the Technical University of Sofia), and even
worked together for one year in one and the same laboratory in this
same University after our graduation. His initials are indeed TP.
Does Mr. Bates imply that I am lying? I am presenting enough facts
which can be verified. Mr. Bates, who is a consultant of the
Computer Crime Unit at Scotland Yard could arrange these "claims" to
be verified, instead of putting my words publicly under suspicion.

2) Mr. Bates writes:

"While engaged in this circular method of product development, TP took
great care (the Storyteller tells us) to ensure that his viruses were
not destructive."

Yes, I am telling you this. The Vacsina/Yankee Doodle viruses were
designed and created at the time when the only known viruses in our
country were Vienna, Cascade, and Ping Pong. The sophisticated tricks
used in the Dark Avenger's viruses were not invented yet. Still, TP
indeed took great care to make his viruses not intentionally
destructive. Has Mr. Bates found some intentionally destructive code
in them? Why does not he mention that some viruses made in England
(Fu Manchu, Superhacker) cause non-intentionally damage much more
often than TP's ones?

The interrupt tracing technique which is now used even in some
anti-virus products was first implemented by these viruses. They used
it to bypass the interrupt monitoring programs. Yet they bypass only
programs that monitor INT 21h, not the ones that monitor INT 13h.
Does Mr. Bates think that the reason for this is that the person who
invented the technique didn't think about this possibility? Yes, he
did think about bypassing INT 13h too, but refused to implement it,
because it would bypass some disk cacheing programs too and could
cause (in some rare occasions!) unintentional damage.

None of the Vacsina/Yankee Doodle viruses tries to infect files with
internal overlays - because they just cannot be properly infected
without they functionality being destroyed. Does Mr. Bates know other
viruses which take the same care? (I do know some, by the way, but
they are very few.)

Note that with the above arguments I am NOT trying to prove that these
viruses are harmless. There is not such thing as a harmless virus. I
do not try to condon TP's activities. I am just trying to justify my
own words that he at least tried to make his viruses non-destructive.

3) Mr. Bates writes:

"TP's later viruses (following this series) were described as 'much
more clever' since they were able to 'hide' in all sorts of exotic
places within the machine's memory - PC DOS I/O buffers, unused space
of EXE headers and so on. They also became able to 'circumvent any
memory-resident program that monitors INT 13h' and eventually became
so clever and dangerous that even his close friend (the Storyteller)
was forbidden access to the code."

Again, Mr. Bates seems to imply that I am lying or telling stories.
Yet he must know rather well that now other viruses exist, which
implement similar ideas: the Number of the Beast viruses hide in the
PC-DOS I/O buffers, The Rat virus installs itself in the unused space
of the EXE headers and so on. Unforunately, the people who produced
these viruses (who are Bulgarians, I have to admit) didn't take as
even much care as TP did and freely released their viruses in wild...

4) Mr. Bates writes:

"However, the Storyteller then proceeds to explain that the reason the
viruses escaped to the outside world was not because TP spread them
himself, but because they were left 'lurking' on his PC which was a
shared machine. TP warned the other users of the presence of viruses
on the machine but this was 'taken as a joke' and that is how the
virus spread! At this point the story's credibility passes the
breaking point - but true or not, this tale of foolishness did have a
number of speciments of virus code accompanying it."

Here Mr. Bates plainly says that he does not believe me. This is his
right, but it is not his right to make the oppinion of the readers for
themselves without refering to the full story.

I would like to remind to Mr. Bates that at the time when the first TP
viruses appeared, such a well-known computer specialist as Peter
Norton claimed that computer viruses do not really exist and that they
are just yet another urban myth. Was it so susprising then that most
people in Bulgaria didn't take TP's warning seriously? Later I learned
that one of the students did spread some of the variants
intentionally, because he wanted to verify that they can really show a
virus-like behaviour... This might look strange now and to the West,
but yet another true story is that the father of the author of the
Voronezh viruses was so proud of his son's creatures, that he went and
spread them intentionally in his office...

Now let me point some technical mistakes in Mr. Bates' article.

5) Mr. Bates writes:

"The samples range in date from February 1989 to November 1990 and,
somewhat strangely, they don't occur in order of development. The
oldest is TP33 while the most recent is TP39."

It has obviously not occured to Mr. Bates that I have not received
those samples directly from the author and that the dates of the files
reflect the dates when I have caught the respective variants in the
wild.

6) Mr. Bates writes:

"In appending this code, the 'MZ' in the header is destroyed but the
program usually continues to function correctly."

Can Mr. Bates provide some examples when the program DOES NOT continue
to function properly (excluding the case of the self-checking
programs)? The code appended to the files does essentially the same as
DOS does when loading an EXE file.

7) Mr. Bates writes:

"The next time the virus tests this file, it will appear to be a COM
file and that is when infection occurs."

Obviously Mr. Bates has failed to disassemble all the examples of the
virus provided to him, otherwise he would have noticed that some of
the later versions of the virus infect EXE files in "one pass",
consecutively converting them into COM format and appending the virus
code to them.

8) Mr. Bates writes:

"With TP25, the author developped a musical penchant and included a
routine to play the George M. Cohan tune 'Yankee Doodle' whenever the
user pressed Ctrl-Alt-Del."

For Mr. Bates' information: very few variants of the virus play the
tune under those conditions. (Only variants 23-25, if I remember
correctly.) The others play the tune at 17:00 (or more exactly, a few
seconds before that).

9) Mr. Bates writes:

"We are told that this was the first virus to introduce armoured code
to deactivate debuggers."

Obviously, Mr. Bates does not seem to believe what he has been told.
Maybe in this case he is able to show us an earlier virus which has
this capability? Or does he not believe in the exsistence of the
capability at all? At least this is something which can be checked
easily...

10) Mr. Bates writes:

"This is a discrepancy in the Storyteller's narrative, since he
insists that TP46 'is able to fight the 1701/Cascade virus'."

Either Mr. Bates' disassembly of the virus is incomplete, or he is
misunderstanding my words. Otherwise I cannot explain how he failed to
notice that the virus (TP46) tests for the presence of Cascade during
installation time, using Cascade's own "are you there?" call and then
deactivates the virus if it is present.

11) Mr. Bates writes: (about TP46)

"The musical trigger is still present but the virus has no other
trigger routine other than code to deactivate the Italian virus."

Again, Mr. Bates' technical tallents seem to fail him. The truth is
that the virus DOES have a trigger to the musical routine and it is
not triggered at "an indeterminate time after the virus goes resident"
(as is written in the sidebar of Mr. Bates' article), but exactly at
the same time as the previous variants - a few seconds before 17:00.
Indeed, the routine is triggered with a probablity of 1/8 - obviously
to prevent the virus from being noticed by some "experts" like Mr.
Bates.

12) Mr. Bates writes:

"This sequence of events is at variance with the Storyteller's
description of the anti-Italian virus which he names as TP42. He
insists that this changes it 'in such a way that after 255 reboots it
will kill itself and the only thing which will rest on the disk will
be the 'dead body' of the virus.'"

Mr. Bates is correct this time and I admit my mistake. I would only
like to point out that it was due to my unexperience at that time and
to the fact that I just believed the virus author, instead of
disassembling the virus myself... To err is human; everybody commits
mistakes especially when speaking about viruses. Mr. Bates' own
articles on this subject are far from error-free...

13) Mr. Bates writes:

"The range of TP viruses has not grown since the original group of
fourteen were sent to the West."

Mr. Bates probably means that no LATER variants have been discovered.
The reason is that TP has simply stopped writing viruses. However,
onle EARLIER variant has been reported later - TP39 has been
discovered signifficantly later than the other variants. In fact, I
have discovered it myself in a Russian virus collection.

14) Mr. Bates writes:

"Only TP04 and TP46 have been reported in the wild,..."

This is a blatant mistake, which even disagrees with Scotland Yard's
Computer Crime Unit's own reports - an organization of which Mr. Bates
is a consultant. In fact, the first variant of the virus reported in
the West was TP05. Probably the most widespread one is TP44, although
variants 4, 6, 33, and 45 have also been reported. Maybe's Mr.
Bates' routine to determine the particular virus variant is buggy...

As a conclusion, I would like to emphasize that I continue to highly
estimate Mr. Bates' technical talents as a computer virus expert. I
would only like to suggest him to limit himself in his articles to
technical matter, instead of using them for personal attacks against
people like myself or Dr. Fred Cohen, who are at the same side of the
virus fight as Mr. Bates... And while it is true that several computer
viruses have been written in Bulgaria, it is definitively NOT true
that all Bulgarians write viruses and none of their words should be
trusted... Mr. Bates should trust (or at least verify) the words of at
least some of them...

Failing to do so he runs the risk to continue to make mistakes like in
the case of the Dir II virus, which it declared as "curiosity", and
"far from being dangerous" in Virus Bulletin's issue of November
1991. Obviously the virus has not read Mr. Bates' article, since it
spreads happily in the UK - just as I have predicted...

Sincerely yours,

Vesselin "The Storyteller" Bontchev

- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN
** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected] D-2000 Hamburg 54, Germany

------------------------------

Date: 30 May 92 20:44:04 -0400
>From: "Tarkan Yetiser" <[email protected]>
Subject: re: re:Clarifications -2

Hello,

From: [email protected] (Vesselin Bontchev) writes
> Subject: Re: Clarifications... part 2 (PC)

>>> I certainly won't spend the time to test all the viruses we have on
>>> your product. It doesn't worth the effort. Besides, even if it does

>> Then you should adjust your claims on the capabilities of VDS.
>> IMHO, you are making too many assumptions.

> My claims are based on my knowledge about the internals of DOS and the
> PC and on my knowledge of what some viruses can do, which I gained by
> disassembling hundreds of viruses... I still claim that it is not
> possible to stop all the possible stealth viruses, even if we restrict
> ourselves to only the currently existing stealth/tunneling -techniques-

I was not questioning your experience with viruses or your knowledge of
the way DOS operates. Definition of "stopping all possible stealth viruses"
is subjective. If a virus can do it, so can an anti-viral and vice versa.
The odds are in favor of the anti-viral since it has nothing to hide :-))

>>> detect all the known viruses, this does not mean anything - most good
>>> scanners do the same. In order to prove that it fails to protect

>> Let's get serious. Scanners do the same? It takes a minor hack to
>> outdate the niftiest one. We are concentrating on large scale/long term
>> solutions. Remember Cohen's cost formulas?

> Yes, I remember Cohen's cost formulas. I have studied most of his
> publications very carefully. And you should read more carefully what I
> am saying. I say that "detects all known viruses" is nothing more than
> what the currently existing good scanner do. And "minor hack" means
> that you are creating a new virus, which falls outside the above claim
> (which is aimed only towards the -already- existing viruses).

How can you constrain your argument like that? New viruses, hacked
versions are an everyday reality. You cannot just stop the clock and
say that a good scanner detects all known viruses. That's the same
fallacy many people trying to come up with virus information banks
are committing. By the time such an effort is completed, it will be
obsolete. Back to square one again. IMHO, such virus-specific approaches
are futile. More generic detection mechanisms should be considered.

>>> construct a virus which uses them - something that I'll never do
>>> anyway. What I might do in the future is a set of programs that

>> Hope, you do not mean to create a virus just to break a certain scheme.

> I think I was clear enough in saying that I won't construct a virus,
> even for the purpose of demonstrating that a particular security
> scheme is weak.

I realize you are a serious researcher with good practices in dealing
with such things. No innuendo was intended. Alas, the same cannot be
said of others who try to prove a point by crafting viruses.

>>> BTW, there's a kind of virus that will defeat -any- anti-virus system,
>>> which is based on integrity checking -only-. This is the Darth Vader
>>> virus. I know, you'll argue that it spreads so slowly that it's
>>> unlikely to be successful in the wild...

>> In the bigger scheme of things, it is trivial as far as the threat it
>> might pose is concerned. Exceptions again.

> I fail to understand your objection. I just plainly said that a virus
> which uses Darth Vader's idea for infection strategy will evade the
> integrity checkers. Do you object to that? Or shall I explain you how
> to write a much better spreading virus than Darth Vader, using the
> same idea and still evading the integrity checkers? I already
> explained this privately to Yisrael Radai, I hope that he can confirm
> what I am claiming...

What I meant is that no one technique can be so successful that the
viral spread cannot be contained. I still would like to hear what kind
of an improvement to Darth Vader you had in mind.

>> Good. You read Cohen's paper :-)

> As I already said, I am following his publications very carefully. My
> own experience shows me that he's usually right in what he says and
> that ignoring what he says might have bad consequences.

Well, yes, he has the kind of focus that many of us lack :-))

>> No, Vesselin, no. We operate quite differently. I'll describe it in
>> private if you are interested.

> Please, do so. I hope to be able to show you what a virus can do in
> order to bypass your program and this is not for public discussion.

I will shortly.

>>> isn't mainly because it tries to bypass stealth viruses - something
>>> which is a priori impossible without memory protection. Therefore why

>> This is not correct.

> Isn't is correct that the stealth bypassing feature is what prevents
> your program from working on compressed disks and other disks that are
> controlled by installable device drivers?

For the most part, yes. What I meant is that, even without memory
protection it is not impossible. The virus does not have the benefit of
memory protection either. Both viruses and anti-viruses are subject
to the limitations of the target system. Odds are in favor of anti-viruses.

>> Memory protection is a different issue, and it
>> would allow us to accomplish many other things, but the implementation
>> overhead is too much.

> The implementation is trivial, since this is already supported by the
> '286 and '386 hardware. Implementation is not the problem. The problem
> is that implementing it will break a lot of currently existing
> applications and this is not acceptable for most people.

No implementation exists in a vacuum. You just defined "overhead" :-)

>> More compatible? Yes, this is needed. VDS 2.10 is a lot more flexible.

> Good! Is is available?

Hopefully, next week. Our acid testers discovered a few glitches that
had to be fixed. Better logging facility was demanded too. Decoys are
smarter (I should thank you as well).

>>> As to UT, it -will- detect any stealth virus, if installed on a clean
>>> system and used according to the manual. Something that cannot be said
>>> about VDS...

>> Any stealth virus? Well, you are contradicting yourself in principle.

> And you fail to read carefully what I'm saying. I said that it is able
> to do so IF installed on a clean system AND used according to the
> manual.

Indeed? Doesn't this put it in the same category as a home-made CRC
checker? Even if a good integrity checker is not installed on a clean
system, it should be able to detect new modifications to existing code. It
will miss the ones that were there before installation, assuming a virus
that was not recognized by the scanner component. How do you explain
failure to notice new modifications?

>> what is that magic quality that makes UT catch all stealth viruses? I

> Ensuring that no such virus is in memory. I.e., booting from a clean
> floppy. At least from time to time.

I rest my case :-)) I could provide source code to a home-made CRC
checker if it would be used only in the manner you prescribe for UT.
Otherwise, all bets are off. But we know such home-made solutions are
doomed since they do not get used as intended: boot from a clean DOS
diskette and then look for modifications while a virus is not active.
I shall let some magazines offer such solutions :-)))

>> have reports from people who forgot to activate the memory resident
>> component of UT and ended up infecting most of their programs as the

> Had they used the safe check, it wouldn't happen.

>> integrity checker component did its miracle. BTW, this was not a stealth
>> virus, just a hacked version of Datalock. Of course, UT told her each

> Yup, it will happen with any fast infector (like Dark Avenger), if the
> virus is already active. The trick is to prevent it from being active.

Fascinating! That very trick requires much user-awareness, something
many people lack, and therefore the viruses continue to spread.
Contributing to viral spread by a full-fledged anti-viral package is
simply not acceptable.

> Oh, BTW, the product is called UT only in the USA. To the rest of the
> world it is known as V-Analyst III.

I wonder if 6th Gen. made BRM people not to compete with them in the US.
The developers probably would not sign their names under 6th Gen's docs.
It is less than realistic, and more than just marketing hype. Very sad.

Regards,

Tarkan Yetiser
VDS Advanced Research Group P.O. Box 9393
(410) 247-7117 Baltimore, MD 21228
e-mail: [email protected]

------------------------------

Date: Fri, 29 May 92 22:12:55 -0700
>From: [email protected] (Robert Slade)
Subject: Related historical programs (CVP)

HISINT2.CVP 920529

Early viral related programs

One of the factors involved in the success of viral programs is a
study of the mindset of the user: a study of the psychology or
sociology of the computer community. Since the spread of viral
programs generally require some action, albeit unknowing, on the part
of the operator, it is instructive to look at the security breaking
aspects of other historical programs.

"Password trojans" are extremely popular in the university and
college environments (where most of the new security breaking ideas
and pranks tend to come from anyway). These programs can be
extremely simple. An easy "painting" of the screen with a facsimile
of the normal login screen will generally get the user to enter their
name and password. It is quite simple to have a program write this
information to a file, or even mail it to a specific account. Most
of these programs will then send back a message to the user that the
login has been denied; most users will accept this as an indication
that they have either a mistake in entering the login data or that
there is some unknown fault in the system. Few question it even
after repeated refusals. Some programs are sophisticated enough to
pass the login information on to another spawned process: few users
even know enough to check the level of nesting of processes.

(A famous, if relatively harmless, prank in earlier computers was the
"cookie" program which ran on PDP series computers. This program
would halt the operation that the victim was working on and present a
message requesting a cookie. There are consistent reports of viral
programs following this pattern, including a very detailed report of
a "Spanish Cookie" virus, however the author has never seen any such
program. In the absence of such data I have, regretfully, come to
the conclusion that this is another piece of computer folklore which
has mutated into legend.)

Another, lesser known, prank has a closer relationship to current
viral programs. In the RISKS-FORUM Digest (6-42) in March of 1988
there was a detailed outline of the use of the "intelligent" features
of Wyse 75 terminals. This was a specific instance of a general case
of the use of intelligent peripherals for security cracking. In this
case, the terminal had a feature which would allow keys to be
remapped from the host system. Another feature allowed the keys to
be called for from the host. This allowed email messages (actually
only the subject line) to be composed which would remap a key to
correspond to the "kill process and logout" command, and then have
the command submitted by the terminal. With only a little thought,
an email virus could be written taking advantage of this fact.

copyright Robert M. Slade, 1992 HISINT2.CVP 920529

=============
Vancouver [email protected] | Lotteries are a tax
Institute for [email protected] | on the arithmetically
Research into [email protected] | impaired.
User CyberStore Dpac 85301030 |
Security Canada V7K 2G6 |

------------------------------

Date: Tue, 02 Jun 92 05:57:05 +0000
>From: [email protected] (Timo Salmi)
Subject: NETSC9191B.ZIP from McAfee at garbo, SIMTEL20, etc (PC)

- -From: [email protected] (Harri Valkama)
To: [email protected]
Date: Tue, 2 Jun 92 07:59:56 +0300

Date: Mon, 1 Jun 92 11:20:06 PDT
From: [email protected] (McAfee Associates)
X-Mailer: Mail User's Shell (7.2.3 5/22/91)

I have uploaded to SIMTEL20 PD1:<MSDOS.TROJAN-PRO>
I have uploaded to GARBO pc/incoming
I have uploaded to CERT.ORG incoming
I have uploaded to RISC pub/00uploads

NETSC91B.ZIP NETSCAN 91-B network server virus scanner

NETSCAN VERSION 91-B RELEASED

Version 91-B of NETSCAN has been released. This release replaces
This release replaces Version 91 which gave a false alarm of the V3 [F3]
virus on the CHK123.EXE file from Lotus.

VALIDATE VALUES FOR VERSION 91-B:
NETSCAN 91B (NETSCAN.EXE) S:75,118 D:05-28-92 M1: CC02 M2: 17FD

Aryeh Goretsky
McAfee Associates Technical Support

Thank you Aryeh. This is now available as:

garbo.uwasa.fi:/pc/virus/netsc91b.zip

- -harri-

------------------------------

End of VIRUS-L Digest [Volume 5 Issue 114]
******************************************

Downloaded From P-80 International Information Systems 304-744-2253