|
Virus- L Digest Vol 6 No. 033
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/1.5)
id AA25977; Wed, 24 Feb 1993 18:59:52 +0100
Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA10614
(5.67a/IDA-1.5 for <[email protected]>); Wed, 24 Feb 1993 11:42:29 -0500
Date: Wed, 24 Feb 1993 11:42:29 -0500
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 © 1991/92, Anastasios Kotsikonas
From: "Kenneth R. van Wyk" <[email protected]>
To: Multiple recipients of list <[email protected]>
Subject: VIRUS-L Digest V6 #33
Status: R
VIRUS-L Digest Wednesday, 24 Feb 1993 Volume 6 : Issue 33
Today's Topics:
Viruses, Greeks, and Trojan Horses
Re: Scanners getting bigger and slower
Re: Virus education
In-Re: "Re: Sale of Viri" [sic]
Re: Virus detection by code inspection
Re: Censorship
Question about Patricia Hoffman and John McAfee
Re: os2-stuff (OS/2)
Re: Suggestion to the developers of resident scanners (PC)
Central Point Antivirus and Stacker (PC)
file name virus? (PC)
Re: Minimal virus scan? (PC)
EXE/COM switch (PC)
Re: Scanning memory (PC)
Re: standardization (PC)
Re: Uruguay on PS/2 Ref disk (PC)
re: logic bomb in PKZIP (PC)
How can you recover a hrad drive from joshi? (PC)
Re: my idea for detecting file infectors (PC)
An undetectable virus I have been infected with. (PC)
CP Antivirus with Stacker (PC)
Re: standardization (PC)
SIMTEL20 subdirectory name changes (PC)
VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed. Contributions should be relevant, concise,
polite, etc. (The complete set of posting guidelines is available by
FTP on cert.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, 22 Feb 93 15:26:57 -0500
From: Brian Seborg <[email protected]>
Subject: Viruses, Greeks, and Trojan Horses
I have been watching the attempts to define a virus here with some
degree of nausea and boredom and thought it only appropriate to punish
those responsible by forcing them to read my own thoughts on the
subject.
Let's go back to the beginning. It all started with the Trojan Horse.
You see, the Greeks were fighting the Trojans, and the Trojans were
basically pouring hot oil on the Greeks, shooting them with arrows,
and generally making the battle a bit of a downer for the Greeks. The
Greeks came up with an idea to take advantage of the Trojan's love of
horses, and to turn the tide of the battle to their advantage. To do
this they built a large horse made out of wood, and loaded the entire
Greek army inside. The Trojans woke up the next day and saw that the
Greek army had disappeared and in their place stood this large wooden
horse. Thinking that the Greeks had given up and had left the horse
as a token of their admiration of the Trojan's war prowess, the
Trojans pulled the horse inside and had a big party. That night as
the Trojans slept the Greeks crawled out and wiped them out. This
story has different flavors, but it will suffice for the rest of my
discussion.
Now, we leap forward to the time of computers, and some joker figures
that he can mess up your system by fooling you into running some
program which promises great speed increases, or a neat game, and this
type of program with hidden functionality becomes christened a "Trojan
Horse." Your computer is the Trojan Fort, you are the Trojan, the
program is the Trojan Horse, and the code inside it becomes the
Greeks. Seems appropriate.
Next we progress to program code which not only houses malicious code,
but code which can spread to other programs turning them into Trojan
Horses. We called these viruses since we assume the original program
is similar to a cell, and the virus code is similar to a biological
virus which attaches to the cell making it function like the virus.
We also saw the development of worms which much like a biological tape
worm are self-contained and can consist of one or several segments,
and essentially exist to tap or sap the resources of systems attached
to networks.
But, we have seen viruses which attach to programs in different ways
other than direct attachment. Companion viruses come to mind, where
the viruses actually create a seperate and distinct file which has the
same name as a legitimate program, but which is lower in the hierarchy
of execution (i.e. creating program.com to ensure that it runs before
program.exe). We have also seen viruses which change the pointers in
the directory to point to the virus first (such as DIR II) and the
virus maintains its own pointers to the original programs. There is
also the "fragmentation attack" (I believe this was coined by Vesselin
Bontchev) in which a virus takes advantage of the fact that certain
system files are assumed to be located in fixed positions on the disk
relative to the beginning of the DOS boot partition, and the virus
simply places itself in these locations after moving the original code
elseware (similar in concept to MBR and Boot infectors). So, we
have to try to come up with a definition which embraces all of these
developments, and still excludes programs such as Xcopy, and Diskcopy
as well other legitimate programs which are not viruses.
The old definition attributed to Fred Cohen's 1987 paper "Computer
Viruses: Theory and Experiments," Computers & Security, Vol. 6, No. 1,
February 1987, pp. 22-25 is:
"We define a computer 'virus' as a program that can 'infect' other
programs by modifying them to include a possibly evolved copy of
itself."
Fred further points out in his article the following:
"The key property of a virus is its ability to infect other
programs..."
He also states:
"It should be pointed out that a virus need not be used for evil
purposes or be a Trojan Horse."
The definitions put forth in this paper were groundbreaking, but Fred
never anticipated some of the new ways viruses currently use to
"infect" program code. However, I believe we can modify Fred's basic
definition and arrive at a new working definition which will include
the different types of viruses such as companion viruses and still
exclude other non-virus programs.
Modified definition:
We define a computer 'virus' as a program that can 'infect' other
programs by modifying them or their environment such that execution of
the infected program implies a call to a possibly evolved copy of the
'virus.'
Granted, the definition is recursive, and may need some work, but it
seems to cover the current state of the art, while still
distinguishing viruses from worms, or Xcopy.
As for Fred's comment about viruses not necessarily being Trojan
Horses, this is true since if one knows that a program contains a
virus, then there is no unknown functionality implied. Also, perhaps
when we find that our programs have a virus inside we should be
historically correct and state, " My program was attacked by a damn
Greek" (my apologies to any one of Greek decent :-)) since the Trojan
Horse would have been nothing but a nice statue of a horse if it were
not for the fact that it concealed the Greek Army inside.
Also, an 'infected' program only becomes a Trojan Horse if we don't
know that it is infected.
Brian Seborg
VDS Advanced Research Group
:-)
------------------------------
Date: 22 Feb 93 19:43:09 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Scanners getting bigger and slower
[email protected] (Gal Hammer) writes:
> I was thinking (Not happen a lot, but...) if every virus have his own sig. and
> every week few or some viruses appers, So don't all the AnitViruses program
> will start to get bigger and slower ?!
Bigger - yes. Slower - not necessarily. First, not everybody's scanner
has a different signature for any different virus. There are a lot of
scanners around that report "Jerusalem variant" for a couple of
hundreds of different viruses, the only common thing being that they
are indeed derived from the old Jerusalem virus. In most cases, all
those variants are detected with 1-2 signatures. But, as more and more
viruses appear, scanners must necessarily get bigger and use more
memory.
The speed, however, is not necessarily reduced. What all scanners do
is essentially to find a substring (the virus signature) in a string
(the file). But this is a well known problem in computer science, and
there are well developed and fast algorithms to handle it. Space does
not permit me to describe them here, so you should check the special
literature - usually Donald Knuth's "bible", "The Art of Computer
Programming", probably the first volume.
Such algorithms allow to your program to tell very quickly that the
substring is NOT contained in the string. In most cases, this can be
achieved with a single comparison. And, remember, most files are not
infected most of the time, and if they become infected, the users are
not very much concerned about the speed of the scanner - they just
want all infected objects properly detected. So, a scanner can permit
itself to be fast on a clean system, with the price to be slow on an
infected system.
These algorithms are commonly referred to as "hashing" and use a
special array, called a "hash table". There are only two problems with
it - the array is usually big (e.g., 64 Kb) and if it gets almost
filled, the access becomes very slow. But this is not likely to happen
soon - currently there are about 2,000 viruses and handling 30,000
this way is perfectly possible.
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: [email protected] D-2000 Hamburg 54, Germany
------------------------------
Date: Mon, 22 Feb 93 22:15:37 +0000
From: [email protected].edu (John Mechalas)
Subject: Re: Virus education
[email protected] (Fridrik Skulason) writes:
>[email protected].edu (John Mechalas) writes:
>
>> I could write a program, for example, that interrupts all I/O
>>access to the hard drive.
>
>Technically no - you could not....well, maybe on a +386+, using protected
>mode, debug registers and such...in general you would need hardware to
>intercept all I/O. Software can be bypassed.
True...in my enthusiasm I overspoke. :) But the idea is still valid...such
a device would be a pretty silly "virus" detector, using a poor definition.
As such, it does address the original posters issue of why it is necessary
to have a clear, concise definition of a virus.
- --
John Mechalas \ If you think my opinions are Purdue's, then
[email protected].edu \ you vastly overestimate my importance.
Purdue University Computing Center \ Stamp out and abolish redundancy.
General Consulting \ #include disclaimer.h
------------------------------
Date: Mon, 22 Feb 93 18:11:00 -0500
From: Tom Zmudzinski <[email protected]>
Subject: In-Re: "Re: Sale of Viri" [sic]
In V-L #29, [email protected] (Thomas Grant Edwards) writes:
> I am just wondering if you got a virus, and passed it on accidently,
> could you be held civilly at fault for thousands of dollars of
> damage say if it got into a business?
First, let me say that I am NOT a lawyer (my parents are married), but
the answer is an otherwise unqualified (and rather loud) *Y*E*S* !!!
Before any other pseudo-legal beagles jump me, the operant word is
"could". I do not know if anyone has been sued over this YET [anybody
got any CASE LAW they want to share?], but given our overly litigious
society, it's an absolute lead-pipe cinch that it's going to happen.
Now, if you want me to gaze deeper into my crystal ball, I'd say that
it's unlikely that any individual will be zapped all by their lonesome
- -- he/she usually doesn't have enough money to make the suit worthwhile.
It's MUCH more likely that the employer (who usually has deeper pockets)
will be tagged with partial liability. ("Partial liability" is a real
trip through fantasyland -- in theory, if one has one-percent liability,
one pays one-percent of the award; in reality, once the resources of the
schmoe with ninety-nine-percent liability are exhausted, the one-percent
liable entity is stuck paying the remainder.)
Tom Zmudzinski [email protected]
"In ten years there's gonna be one million lawyers!
ONE MILLION LAWYERS! One million lawyers!
How much can the poor nation stand?" -- Tom Paxton, about a decade ago.
------------------------------
Date: 22 Feb 93 21:00:55 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Virus detection by code inspection
[email protected] (Jim O'Shea) writes:
> Could you recognise that a file had been infected by a virus purely by
> inspecting a disassembled listing? I do mean any virus, including one
> you might not have met before. I accept it might not be possible to be
> specific but answers like "Yes, given unlimited time." or " Seventy
> percent probability of a correct answer after spending 6 hours on
> inspection" will be useful. I am interested in applying AI to virus
In general, when the file is infected, this is pretty obvious. (Just
don't ask me to figure out how I am doing it...) What is NOT obvious
is when the file contains a dropper, or an overwriting virus written
in a high-level language and compressed, or when it is a buggy virus
that always crashes when run. In those cases, the virus expert who is
examining the file is likely to make a mistake and he usually needs to
"try it out". Unfortunately, some viruses replicate only in very
special conditions (one of the silly Violator viruses can infect
properly on 17-byte files, I think - not larger and not smaller). For
such viruses we say that they "need to be fed with a spoon".
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: [email protected] D-2000 Hamburg 54, Germany
------------------------------
Date: Tue, 23 Feb 93 06:27:25 +0000
From: [email protected] (Albert Lunde)
Subject: Re: Censorship
[email protected] (Donald G Peters) writes:
>All I really want to know is whether there should be
>guidelines for this matter. It seems to me that if we could
>develop guidelines (and who would be all that much better
>than us?) we could provide something of use to the computer
>community as a whole.
>
>I have NO objection to people keeping information private on
>the basis of 'trade secrets'. That is, privacy because they
>want to make money from their ideas. THat's fine. But very
>often I see people saying (or implying) "I can't talk about
>that here because that might give ideas to the bad guys."
>[...]
>Please feel free to propose things that we should NOT post
>on this forum. I would agree to censor raw virus code but
>would like to consider the value of censoring ANYTHING else.
I think people who know the details of how viruses work have
plenty of reasons to be cautious -- anti-virus "experts"
with no commercial interests to protect, who have no "trade
secrets" seem equally circumspect. Anyone who maintains
anti-virus software has to respond to new viruses; anything
that encourages the development of new viruses is more work
for them.
History shows that a lot of viruses are copies and variations
of others. One reason to be wave hands at the details is
to force virus creators to do some work. This does *not*
interfer with defending against viruses -- unless I am writing
an anti-virus package from scratch (actually more difficult
than writing a virus), I don't need to know more than the
general characteristics and symptoms of a virus to protect
against it.
It is true that lots of programmers could write a virus;
however the higher we keep the skill level required, the
more likely they will have better things to do.
Virus source code is one thing I absolutely don't want
made public, but I can see value in being relatively
careful about what one says on other topics.
- --
Albert Lunde [email protected]
------------------------------
Date: Tue, 23 Feb 93 07:22:36 +0000
From: [email protected] (McAfee Associates)
Subject: Question about Patricia Hoffman and John McAfee
Hello Mr. 007,
[email protected] (007) writes:
>[email protected] (McAfee Associates) writes:
>>>As far as I know, there is a close link between the authors of SCAN and
>>>VSUM, and i wouldn't trust the test as a purely independent test.
>>There is no close link between McAfee Associates and Ms. Hoffman, at
>>least, none different from that between her and any other anti-viral
>>vendor.
>Really? I wonder why Ms. Hoffman states in her "A word from Patricia..."
>section:
>
> A special thanks goes to John McAfee for the countless hours he
> has spent reviewing VSUM prior to its release.
>
>Seems she has a bit more of a connection with SCAN than "any other
>anti-viral vendor."
Simply because John McAfee would spend hours on the phone telling her
about what viruses were new, where they came from, how common they
were, etc. If you think you have any such information that may be of
use to Ms. Hoffman, I'd suggest that you contact her. Perhaps you too
can get your name mentioned in her virus summary.
Regards,
Aryeh Goretsky
Technical Support
- --
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
McAfee Associates, Inc. | Voice (408) 988-3832 | INTERNET:
3350 Scott Blvd, Bldg 14 | FAX (408) 970-9727 | [email protected]
Santa Clara, California | BBS (408) 988-4004 | CompuServe ID: 76702,1714
95054-3107 USA | USR HST Courier DS | or GO MCAFEE
Support for SENTRY/SCAN/NETSCAN/VSHIELD/CLEAN/WSCAN/NETSHIELD/TARGET/CONFIG MGR
------------------------------
Date: 22 Feb 93 19:27:39 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: os2-stuff (OS/2)
Malte.[email protected] (Malte Eppert) writes:
> Two years ago I had a strange case of Cascade infection on a 386. An
> APP-File of Ventura Publisher had been mistakenly hit by 1704-B and
> was damaged - but not infected, since the virus in the file was no
> longer capable of replicating - Ventura always crashed at startup.
> Nevertheless SCAN (dunno which version it was those days :-) ) flagged
> it as infected when using the /A switch; and there were other,
> regularly Cascade-infected COM files on the drive which were simple to
> clean. The APP-File had to be reinstalled.
That can happen, because the APP files are Exec'ed - i.e., they are
passed to INT 21h/AX=4B00h (or to INT 21h/AH=4Bh) and Cascade just
happens to infect anything that is executed this way (in the second
one, more exactly) and does not contain 'MZ' in its first two bytes.
> I don't know the conditions under which that happened, but I think similar
> things should also be possible with DLLs and other viruses.
We were talking about the DLLs in OS/2 and they are NOT executed in
the way mentioned above. Thus, Cascade cannot infect them.
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: [email protected] D-2000 Hamburg 54, Germany
------------------------------
Date: Mon, 22 Feb 93 12:14:39 +0000
From: [email protected] (Ivar Snaaijer)
Subject: Re: Suggestion to the developers of resident scanners (PC)
[email protected] (Vesselin Bontchev) writes:
>Ah, yes, I forgot about that. Yes, the file should be scanned when
>executed from a network drive too. BTW, one thing that Frisk really
>*MUST* implement soon is an option to re-activate VirStop after the
>network shell has been loaded...
you might try tbscanx the driver for the memory resistend TB* programs
makes networks possible.
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: Mon, 22 Feb 93 12:32:52 -0500
From: [email protected]
Subject: Central Point Antivirus and Stacker (PC)
I use stacker, and recently have begun Internet, etc. I have Central
Point Antivirus, but haven't installed it yet. Stacker manual warns
against using some antivirus packages, but doesn't cite which not to
use.
Are Central Point Antivirus and Stacker compatible?
Thanks
Jack Gill
[email protected]
------------------------------
Date: Mon, 22 Feb 93 18:51:54 +0000
From: [email protected] (UMR Usenet News Post)
Subject: file name virus? (PC)
I'm not sure if I have a virus or not. A user came to me today and
the program he was using could no longer create files, the error
message displays the names of the files it attemps to create. This
used to create files fine every time. This user experienced this
problem after allowing another user to copy files to his hard drive
so that another machine with this problem could have the hard disk
reformatted. Now both machines display this problem.
The file names used to be a rather normal MYFILE.DAT type name,
now when it attempts to create a file it says "ERROR, CAN'T
CREATE bMYFILE.BAT" where the "b" is a beta (ASCII 225 in the
English version of the extended character set).
Are there any viruses that change or create files with a "beta"
character (ASCII 225) prepended to the file name?
Thanks,
Scott Hayes
[email protected]
Please e-mail me copies of answers since I am not a regular reader here.
- --
Scott Hayes [email protected] [email protected]
"This page intentionally blank."
------------------------------
Date: 22 Feb 93 19:09:22 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Minimal virus scan? (PC)
[email protected].nokia.fi writes:
> My question now is if these assumptions are correct:
> - - viruses only infects:
> *.EXE and *.COM -files that has been used when a virus is in memory
> the boot sector
> command.com
You forgot the SYS files and the master boot sector. And COMMAND.COM
is not really different from the other *.COM files.
> - - it is enough to scan only memory, the boot sector and for example the
> following files:
> command.com smartdrv.exe emm386.exe keyb.com
> win.com win386.exe lat.exe redir.exe
No. If the virus is not resident, you won't detect it at all. If the
virus infects SYS files, you won't detect you there. If the virus
infects MBRs, you won't detect you there.
> Is that correct? If not please tell me why not! I can also think about
> varying the scanned directories from day to day.
Better install a resident scanner - a scanner that scans only those
files that are executed. Also, install an integrity checker.
> Also is there really any need to scan DLL, DRV, OVL and SYS-files?
The SYS files - yes. There are already several viruses that can infect
them. There are even SYS-only infectors (i.e., you won't find them in
any other files), but for obvious reasons they don't spread well.It
The other files should be scanned only if you find an infection - a
virus could infect them by mistake, but a virus that infects -only-
them cannot survive.
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: [email protected] D-2000 Hamburg 54, Germany
------------------------------
Date: Mon, 22 Feb 93 15:17:38 -0500
From: Donald G Peters <[email protected]>
Subject: EXE/COM switch (PC)
Here is an idea I have cooked up to defend against some types
of viruses. It has not (to my knowledge) been in print before.
Viruses which infect files often *look* for the extensions
EXE and COM. If no such files exist, the virus will not
replicate. Some people have propagated the idea that you
should rename your EXE files as XXX so that a virus will
not find it and it will remain safe from infection.
>From what I have read, many viruses are *either* EXE or COM
infectors, but not both. And even for viruses that infect
both types, the following defense may work against them.
The trouble with the XXX idea above is that the programs
cannot be found and cannot be run with such a name. My idea
is to rename all your EXE files as COM and rename all your
COM files as EXE. Believe it or not, DOS is still able to
run your programs after you make this switch. DOS does not
rely on the extension to determine if the program is
relocatable (a la EXE) or not (a la COM), rather it looks
for the file signature ("MZ", the initials of the early
Microsoft employee who developed this scheme) and takes
action upon that.
Now any virus which is tailored to work specifically on
one type of program is not very likely to work when you
pull this trick on it. I will leave it to the experts on
this forum to determine the details of that.
I will also leave it to an enterprising individual to
determine wither COMMAND.COM will run if it is renamed
to COMMAND.EXE (with the appropriate change to the COMSPEC
variable in CONFIG.SYS). Personally, I doubt it, but
perhaps a simple modification to the boot sector may make
this possible. I think a utility in this regard would be
very nice!
A handful of programs may not run with the EXE/COM switch,
and some programs may require "reconfiguration" especially
if they are looking for programs of a given name, although
some of them allow you to change the name to search for.
In the future, viruses WILL be able to defeat this approach,
but for now I think it is a valuable tool for those who
are vulnerable to viruses. I would appreciate comments from
the experts on this forum who know *exactly* how various
viruses work (or who can simply test this idea with
viruses that they contain in safe keeping.)
Remember where you heard this from!
(because I always wanted to be famous as a kid...)
Don Peters
------------------------------
Date: 22 Feb 93 20:18:05 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Scanning memory (PC)
[email protected] (Bob Babcock) writes:
> Isn't it better to be conservative and look everywhere in memory for active
> viruses?
No. There are some parts of memory where some viruses just cannot
be active. Like Stoned in the DOS buffers.
> I'd much rather see a false alarm than have something be missed
> because a scanner was wrong about where viruses could lurk. Also, this sort
I also used to think like you some time ago, but now I am convinced
that this is not the case. A false positive can be very costly to a
company - as much as a real virus. Because they have to figure out
that this is a false positive. And sometimes this is more difficult
than to clean up a virus, especially if it is a ghost positive that
sometimes appears and sometimes not.
> of false alarm can only arise if you have scanned an infected floppy. If a
> user has an infected floppy, and doesn't know enough about viruses to
> understand the ghosting problem, they should consider getting expert help.
First, expert help is not running the streets, so why not push the
producers of anti-virus program to make smarter software? Second, the
in one of the cases it was a false positive that actually PREVENTED
the user to quickly remove the virus from all floppies - because he
had to reboot after each one...
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: [email protected] D-2000 Hamburg 54, Germany
------------------------------
Date: 22 Feb 93 20:24:44 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: standardization (PC)
bill.lambdin%[email protected] (Bill Lambdin) writes:
> I feel that the authors of scanners need to get together, and agree on a
> naming system.
That's a very good idea, but it is damn difficult to implement...
First, somebody has to come up with a good naming scheme. But what is
a "good" naming scheme? For instance, for me, a good naming scheme is
a scheme that allows two people to understand each other that they are
talking about a particular virus variant. That is, when I'm saying
Jerusalem.AntiCAD.4096.Mozart, Frisk knows what I mean. But the
producer of product XYZ does not like it, because it takes too much
memory in its resident scanner to keep such long names. Anyway, we
(CARO) have come up with such a naming scheme and now we are waiting
the other anti-virus producers to use it. The latest status of the
proposal is available for anonymous ftp from our site:
ftp.informatik.uni-hamburg.de:/pub/virus/texts/tests/naming.zip
The second problem is that different producers of virus scanners use
different approaches to scan for viruses. For instance, it seems to me
that the classification of viruses into families and subfamilies is
important for Frisk's scanner, because he has become very skilled at
that and does it regularly. Thus, any naming scheme used by him is
likely to group the viruses into families. This, however, might not be
helpful at all (or even annoying) to the producer of the scanner ZYX,
who calls all the 200 Jerusalem subvariants "Jerusalem-B". So,
obviously, he is not likely to adopt this naming scheme.
Third, even if two producers of scanners agree to use one and the same
names, it is very difficult to keep their products synchronized. For
instance, both F-Prot and FindVirus are using the CARO naming scheme
(although they use a different notation), and they -tend- to use the
same names for the viruses, and both Frisk and Dr. Solomon are getting
the new viruses practically at one and the same time, yet if you look
at that "naming" file mentioned above, you'll see how different the
names used by their programs still are... The anti-virus researchers
are really overloaded with new viruses popping up literally every day,
and they have more important things to do than to sit and ponder
whether to call the yet another silly overwriting Burger variant
Burger.V or Burger.Y. (Yet, they are doing this too...) The problem
increases in difficulty in an exponential rate, if more than two
scanners have to be synchronized...
So, your idea is good. The only problem is to get an easy
implementation of it...
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: [email protected] D-2000 Hamburg 54, Germany
------------------------------
Date: 22 Feb 93 20:56:35 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: Uruguay on PS/2 Ref disk (PC)
[email protected].edu (Patricia C Inman) writes:
> Fprot 2.06 reports: command.com "Infection: Uruguay" on all PS/2
> Model 70/80 Reference Disks Version 1.06. Version 1.03 of the Ref
> Disk reports clean. CPAV is current and reports nothing.
> I recently went through a scare and collected all disks in the
> facility. This is all I have left to cleanup. Is this "normal"?
No, it is not normal. It is a false positive in F-Prot 2.06. The
problem has been fixed in version 2.07, but now it does not detect the
Uruguay viruses reliably... :-( The only good news are that (a) you
are not infected and (b) the Uruguay viruses are not in the wild.
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: [email protected] D-2000 Hamburg 54, Germany
------------------------------
Date: Mon, 22 Feb 93 16:34:14 -0500
From: [email protected] (Bob Babcock)
Subject: re: logic bomb in PKZIP (PC)
>Well, the new PKZIP 2.04g (and possibly the older 2.04 versions too)
>make use of this possibility. On execution, they check for the
>identifier mentioned above, and, if it is not found, they destroy
>themselves by overwriting argv[0] with 64 Kb of junk.
..
>The logic bomb is obviously put there by PKWare, and does NOT have any
>other destructive effects. I couldn't figure out any way in which it
>could destroy anything that it shouldn't.
What happens under DOS 2.x where argv[0] does not contain the program
name? What happens if the disk has less than 64Kb of free space
(counting the overwritten file as free space)? Suppose you are
writing a task switcher, and it has a bug which causes it to not
properly switch the PSP? Suppose a program you are debugging branches
to a random location, and happens to run into the file trashing code
still in memory from a previous PKZIP execution? I'm postulating some
low-probability events, but I find the existence of the file trashing
code disturbing. Remember that other parts of the code did not
perform as expected on some machines when released into the real
world.
------------------------------
Date: 22 Feb 93 21:40:24 +0000
From: [email protected] (Murray Karstadt)
Subject: How can you recover a hrad drive from joshi? (PC)
Can a hard drive once its been attacked by joshi be recovered?
The story in brief is that a program was run that contained joshi( the
bad news is that the program was an old antivirus program). The women
in question ran the program found joshi, got rid of it and now cannot
see her harddrive.
We booted the system from a protected floppy but cannot find c:. Any
suggestions as what to do next. One last thing, there are no backyps of
anything.
thanks in advance for any help
murray
[email protected]
- --
not a test
------------------------------
Date: 23 Feb 93 00:48:41 +0000
From: [email protected] (Vesselin Bontchev)
Subject: Re: my idea for detecting file infectors (PC)
bill.lambdin%[email protected] (Bill Lambdin) writes:
> I have an idea to detect new and unknown viruses.
> Let me tell you up front, my idea is only for detecting file infectors,
> and should be used in conjunction with other virus detection software.
> It's only another tool for the virus detection toolkit. This will not give
> the users the name of the virus or tell how to remove it. Simply a Yes or
> No if the user has a file infector on the loose.
Actually, it is worse than that - it -might- tell you that there is a
file infector. But it also might fail to do so. The idea is not new,
it is sometimes called "decoy launching".
> 1575, and Frodo will attach to two byte .COM files. But 8 Tunes will not
> attach to any file smaller than 9216 bytes.
And DataLock does not infect a COM file smaller than 23,000 bytes. And
some viruses infect only some special files (Lehigh infects only
COMMAND.COM, ZeroHunter infects only files with large areas of zeroes
in them, some viruses do not infect files with some particular names,
etc.
> I recommend PKzip or LHA, but not ARJ because the files size fluctuates.
Uh, what do you mean by "file size fluctuates"?
> As long as FC or COMP do not report any differences in the two archives,
> you can be reasonably sure that you don't have a file infector.
No, the only thing you can be sure about is that THOSE FILES (the ones
you put in the archive) are not infected by a non-stealth virus. You
cannot tell for sure that there is no virus in the system or that it
is not a stealth one.
> If you want this to detect stealth viruses, copy, this .BAT file, the
> archive software, and FC.COM or COMP.COM to a known clean bootable
> diskette. Once ever week or two; cold boot from this known clean diskette
> (preferably write protected) and run this test.
OK, that will do it for the stealth viruses, except that it's
considered a bit inconvenient by most people...
> In my tests, I archive six files.
>
> COMMAND.COM
> FORMAT.COM
> PKZIP.*
> WINLOAD.*
> DRWATSON.EXE
> NOTEPAD.EXE
And what if the virus refuses to infect files with such names?
There are other holes in your idea - you are assuming that the virus
will infect those files, because you are using them often. And what if
it is a non-resident virus, that infects only in the current
directory, or if has a weird infection pattern, like Anthrax?
In general, the idea is equivalent to checking the integrity of a
small subset of your executables.
> I am releasing this idea to the public domain, so authors of virus
> detection software can incorporate this idea into their software if they
> care to.
I have already seen this idea implemented in some products - VDS comes
into my mind. However, there are some improvements:
1) The names of the generated decoys are rather random, so it is not
easy for a virus to avoid to infect them.
2) The decoys are both copied and executed.
3) Some anti-stealth tunnelling tricks are used. They are able to
bypass most stealth viruses, but unfortunately they also bypass very
successfully any user-installable volumes, like Stacker.
4) They don't claim to be able to detect any file virus - they are
just using that idea as a tool to help detecting the virus. Sometimes
it works, sometimes it doesn't.
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: [email protected] D-2000 Hamburg 54, Germany
------------------------------
Date: Mon, 22 Feb 93 21:07:30 -0500
From: Max Maser <[email protected]>
Subject: An undetectable virus I have been infected with. (PC)
I hope that this is being sent to the correct recipient. I do not
receive the 'comp.virus' group at my location. On the 6th of Feb. at
7:10:56 pm, (est.) my computer crowed like a rooster. At precisly the
same time every day it 'crows' 21 times. McAfee's scanv100 detected
stoned active in memory and in the partition table. I formatted several
discs and then used clean100. It reported that there were no virus's
detected, and 1 hour and 15 minutes later, the crowing repeated.
I would like to know if you have had any other reports of this
virus, plus any other information that you may have available re this.
Since I am unable to get the newsgroup at this time, I would greatly
appreciate direct mail replies. Other scan programs I have tried are
F-PROT, IBM's latest virus scanner, Central Points latest CPAV, and
McAfees V100. Thanks for your time and I look forward to a reply soon.
Max Maser [215] 494-5813 148 Bethel Rd. Aston, Pa. 19014
My internet address is [email protected]
------------------------------
Date: Mon, 22 Feb 93 22:50:19 -0500
From: [email protected]
Subject: CP Antivirus with Stacker (PC)
I have stacker on my hard drive. Can I use CP Antivirus on the same
drive without disturbing Stacker? Has anyone reported adverse effects
of the two on the same drive?
JACK GILL BITNET: D_GILL@TWU
TEXAS WOMAN'S UNIVERSITY INTERNET: [email protected]
DENTON, TEXAS 76204
------------------------------
Date: Tue, 23 Feb 93 07:41:06 +0700
From: [email protected] (Micke Larsson)
Subject: Re: standardization (PC)
[email protected] (007) writes:
> bill.lambdin%[email protected] (Bill Lambdin) writes:
>
> >I feel that the authors of scanners need to get together, and agree on a
> >naming system.
>
> A (very) few already have. The naming system is called the CARO
> standard, and the scanner that adheres most closely with it (that is
[stuff deleted]
> (Hey frisk, how about "f-prot /CARO" as a command line switch?? ;-)
Solomon's FindVirus have a /EICAR switch which outputs the Eicar code for
viruses found. These codes are a part of the CARO naming standard.
Micke Larsson QA Informatik AB, PO Box 596 S-175 26 Jarfalla Sweden
Tel +46-8-7602600 Fax +46-8-7602605 BBS +46-8-7602615 2:201/370@FidoNet
e-mail micke.[email protected] Compuserve Id 100135,1742 TeleGuide 81006329
QA Informatik distributes Dr Solomon's Anti-Virus Toolkit in Sweden
------------------------------
Date: Mon, 22 Feb 93 14:37:33 -0500
From: [email protected] (Keith Petersen - MACA WSMR)
Subject: SIMTEL20 subdirectory name changes (PC)
Effective immediately the following WSMR-SIMTEL20.Army.Mil subdirectories
have been renamed:
Old Name New Name
PD1:<MSDOS.ARC-LBR> PD1:<MSDOS.ARCHIVERS>
PD1:<MSDOS.TROJAN-PRO> PD1:<MSDOS.VIRUS>
This corresponds to the following on OAK.Oakland.Edu:
Old Name New Name
/pub/msdos/arc-lbr /pub/msdos/archivers
/pub/msdos/trojan-pro /pub/msdos/virus
Keith
- --
Keith Petersen
Maintainer of the MS-DOS archive at WSMR-SIMTEL20.Army.Mil [192.88.110.20]
Internet: [email protected] or [email protected]
Uucp: uunet!umich!vela!w8sdz BITNET: w8sdz@OAKLAND
------------------------------
End of VIRUS-L Digest [Volume 6 Issue 33]
*****************************************
|
|
