From abacus.hgs.se!mikael Sun Mar 28 02:34:52 1993 remote from vhc
Received: by vhc.se (1.65/waf)
via UUCP; Sun, 28 Mar 93 01:37:15 GMT
for mikael
Received: from Abacus.HGS.SE by mail.swip.net (5.65c8-/1.2)
id AA27714; Sun, 28 Mar 1993 01:35:03 +0100
Received: by abacus.hgs.se (5.65c/1.5)
id AA04467; Sun, 28 Mar 1993 01:34:52 +0100
Date: Sun, 28 Mar 1993 01:34:52 +0100
From: Mikael Larsson <
[email protected]>
Message-Id: <
[email protected]>
To:
[email protected]
VIRUS-L Digest Thursday, 25 Mar 1993 Volume 6 : Issue 49
Today's Topics:
Legal Net Monthly Newsletter (All)
Mixed IBM & MAC LANs
Re: Results of updated MtE tests (PC)
Re: Looking for OPCODE lists (PC)
WordPerfect File growth etc. (PC)
scanners. (PC)
Michelangelo (PC)
Ignorance is curable (mostly PC)
Central Point and Stacker (PC)
Virus signature determination. (PC)
Re: Virus that infects while Scanning? (PC)
virus-map (PC)
Re: EXE/COM switch (PC)
Singaporean car dealers & Mike (PC)
VirusCheck 3.0 looking for Beta testers (PC)
Catch from DIR? (PC)
michelangelo (PC)
michelangelo (PC)
Re: Partition table virus (PC)
McAfee's Clean-output (PC)
Virus Catalog update/New VirusBase
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: Tue, 23 Mar 93 15:21:07 -0500
>From:
[email protected] (Paul Ferguson)
Subject: Legal Net Monthly Newsletter (All)
Opinion, editorial and news worthy submissions are currently being
(sought and) accepted for a new start-up electronic news journal.
This monthly compilation will be called 'The Legal Net Monthly
Newsletter' and will focus on the legal and ethical aspects of
computer networking. Legal Net Monthly will be a non-biased, open
forum electronic newsletter keeping in step with the networking
environment of the '90's and will be availble by E-Mail subscription.
Legal Net Monthly is aiming to release it's first issue on May 1st,
1993. Articles on the following topics are especially welcome:
o Defining "Criminal Mischief" on the Nets
o Authoring/Distributing Computer Viruses: Legal Implications
o Legislative news around the world
Send all sumissions, subscription requests and correspondence to:
[email protected]
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, 23 Mar 93 17:39:32 -0500
>From:
[email protected] (A. Padgett Peterson)
Subject: Mixed IBM & MAC LANs
While "cross-polinating" viruses have not appeared as yet (and are
difficult to write), such a client/server network can spread viruses
very quickly among homogeneous clients unless precautions are taken.
Further, while "first-generation" anti-virus programs exist for
the Novell Netware/IBM environment, I know of no such top-level
defense for MACs.
As a result, and since MACs will only access MAC software (except
for DOS boxes) and IBMs will access only IBM software, if anything,
the mixed nature of such a heterogeneos system makes it *more*
likely to become infected by a virus than a single platform system,
and less likely to have a proper defense.
Artisoft LANTASTIC was also mentioned (have 4.1 but not 5.0 - yet)
and it shares the limitation of any peer-peer network in not having
login scripting capacity & such is yet another step down from client/
server in robustness. I do not know of any heterogeneous peer-peer
LANs as yet though daya sharing is certainly possible.
Warmly,
Padgett
------------------------------
Date: Mon, 22 Mar 93 12:31:48 +0000
>From:
[email protected] (Zwienenberg)
Subject: Re: Results of updated MtE tests (PC)
[email protected] writes:
|> As material for my lecture on "Methods and Requirements for Quality Assuranc
e
|> of AntiVirus Products" in 6th International Computer Security and Virus Conf
e-
|> rence" (New York, March 11-12, 1993), Vesselin Bontchev kindly repeated the
|> MtE tests published in Virus-L last year. Here are the major changes:
|>
|> In November 1992, CATCH-MTE 1.5, F-PROT 2.05, FINDVIRU 6.01
|> and VirScan 2.2.3A detected *all* instances (2000 each)
|> of CoffeeShop, Cryptlab, Dedicated, Fear, Groove/EXE,
|> Groove/COM, Pogue and Questo.
|>
|> On March 7, 1993, CATCH-MTE 1.8, F-PROT 2.06a, FINDVIRU 6.10,
|> and VIRSCAN 2.2.3A
|> AS WELL AS: HTScan 1.19, PC Vaccine Professional 1.13,
|> SCAN V100 and TBScan 4.3 detect *all*
|> (8*2000) instances on the same testbase.
|>
|> Moreover, VirX 2.6d detects *all instances but 1 Pog
ue |> This significant improvement in recognition quality of AV products may be re
|> garded as a result of the public discussion on test results published (and
|> somehow controversially discussed) last year by VesselinBontchev. VTC plans
|> to update it's procedure to also test recognition of 8 new MtE-based viruses.
Of course, a good thing to keep this going, but what about TPE detection?
The just released 1.14 version of our product PCVP detects the TPE as well as
the next TBSCAN. I think that now almost all packages do detect the MtE,
people will start to use TPE (and future engines) as it is stupid to use
a mutation engine which already is detected by the majortity of scanners.
[RiZwi]
Computer Security Engineers Ltd R&D
P.O. Box 45610
2504 BA The Hague
The Netherlands
+31-70-3622269 (voice)
+31-70-3652286 (fax)
------------------------------
Date: 22 Mar 93 13:55:54 +0000
>From:
[email protected] (Alan Christiansen)
Subject: Re: Looking for OPCODE lists (PC)
[email protected] (Charles Howes) writes:
>Someone recently mentioned 'serializing' an executable program by using
>alternate opcodes as binary ones, to the regular opcodes' zero.
>That was in comp.security or alt.security.
>I thought 'Hey, the folks in comp.virus know a lot of this technical stuff,
>I'll ask them!'. This could also be tied in to the earlier discussion of
>polymorphic viruses, if necessary.
>My question:
> What are some opcodes that have two possible numeric values?
> This is for the 80x86 family of machines.
>(I want to serialize software, not write viruses, polymorphic or otherwise.)
All the XCHNG R,R should be suitable
There are a number of CMP AL,#immediate type instructions that have
one and 2 byte versions. so th one byte version and a NOP should be swappable
with the 2 byte version.
Jmp short NOP and Jmp dd where dd and d are signed displacements can be inter
changed
etc
>Thank you!
>Charles Howes --
[email protected]
------------------------------
Date: Mon, 22 Mar 93 12:18:52 -0500
>From: Brian Seborg <
[email protected]>
Subject: WordPerfect File growth etc. (PC)
I have seen the same problem with WordPerfect file growth in a Banyan
environment. We have traced it to users exiting WordPerfect abnormally.
Meaning that they either use cntrl-alt-delete to exit, or they turn off their
machines while still in WordPerfect. This causes WordPerfect to create a huge
file sometimes in excess of available disk space. The only way to prevent
this from happening is to educate your users not to abnormally exit from
WordPerfect. This is a known bug by WordPerfect, I imagine that they will
address it in the next release if enough people complain.
Regarding a comment that Richard Ford made about using FDISK or SYS while a
virus is memory resident. It is not always the case that this will cause
the disk to be re-infected if the system has booting from the floppy disabled.
In fact, several viruses can successfully be eradicated using this technique
although it is not advised. The reason for this is simple. Many viruses
like the Michelangelo will perform an "are you there call" before attempting
to infect the MBR. If they find that they are there in memory already, then
they assume that they have already infected the MBR and no longer need to do
this. Therefore, if you replace the MBR with these type of viruses in memory
and then shut down the machine and reboot you should come up clean. Again,
this is not true for all MBR viruses, but it is true for some like the Michel-
angelo.
Brian Seborg
VDS Advanced Research Group
(Makers of VDS Pro 1.0 and CatchMtE)
------------------------------
Date: Fri, 19 Mar 93 10:55:13 +0100
>From:
[email protected] (Malte Eppert)
Subject: scanners. (PC)
Hi Inbar!
> I see what you mean. I thought 'slow' only refered as to the
> speed of the damage the virus causes. Can you think of an idea
> (or is there one already) to bypass this?
I'm sorry I don't know of one. Maybe Vesselin does, he has more practice than
me :-)
>> The DOS file fragmentation, a theoretically possible infection described
> But still. If the virus DOES manipulate things, those
> manipulations should be caught, no?
> the fat or not, eventually one of the files' clusters won't be
> the same, and I should catch that.
You can't by normal, file-based means... The DOS image of the file is the same
as before, while the physical image, which is relevant at boot time, has
changed :-(.
cu!
eppi
- --- GEcho 1.00
* Origin: No Point for Viruses - Eppi's Point (9:491/6051)
------------------------------
Date: Fri, 19 Mar 93 00:34:06 +0100
>From:
[email protected] (Chris Franzen)
Subject: Michelangelo (PC)
> Hi Vesselin!
>> BTW, I am very curious how many Michelangelo hits have happened
>> this year...
> I know about at least two. One in Braunschweig, another one in the
> Vechta area, both Northern Germany.
Oh come on. There is NO town in Germany where Mich could not be found.
> cu!
> eppi
Chris, The Blast I
- --- GEcho 1.00/beta+
* Origin: You wanted junk -- so I drop some. (9:491/3020)
------------------------------
Date: Mon, 22 Mar 93 12:51:00 +0100
>From:
[email protected] (Amir Netiv)
Subject: Ignorance is curable (mostly PC)
To:
[email protected] (A. Padgett Peterson)
Quating
[email protected] (Amir Netiv):
>>> my previous posting With the rise of companion and stealth viruses, to be
>>> sure in checking the low levels you must first authenticate the path to
>>> disk
>>How exactly do you do that? If a virus has been loaded and is chained to
INT >>13h, so that when you look for Sector-X Cyl-Y Head-Z it will replace it
with
>>another location and you will never know !
Padgett answers:
> Read Andrew Shulman's "Undocumented DOS". Int 2F Fn 13 will return the path
> to Int 13 DOS found when loading. If it does not point to the ROM BIOS or a
> controller card ROM, you have a problem (how you WILL know). If your
program > runs at the BIOS level like mine do, the table vector *must* point
to the
> ROM BIOS or a disk controller if the machine is clean.
> At BIOS time, high RAM does not exist and every Intel processor is in REAL
> (8086) mode. Things are very predictable.
Well dear Padgett, it seems like you didn't quite get my idea: There is no
problem in checking that the original INR-13 ISR is located on the BIOS area (
except if you are using some smart PC that does the shadowing of the BIOS to
another area in RAM location and completely remapps the adresses), However
that is not the issue here. When you know the location of the original INT-13
ISR is when the system is already booted (or in the process) but *AFTER* the
IO.SYS is loaded (unless your Anti Virus is also an operating system which you
will excuse me for not believing it is so).
Therefor, your program cannot tell you that the original boot sector or
partition table is replaced!
Remember that AFTER what you call BIOS time (nice term) the BIOS usually does
not necessarily continue to supply INT-13 services.
AN:
>>Any way that you might point out as the total solution to the problem, I
can >>show a hole that viruses (naturally) may (or alredy do) use.
Padgett answers:
> A virus can intercept an interrupt vector. It cannot intercept as FAR CALL.
> All you need to know is where to make the far call to (the exercise is
> left to the student). *No* virus can infect ROM memory unless
> built in at the factory.
A. I agree that a virus does not intercept a FAR CALL, but only hooks an
interrupt.
B. To know where to make the far call to, you should be a Gypsy and own a
crystal ball to consult with. Because what ever YOU consider predictable is
not so in reality.
The "original" procedure is located somwhere in the system depending
which program took it. You cannot assume that the INT-13 ISR is in a
constant place nor can you assume it is a part of the BIOS, because if you
do, your program is likelly to crach a lot of PCs especially those that
use special low level programs like Access control to disks, and several
Network tools. So much for predictions.
C. Did I ever say that the virus infects the ROM ? You have to be very
ignorent to say so.
D. I'd reccomend that the student will learn a little more about programs
and utilities before writing programs that makes the PC a solid rock with
no flexibility (interrupts hooked in place forever by some Anti-Virus).
> As a consequence, the fact that the A-V is checking the STACed drive boot
> sector means more than just an error is being flagged each time, it would
> make me concered that the real boot sector may be skipped.
>>Not necessarily so, but quite likely.
> Would you care to bet your PC on it ? Perhaps I was being too gentle. EVERY
> A-V I have seen that flags the compressed drive has been missing the real
> DBR. Further, with the possible exception of the DOS 6.0 compression
> (haven't gotten that far in studying it yet, it blew up on the
> test XT) every one of the compression schemes I've looked at have layered
> their driver on top of DOS and intercept INT 25 & 26, not 13. If you
> use 13, you will never see the compressed disk boot sector. Is that clear
> enough ?
I'm sorry to be the one that lets you know that int-25 & 26 are translated
eventually into INT-13. Just as INT-21 Fn 02 (write char) is translated into
INT-10. So you see, what you wrote is incorrect. Ther is *NO* are on the
formatted disk surface that is not acessible via INT-13.
AN:
>>As for myself, I do not recommend using these double-diskers,
>>since the problem that you mentioned (and viral problems
>>in whole) is only a small portion of possible problems to happened. And
>>believe me - you don't want to be the owner of a disk when it crashes.
Padgett answers:
> Legitemate opinion. Mine is that compressed drives make so much sense that
> they will become a standard. The key is in the recovery programs and they
> are maturing nicely.
As Darwin said, eventually if the environment is hostile the species that will
survive is the one that will adapt. But the question should be: Is that the
right thing to do here?
We (software makers) are so anxious to supply the users with
what they want, that we tend to disregard the consequences.
AN:
>>It remindes me of the EXPANDED memory cards that people used to buy once,
>>and got stuck with it immediatelly since EXTENDED memory has emerged.
>>Get a bigger (faster) and reliable disk.
Padgett answers:
> I have not yet reached the point of being able to treat PCs as disposable
> items, nor would I want to.
Who said you should?
> Extended memory is a valuable attribute for
> 386 and higher machines. I still have 2 XT class and 1 AT class machines
> that see regular and valuable use.
It seems you do not read the things you reply to!
I said that the EXPANDED memory cards that used to be, were out of fassion
before they were able to be sold in large quantities. I truelly hope that the
same will happen with the disk-doublers.
> My next *major* purchase
> will be a parallel port ethernet adaptor for my laptop. I suspect that
> like myself, most readers are not independantly funded.
Good for you.
Hope N.Y. was not too cold for you.
Regards
* Amir Netiv. V-CARE Anti-Virus, head team *
- --- FastEcho 1.21
* Origin: <<< NSE Software >>> Israel (9:9721/120)
------------------------------
Date: Mon, 22 Mar 93 13:23:00 +0100
>From:
[email protected] (Amir Netiv)
Subject: Central Point and Stacker (PC)
Donny Gilor writes
Quating
[email protected] (Amir Netiv):
AN:
>> Remember that stacker (or any other disk doubler) uses the DOS
>> environment to do what ever it is doing,
>> and so does Anti Virus TSRs (especially those that use many interrupt
>> monitoring). A conflict might be fatal (generally speaking).
Donny:
> Most TSR writers disagree with you especially since DOS is built for
> TSRs. If you're right you should be warning anybody using any sort of
> TSR with Stacker (including keyboard handlers, EMM386, Windows, etc).
Since you are new here, let me first welcome you.
As for TSRs, I think you are way out of time in starting again the encient
discussion of TSRs or not. Juust to remind
you V-CARE is equipped with a TSR for quite some time already,
and as a TSR writer myself, I think I may express my poinion
about them.
Second thing: your *"DOS is built for TSRs"* flag ship is not correct (
historically speaking). "DOS supports TSRs" is a much better term. However the
main problem is that DOS is an operating system that suffers from the lack of
standartization, thus causing conflicts and crashes between programs, and
since TSRs use system resources in the most intensive way they are the main
cause for conflicts.
Evidently it seems you've missunderstand my view on TSRs and so you keep
answering to things I do not say.
Thired: You do not have to warn anybody using other TSRs like keyboard
handlers since they do not tamper with the set of interrupts used to acess the
disk. As for QEMM386 I'm surprized that a man with such an experiance as you
claim to have does not know thet EMM386 has many conflicts, which makes a lot
of users switch to QEMM (which also has a lot of different conflicts).
Last but not least: If it didnt happened to yet I truelly hope it never will,
but Double disk for example conflicts with several optimization programs and
some utilities,
the result is fatal, I've experianced it myself several times.
Regards
* Amir Netiv. V-CARE Anti-Virus, head team *
- --- FastEcho 1.21
* Origin: <<< NSE Software >>> Israel (9:9721/120)
------------------------------
Date: Mon, 22 Mar 93 16:01:31 +0000
>From:
[email protected] (Rune Fr|ysa)
Subject: Virus signature determination. (PC)
I'm planning to expand an anti-viral utility to include file
scanning, like Mc'Affe's scan program does. Therefore I would
be interested in more information of how I determine the signature
of any virus, including mutating ones. I know that I
could allow one virus to infect multiple files, and then do a
file comparsion to find the equalities between the files. This
however would probably result in very long signatures (if not
the entire virus, which would make it fatal to distribute the
signature file). Just taking the very first bytes of the virus
into account, would however cause to many false alarms.
Is it also possible to get signature files from somewhere and
implement them in the package? (The format of the files would
ofcourse be of ultimate interest.)
- -Rune
(
[email protected])
PGP 2.x public key available on request.
------------------------------
Date: Tue, 23 Mar 93 15:47:41 +0000
>From:
[email protected] (Chris Antkow)
Subject: Re: Virus that infects while Scanning? (PC)
[email protected] (Ryan Kolter) writes:
>I don't know if there is a virus out there that does this. Is there?
>If so, is there a way to protect against it? He said that Mcaffee didn't
>pick it up. (I don't know what version he used).
Some virus scanners do protect against these types of viruses (I
believe ViruScan does this somehow...). YES! There are viruses out there
that do this. I don't know about "Removing" themselves from memory, but
the way that many of the techniques are accomplished, are by not
infecting the Scanner (To avoid a faulty CRC check), and then using the
scanners Func. 3Dh/INT 21h (Open file) call in order to infect the file.
Some viruses that do this are later versions of DataRape (Aka: Sunday
2), NPOX (NukePox), and I believe Horse does this as well (Can't really
remember, I don't have the source code handy...) Also, any other
disinfect-on-the-fly virus is able to do this as well (NPOX v2.0+,
1963...)
They do exist...
Cheers...
Chris
[email protected]
"Smash the control images, Smash the control machine"
- William S. Burroughs
------------------------------
Date: Tue, 23 Mar 93 11:23:44 -0500
>From:
[email protected]
Subject: virus-map (PC)
Hi all,
is there a kind of map, report, list, whatever about the places in the world
where specific viruses usually can be expected to be found ? Some of them
are probably all over the world, but every now and then I read, that virus
X is not even in the wild, virus Y might be the culprit, as the PC stands
in South Africa. Can someone give me a pointer ?
TIA, Alfred
- --
###############################################################################
Alfred JILKA # This place intentionally left blank! This place i
Geological Survey, Austria # ntentionally left blank! This place intentionally
[email protected] # left blank! This place intentionally left blank!
[email protected] # This place intentionally left blank! This place i
#################Don't cut here, you'll damage the screen !####################
------------------------------
Date: Tue, 23 Mar 93 11:31:52 -0500
>From: Donald G Peters <
[email protected]>
Subject: Re: EXE/COM switch (PC)
JR sent me a scathing letter (which was cross posted here) saying
that the EXE/COM switch was "simply dangerous" to use. There was
no explanation, but one could infer that JR was concerned about
having a false sense of security that the EXE/COM switch would
give because it would only work against "stupid" viruses.
Of course no SINGLE mechanism which JR uses is sufficient to
prevent a virus infection. Surely JR uses a variety of techniques.
In this case, I once threw out an estimate that this would
work against 50% of all viruses. To my regret, nobody attempted
to produce a more accurate figure. I guess I could make a
tabulation based on lists like the one in CPAV, but I didn't
want to use figures from a source that people seem to dislike
on this forum.
If I came up with a device that could prevent 50% of all plane
crashes, would that also be a "dangerous" device because it
would give a false sense of security?
For people who use scanners, I don't think the EXE/COM switch
buys much. It wouldn't "add another 50%" in that case. For people
who know enough to poke values into COMMAND.COM to change COM
to CCC, this method probably wouldn't help much either. These
people probably have other defenses set up.
The EXE/COM switch is only useful for a certain group of people,
like maybe my parents, who had to call me the other day to ask
which way they stick a 3.5" floppy diskette into the drive. :-)
However even they, like me, don't share executeables, so not
even a scanner would do us much good.
------------------------------
Date: Tue, 23 Mar 93 23:16:25 +0000
>From:
[email protected] (C R Pennell)
Subject: Singaporean car dealers & Mike (PC)
I shouldn't have done it. It's my punishement for wishing ill of car-dealers.
Anyway lots of people want copies of the article on virus attacks on those
nice people who help us buy cars in Singapore.
BUT I posted the article ages ago, and only today has it surfaced so I'm
not sure I can find the article so easily (This is an explanation, not a
criticism of our ref., who probably has better things to do)
I'll try and locate it. But bear in mind that the people who write on
viruses in the STRAITS TIMES are no better than the people who write on
viruses in newspapers anywhere. . . .
Richard Pennell History NUS
------------------------------
Date: Tue, 23 Mar 93 21:12:48 -0500
>From:
[email protected] (Jon Freivald)
Subject: VirusCheck 3.0 looking for Beta testers (PC)
VirusCheck 3.0 is well underway and looking for BETA TESTERS.
What is it?
VirusCheck is a watchdog/shell for McAfee Associates ViruScan
virus scanning software. It eliminates the need for many custom batch
files to accomodate different machines and eliminates the need for the
user to sit and watch while his system is being scanned.
VirusCheck is designed around US Marine Corps anti-virus policies,
yet is flexible enough to be in use by many agencies and thousands of
users world-wide. It will insure that the entire system gets scanned.
(How many of your network users or temporary employees know how many
partitions are on the system(s) they use?) It will monitor the exit
code returned by ViruScan and lock the system if a virus is found.
VirusCheck also includes "policy enforcement tools" for the
local area network administrator to use. Using this utility (affectionately
named "the Enforcer") will deny network access to any user who does not
comply with the established anti-virus policy (as long as that policy
is the use of VirusCheck/ViruScan).
VirusCheck 2.3b has been in production use throughout the US
Marine Corps and on tens of thousands of other systems since November 91.
Version 3.0 is a complete, ground-up re-write with many new and improved
features.
If you are interested in BETA TESTING this new version, you can obtain it
in the following ways:
Download from my BBS -- dial (516) 483-5841, settings n81,
300-9600 V.32, login "guest", password "guest",
download /public/dos/virus/vc3beta.exe
Via mail-server -- send mail to "mail-server%
[email protected]"
the subject line will be ignored, include the text
"get dos/virus/vc3beta.exe"; if you also need ViruScan,
"get dos/virus/scanv102.zip" will get it. The files will
be sent to you via return e-mail in multiple UUEncoded
segments.
Snail-mail -- send a stamped, self-addressed diskette mailer and
your preferred format diskette (360K through 1.44M) to:
Jon Freivald
269 Mitchel Ave
East Meadow, NY 11554
=============================================================================
Jon Freivald ( jaf%
[email protected] )
Nothing is impossible for the man who doesn't have to do it.
PGP V2 public key available on request
=============================================================================
------------------------------
Date: Wed, 24 Mar 93 06:52:57 +0000
>From:
[email protected] (Terry Lundgren)
Subject: Catch from DIR? (PC)
I have received some excellent replies to my posting on catching
a virus. Basically the question is this: Assume my system is
clean and I have an infected disk. I put the disk in the drive
and do a DIR. Then I take the disk out. Can my system be
infected now?
The responses are running about 1/3 saying no way and 2/3 saying
it is possible. I would really like to get a definitive answer.
If a virus can be passed in this way, would someone please
describe how it might happen? Or not.
Thanks.
- --
Terry Lundgren, Administrative Information Systems, EIU
------------------------------
Date: Wed, 24 Mar 93 03:39:36 -0500
>From:
[email protected] (Bill Lambdin)
Subject: michelangelo (PC)
>From:
[email protected] (Chuck S.)
Subject: Re: Michelangelo (PC)
Dido We had a drive die just as it was turned on Sat.
Mikey was not announched this time around and got us!
chuck
- --------------------------------------------------------------------------
I'm sorry to hear that tou were affected by Michelangelo.
CNN posted a little blurb about Michelangelo on March 5th. Apparently
their informant wasn't very well informed. but they did spread the word
about Michelangelo set to attack on March 6th. But Michelangelo is not a
file infector.
Michelangelo is a variant of Stoned, and hides in the boot sector of
diskettes, and the partition table of hard drives.
Bill
- ---
* WinQwk 2.0 a#383 * SICILIAN MOB activates after December 31st 1991
------------------------------
Date: Wed, 24 Mar 93 03:47:40 -0500
>From:
[email protected] (Bill Lambdin)
Subject: michelangelo (PC)
>From:
[email protected] (Tackey Chan)
Subject: Michelangelo Virus (PC)
I was wondering if anyone can tell me about how this virus
works? Does it only affect that one day or does it tag allow somwhow
onto things posted on "nn"? Anything you can tell me would be
appreicated do that I can know what to look for.
- --------------------------------------------------------------------------
Michelangelo is a variant of Stoned. Meaning that it hides in the boot
sector of diskettes, and partition table of hard drives.
Michelangelo is detectable, and removable by most if not all scanners.
When the hard drive is infected, the virus goes resident, taking about 2K
of memory below the 640K limit.
It will infect diskettes (even high density diskettes) as they are
accessed in A:
Bill
- ---
* WinQwk 2.0 a#383 * KENEDY activates Nov 18th
------------------------------
Date: Wed, 24 Mar 93 03:47:53 -0500
>From:
[email protected] (Bill Lambdin)
Subject: Re: Partition table virus (PC)
Date: Mon, 08 Mar 93 16:55:41 +0000
>From:
[email protected] (Andrew M Smith)
Subject: [Stoned] (PC)
Has anyone heard of the [Stoned] virus and if so, then what does it do?
Also, I have an odd question concerning infected disks...If I have an
infected disk and run a magnet across it, will all data (and the virus) be
erased???
- --------------------------------------------------------------------------
Stoned is a rather benign virus except for when it infects irregular hard
ware.
Stoned hides in the boot sector of floppies, and the partition table of
hard drives.
McAfee's Clean can remove the virus from hard drives, and floppies.
the command is
CLEAN C: [STONED]
substitute the drive letter when removing Stoned from diskettes.
Bill
- ---
* WinQwk 2.0 a#383 * SATURDAY THE 14TH activates Saturday 14th
------------------------------
Date: Wed, 24 Mar 93 06:19:29 -0500
>From: Rutger van de GeVEL <
[email protected]>
Subject: McAfee's Clean-output (PC)
Dear networkers,
I'm not sure if this is the right place to ask this, but I'll do it
anyway. Maybe some of you have noticed that the screen output from
both SCAN.EXE and CLEAN.EXE (from McAfee Associates) is different from
the output produced when the /REPORT option is used. The output in the
report file is very brief and (for example) doesn't show if a virus is
(or isn't) removed: it only tells that a virus has been found. Why is this?
The reason why I ask this is that I would like to process the report files
from SCAN.EXE and CLEAN.EXE in order to automatically eliminate any virus
that is found with a self-written program. So IMHO the output in the report
files should be more elaborate or at least the same as the screen-output
(this applies to both SCAN.EXE and CLEAN.EXE).
Example:
Output on the screen from CLEAN.EXE when cleaning [Stoned]:
Cleaning [stoned]
Scanning for memory resident viruses.
Scanning 64K RAM......
Drive B: has no volume label.
Scanning boot sector of disk B:
Found the Stoned [Stoned] Virus in boot sector.
Virus cannot be safely removed from boot sector. <--- Yes, message is there
Found 1 file containing viruses.
This McAFEE(TM) software may.....
Copyright (c) McAfee Associates 1989-1993. All Rights Reserved.
Output in the report file by CLEAN.EXE (with /report option) when
cleaning [Stoned] (the same disk with the same virus):
Options: b: [stoned] /a /m /chkhi /nopause /unattend /report c:\clean.log
Drive B: has no volume label.
Found the Stoned [Stoned] Virus in boot sector.
- ---> Am I missing something here? <----
Found 1 file containing viruses.
So perhaps this could be fixed in futures releases.
Thanks,
Rutger
*******************************************************************************
Three Accounts for the Super-users in the sky, * Rutger van de GeVEL,
Seven for the Operators in their halls of fame, * Student Information
Nine for Ordinary Users doomed to crie, * Management & Technology,
One for the Illegal Cracker with his evil game * Tilburg University, Holland
In the Domains of Internet where the data lie. *********** Email address:
One Account to rule them all, One Account to watch them, *
[email protected]
One Account to make them all and in the network bind them * Phone : (66)2049
In the Domains of Internet where the data lie. * Office: B512
*******************************************************************************
------------------------------
Date: Tue, 23 Mar 93 11:31:09 -0500
>From:
[email protected]
Subject: Virus Catalog update/New VirusBase
The new version of Virus Test Center' *Computer Virus Catalog* is now available
for ftp (ftp.informatik.uni-hamburg.de). The following files may be downloaded:
INDEX.ZIP the new index file (INDEX.293), listing all
283 viruses in 5 platforms yet described
AMIGAVIR.ZIP the cumulative AMIGAVIR files, now describing
77 AMIGA viruses (15 new ones)
MSDOSVIR.ZIP the cumulative MSDOSVIR.files, now classifying
156 MSDOS viruses and trojans (32 new ones)
MACVIR.ZIP the cumulative MACVIR files; no update since
July 1992 (.792) as no new viruses were found
ATARIVIR.ZIP the old AtariVir files (20 viruses) not updated
as we have no new viruses for analysis.
The single UNIX virus (AT&T Attack) will be sent on request (on ftp soon).
In the new MSDOSVIR.293 file, the following new PC viruses are classified:
10_past_3 (2), Adolf, Alabama, Chemnitz, Exe_Bug (2), Flip, Hey_You,
Kampana=Spanish Telecom (2), Minimal (15), Techno, VOID_POEM, V-163
and V-Sign/CANSU.
Moreover, characteristic features of viruses generated by the following author-
ing packages are also classified:
PS-MPC and VCL.
As announced last year, the new *machine readable CVC version* called CVBASE
is also available for downloading: cvbase-293.zip. CVBASE allows to display
all CVC entries (in total 288, on Amiga, Atari, Mac, MsDos and the single UNIX
virus), under option VIRUS, but also gives an OVERVIEW and STRAIN relationsship
about All (about 2,200) viruses in the CARO/VTC collections (using CARO naming
scheme) as well as the VTC collection on Amiga (77), Atari (20), Mac (35) and
Unix (1). From STRAIN, one may read available CVC entries.
*Any suggestions how to improve this version are welcome*
Klaus Brunnstein (U-Hamburg, Virus Test Center, March 22,1993)
------------------------------
End of VIRUS-L Digest [Volume 6 Issue 49]
*****************************************
Downloaded From P-80 International Information Systems 304-744-2253