Return-Path: <wack>
Received: by csrc.ncsl.nist.gov (4.1/NIST)
id AA16751; Thu, 23 Jul 92 08:15:41 EDT
Date: Thu, 23 Jul 92 08:15:41 EDT
From: John P. Wack <wack>
Posted-Date: Thu, 23 Jul 92 08:15:41 EDT
Received-Date: Thu, 23 Jul 92 08:15:41 EDT
Message-Id: <
[email protected]>
To: csrc-virusl
Status: R
VIRUS-L Digest Wednesday, 8 Jul 1992 Volume 5 : Issue 128
Today's Topics:
Re: 696/Scr2/Enemy (was Re: Scream II virus help?) (PC)
Re: 696/Scr2/Enemy (was Re: Scream II virus help?) (PC)
A Trojan in Sydney, Australia (PC)
Check archives for Virus... (PC)
Re: MtE analysis & report (PC)
Re: Imprecise scanners (PC)
Getting a Copy of Cohen's Paper
Re: The "Lehigh" virus (CVP)
Checksumming and false positives
Re: virus-l stuff of late
questionnaire
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].
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: Mon, 06 Jul 92 22:40:58 +0000
>From:
[email protected] (Mike J. Brown)
Subject: Re: 696/Scr2/Enemy (was Re: Scream II virus help?) (PC)
Repeat after me: LESSON LEARNED THE HARD WAY.
You know what I honestly thought? "Viruses aren't that common" and
"it's too much trouble to buy all those disks and take all that time
to back up." Yeah, I know I was playing with fire, and I don't
deserve anybody's help, but both Frisk and "the McAfee people" seem
willing to investigate it since the virus is destructive and is in the
wild. I'm going to leave my other hard drive infected and untouched
for now, and I'm running VirStop on bootup and F-Prot at least twice a
session to be sure nothing's happening. I ran Norton Utilities which
repaired some "lost clusters" and in the process ended up repairing
some of the not-completely-disinfected files back to their infected
state. What a mess!
- --
Mike Brown
[email protected]
"The Universe is a spheroid region 705 meters in diameter."
------------------------------
Date: 06 Jul 92 22:54:47 +0000
>From:
[email protected] (Fridrik Skulason)
Subject: Re: 696/Scr2/Enemy (was Re: Scream II virus help?) (PC)
[email protected] (Vesselin Bontchev) writes:
>:-) The "F-Prot people" are just Fridrik Skulason.
Well...I have a few people working for me... :-)
> I hope that he'll
>include disinfection for this virus soon,
I have... version 2.04B (to be released tomorrow or the day after) includes
disinfection of this virus.
> since the virus is
>definitively in the wild. The discrepancy is only in the naming and
>probably F-Prot will match the CARO standard.
It does now...
- -frisk
------------------------------
Date: Mon, 06 Jul 92 22:02:56 +0000
>From:
[email protected] (Jim Baltaxe)
Subject: A Trojan in Sydney, Australia (PC)
I just returned from a two week holiday to find a request from a local
radio station for information concerning a trojan program which was
discovered in Sydney, Australia.
Unfortunately the original wire service story was slightly garbled (it
identified the program as a "virus" called "trojan" then said that it
did not replicate itself) and did not include the name of the carrying
files/programs to watch out for. It did say that the program displayed
a message that it was a virus simulation, but it then seemed to
distroy FAT & directory information making the hard disk unusable.
Does anybody have any further details concerning this trojan, like
what it actually does, how common it might be, where it has come from,
spread to etc.? Please e-mail replies directly since there is some
urgency if the information is to be incorporated into the news story
that is being written (It'd be nice for a change to have an _accurate_
account of one of these things).
My apologies if this is asking for old news, as I said, I was away on
holiday.
Thanks again.
- --
Jim Baltaxe -
[email protected]
Computing Services Centre - Victoria University of Wellington - New Zealand
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Time is such a valuable commodity because they're not making it any more.
------------------------------
Date: Tue, 07 Jul 92 14:37:30 +0000
>From:
[email protected] (Bill Richmond)
Subject: Check archives for Virus... (PC)
My appologies if this subject has been beaten to death but I
need to know if most virus scanners (ie SCAN) look through all files
in a zipped file? Is there a switch to make it do this? All email
would be greatly appreciated...
I can't give you brains,
|\ but I can give you a
O __________|_\______ diploma.
\_.______________________| * * * * * * * * */ -- The Wizard of Oz
__\____ |=================/
[email protected]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
------------------------------
Date: Wed, 08 Jul 92 05:55:15 +0000
>From:
[email protected] (Holt Sorenson)
Subject: Re: MtE analysis & report (PC)
[email protected] (Fridrik Skulason) writes:
>
[email protected] (Tarkan Yetiser) writes:
>
>fraction of the (rare) Method-3 encrypted files, which I hope I will
>be able to fix as soon as I have succeeded in creating a single sample
>that I don't detect.
What exactly is Method-3 encryption ? What makes it different from the
usual XOR schemes ?
Holt Sorenson
------------------------------
Date: Wed, 08 Jul 92 05:59:58 +0000
>From:
[email protected] (Holt Sorenson)
Subject: Re: Imprecise scanners (PC)
[email protected] (Vesselin Bontchev) writes:
>
>Version 91 of Scan is MUCH worse in identification than any previous
>version.
I have to agree with this. After disassembling and comparing the virus
that I posted here a couple weeks ago about, it turned out that it was
Datarape v1.1 not 1530. Oh, well. Guess we have to rely on down and
dirty disassembling for real identification.
Holt Sorenson
------------------------------
Date: Mon, 06 Jul 92 17:43:22 +0000
>From:
[email protected] (The Weasel)
Subject: Getting a Copy of Cohen's Paper
Hi There,
Many of the general discussions on this group mention Fred Cohen's
paper, his thesis I think. I was wondering if there is an ftp site
where I can get this paper, or if someone out there could mail it to
me.
Thanks in advance.
Peter
- ---
Peter Chang | "Would it save you a lot of time
E-Mail:
[email protected] | if I just gave up and went mad now?"
Snail Mail: PO Box 9603 | Arthur Dent, The HHG
Stanford, CA 94309 |
------------------------------
Date: 07 Jul 92 07:08:39 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: The "Lehigh" virus (CVP)
[email protected] (Robert Slade) writes:
> computer literate. Student consultants at universities and colleges
> are presented with a steady stream of disks from which files have
> "mysteriously" disappeared. In November of 1987, however, it
> appeared that certain of the failed disks were due to something
> other than user carelessness.
Well, the disks returned had a more serious problem than just a few
files disappeared. They were unreadable. Of course, this happens every
now and then, but what surprised the consultants at Lehigh was the
quantity of returned unreadable diskettes.
> The Lehigh virus overwrote the stack space at the end of the
> COMMAND.COM file. (Early reports stated there was no increase in
> file size: later research showed an increase of 555 bytes in the
> size of infected files.) When an infected COMMAND.COM was run
Then the "later research" is wrong. The virus indeed is 555 bytes
long, but it does NOT increase the size of the file. It just
overwrites the last 555 bytes of any file named COMMAND.COM.
> uninfected COMMAND.COM files would be infected. A counter was kept
> of infections: after four infections the virus would overwrite the
> boot and FAT areas of disks with contents from the BIOS.
The counter was kept in memory on computers without a hard disk and on
the hard disk on computers which had one.
According to some reports, a new version of the virus appeared in
February the next year. It had the counter limit increased to 10.
Unfortunately, Ken didn't save a copy of it, so now this variant is
"lost".
Regards,
Vesselin
P.S. I am taking my holidays the next week. This will have the side
effect to reduce the traffic on Virus-L/comp.virus... :-) No e-mail
sent to me will be lost, but don't expect a reply before the end of
August. For several reasons I cannot install an e-mail answering
machine.
- --
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, 07 Jul 92 20:24:59 +0000
>From:
[email protected] (Paul Ducklin)
Subject: Checksumming and false positives
As someone said:
> I am somewhat taken aback by the claims that integrity
>checkers get substantial numbers of false positives or that they
>require users to make decisions when they don't know how.
Modifying executable files on disc is, alas, fair game under DOS.
There are many programs which, when executing, record information
about their last run (or what have you) back into their binary
on disc. There are also plenty of software systems in which the
installation utilities write configuration information back into
binary files on disc. Program pairs like TURBO--TINST and TC--TCINST
come to mind at once.
Binaries modified in this way trip up integrity checkers as surely
as unauthorised tampering or virus infection. Somewhere in the
checking loop, users need to decide whether a modification was
legitimate or not...a sometimes onerous burden. And, of course, if
you have a slow virus (one which infects only when binaries change
or are created), this burden becomes more problematic.
In other words, nothing's easy :-)
Paul Ducklin
Somewhere near the middle of the City of Pretoria
South Africa
------------------------------
Date: Wed, 08 Jul 92 15:12:00 +1200
>From: "Mark Aitchison, U of Canty; Physics" <
[email protected]>
Subject: Re: virus-l stuff of late
[email protected] (Vesselin Bontchev) writes:
>
[email protected] (Jimmy Kuo) writes:
>> People seem to forget, 99.99999999% IS 100%. It is not, however,
(sigh) The whole point of the "as close to 100% as can be reasonably
tested" discussion is that a few mutations might get past (although
the generation after them might not all escape detection, spoiling the
analogy with biological viruses). The testing processes can only say a
product probably detects ninety nine-point-so-many-nines percent of
the mutations. Knowledge of the software that creates the mutations
and the software detecting them, plus some assumptions about other
software not changing things (e.g. the effects of a second virus!)
might lead to a theoretical hundred percent. But what good is saying
you have 100% detection of a subset of what one mutation engine can do
at one point in time? Users really want 100% detection of 100% of the
viruses that are known or unknown. What we get is advertising hype, in
which the "numbers game" looks to now include the magic number "100%"
in places it simply shouldn't be.
>> 1) a standard location on a network drive could provide information to the
>> integrity checker of updates conducted or available through the network.
>>...
> This is a nice idea and certainly has to be researched... However,
> consider this: such tool will be something standard. What prevents the
> virus from using it to register the infected files as properly
> updated?
But the important use of this is where there are areas that network
nodes cannot write, so the updating can only be made on the server.
In that case, you might ask, why worry about the programs in such
read-only areas? Well, there could be programs of the same name (or
COM extension) that get executed first, created by viruses in data
areas. Or there could be machines with a mixture of local programs and
some network drives, meaning it is worth running change checkers - but
they would keep choking on changes made by system adminstrators. So
the idea is a good one, I'd say, so long as that "standard" area is
safe. In fact, the more that change detectors can be told about the
environment, the better. Not only should some areas be read-only (here
we might not be talking only about networks), but rules like (there
must not be a program with the same name (or even any programs!) in
particular areas.
I have a feeling that networks have so far mainly been thought of as a
hassle for anti-viral programs, but they are - if used properly - a
way of getting very good security for organisations where PC's and
Mac's with diskette drives (and all that implies). They can provide
the same level of security as good hardware protection schemes,
without all the problems (well, with a different set of problems,
perhaps!).
Mark Aitchison
------------------------------
Date: Wed, 08 Jul 92 07:44:43 -0400
>From:
[email protected] (Celustkova-k336-doktorand(Richta))
Subject: questionnaire
Hello,
I am postgraduate student on Department of Computers of Faculty of
Electrical Engineering in Prague, working on my thesis "Software
Reliability with regar- ding to computer viruses".
Thesis is planned to be composed of three parts. First part should
present computer virus problem today. The presentation should include
introduction to computer virus problem in general with short history,
description of typical computer virus behaviour and list of computer
virus types today. Second part should give a mathematical description
of computer virus infection process and reliability function of
software attacked by computer virus. This part should include:
- - description and results of experiments performed with several computer
viruses,
- - mathematical definition of infection process based on results of the
experiments,
- - mathematical description of reliability of software endangered with
computer virus based on mathematical form of infection process which
actually represents failure rate process (a term from reliability theory),
- - verification of some of today's present antivirus programs regarding to
software reliability maintenance.
Third part of thesis should give a prediction of environment for
computer viruses spread in future, a model of future computer virus
and suggestion of the most effective antivirus protection. For the
purpose of this part I prepared the questionnaire which results should
give a prediction of environment for computer virus spread and
evolution in future.
I would like to have a sample of at least 100 filled in
questionnaires. I hope that it is possible to obtain via VIRUS-L.
The questionnaire is rather long ( about 25 K ) and detailed one. It
has eight question groups :
1.Electronic data processing and electronic data interchange,
2.Information systems,
3.Hardware,
4.Operating systems and software,
5.Software reliability,security and security management,
6.Computer viruses,
7.Antivirus protection,
8.Standardization.
I hope you will help me. Every answer, further suggestion, comment or
advice regarding questionnaire as well as suggestions to my thesis
topics will be appreciated.
Thank you in advance.
Best regards,
Suzana Stojakovic-Celustka
[Moderator's note: Anyone wishing to take part in Suzana's project may
get the questionnaire by anonymous FTP from cert.org in
pub/virus-l/docs/celustka.questionnaire. I would appreciate it if an
e-mail based archive site would pick up this file and make it
available by e-mail, and then announce it here.]
- -------------------------------------------------------------------------
Address: Suzana Stojakovic-Celustka e-mail address:
Department of Computers
[email protected]
Faculty of Electrical Engineering
Karlovo namesti 13
12135 Prague 2
Czechoslovakia fax : (+42 2) 290159
------------------------------
End of VIRUS-L Digest [Volume 5 Issue 128]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
