From lehigh.edu!virus-l Tue Apr 13 05:29:20 1993 remote from vhc

From lehigh.edu!virus-l Tue Apr 13 05:29:20 1993 remote from vhc
Received: by vhc.se (1.65/waf)
via UUCP; Tue, 13 Apr 93 18:01:31 GMT
for mikael
Received: from fidoii.CC.Lehigh.EDU by mail.swip.net (5.65c8-/1.2)
id AA10226; Tue, 13 Apr 1993 16:01:17 +0200
Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA19983
(5.67a/IDA-1.5 for <[email protected]>); Tue, 13 Apr 1993 09:29:20 -0400
Date: Tue, 13 Apr 1993 09:29:20 -0400
Message-Id: <[email protected]>
Comment: Virus Discussion List
Originator: [email protected]
Errors-To: [email protected]
Reply-To: <[email protected]>
Sender: [email protected]
Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: "Kenneth R. van Wyk" <[email protected]>
To: Multiple recipients of list <[email protected]>
Subject: VIRUS-L Digest V6 #60

VIRUS-L Digest Tuesday, 13 Apr 1993 Volume 6 : Issue 60

Today's Topics:

New Mac Virus Announcement - INIT-17 (Mac)
Virus vectors of infection
Scanners getting bigger and slower
Re: Scanners getting bigger and slower
Re: IDES'93 [Dick Lefkon]
Vshield V102 Bug? (PC)
Scanners and exe/com file compressors? (PC)
VI-SPY VS Central Point AntiVirus (PC)
DOS v6.0 and Virus Functionality (PC)
Re: Optimum Strategy for Virus Checking (PC)
Re: Port Writes (PC)
Re: Scanners and exe/com file compressors? (PC)
Re: Scanners and exe/com files (PC)
Re: Catch from DIR? (PC)
Re: Virus signature determination. (PC)
Re: VI-SPY VS Central Point AntiVirus (PC)
Re: WIndows Virus (PC)
Re: Which CRC/scanner to use. (PC)
New signature for TBAV (PC)
Re: April Viruses? (PC)
Re: Unknown little virus? (PC)
Re: Uruguay on PS/2 ref disk (PC)
Numbers and weighting (CVP)

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.org 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, [email protected]

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

Date: Mon, 12 Apr 93 12:42:05 -0500
From: [email protected]
Subject: New Mac Virus Announcement - INIT-17 (Mac)

New Macintosh Virus Discovered
12 Apr 1993

Virus: INIT-17
Damage: Alters System and applications files; may crash some
Macs. See text below.
Spread: unknown
Systems affected: All Apple Macintosh computers, under both System 6 &
System 7

The INIT-17 virus was recently discovered and analyzed. It spreads to
the System file and many applications as they are run, and is likely
to spread quite quickly on an infected machine. The infection is
accomplished by altering existing program code, but the virus code
that does this contains several bugs of various types. These bugs,
coupled with the behavior of altering applications and the System
file, may result in damage to those files. On some older Macs (e.g.,
Mac Plus, SE, Classic), the presence of the virus will cause those
systems to crash during execution of infected applications.

The only overt action by the virus is to display an alert message in a
window entitled "From the depths of Cyberspace" the first time an
infected machine is rebooted after 6:06:06 pm, 31 Oct 1993.

The authors of all other major Macintosh anti-virus tools are planning
updates to their tools to locate and/or eliminate this virus. Some of
these are listed below. We recommend that you obtain and run a CURRENT
version of AT LEAST ONE of these programs.

Some specific information on updated Mac anti-virus products follows:

Tool: Central Point Anti-Virus
Status: Commercial software
Revision to be released: 2.01d
Where to find: Compuserve, America Online, sumex-aim.stanford.edu,
Central Point BBS, (503) 690-6650
When available: immediately
Comments: The MacSig file will be dated 4/10/93

Tool: Disinfectant
Status: Free software (courtesy of Northwestern University and
John Norstad)
Revision to be released: 3.1
Where to find: usual archive sites and bulletin boards --
ftp.acns.nwu.edu, sumex-aim.stanford.edu,
rascal.ics.utexas.edu, AppleLink, America Online,

CompuServe, Genie, Calvacom, MacNet, Delphi,
comp.binaries.mac
When available: immediately

Tool: Gatekeeper
Status: Free software (courtesy of Chris Johnson)
Revision to be released: No new revision needed; 1.2.7 works
Where to find: usual archive sites and bulletin boards --
microlib.cc.utexas.edu, sumex-aim.stanford.edu,
rascal.ics.utexas.edu, comp.binaries.mac
When available: immediately

Tool: Rival
Status: Commercial software
Revision to be released: INIT17 Vaccine
Where to find it: AppleLink, America Online, Internet, Compuserve.
When available: Immediately.

Tool: SAM (Virus Clinic and Intercept)
Status: Commercial software
Revision to be released: 3.5.5
Where to find: CompuServe, America Online, Applelink, Symantec's
Customer Service @ 800-441-7234
When available: immediately
Comments: Updates to various versions of SAM to detect and remove
INIT-17 are available from the above sources.

Tool: Virex
Status: Commercial software
Revision to be released: 3.92
Where to find: Datawatch Corporation, (919) 490-1277
When available: immediately
Comments: Virex 3.92 will detect the virus in any file, and
repair any file that has not been permanently damaged. All Virex
subscribers will automatically be sent an update on diskette. All
other registered users will receive a notice by mail. Datawatch's
BBS number is: (919) 419-1602.
UDV Code for INIT 17
----Guide Number = 11583776
1: 0310 0011 2006 9230 / 7A
2: FE84 7520 0056 4952 / 4C
3: 7900 3400 11A9 A081 / D5
4: 0210 0001 30FE 8475 / F6
5: 2000 5649 5279 0034 / 89
6: 0011 A9A0 8182 8090 / 91

Tool: VirusDetective
Status: Shareware
Revision to be released: 5.0.8
When available: immediately
Comments: VirusDetective is shareware. Search strings for the new
virus will be sent only to registered users.

If you discover what you believe to be a virus on your Macintosh
system, please report it to the vendor/author of your anti-virus
software package for analysis. Such reports make early, informed
warnings like this one possible for the rest of the Mac community. If
you are otherwise unsure of who to contact, you may send e-mail to
[email protected] as an initial point of contact.

Also, be aware that writing and releasing computer viruses is more
than a rude and damaging act of vandalism -- it is also a violation of
many state and Federal laws in the US, and illegal in several other
countries. If you have information concerning the author of this or
any other computer virus, please contact any of the anti-virus
providers listed above. Several Mac virus authors have been
apprehended thanks to the efforts of the Mac user community, and some
have received criminal convictions for their actions. This is yet one
more way to help protect your computers.

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

Date: Tue, 06 Apr 93 02:29:32 +0000
From: [email protected] (Bruce Ediger)
Subject: Virus vectors of infection

My question is, "how do viruses spread?", and the followup question is,
"are there any pointers to quantification of such spread?" It would seem
that the only information on this is contained in the post-mortem reports
on the 1988 Internet worm and the various DECnet worms.

There are two likely, but unacceptable, answers to the question and its
followup.

1. Thundering silence.

2. An insistence that Fred Cohen's original papers demonstrate that viruses
spread due to information transitivity.

Answer 1 is really a non-answer, making me think that such information
doesn't really exist. This can't be true, given the amount of verbage
generated by things like the threat of Michelangelo on March 6th.

Answer 2 is a lot like asking what causes cholera and getting the answer of
"bacteria", rather than "contaminated water supplies." Of course computer
viruses spread because of information transitivity. Of course cholera is
caused by bacteria. But we try to prevent cholera by promulgating clean
water and sanitation standards. We don't try to catch cholera bacteria as
they individually exit the drinking tap.

It strikes me that there are several actual "vectors of infection".
An incomplete enumeration might be:

A. Networks.

B. Media transfer from infected machine to uninfected machine.
It may be necessary to break this down into two classes: "informal
transfer", such as bringing a diskette full of games to work, and
"formal transfer", when a vendor ships mass-produced media with a
viral passenger.

C. "Virus Exchange" bulletin boards.

D. Source code published in books.

E. Malicious individuals gain access to computers and insert viruses manually.

Clearly, all are subsumed by the generalization "transitivity of information".
Once a list such as that above is made, stopping viruses via "limiting
information transitivity" seems a bit more of a productive approach.

The November, 1988 worm and the DECnet worms used network related methods
to spread. The geography of the spreading is irrelevant because of network
connections, but based on the public reports, it appears fairly easy to
determine that the worms spread via network protocols. The also seem to be
of short duration and low number of hosts infected. According to the
GAO/IMTEC-89-57 report, the Nov 88 worm infected 1000-3000 hosts. RFC 1135
says that within 48-72 hours, all instances of the worm had disappeared.
In the report SPAN-027, the "Father Christmas" DECnet worm is said to have
been on the loose approximately one day, and infected around 40 hosts.
According to CIAC Advisory A-4, the "OILZ" variant of the WANK DECnet worm
"attacked 60 hosts". This compares to estimates of tens of thousands of
PCs infected with the Michelangelo virus a year ago.

It would seem that if "Virus Exchange bulletin boards" are important,
then outbreaks of new viruses would be contemporary, yet widely spread
geographically.

If a malicious individual gains access to computers and inserts
viruses manually, there should be a series of geographically localized
outbreaks of nearly identical viruses. I suppose "series" presumes that the
malicious individual performs the act several times.

Infection via media transfer would look very different if some vendor provided
distribution media that was already infected than if someone just brings
an infected disk home from a user group meeting, or to his/her office.
Depending on the scale of the vendor's distribution, outbreaks might be
provincial, national, continental or international. The virus itself should
be identical everywhere.

If viruses spread via publishing of source code, then inevitable typographical
errors would creep into the code during transcription. Multiple similar,
but not identical, variants should appear over a long period time, given
the persistent nature of reference books. The geographic spread should
be mostly coincident with the languages the reference book is published in.
The "Vienna" virus is often cited as having many, many variants, and this
is claimed to be so because of the source code published in Ralf Burger's
books.

The DECnet worms may illustrate a case of publishing of source code.
I gather from SPAN report SPAN-027, CERT Advisory CA-89:04, and CIAC
Advisory Notice A-4, the DECnet worms were all quite similar, and all were
written in DCL. Thus each infected site had full source to them. The WANK
worm also happened about a year after the Father Christmas worm.

A counter-example might be Mark Ludwig's "Little Black Book of Computer
Viruses." Source code for several viruses is provided. If the "timid"
virus is made into several variations, publication of source code might
be considered an effective vector of infection. If the "Little Black Book"
viruses don't collect imitations over the years, publication should not be
considered a threat. Since Ludwig's book is more accessible that Burger's,
the "Vienna" virus variation would have to be considered in a different light.

It seems to me that it would pay off to identify the most prevalent methods
of spreading and attempt to hinder spread of infections by those methods.
Naturally, this implies that there is interest in stopping virus spread.
If the interest is making money by selling software and books, or through
consultation fees, then identification of vectors of infection is not the
best idea.
- --

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

Date: Wed, 31 Mar 93 08:55:00 +0100
From: [email protected] (Inbar Raz)
Subject: Scanners getting bigger and slower

[email protected] (Fridrik Skulason) writes:

>>The whole point of having more than one scanner, is that there is a
>>considerable amount of viruses which are considered rare, or extinct, whose
>>chances of infecting you are unreal.

> Unreal ? Well, the problem is that almost all "extinct" or "research only"
> viruses are generally available on the virus exchange BBSes - so somebody
> could download one of them and spread it.

I see your point.

However, the way I see it, when we're discussing protection of BIG companies,
as opposed to the protection of private people, the chances of someone
downloading a virus from a board in order to deliberately upload it, are much
smaller, if existant at all. If a company is wise enough to enfore a
prohibition of disk exchange, and capable of doing it, then the networks/modem
connection are the only way to get infected, and assuming those links are
reliable links with reliable sources, this reduces the chance even further.

> As I have said before - the number of viruses should not affect the speed
> significantly - memory shortage is a problem, however - in 5 years a virus
> scanner might require more than 640K of memory to run....but so what ?
> I think it is reasonable to expect "everybody" to have more memory than
> that in 5 years..

I see your point.

Well, I don't think I have the slightest idea about what 5 years from now will
look for, in whatever concerns virus techniqes, virus availability and degree
of common, and so on. This is is a fast business...

Inbar Raz
- - --
Inbar Raz 5 Henegev, Yavne 70600 ISRAEL. Phone: +972-8-438660
Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 [email protected]

- --- FastEcho/386 1.25/Real!
* Origin: Inbar's Point - Home of the UnTinyProg. (9:9721/210)

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

Date: Tue, 06 Apr 93 15:13:41 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Scanners getting bigger and slower

[email protected] (Inbar Raz) writes:

> However, the way I see it, when we're discussing protection of BIG companies,
> as opposed to the protection of private people, the chances of someone
> downloading a virus from a board in order to deliberately upload it, are much

> smaller, if existant at all.

Why do you think so? Just the opposite, a directed attack is the most
probable thing that a disgruntled employee of a big company will do...
It is difficult to detect, almost impossible to stop, and often
impracticable to trace.

> If a company is wise enough to enfore a
> prohibition of disk exchange, and capable of doing it, then the networks/mode
m
> connection are the only way to get infected, and assuming those links are
> reliable links with reliable sources, this reduces the chance even further.

Problem is, this is very difficult to enforce... What are you going to
do - searching the people each time they enter the company? A 3.5"
floppy fits in a wallet... And, in the worst case, a virus could be
brought in as a hex dump on a sheet of paper and the attacker could
manually type it in!

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

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

Date: Tue, 06 Apr 93 12:44:24 -0400
From: [email protected]
Subject: Re: IDES'93 [Dick Lefkon]

Having been associated with the preparation of IDES'93 (and, despite of my
remote connection, sharing somehow the responsibility of this year's "perfor-
mance"), I regard "Buford Buckeye's" report a nice understatement of what
happened: plainly a "disaster". For those lucky non-participants, here are only
three "happenings":

1) Absence of ANY printed program: nobody, neither conference secretariat
nor session chairpersons nor speakers nor participants had the slightest
information which paper would be presented in what session. Moreover,
as some speakers (whom to know was the singular privilege of Mr. Lefkon)
didnot show up, Dick sometimes intervened session chairs by introducing
new speakers (sometimes for totally different themes). Conference pro-
ceedings were not available at the conference, and even today
(23 days AFTER the conference), three participants from Hamburg did not
receive the proceedings, said to be distributed on last day!

2) Registration and Keynote session: All started with long registration
queues (despite attempted improvements of 1992's even worse queuing
problems), and procedures overlapped heavily with keynote session. The
announced keynote session on World Trade Center disaster began so late
that the invited speaker (Sally Meglatherry) had to leave after
10 minutes talk! Despite of special advertisement, only 2 of the announ-
ced 4 speakers appeared!

3) Unconvivial atmopshere: Two well-known AV experts, having been speakers
in earlier years, whose photos were used to attract participants to "meet
the experts" were escorted out-of-conference without justification and
(as Mr. Lefkon said) "without any order" from the overall chairman,
(Dick Lefkon chaired the conference, intervened in sessions, directed
the organisaing committee, conference secretariat and program committee)

Mr. Lefkon argues that "... the way the conference is run is being reorganized
from the ground up". I wished so much that Mr. Lefkon were right!!! BUT:
I've worked very hard, within IDES-94 Committee, to prepare a recovery from
this year's disaster, including a report on the shortcomings, separation of
organisation from program committee, and setting clear objectives before
making personal decisions. After carefully observing, for 3 weeks, that NONE
of the basic faults were changed, I decided (April 5,1993) to leave program
committee. Some well respected experts had taken this step before - Harold
Highland, Padgett Peterson, Fridrik Skulason - and others - Eugene Spafford,
Ken van Wyk - followed me. I'm so unhappy because I always liked the idea to
meet the experts (even if the scientific "value" was NOT comparable to other
conferences on Security, Safety and Malware matters :-)

As many experts have expressed their decision NOT to go to IDES-94 and their
demand to meet next year at some nearby place (Philadelphia?) around March or
April 1994, a new opportunity to meet AV experts is presently being prepared.
Announcements will be made on Virus-L and related electronic fora in due time.

Klaus Brunnstein (U-Hamburg, April 6, 1993)

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

Date: Mon, 05 Apr 93 19:41:15 +0000
From: [email protected] (Scott Allen Barber)
Subject: Vshield V102 Bug? (PC)

I am running a Pionex Goldseries 486DX Computer with AMI Bios and am
having a "problem" with VSHIELD.

It seems that if I load VSHIELD, when I go to do a warm boot
(ctrl-alt-del) it will cause my computer to access the A: drive and
restart the cold-boot memory check.

It seems that some part of memory is written over when VSHIELD becomes
resident, because SCAN's memory scan function will not cause this to happen.

Does anyone else know about this problem???

Thanx...and please reply thru e-mail if possible...

I will post a summary of all replies.....

Scott Barber
[email protected]

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

Date: Fri, 02 Apr 93 12:38:02 +0100
From: [email protected] (Inbar Raz)
Subject: Scanners and exe/com file compressors? (PC)

> From: [email protected] (Philip Coull)

> Do virus scanners "unpack" exe/com files that have been
> packed/compressed? If they do, how do they cope with all the various
> packing programs? I'm absolutely sure that most "average" users are
> totally unaware that some of their executables are modified in such a
> way. Does it compromise the ability of scanners? I've never seen the
> ability of scanners to deal with such programs mentioned in any reviews.

> Even more worrying, is the following quote from PKWare's PKLite
> documentation, when discussing the Professional PKLite version:

> It uses a slightly different algorithm, which also scrambles the
> excutable file. This scrambling makes the executable data more
> resistant to disassembly or "reverse engineering" procedures. After a
> file is compressed using this method, it cannot be expanded to match
> the original executable file.

Well, in Israel there is a company called B.R.M., marketed by PF1. They have
an anti-virus program called 'UnVirus'.

UnVirus is currently capable of scanning relatively SIMPLE compressed files -

PKLITE (with the obvious exception of 1.15),
LZEXE
DIET

Also:

ARJ
PKZIP (with the exception of 2.04)
LHA

The exceptions were correct as for August. I believe they are no longer
existing.

Aside from this fact, if I were you, I wouldn't pay much attention to the
aledged warning by PkLite. Extracting the PkLited files, extra compressed or
not, is really an easy thing to do. In simple words - Why should I bother
trying to figure out the algorithm, if the PkLited file already has a
mechanism to expand the code? This is a foot-thick clue, and I'll say no more.

Regarding the Professional PkLite, though, there are dozens of programs
lurking around the PC Market that allow you to successfully extract PkLited -e
files. As a matter of fact, I once wrote one myself, but I no longer have it.

Inbar Raz
- - --
Inbar Raz 5 Henegev, Yavne 70600 ISRAEL. Phone: +972-8-438660
Netmail: 2:401/100.1, 2:403/100.42, 9:9721/210 [email protected]

- --- FMail 0.94
* Origin: Inbar's Point - Home of the UnTinyProg. (111:405/2)

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

Date: Mon, 05 Apr 93 23:31:10 -0400
From: [email protected]
Subject: VI-SPY VS Central Point AntiVirus (PC)

[email protected] (Min-Chin Hsiao) asks

> Just wondering if anyone has this problem? Is it just coincidence that
> Flip's signature was found in CPAV files?

Yes, this is a perennial (literally) problem between CPAV and other
scanners, especially scanners that scan all parts of files. I first saw
it with the Flip virus. Basically, CPAV appears to include search
patterns for "polymorphic" viruses that can be found with wildcarded
search patterns, and these search patterns are stored "in the clear" in
program files. The search pattern representation used is hard to
distinguish from a real virus degarbler (decryptor); metacharacters of
some sort are apparently used to represent wildcards. This wasn't
clear-cut when the only hit was on the Flip virus(es), but after a
half-dozen other virus degarblers were "found" in CPAV files, the
pattern became clear, without any reverse engineering required (or
done).

I'll let others pronounce judgment on whether or not this is a
reasonable practice.

Bill Arnold [email protected] (IBM AntiVirus development)

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

Date: Tue, 06 Apr 93 04:24:03 -0400
From: [email protected] (Paul Ferguson)
Subject: DOS v6.0 and Virus Functionality (PC)

Greets.

Has anyone had an opportunity to tinker with MS DOS v6.0 and it's
"capacity" for existant virus functionality? No, I'm not referring to
Microsoft's sad attempt to implement Central Point's CPAV (MSAV), but
rather the architectural changes in the OS. I'm curious, although
I'm not going to rush out and obtain a copy merely to satisfy my
curiosity. Given the impact that DOS v5.x had on many existant
viruses when it was introduced, (many existant viruses would simply
not run under DOS v5.x), I'd garner that much of the same
"non-functionality" will appear with the architectural changes to the
DOS v6.0 implementation(s).

I'm of the opinion that keeping your toolkit of third-party products
current beats the tar out of relying on Microsoft to provide it for
you in the DOS v6.0 "upgrade". In fact, I've been hearing that several
folks have had problems while logged in under Netware 3.11, on both
4Mb Token Ring and Ethernet LANs after thet rushed to "upgrade" to DOS
v6.0 ....

But then again, what do I know? <g>

Cheers.

Paul Ferguson | "Sincerity is fine, but it's no
Network Integration Consultant | excuse for stupidity."
Centreville, Virginia USA | -- Anonymous
[email protected] (Internet) |
sytex.com!fergp (UUNet) |
1:109/229 (FidoNet) |
PGP 2.2 public encryption key available upon request.

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

Date: Tue, 06 Apr 93 09:19:27 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Optimum Strategy for Virus Checking (PC)

[email protected] (Roger Riordan) writes:

> 5. By default VET will check the first 50 executable files it
> finds. Most program viruses will spread rapidly, so this will
> detect nearly all infections the next time the PC is booted.

Uh, what do you mean exactly by "the first"? Because, for a
non-resident virus that traverses the directory tree like Old_Yankee,
"the first" files is one thing and for a non-resident virus that
infects the files in the directories listed in the PATH variable (like
the Vienna viruses), "the first" might mean something completely
different... Again, for a non-resident virus (like Pixel) that infects
all COM files in the current directory, "the first" could have a third,
again completely different meaning. Make the virus resident and the
picture changes again...

> The author of the locally written Gingerbread virus went to
> inordinate lengths to hide it, but if it infected a PC with VET
> installed the user would be warned in the normal boot that the top
> of memory had been changed. After a clean boot VET would also warn
> that the MBR and the VET file were corrupted.

You've had luck that the author has not used the method used by the
Necropolis (1963) virus to remain resident...

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

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

Date: Tue, 06 Apr 93 09:25:27 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Port Writes (PC)

[email protected] (Inbar Raz) writes:

> A couple of days ago, I first succeeded in compiling and running a routine to

> access disk using port writes only, therefore avoiding any interrupt
> whatsoever.

[stuff deleted]

> Is there any EXISTING control program to inhibit such access?

Yes. Most modern hard disk controllers issue a hardware interrupt to
indicate "device ready" when they are done with the request. You could
count the access requests that have passed "naturally" through INT 13h
and check whether the number matches the number of "device ready"
interrupts from the hard disk controller. If there are more "device
ready" interrupts than INT 13h requests, this means that something has
accessed the disk in a non-natural way, so you raise an alert. At
first look it might seem that this way you can only -report- the disk
write after the fact. Fortunately, for each Write request the
controller actually performs -two- actions - Seek and then Write. It
issues "device ready" after each of them, so you'll be able to raise
the alert after the Seek and before the Write.

Unfortunately, this does not work on all controllers (I've seen at least
one which is dumb enough not to issue "device ready" interrupts) and
theoretically a virus could disable your program that is listening to
the device ready interrupt, but this tends to screw things up...)

> If a virus were
> to use port writes, no anti-virus shield would be able to stop it.

This will also make the virus rather non-portable. Unfortunately, it
will still work on many computers and the virus writers don't seem to
care about portability anyway... (I've seen a virus that is able to
infect correctly only 17-byte files...)

BTW, note that many hardware anti-virus products -will- be able to
stop this kind of disk access, if they can be installed between the
computer and the disk controller or between the disk controller and
the bus...

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

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

Date: Tue, 06 Apr 93 09:35:41 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Scanners and exe/com file compressors? (PC)

[email protected] (Philip Coull) writes:

> >It cannot be expanded by PKLITE, that is...expanding it with a special
> >program is not a problem at all.

> I think what you're saying here is that pklite can't expand it, but its prett
y
> easy to write one that does!(?)

Almost. Read carefully the PKLite documentation. It says that the
files compressed with the extra compression option cannot be
decompressed to match the original. This is true - often such files
cannot be recovered EXACTLY to their original state, because some
information is lost during the compression... But it does not mean
that they cannot be decompressed to an EQUIVALENT state. The only
difference is in the relocation items of the EXE header... There are
several programs available that are able to decompress the files,
compressed with the extra compression option of PKLite. DISLITE and
UNP are two of them; both are available from Simtel20.

> If that is the case there seems to be little
> point in using PKLITE Pro!

Yes, if your aim is to obscure the contents of the file. Don't forget
that the extra compression option compresses slightly better than the
"normal compression", so there -is- some point of using it...

> As an aside, and without giving away any "trade secrets". Can you use the
> compressed programs built-in ability to uncompress itself, or do you have
> to write a de-compressor totally from scratch??

Any of the two approaches can be used.

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

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

Date: Tue, 06 Apr 93 09:45:58 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Scanners and exe/com files (PC)

[email protected] (Shakib Otaqui) writes:

> You're so right. Some idiot recently posted on the Fido-Net
> Batchpower echo the debug script for what was described as a tiny
> disk cache program. At least two users have reported that the
> program trashed their drives, even though it had been scanned.

Well, if they are relying only on a known-virus scanner for anti-virus
protection, they could be successfully attacked by any new virus -
regardless whether it has been compressed or not.

> Investigation showed that the file was compressed with PKLite
> 1.15, and that a hex editor was used to replace the PKLite
> signature with null characters. This apparently defeated SCAN,
> which treated it as an ordinary file. After uncompressing the
> file with PKLite, one user said SCAN apparently identified it as a
> virus, though I suspect it's more likely to be a trojan.

Hm, I just tried the same with F-Prot 2.07. It succeeded to recognize
that the file is PKLited, but didn't try to scan inside it... Why,
Frisk?

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

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

Date: Tue, 06 Apr 93 10:01:57 +0000
From: [email protected] (Louis *grin* siuoL)
Subject: Re: Catch from DIR? (PC)

[email protected] (Malte Eppert) writes:

>Hi Frisk!

> > There is, however, one way to run a program from a diskette by
> > just doing a DIR,

>Ugh... if this isn't too special, can you or someone else post how this could
>be possible? I just know about an ANSI bomb which will execute a file from
>disk if you hit the 'hot key' next time. Do you mean this?

That may be one way. A method that I KNOW WILL WORK is, to trap DOSs
findfirst and findnext services, and infect any files that are
returned via thos services. Is as easy as traping DOSs Exec services,
which is what a large number of virii do.

- --
Louis Solomon
Internet: [email protected]
FidoNet : 3:670/216

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

Date: Tue, 06 Apr 93 09:54:16 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Virus signature determination. (PC)

[email protected] (Malte Eppert) writes:

> I always use the term 'polymorphic' in a different way to 'encrypting'. What
> you describe under 2) is an encrypting virus, what you mention under 3) is a
> polymorphic one.

You are correct; just a minor nit-picking: we call "encrypted" any
virus that uses any kind of encryption ("encoding" is the more exact
word). Those of them that use a different key each time, but a
constant decryptor, are called "variably encrypted" viruses. Those
that also modify the decryptor are called "polymorphic". There is some
fuzzy class of viruses like Bad_Boy or Commander_Bomber, which do not
use encryption at all, but instead swap/generate (unencrypted) parts
of themselves, but they are currently not of much concern...

> Isn't the term 'polymorphic' specifically reserved for viruses who
> have their encoder changed along with every copy by exchanging instructions
> etc. in a way that there can be no signature extracted?

Yes, except that for -some- polymorphic viruses (e.g., the Phoenix
viruses), it -is- possible to pick a (possibly wildcard) scan string
from the variable decryptor...

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

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

Date: Tue, 06 Apr 93 10:11:35 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: VI-SPY VS Central Point AntiVirus (PC)

[email protected] (Min-Chin Hsiao) writes:

> Vi-Spy consistently pick the Central Point Antivirus files like
> vsafe.com or Vsafe.sys saying that Flip virus is found. I think I have used
a
> Virus scanner from Taiwan Eten group which report the same thing.

Read the FAQ, question C6, the last sentence of the second paragraph.
It answers to your question. Maybe we should put it in a separate FAQ
entry...

> Just wondering if anyone has this problem?

Yes, about everybody who is using CPAV and some other scanner... :-)

> Is it just coincidence that
> Flip's signature was found in CPAV files?

No, it is not.

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

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

Date: 06 Apr 93 10:20:50 +0000
From: [email protected] (Roger Allen)
Subject: Re: WIndows Virus (PC)

Thanks for all the help I have received from everyone, I even
received an email address for Macfee etc from someone. I have a file
which I think may be the culprit; I say this cos I havn't mangaged to
get the virus back properly. It did start to fade the screen but now
it won't at all (no it wasn't a screen fault). Anyway, I'll be sending
out this file to people who requested it and in the mean time I'll check
all the other files I received around that period to try and find
the infected file if it isn't the one I thought it was.

Roger

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

Date: Tue, 06 Apr 93 10:20:48 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Which CRC/scanner to use. (PC)

[email protected] (Byron Faber) writes:

> I currently use f-prot/virstop/ and Integrity master on my machine.
> (a 386/40 pc). I was curious if anyone could give me their opinions
> as to which scanner would be the best to use.

According to my experience, F-Prot detects more viruses than the
scanner in the Integrity Master package. From IM you should use mainly
the integrity checker.

> I have been in a
> high risk group for computer viruses and have found that Integrity
> master's crc checks and f-prot's heuristic scans have done pretty well.

> If anyone has opinions on my setup, or could suggest any other
> alternatives please mail me.

If you are protecting yourself from a highly probable, but random
(i.e., not directed against your particular installation) attacks,
then the above set of programs is OK. Just use F-Prot to ensure that
the system is virus-free before installing the IM's integrity checker
and then use F-Prot to scan any incoming software. Also, install IM in
the most secure mode, with the information saved on a floppy and
checked after a clean boot.

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

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

Date: Tue, 06 Apr 93 13:15:18 +0000
From: [email protected] (Snaaijer)
Subject: New signature for TBAV (PC)

Althoug i posted reasently that there will be no more VIRSCAN.DAT
I found on the TBBBS (Thunder Byte BBS) a new signature file
vsig9303.zip and a new Beta version TBAVB510.zip
unfortunaly the new signature file doesn't detect Terminator II
(althoug v5.10b does detect it for a while).
The vsig9303.zip file isn't made by Frans Veldman, but as it is available on
his BBS I assume it's checked by him. I mailed the files to
Timo Salmi, because I can't use ftp fully. The files will hopfully
be available soon.

Ivar.

- -----------------------------------------------------------------------------
Rule one in program optimization : Don't do it.
Rule two in program optimization (for experts only) : Don't do it yet.
Rule three in program optimization (for athlets only) : Just do it.
- --
E-mail : [email protected] ... i can't help it, i'm born this way ...
- -----------------------------------------------------------------------------

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

Date: Tue, 06 Apr 93 15:10:32 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: April Viruses? (PC)

[email protected] (Mikael Larsson) writes (about VSUM):

> That listing contains info about all know viruses, activation dates,
> origin countries etc.. it's quite good.

It for sure cannot contain "info about all known viruses", because
new viruses appear averagely three per day and it is updated monthly.
But this is not the only problem - I have found almost all articles in
VSUM to be very inaccurate, incomplete, verbose, and just plain
wrong... So, no, I don't agree that it can be considered to be quite
good...

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

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

Date: Tue, 06 Apr 93 15:18:05 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Unknown little virus? (PC)

[email protected] (Maciej Otreba) writes:

> Last time I had virus in my PC. It came from Internet probably with one
> from shareware games.

Uh, according to my experience, the executables on the net are usually
virus-free... In fact, they are even more reliably virus-free than the
files on a local BBS, which are known to be more reliably virus-free
than the shrink-wrapped software distributed by some companies... :-)

> The problem is that teh virus was not detected by any
> program. I tried to find it by Scan 100, F-Prot 2.07 and Polish AV program
> MkSVir (available at FUNET with on-line translator). This virus caused

Scan and F-Prot can find almost even self-spreading nasty that is
internationally know and MkSVir probably can find all local Polish
nasties (haven't tested a recent version soon, but it seems to be
rather good). Chances are that you don't have a virus problem.

> Paintbrush, MS Word 2.0 and System Editor. It was probably very small. I
> think it took 32 bytes of base memory (difference between memory with and
> without virus).

There's no way to fit a memory-resident virus into 32 bytes... Several
cases of missing 16 bytes of memory are mentioned in the FAQ; I am not
sure what exactly can cause 32 bytes of memory to be missing...

> I throw it out by formatting HD and setting up system

As usual, this is never necessary.

> again. My question is: has anyone heard/seen anything about this virus? Is

I would bet that the problem has not been caused by a virus.

> Which programs in Internet might be infected?

None, I guess...

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

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

Date: Tue, 06 Apr 93 15:26:58 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Uruguay on PS/2 ref disk (PC)

bill.lambdin%[email protected] (Bill Lambdin) writes:

> KL| There is something funny F-Prot has given false alarms on several
> KL| different files about Uruguay-virus and when I tried whether it will
> KL| really find the Uruguay-virus - it didn't find not at least the sampl
> KL| I have - funny.

> This is a known bug in F-Prot 2.06. You should upgrade to the 2.07
> revision.

Problem is, now F-Prot 2.07 does not detect this virus reliably... :-(

On the other side, the virus has never been found in the wild and its
author is always sending the samples only directly to the anti-virus
researchers... So, maybe it is not worth the effort to detect it,
especially having in mind how polymorphic it is... At least not unless
somebody uploads it to the virus exchange BBSes...

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

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

Date: 05 Apr 93 22:06:00 -0600
From: "Rob Slade" <[email protected]>
Subject: Numbers and weighting (CVP)

PRTAVS2.CVP 930404

"Numbers" and "Weighting"

Before going into detail on the specific types of programs, I would
like to address some issues which can be applied to reviewing any
antiviral software. Aside from the specific efficacy against large
numbers, and certain types, of viral programs, there are
considerations of "user" aspects of the system in question. This
does not relate solely to the chimera of "user-friendliness", but to
the fact that a given system is intended not only to be somehow
effective against viral programs, and must be used by a "user
population" in a given work, social and technical environment.

It is very easy to "rank" antiviral software on the basis of how
many viral programs or strains that it will identify. It is not
quite as easy to assess many other, more important, features.
Although there may be more than 2000 different strains of viral
programs in the MS-DOS "world" (fewer in the other environments),
one percent of that number are likely responsible for ninety nine
percent of infections. Thus it is of far greater importance that,
for example, one particular antiviral program does not prevent
infection by the "Stoned" virus (as of this writing the most common
virus), than that it "protects" against literally thousands of
others.

Thus the choice of a "test suite" is made more difficult than it
might be otherwise. Certain programs are very significant in terms
of danger of attack, and therefore must hold higher ranking than
others. It is not possible to say that any collection of eighty
viral programs is better than any collection of ten. If the eighty
happen to be all "basement variants" of Jerusalem, that "test suite"
is virtually useless. First, a decent antiviral program should deal
with variants. Second, "basement variants" have a generally low
survival rate "in the wild", and are not likely to be a threat.
Third, "basement variants" tend to mutate "non-functional" aspects
of viral programs through the insertion of "NOP" codes and the
changing of text.

The test suite should, however, contain a range of viral programs
which are functionally distinct. A good test suite should contain
programs from different categories of programs, such as boot sector
infectors versus file infectors and "master boot record" infectors
versus boot sector infectors. Self-encrypting, polymorphic,
stealth, tunneling, multipartite and companion viral programs should
all be represented. Some of these programs are very rare "in the
wild", and so the value of their inclusion may be questionable.
(Indeed, there is some evidence that the more "sophisticated" a
virus is, the less likely it is to be "successful".) However, it
would be well to test antiviral programs against the known
"possible" viral technologies.

If at all possible, some rare, or even unknown (ie. you make it up)
viral programs should be included in the test suite. The assertion
by some software producers that they can catch all "known and
unknown" viral programs should never be left unchallenged.

copyright Robert M. Slade, 1993 PRTAVS2.CVP 930404

==============
Vancouver [email protected] | "A modern US Navy cruiser now requires
Institute for [email protected] | 26 tons of manuals. This is enough
Research into [email protected] | to affect the vessel's performance."
User [email protected] | "New Scientist" article
Security Canada V7K 2G6 | on the "paperless office"

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

End of VIRUS-L Digest [Volume 6 Issue 60]
*****************************************

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