home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Supreme Volume 6 #1
/
swsii.zip
/
swsii
/
201
/
VL6-005.ZIP
/
VL6-005.TXT
Wrap
Text File
|
1993-01-08
|
43KB
|
1,033 lines
From virus-l@lehigh.edu Thu Jan 7 06:52:32 1993
Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/2.0)
id AA10431; Thu, 7 Jan 1993 17:56:32 +0100
Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA20246
(5.67a/IDA-1.5 for <vhcguest@abacus.hgs.se>); Thu, 7 Jan 1993 11:52:32 -0500
Date: Thu, 7 Jan 1993 11:52:32 -0500
Message-Id: <9301071651.AA16031@barnabas.cert.org>
Comment: Virus Discussion List
Originator: virus-l@lehigh.edu
Errors-To: krvw@cert.org
Reply-To: <virus-l@lehigh.edu>
Sender: virus-l@lehigh.edu
Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: "Kenneth R. van Wyk" <krvw@cert.org>
To: Multiple recipients of list <virus-l@lehigh.edu>
Subject: VIRUS-L Digest V6 #5
VIRUS-L Digest Thursday, 7 Jan 1993 Volume 6 : Issue 5
Today's Topics:
Re: Untouchable (PC)
Re: Untouchable (PC)
noint - what is it? (PC)
Re: Untouchable (PC)
Re: Invalid Boot Sectors (PC)
Known virus that tweaks PC date function? (PC)
Re: Clash between FDISK/MBR and scanners (PC)
Re: Invalid Boot Sectors (PC)
Joshi Question (PC)
PKZIP V2.04C (PC)
False positive in the new PKZIP (PC)
Info on Music Bug virus (PC)
New Virus (PC)
Re: Vshield vs Virstop (PC)
Re: Jerusalem (Israeli) Virus (PC)
Clearing out old signatures (PC)
DOS Serial Numbers (PC)
Viral Code Access
Re: The Internet Worm (CVP)
Re: Good use of (possible bad) viruses
Export restrictions of anti-virus software?
How to measure polymorphism?
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 VIRUS-L@LEHIGH.EDU.
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:
<krvw@CERT.ORG>.
Ken van Wyk
----------------------------------------------------------------------
Date: 28 Dec 92 23:48:00 +0000
From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
Subject: Re: Untouchable (PC)
Quoting from Vesselin Bontchev to All About Re: Untouchable (PC) on
12-07-92
VB> One important thing to have in mind is that the product is very good,
VB> but not as good as the advertisements are trying to suggest you. Some
VB> advertisements (in France) say that it is "the absolute weapon agains
VB> computer viruses" and that no virus, even an unknown one, is able to
I agree 100%.
Untouchable is capable, but I wouldn't do much farther. I have Untouchable
1.13.
UTScan
Detection is fair
removal leaves a lot to be desired.
I would place F-Prot, VIRx, and Scan in front of it.
UTRes
Detection is fair.
UTPeriodic
This is one of the best integrity checkers that I have seen. I would put
it in the same league with Victor Charlie's Bit Checking, or Integrity
Master.
The advertising for Untouchable is doing them a dis-service.
Untouchable is good, but not THAT good.
Bill
- ---
* WinQwk 2.0 a#383 * Hacked version of Math Master MATHMSTR.*
------------------------------
Date: 29 Dec 92 00:05:00 +0000
From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
Subject: Re: Untouchable (PC)
Quoting from Y. Radai to All About Re: Untouchable (PC) on 12-08-92
YR> UTSCAN has the ability to examine archives and compressed executa-
YR> bles (recursively), includes one of the better MtE detectors (its
Untouchable does well at scanning archives, abd files compressed with
PKlite, LZEXE, Diet, and maybe others.
However; I performed some tests with PKlite 1.15 recently. McAfee's Scan
was able to detect the virus inside the file compressed with PKlite 1.15.
Untouchable wasn't able to scan inside the file.
I hope that UTScan can be updated to work with compressed files created
with PKlite 1.15 and above.
Bill
- ---
* WinQwk 2.0 a#383 * SURIV 3.0 activates Friday the 13th
------------------------------
Date: 29 Dec 92 07:40:00 +0000
From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
Subject: noint - what is it? (PC)
Quoting from Gang Wu to All About noint - what is it? (PC) on 12-23-92
GW> anyone has any idea what noint virus is? we discovered several of the
GW> here in barnard college and it seemed that the virus can physically
GW> destroy the floppy disk (all the disks we found infected by this viru
GW> has numerous bad sectors after the infection.)
No-Int is a stealth boot sector virus. Sometimes called Stoned 3.
This is the virus that was accidentaly distributed by Novel about a year
ago.
Bill
- ---
* WinQwk 2.0 a#383 * MICHELANGELO activates Mar 6th
------------------------------
Date: 29 Dec 92 01:37:00 +0000
From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
Subject: Re: Untouchable (PC)
Quoting from Y. Radai to All About Re: Untouchable (PC) on 12-12-92
YR> I was referring to Ver. 26 of UTScan.
I am using version 25.10 of UTScan.
When was 26 released?
Bill
- ---
* WinQwk 2.0 a#383 * CASINO activates Jan 15th
------------------------------
Date: Tue, 05 Jan 93 17:58:25 -0500
From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Subject: Re: Invalid Boot Sectors (PC)
>From: "Roger Riordan" <riordan@tmxmelb.mhs.oz.au>
>I recently wrote
>>In a recent comment on a query by MOPURC01@ULKYVM.LOUISVILLE.EDU
>>(Michael Purcell) about a virus which allegedly made disks
>>unreadable I wrote.
>>> If you put the wrong byte in the wrong place you can get the
>>> symptoms described. ...
>It appears the original message got lost, but the gist was that,
>IN THEORY, it is possible to write a BS virus which is invisible
>on an infected PC, but impossible to detect on an uninfected PC
>with any existing scanner because DOS will crash if any attempt is
>made to access an infected disk.
This is something that experimentation has been done on. What I have
found is that:
a) If the Partition table is missing certain DOS signature bytes, DOS
will refuse to recognise the disk (but a floppy boot will still work).
b) If certain bytes in an otherwise good P-Table have certain wrong values
a floppy boot may hang (which bytes and what values are DOS version
dependant).
c) Even given (a) or (b), BIOS software can restore bootability (I have
a version of FIXMBR that loads and runs from the BIOS just like
the early Microsoft Flight Simulator).
d) *Every* MBR infection that I have seen is detectable if you
look in the right places. "Stealth" can always be bypassed with a
direct BIOS call.
In other words, every infection I have seen is recoverable with the
right tools (usually DEBUG, FDISK, & SYS). Sometimes it is not worth
the bother since repair via E-Mail is somewhat more difficult, but
whatever is not corrupted can be retrieved and that which has been
corrupted can usually be restored. In general I have found that the
stupider the program, the more likely it will work.
I am glad that the above said "IN THEORY" since an undetectable,
invisible virus that can make a system completely unbootable except
from the hard disk just cannot exist. (Note, I am not including
access control programs that encrypt the whole disk and rely on
input of the key by the user for decryption - this could be made
"strong enough" - but a self-contained program cannot. Period.
82 today - what Floridians put up with summer for,
Padgett
------------------------------
Date: Tue, 05 Jan 93 22:57:57 +0000
From: vpcsc11@sfsuvax1.sfsu.edu (student)
Subject: Known virus that tweaks PC date function? (PC)
In the office where I work, we recently purchased a 286 clone.. Over
the past few weeks, the computer's internal clock has been losing
days. The first time, it stuck on Thanksgiving. A week later, it
hung on December 7th (Pearl Harbor Day). A few weeks later, it stuck
on Christmas Eve.
Has anyone heard of a virus that would produce these symptoms? If
not, does anyone have any other ideas about how to fix the problem?
Please respond via e-mail to: vpcsc11@sfsuvax1.sfsu.edu
Thanks!
------------------------------
Date: 06 Jan 93 09:05:10 +0000
From: tck@bend.ucsd.edu (Kevin Marcus)
Subject: Re: Clash between FDISK/MBR and scanners (PC)
riordan@tmxmelb.mhs.oz.au (Roger Riordan) writes:
>The command FDISK /MBR is often recommended for removing MBR
>infectors (Stoned, etc) from hard disks. However in some
>circumstances this can cause problems with some scanners. It
>appears that some versions of FDISK/MBR rewrite the Master Boot
>Record only as far as the end of the error messages, leaving the all
>important partition information unchanged, but also leaving any
>viral code between the messages and the partition information.
I recently installed Linux, a version of unix for the PC, in addition
to my regular dos partition. This comes with a small program called
"wini" which is a program, which occupies the MBR to allow me to
choose which OS I would like to boot into. It's my understanding
OS/half does somethign like this, also, or can do something like this.
If FDISK/MBR REWRITES the MBR with the basic, boring code that
normally is there with DOS, then if I use this method, I will destroy
the wini program, and restrict myself from booting into my Linux
partition. This is another drawback to fdisk/mbr.
- --
|| Kevin Marcus, Computer Virologist. (619)/457-1836; RE-xxx, TSCAN ||
|| INET: tck@bend.ucsd.edu []-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]
|| tck@fold.ucsd.edu || All I wanted was a Pepsi... ||
|| datadec@watserv.ucr.edu || And she wouldn't give it to me...||
------------------------------
Date: 06 Jan 93 09:06:21 +0000
From: frisk@complex.is (Fridrik Skulason)
Subject: Re: Invalid Boot Sectors (PC)
riordan@tmxmelb.mhs.oz.au (Roger Riordan) writes:
>It appears the original message got lost, but the gist was that,
>IN THEORY, it is possible to write a BS virus which is invisible
>on an infected PC, but impossible to detect on an uninfected PC
>with any existing scanner because DOS will crash if any attempt is
>made to access an infected disk.
well, only if the scanner uses int 21H/25H/26H to access the disk. If it uses
int 13H to access the disk the disk can be read no matter what data is in the
boot sector.
- -frisk
- --
- --
Fridrik Skulason Frisk Software International phone: +354-1-694749
Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801
------------------------------
Date: 06 Jan 93 16:38:22 +0000
From: rind@enterprise.bih (David Rind)
Subject: Joshi Question (PC)
I have a question about the Joshi virus (yes, yesterday was January 5th).
Does Joshi trap attempts at warm reboots? There was an intermittent
problem with a new program on a computer that turned out
to be infected with Joshi. The problem was sporadic enough that I
can't be certain that getting rid of Joshi eliminated it, but if
Joshi was trapping Alt-Ctrl-Del, then that would explain the "bug".
I checked the info in F-Prot, and it wasn't that specific, and I'm
not sure where else to check (my impression from reading this group
is that there aren't many reliable sources for descriptions of
specific viruses). Thanks.
- --
David Rind
rind@binoc.bih.harvard.edu
------------------------------
Date: Thu, 07 Jan 93 11:44:21 +0000
From: pd@nwavbbs.demon.co.uk (Peter Duffield)
Subject: PKZIP V2.04C (PC)
I picked the following post up in comp.archives.msdos.announce and thought
it may be of interest to this group...
- --------------------------------- cut here -----------------------------
From: PKWare.Inc@mixcom.mixcom.com (PKWare.Inc)
Subject: PKZIP 2.04c RELEASED (NO VIRUS)
Reply-To: PKWare.Inc@mixcom.com
Date: Thu, 7 Jan 1993 09:38:18 GMT
PKZIP 2.04c is now released and on the PKWARE BBS (414-354-8670)
Some reports have come in the certain version of Norton Anti-Virus
are reporting PKZIP 2.04 to have the Maltese Amoeba virus.
THESE REPORTS ARE FALSE! If the version of Norton is upgraded to
a newer version the false reports cease.
The correct files size,date and time should be:
PKZ204C.EXE 188818 12-28-92 2:04
SIZE DATE TIME
If you have any further questions, please feel free to contact
me here at pkware.inc@mixcom.com
Mark Gresbach
PKWARE, Inc.
- --
PKWARE.Inc@mixcom.com Voice (414)354-8699 Authors of PKZIP, PKLITE
9025 N. Deerwood Dr. BBS (414)354-8670 PKZFIND, PKZOOM, and the
Brown Deer, WI 53223 USA FAX (414)354-8559 Data Compression Library
- --------------------------------- cut here -----------------------------
Peter
- --
Peter Duffield pd@nwavbbs.demon.co.uk (Internet)
Voice: +44 244 545669 BBS: +44 244 550332 8,N,1
North Wales Anti-Virus Support BBS, FidoNet: 2:250/201, VirNet: 9:441/110
=== PGP 2.0 == public key available on request == Key ID 991AB1 ===
------------------------------
Date: 06 Jan 93 21:03:27 +0000
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: False positive in the new PKZIP (PC)
Hello, everybody!
As most MS-DOS users probably know, the very popular archiver PKZIP
from PKWare Inc. has not been updated from version 1.10 since about
two years. The new version was in "about to be released final
beta-test" during more than a year. This, of course, caused a lot of
bogus, hacked, or trojanized versions to be released by malicious
people to fool the legitimate users. The number of hacks is probably
above 10.
A few days ago, PKWare finally decided to release a new version of
their archiver, called 2.04c. Regardless of the long developpment
period, the program turned out to contain a few minor bugs and even
errors in the documentation. But this is not so interesting from the
computer virus point of view... :-)
What is interesting is that somebody used an out-of-date version of
Symantec's Norton Anti-Virus to scan the new archiver. It seems that
this version causes a false positive - the program is flagged as
infected by Maltese Amoeba. The confusion is increased by the fact
that all executables in the package are self-compressed with PKLite
1.20. This caused the heuristic scanner of F-Prot to report that those
files are suspicious, because they contain a program that modifies
itself in memory (of course - the decompressor unpacks the compressed
code) - something often used by viruses.
As a result, a major hoax was started; the archiver was several times
uploaded and deleted at wuarchive.wustl.edu; and the number of
messages about that in comp.compression is reaching the record caused
by the famous posting that informed about the claims of a company to
produce an archiver which is able to achive compression rate of 16:1
for any file... :-)
I obtained a copy of the new version of PKZIP, examined it manually
with a debugger, and scanned it with about a dozen scanners. The
result is that NONE OF THE EXECUTABLE FILES IS INFECTED. Even a recent
version of NAV (2.1 with signature updates of December) does not
report the false positive any more. PKWare has confirmed that this is
a "real" version.
So, please done's pay attention to the rumors, if they reach you. The
VALIDATE codes of the self-unpacking archive containing the new
version of PKZIP is:
File Name: PKZ204C.EXE
Size: 188,818
Date: 1-5-1993
File Authentication:
Check Method 1 - 0DC8
Check Method 2 - 045E
The actual Date: field may be different; it was destroyed while I was
downloading the file.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany
------------------------------
Date: Wed, 06 Jan 93 17:04:01 -0500
From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Subject: Info on Music Bug virus (PC)
>From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin)
>The Music Bug virus isn't generally destructive, but the FAT table
>structure on hard drives gives some weird effects occasionally.
Not quite. The MUSIC-BUG is not *intentionally* destructive however
mistakes do cause damage since this virus makes assumptions about disk
structure that works only on some floppies and on no hard disks.
The virus tries to create a "haven" for its code by searching for
unused sectors and allocating them (six or seven as I recall).
Unfortunately, while the chosen clusters are "safe", in computing the
register values for a cluster/sector translation the M-B makes
mistakes that cause the virus to write to a different set of sectors
which may be in use.
The virus also makes a single byte change to the Boot Parameter Block
which renders removal via SYS C: unusable since the disk becomes
unbootable. For some time this led to the opinion that recovery was
impossible but most vendors now use a equally simple recovery method
that works (think it took less than 30 bytes).
The most common vector was via a graphics driver disk furnished with
certain computer systems and though the manufacturer was notified, I
have never seen any indication that the disks were withdrawn/replaced.
Unseasonably warm & humid,
Padgett
------------------------------
Date: Wed, 06 Jan 93 23:52:02 +0000
From: s3176997@techst02.technion.ac.il (Daphne Rosenhouse)
Subject: New Virus (PC)
hi all
Id like to report a new virus/mutation i found
It looks like a variant of te WHALE, but larger, and harder to remove
im researching it and will soon post the results and send a sample to all
anti-viral softs programmers...
i just wanted to inform all users on comp.virus and VIRNET.
p.s. do VIRNET users get messages from here too ?
bye
------------------------------
Date: Thu, 07 Jan 93 01:22:10 +0000
From: aryeh@mcafee.com (McAfee Associates)
Subject: Re: Vshield vs Virstop (PC)
Hello Bill Lambdin,
You write:
[regarding VSHIELD's ability to check validation (CRC) data created by SCAN]
>2. These CRCs will not detect stealth infectors because stealth viruses
> disinfects infected files when an infected file is opened for any
> reason.
VSHIELD (or SCAN) will detect the change in a CRC made by a stealth
virus provided the stealth virus is not resident in memory to
interfere with checking.
Regards,
Aryeh Goretsky
Technical Support
- --
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
McAfee Associates, Inc. | Voice (408) 988-3832 | INTERNET: aryeh@mcafee.COM
3350 Scott Blvd, Bldg 14 | FAX (408) 970-9727 | IP# 192.187.128.1
Santa Clara, California | BBS (408) 988-4004 | CompuServe ID: 76702,1714
------------------------------
Date: Thu, 07 Jan 93 01:26:20 +0000
From: aryeh@mcafee.com (McAfee Associates)
Subject: Re: Jerusalem (Israeli) Virus (PC)
Hello Bill Lambdin,
You write:
>Quoting from Samid Hoda to All About Jerusalem (Israeli) Virus on 12-20-92
[asking about how to remove the Jersualem virus]
>McAfee's Clean can remove this virus fairly easy to remove. It would be a
>very good idea to re-boot the computer from a known clean bootable
>diskette. If you don't have a clean bootable diskette, go ahead and type
>the following on the command line.
>
>CLEAN C: [JERU]
>
[...deleted...]
Since the Jerusalem virus also infects overlay files. I would recommend
the use of the the /A and /NOPAUSE switches, which tell CLEAN-UP to check
all files on the disk for the virus and remove it if found regardless of
their extension, and not to pause when it has filled up the screen with
messages, respectively.
Regards,
Aryeh Goretsky
Technical Support
- --
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
McAfee Associates, Inc. | Voice (408) 988-3832 | INTERNET: aryeh@mcafee.COM
3350 Scott Blvd, Bldg 14 | FAX (408) 970-9727 | IP# 192.187.128.1
Santa Clara, California | BBS (408) 988-4004 | CompuServe ID: 76702,1714
------------------------------
Date: Wed, 06 Jan 93 20:34:25 -0500
From: "Roger Riordan" <riordan@tmxmelb.mhs.oz.au>
Subject: Clearing out old signatures (PC)
padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) wrote recently
> Enclosed is a DEBUG script that will create a 68 byte .COM file
> (CLEAR.COM) that will zero out memory between the current load
> position and the TOM. To use, ...
The only trouble with this is there is a surprising amount of
software which leaves active code in memory, but does not bother to
tell DOS.
To guard against possible unknown viruses like to Chinese Fish,
which install themselves in high memory, but do not set the top of
memory down, we recently added a feature to VET to fill unused
memory with a diagnostic procedure which gives a warning message,
and locks the PC, if anything attempts to execute unused memory. So
if you run VET, and an unknown virus of this type is already in
memory, you get the warning as soon as VET calls an interrupt the
virus has trapped.
Ahh! Another loophole closed! Unfortunately a big customer
immediately complained some users could no longer log in.
We investigated, & found that they were using Microsoft Lan Manager.
When PROTMAN was run from CONFIG.SYS a block of code was installed
at 7000:7800, but top of memory (as recorded at offset 2 in the PSP)
remained 9FFF:0000. If this code was overwritten by running VET (or
anything else) before the user logged in, the system would crash
when the program NBP.EXE was run as part of the log in procedure.
We sent details of this to MicroSoft Support, but, naturally, never
received any reply.
We added an option to VET to disable this feature. A significant no.
of users have encountered similar problems. Most have been using
Lan Manager, but other programs may also have been involved.
Roger Riordan riordan.cybec@tmxmelb.mhs.oz.au
CYBEC Pty Ltd. Tel: +613 521 0655
PO Box 205, Hampton Vic 3188 AUSTRALIA Fax: +613 521 0727
------------------------------
Date: Wed, 06 Jan 93 23:44:33 -0500
From: Jack Davis <jack@csn.org>
Subject: DOS Serial Numbers (PC)
Regarding the question of changing the SERIAL NUMBER of a DOS disk.
An undocumented DOS function 69h which will GET or SET the serial
number of a disk is discussed in PC Magazine, July 1992, V11N13, Page
496. A PASCAL program listing is included with the article and the
program itself is avaiable from PC Magazine.
Regards,
Jack Davis
jack@csn.org
------------------------------
Date: 06 Jan 93 08:44:34 +0000
From: ygoland@edison.SEAS.UCLA.EDU (The Jester)
Subject: Viral Code Access
I REALLY don't mean to start this debate again but my personal
experience have left me with little choice:
The Situation:I am trying to get ahold of a certain virus because it
implements certain features which are of central importance to a paper
I'm writing. (Note:I am trying VERY hard to leave out all details
because I want this to be a discussion of topic and not a hidden
request, something the moderator has made clear he will not stand for
and a request I intend to respect.) The problem is that for all
intents and purposes I am a 'nobody'. I am a Junior at U.C.L.A.'s
school of engineering and getting my degree in computer science and
engineering. In addition just about everybody has a dead on
prohibition against giving anyone their viral code, even though they
got it from someone. So I have been totaly unable to get a copy of
this virus.
Solution:One researcher who shall rename nameless suggested that I
call a virus exchange board in order to get a copy of the virus. In
other words that I go skulk around with the miscreants who keep many
of you employed so I can get the material I need for my paper. However
its not just a matter of dealing with the lowest of the low. Many
viral exchange bbses require you to upload a new virus in order to
access their collection. Should I go out and write some hyper deadly
virus so I can get into their collection in order to look at the
virus that every researcher and his brother already has but is to
scared to give out? Maybe I should just write a moderatly deadly
virus? A dude? What?
Is this how the anti-viral community wants to run itself? Is this
'open and free exchange of information'?
[Moderator's note: This is obviously a touchy subject. I stand by my
policy of keeping requests for live viruses off of the group. At the
same time, I certainly recognize the need to get virus samples to the
appropriate people for analysis purposes. I welcome thoughts and
discussions on this issue.]
Yaron (The Jester) Goland
- --
"Only the blind see in color."
"Any union based upon pigment is foolish ignorance designed to
give power to those few who enjoy power's taste above the common
welfare."
------------------------------
Date: Wed, 06 Jan 93 10:44:43 -0500
From: Olivier "M.J." Crepin-Leblond <o.crepin-leblond@ic.ac.uk>
Subject: Re: The Internet Worm (CVP)
>From rslade@sfu.ca Fri Dec 25 08:15:00 1992
>Date: Fri, 25 Dec 92 00:15:35 -0800
>From: rslade@sfu.ca
>Subject: The Internet Worm (CVP)
>
>HISVIRO.CVP 921215
>
> The Internet Worm
>
>By the fall of 1988, VIRUS-L had been established (let's hear it for
>Ken!) and was very active. Issues were, in fact, coming out on a
>daily basis, so I was quite surprised when I didn't receive one on
>November 3rd. I didn't get one on November 4th, either. It wasn't
>until November 5th, actually, that I found out why.
This is incorrect. The first digest of VIRUS-L appeared on 9th Nov 88.
I suspect that this was triggered by the FLOOD of undigested messages
that had to be sent all around the place during the week 1 Nov to 8th
Nov 88. (am I right, Ken ?)
[Moderator's note: For the e-record, VIRUS-L Volume 1 Issue 1 was
posted Wednesday, 9 Nov 1988, just a few days after the Internet worm
incident. The primary input behind going digest+moderation at that
time was a storm of ASCII "pictures" that were posted to the group.
That, plus the added discussions due to the worm prompted several
people (including myself) to want the list to go to digest format. In
any event, VIRUS-L was distributed unmoderated and undigested from
Fri, 22 Apr 88 07:48:39 EDT (when I sent the first announcement to the
newly formed group) until 9 November. The distribution was from
LEHIIBM1.BITNET aka IBM1.CC.Lehigh.Edu - the same IBM 4381 mainframe
that served the group until July 1992, when we switched over - not
without pain - to an RS6000 running AIX and IDA's sendmail.]
VIRUS-L was a BITNET listserv list (LEHIIBM1.BITNET) and was just an
email exploder, forwarding messages on BITNET and traffic went-on
throughout the internet worm. I recall receiving messages here in UK
via EARN-RELAY (known as UKACRL.BITNET). It was interesting to read
messages as they came in. I remember spending most of the 4th of
November 1988 on my terminal, reading message after message. (or was
it 5th ?)
Receiving so many messages per day was quite exciting, since I had
only started to subscribe to VIRUS-L a week earlier. An amazing
coincidence. Judging from the nonsense that was often written, the
amount of confusion amongst those affected by the worm was at a peak.
Rumours spread so quickly.
- --
Olivier M.J. Crepin-Leblond, Digital Comms. Section, Elec. Eng. Department
Imperial College of Science, Technology and Medicine, London SW7 2BT, UK
Internet/Bitnet: <foobar@ic.ac.uk> - Janet: <foobar@uk.ac.ic>
------------------------------
Date: Wed, 06 Jan 93 16:50:11 +0000
From: grweiss@phoenix.princeton.edu (Gregory Robert Weiss)
Subject: Re: Good use of (possible bad) viruses
celustka@sun.felk.cvut.cs (Celustkova-k336-doktorand(Richta)) writes:
>Hi boys and girls, (a day of inspiration,huh ?)
>
>Just one of those days...Two examples of good use of (possible bad)
>viruses come to my mind :
>
>1. Viruses written to improve an A-V product
>
>The logic is simple. It is better that I write virus which can do this
>or that and have prepared solution to implement in my A-V product than
>wait that such virus arises in wild and then react. That means if I
>know that today exist viruses which could be stealthy, tunneling or
>polymorfic why shouldn't I write virus which is all that and design my
>A-V product to recognize such virus before it really appears in wild.
>(Well, maybe it is not commercial, I don't know).
Developing solutions for anticipated problems is quite reasonable; however,
the following statement isn't:
>If such virus *by
>accident* escape from my lab I already have a response and there is no
>ethical problem at all.
No problems if it "accidently escapes"...
- unless of course you developed the virus and it "escaped by accident"
before you had your A-V program properly detecting it.
- unless you think about the fact that most people will not use *your* A-V
program, they'll use someone else's, or maybe even no protection at all.
- unless you consider that and you will create a lot of work for
other A-V writers, and damage to others in the meantime.
These problems are both technical and ethical problems that you must
confront before doing this kind of work, IMHO.
>2. Viruses built in an A-V product (it's just an idea, don't blame me if it
>is not applicable in reality)
>
>Suppose that we have an A-V product which in regular intervals or
>randomly send a virus in system. Virus (fast infector) infects only
>programs which checksum doesn't correspond to previously calculated
>values. If no such program is found virus deletes itself or removes
>from memory. If changed program found virus activates scanner to check
>if there is any known virus. If known virus is found message is sent
>to the user. If program is changed and no known virus is found the
>message is sent to the user to make decision.
This sounds fine and good for a strictly contained system owned by an
A-V writer (note the dangers mentioned in my previous comment above),
but will be *absolutely, fundamentally worthless* in an A-V product
as you describe, because you are describing a system in which the
virus is discovered (and hopefully removed) only *after* files have been
damaged. The point of having A-V products is to prevent the damage in
the first place.
So now my financial records which I hadn't backed up for a
month or two (or more...) are damaged: my A-V virus says the checksum has
changed. Well, I'm glad that I caught that virus, even though it destroyed
the data file I was trying to protect! :-)
The reason why many A-V products are TSRs is to catch viruses *as* they
enter the system, not *after* they enter the system. Your A-V virus
seems to fall short in this regard.
> If decision is to leave
>program as is, virus cuts itself from the program. The whole process
>(except messages) takes place in background. There is no need for all
>A-V program (which is combination of I-checker and scanner) to be TSR,
>only virus is occasionally TSR. There is slight similarity in this
>idea with reaction of human immunity system. Anyone has ethical
>problem with her/his own immunity system ?
I understand your comparison is tongue-in-cheek, but you really are comparing
apples and oranges here. In the immune system, a few cells can die, but
your body can still function properly. Computer data files and programs
are much less forgiving of a few errors.
>Cheeeers,
>
>Suzana
Happy New Year everyone!
--Greg
grweiss@phoenix.princeton.edu
------------------------------
Date: 06 Jan 93 20:57:29 +0000
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Export restrictions of anti-virus software?
The following was provided by Robert Heuman from Canada in one of the
newsgroups (sci.crypt, I think). It seems to imply that some kinds of
anti-virus programs are restricted from export in Canada. I would be
very interested whether similar export restrictions exist for the USA.
Please note that I am interested -only- in export restrictions of
anti-virus software, not in export restrictions of cryptographic
software. Could somebody in the USA who has access to the full text of
ITAR verify that? Please, if you find something, post the exact
reference and quote, if possible. Thanks.
Regards,
Vesselin
Date Entered: 12-22-92 10:34
I was asked to supply information re export control over anti-virus
software, since I stated it was restricted in some cases.
The exact information follows:
Source: A Guide to Canada's Export Controls, January 1, 1992
Page 25, item 1150.Information Security
NOTE: The embargo status of "information security" equipment,
"software", systems, application specific "assemblies", modules,
integrated circuits, components or functions is defined in this
Category even if they are components or "assemblies" or other
equipment.
Page 25, item 1154. Software
1154.a.c.3. "Software" designed or modified to protect against
malicious computer damage, e.g., viruses.
Page 1, General "Software: Note
This List does not embargo "software" which is either:
1. Generally available to the public by being:
a. sold from stock at retail selling points, without restriction,
by means of:
1. Over the counter transactions
2. Mail order transactions
3. Telephone call transactions _AND_
b. Designed for installation by the user without further
substantial support by the supplier, _OR_
2. "In the public domain".
A check with Ottawa resulted in the statement that F-PROT was export
restricted (controlled) as shareware did not meet the criteria of this
general "software" note... Therefore SCAN by McAfee also would not
meet the requirements.
I believe a similar restriction will be found in the US regs, as
Canada's are based in good measure on the US regs, and this specific
restriction was added at the request of the US gov't.
Bob
- ---
RoseReader 1.70 P001886: Twice as human as anyone else my opinions are my ow
n
RM 2.00 : RoseNet<=>Usenet Gateway : Rose Media 416-733-2285
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany
------------------------------
Date: 06 Jan 93 21:21:12 +0000
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: How to measure polymorphism?
Hello, everybody!
There are already two polymorphic engines available (MtE and TPE) and
we are going to see more and more polymorphic viruses in the future.
An interesting question arises - how to determine how polymorphic a
virus is? How to determine which of two viruses is "more polymorphic"?
In other words - how to measure polymorphism in an objective way?
There are several ways one could think about:
1) Determining the total number of different instance that a
particular virus can take. Obviously, a virus that can take 6
different appearances (V-Sign) is less polymorphic than a virus that
can take 65,536 (Cascade).
Unfortunately, this does not work. First, for some viruses it is
almost impossible (well, at least too difficult) to count the total
number of appearances. Nobody has succeeded yet to determine the exact
number of different decryptors that MtE can generate.
Second, a variably encrypted virus with the following decryptor
mov si,code_end
mov cx,code_length
mov ax,key
decode:
xor word ptr [si],ax
jmp short skip
garbage db ?
skip:
dec si
dec si
loop decode
where the byte 'garbage' can take any value is not very polymorphic,
regardless that the number of possible decryptors is 256. If we change
garbage db ?
to
garbage dw ?
this will mean that the number of possible decryptors is 65,536, but
the virus is not more polymorphic...
2) The second idea is to divide the polymorphisms is classes. Class 0
means no polymorphism, class 1 means variable encryption with constant
decryptor, class 2 means variable encryption with a decryptor that can
be detected by a wildcard scan string, class 3 is a virus that cannot
be detected even with a wildcard string. E.g., Vienna (class 0) is
less polymorphic than Cascade (class 1), which is less polymorphic
than Suomi (class 2), which is less polymorphic than V2P2 (class 3).
Unfortunately, this is not good enough. First, what to do with viruses
that use a limited set of decryptors, one of which is selected
randomly (Whale). Such viruses are obviously more polymorphic than
Cascade. But are they more or less polymorphic than Suomi? They can be
detected by a set of non-wildcard strings...
Second, what about Bad Boy? It consists of 9 segments of code, 8 of
which can appear in any order. This gives 8! = 40,320 variants. But
the virus is even not encrypted, so it can be detected with a simple
(non-wildcard) scan string...
Third, what is a "wildcard string"? A string allowing "don't care"
bytes? A string allowing "don't know how many don't care bytes"? A
string allowing "don't care" bits? For instance, Maltese Amoeba cannot
be detected by the user-defined scan strings of SCAN or F-Prot, but
can be with the wildcard scan strings of HTScan/TbScan... So, is
Maltese Amoeba class 2 or class 3 polymorph?
Fourth, what about V2P2 and V2P6Z? None of them can be detected by a
scan string (even a wildcard one), but most experts agree that V2P6Z
is "more polymorphic" than V2P2 - because the decryptor can be of
different length, the virus too, and many other things...
3) The third idea was proposed by Dr. Solomon. He proposes to use the
length of the longest byte sequence that is present in the decryptor.
As an addition, one could use the sum of the length of all constant
byte sequences in the decryptor - if there are several short ones that
can appear in any order (like it is in V2P2).
This is already better, but still not good enough. According to this
criterium, the MtE-based viruses have polymorphism 1 - because all
decryptors contain only a single constant byte (the JNZ instruction),
which does not appear at a constant place. (Obviously, by this
criterium, the higher the number, the less polymorphic the virus is.)
Unfortunately, as I said, this is still not good enough. There are
other viruses with only a single constant byte in the decryptor, which
are much less polymorphic than the MtE-based ones. On the other side,
the TPE-based viruses can have 0 constant bytes in the decryptor, but
this does not imply that they are more polymorphic than the MtE-based
ones... In fact, if one looks at them very carefully, it is possible
to see that the different decryptors are pretty similar, if you remove
the garbage ("do-nothing") instructions...
It seems that what each anti-virus researcher considers as "level of
polymorphism" is dependent somehow on the technique he uses in his
anti-virus product to detect polymorphic viruses. For instance, V2P6Z
might look "more difficult" (i.e., more polymorphic) than the
MtE-based viruses to those people whose scanners depend on the number
of addressing modes used by the instruction that performs the actual
decoding...
This article is not meant to provide a solution of the problem. I am
trying just to explain the problem and am asking for solutions. Any
ideas are welcome - we really need an objective way to measure the
level of polymorphism...
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany
------------------------------
End of VIRUS-L Digest [Volume 6 Issue 5]
****************************************