VIRUS-L Digest Tuesday, 18 Feb 1992 Volume 5 : Issue 32
Today's Topics:
Re: Michaelangelo ID sigs comp/w Stoned (PC)
Re: IBM PS/2 and CHKDSK ... (PC)
Re: Michelangelo threat (PC)
Re: Ohio Virus? (PC)
Re: two small comments (PC)
Re: Will re-formatting a floppy remove ALL vires (PC)
New original disks with Michelangelo (PC)
Re: AUX files (PC)
Intel enters the game (PC)
Floppy boot sectors & viruses (PC)
Network World 10FEB92 (PC)
Non-inanimate Michelangelo (PC)
Re: AUX files (PC)
WDEF infection at a school (Mac)
Re: Cohen's error
VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed. Contributions should be relevant, concise,
polite, etc. (The complete set of posting guidelines is available by
FTP on cert.sei.cmu.edu or upon request.) Please sign submissions
with your real name. Send contributions to
[email protected]
(that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks).
Information on accessing anti-virus, documentation, and back-issue
archives is distributed periodically on the list. Administrative mail
(comments, suggestions, and so forth) should be sent to me at:
[email protected].
Ken van Wyk
----------------------------------------------------------------------
Date: 10 Feb 92 21:53:56 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Michaelangelo ID sigs comp/w Stoned (PC)
[email protected] (William) writes:
> The little program, which I call "stone.com" reads in sector 1 track 0
> and scans it for a unique string which identifies the presence of the
> "STONED" virus, and if found, the program displays a warning message
> and terminates with an errorlevel code. In the case of the stoned
> virus, a 100% reliable search string is simply the word "stone" (read
> case insensitive).
Be careful. There are several versions of this virus, most of which
are just a trivial patch. Some of them do not contain the word
"stoned". For instance, one of the variants says "sanded"...
> My question to the net is -- what is an analogous ID string for the
> Michaelangelo virus that I could look for at the same time as I look
> for "stone"?
If you mean a plain ASCII text - no, there isn't any. You must modify
your program to be able to scan for hex strings as well...
> Normally I don't worry extremely too much about virus's, but the boot
> sector kind are such pests, and if Mikey is as stupid as stoned, I'd
Please, be careful when naming viruses. Michelangelo, not Mikey. There
is a virus, named Miky, which is a completely different one, so you
may confuse some people...
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN, rm. 107 C
Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 10 Feb 92 21:09:55 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: IBM PS/2 and CHKDSK ... (PC)
[email protected] (Andrew Brennan) writes:
> When you run CHKDSK under Dos 3.3 on a PS/2, shouldn't the
> numbers for total memory still come up to 655360? I have four
Nope. I'm on a PS/2 Model 50Z right now, using DOS 5.0 and also have a
1 Kb missing. This often happens with the PS/2 models, they are meant
to be like that.
> machines here (at least) all pulling 1k short of that. The
> only explanation I have is that it might be linked to the
> Microchannel, etc. I booted from (what I think to be a) clean
My (wild) guess is that it has something to do with the configuration.
Try to play with the configuration program and see if you can get
better results.
> Dos and still have the same results.
Calm down, you don't have a virus.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN, rm. 107 C
Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 10 Feb 92 21:59:44 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Michelangelo threat (PC)
padgett%
[email protected] (A. Padgett Peterson) writes:
> With the latest announcement of Michelangelo being distributed on
> BitCom disks packed with modems, it seems apparent that the spread of
> this virus is getting out of hand.
BitCom too? My God, this sounds like a conspiracy... Is there a major
software dealer, who HAS NOT shipped Michelangelo recently? Or maybe
they have decided to cut off the funds for the quality control
departments? Just wondering...
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN, rm. 107 C
Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 10 Feb 92 22:09:28 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Ohio Virus? (PC)
[email protected] (Terry N Reeves) writes:
> Ohio virus is real there are 5 or 6 variations on it at least. It is a
Let's not exaggerate. Ohio is juts one of the Den Zuk variants and the
whole Den Zuk family consists of 4 different viruses.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN, rm. 107 C
Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 10 Feb 92 22:26:01 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: two small comments (PC)
[email protected] (*Hobbit*) writes:
> F-prot 2.02 believes that Central Point's "vsafe" and "vwatch" are
> Flip variants. This may have been stated already on virus-l and I
> think I dimly remember it, but perhaps it should find its way into the
> doc...
Yes, it has been mentioned. But, IMHO, it should find its way into
CPS' software, because it's their problem. Any anti-virus scanning
program -must- encrypt the scan strings it uses, otherwise it risks to
be flagged as infected by other virus scanning software.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN, rm. 107 C
Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 10 Feb 92 22:43:33 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Will re-formatting a floppy remove ALL vires (PC)
[email protected] (Jim Washer) writes:
> I am know the proud and happy owner of an infected 3.5" 1.44Mb floppy.
> Should I immediately burn it in a large bonfire, or will re-formatting
> exorcise it adequately.
Formatting should be enough - if you don't have a virus in memory.
Otherwise you'll destroy everything... except the virus. :-)
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN, rm. 107 C
Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: Tue, 11 Feb 92 19:28:03 +0100
>From:
[email protected]
Subject: New original disks with Michelangelo (PC)
Hello netters,
Our university purchased a ARTEC mouse at a large vendor in Germany
(Computer Schmitt). This mouse is delivered with a black, not writable
5 1/4 " diskette (no hole). On this diskette was Michelangelo (Scan
85).Is there the possibility of a mutation, because it infected an PC
and it seems that this PC never was booted or started with this
diskette in the drive.
RALF
------------------------------
Date: Thu, 13 Feb 92 07:57:28 -0500
>From:
[email protected]
Subject: Re: AUX files (PC)
In VIRUS-L Digest v5i27 Vesselin Bontchev writes:
>... If somebody has DOS 3.3 and FF from version
>4.5 of NU, could you please check and
>confirm or deny this? ...
>
>Regards,
>Vesselin
I am running MS-DOS 3.3 and Norton Utilities 4.50 Advanced Edition. I
haven't been able to duplicate this with FF (FileFind), but quite
similar behaviour is produced by FI (FileInfo), a DIR command
replacement.
I first noticed this about a month ago, but with NUL instead of
with AUX. (Funny how it should come up here so soon after I bumped
into it.) Anyway, I was briefly worried, not about a virus but that
through some strange error in a program I had just completed I had
managed to create a file with the name "NUL" while trying to tell the
program to send its output to the NUL device.
However, examination of the directory with the Norton Utilities
main program, NU, quickly revealed that there was no actual file named
"NUL" in the directory. Running "FI NUL", "FI CON", "FI PRN", etc.,
and especially relevant to this discussion, "FI AUX", will seem to
indicate that there is such a file in the current directory, *whatever
the current drive and directory may be*!
Incidentally, the DIR command of COMMAND.COM doesn't display these
'ghosts' of the device drivers, however I use a command aliaser and
have the "DIR" command mapped to Norton's "FI" program. Perhaps the
worried user does something similar? I don't often remember that I'm
running a program and not executing a built-in command when I type
'DIR', and this has the psychological effect of making the output seem
more 'official' since I think it's being reported by the Operating
System.
In any case, this problem is caused by a bug in either DOS 3.3 or
Norton's FileInfo 4.5, and not by any virus, trojan, or logical error
on the disk, and ought to be in some FAQ list somewhere. It's certainly
no cause for alarm. Since we're so into nomenclature lately, we could
call these 'device driver ghosts' or just 'device ghosts' for short.
Regards,
David R. Conrad
[email protected]
------------------------------
Date: Thu, 13 Feb 92 12:50:48 -0500
>From:
[email protected] (*Hobbit*)
Subject: Intel enters the game (PC)
I haven't seen a reference to this yet, so it might be new info. At
Networld this week I had a brief look at a product Intel is offering
"rsn", which is a network-based virus scanner that runs "continuously"
as well as being able to do one-time scans. It can also scan files
going in and out of the server on the fly as they are opened. Looked
pretty cute. I grilled them about their detection methods; they
claimed to get all their samples and info from NCSA. [Does this mean
that NCSA will send virus samples to "just anybody", or if not, what
are their criteria?]
_H*
------------------------------
Date: Thu, 13 Feb 92 12:24:56 -0500
>From: padgett%
[email protected] (A. Padgett Peterson)
Subject: Floppy boot sectors & viruses (PC)
>From: martin zejma <
[email protected]>
>Subject: unremoveable michelangelo virus (PC)
>In response to
[email protected] (Issue # 19 ) :
lengthy destription of multiple-infection deleted
- ------------------------------
>From: martin zejma <
[email protected]>
>Subject: clean up v85 destroys floppy (PC)
> Due to a slight wonder ( for me) explained by Frisk or Vesselin a while ago
> the floppy is still usable ( cause the Media Descriptor Byte in the bootsct
> is only read under certain conditions which I don't remember ) , but
> I Wonder what happens if I try to boot using this disk ( I expect a message
> from the ROM-BIOS , cause even the 'No bootable disk' message isn't there).
This is the reason I do not bother in the FixFBR program to try to retrieve
the original boot sector. Instead, for any of the four main floppy disk types
360k & 1.2 Mb 5 1/4, 720k & 1.44 Mb 3 1/2, I simply replace the "infected"
boot record with a complete new one consisting of a "generic" table and my
SafeFBR code that checks the integrity of the system and displays a message
if there is a problem. Since the Floppy boot record cannot be trusted, it
is just replaced. If the media type is not there or wrong, the user must
physically examine the disk (software does not have eyes) and select the
appropriate size.
Of course, this is primarily for use on uninfected disks (if you boot from an
infected floppy with the SafeFBR (FREEWARE) code, it will warn you). However,
an infected floppy's integrity cannot be trusted thereafter (after data is
retrieved, reformatting of the floppy is recommended) since if the virus
overwrote part of the FAT, while the virus can be defanged, the corruption is
still there.
This all stems from my basic concept - without hardware it is impossible
to protect a system from an accidental reboot with an infected floppy. 98%
maybe (see NoFBoot, also FREEWARE) but not 100%.
Similarly, you cannot protect (without hardware again) and infected PC from
infecting a floppy. However, IMHO, if you detect the infection immediately
and force the user to eradicate the virus before going further, they are
not going to spread very far. SafeFBR will do this.
Actually, I wrote FixFBR more to provide this kind of protection for floppies.
The fact that it has proven 100% successful in making boot-sector-infected
(e.g. Michelangelo) floppies non-contageous was serendipious (though welcome).
If I ever get the time, my plan is to complete the trio with a program to
replace the hard disk DOS boot record with a similar construct for protection
& active detection of those infections which replace the MBR (e.g. Azusa)
and those which replace the DBR (e.g. MusicBug) from the BIOS level. This
is a bit more complicated since I also intend to include recovery but after
examining the Microsoft DOS 5.0 DBR, IMHO I couldn't do any worse.
Chilly (fog still there @ 11 am)
Padgett
<padgett%
[email protected]>
Usual Disclaimers...
------------------------------
Date: Thu, 13 Feb 92 14:03:24 -0600
>From: THE GAR <
[email protected]>
Subject: Network World 10FEB92 (PC)
An article in this week's Network World reported on a test by the
National Computer Security Association which rated 19 virus scanning
products on their ability to detect viruses, and how many additional
detection features they had. It did not say what those additional
features were. Please note that many of the below products have been
updated since the versions below.
Here are some excerpts, which I take from their graphic. The address
of the NCSA follows if you would like the full report. Or you could
call Network World at (800) 622-1108. The article was by Salvatore
Salamone, and the graphic I refer to below was by Susan Slater.
Top 5
Features
76 points possible
- ------------------
69 Dr. Solomon's ToolKit FindVirus V3.2
68 Certus International Corp.'s NOVI V1.0
64 Fridrik Skulason's F-Prot V2.0
63 Lerechaun Software Internationsl, Ltd's Virus Buster Doctor V3.75.0
61 XTree Co.'s ViruSafe LAN V4.50
Top 5
Detection
77 Points Possible
- ------------------
76 McAfee Associates Scan V7a9V84
75 Central Point Software, Inc.'s Anti-Virus V1.1
75 Leprechaun Software International's Virus Buster Doctor V3.75.0
75 RG Software Systems, Inc.'s Vi-Spy V7.0
74 Fridrik Skulason's F-Prot V2.0
The above data was in a graphic labelled Virus Scanner Scorecard which
said at the bottom: "The NCSA rated virus scanner programs both on the
product's ability to detect viruses and features that help net managers
find virus infections."
Hope this is useful to someone,.
Later
Gary Warner
Disclaimer: The above data in no way reflects my personal opinion.
I am merely passing on information that I thought might be useful to
some of you. If you would like the full report of the NCSA's findings
send $75 to:
NCSA
227 W. Main St.
Mechanicsburg, PA 17055
(717) 258-1816
------------------------------
Date: Thu, 13 Feb 92 12:38:49 -0800
>From: Richard W. Lefkon <
[email protected]>
Subject: Non-inanimate Michelangelo (PC)
Here is a several-words statement whihch, each time I mention it, the
listener generally says, "probably true."
It is aimed at product vendors, many of whom are recipients of virus-L
or friends of those who are:
IT IS STATISTICALLY IMPROBABLE THAT THE THREE OR MORE SHRINK-WRAPPED
BROADCASTS OF MICHELANGELO COULD HAVE COME ABOUT WITHOUT EXPLICIT
HUMAN INTERVENTION - PERHAPS BY DISGRUNTLED INSIDERS AT THE SOURCE
COMPANIES. IT'S NOT OUTLANDISH TO CONSIDER THE POSSIBILITY THANT
TWO OR MORE OF THESE INDIVIDUALS HAVE BEEN IN TOUCH WITH ONE ANOTHER.
Very few Virus-L readers would want to see more instances of the
statistically unlikely avoidance of successful companies' quality
control procedures by the Michelangelo Virus.
If you would like, please pass this along to someone who might want
to be reminded about enforcing all points of their quality control
process over the next few weeks. This one isn't "you are stoned,
or "your computer wears army boots," and it could matter.
Thanks,
- -dick
P.S. This statement isn't the official position of an y university,
comp[nany or professional group I may be associated with.
------------------------------
Date: Thu, 13 Feb 92 16:00:42 -0600
>From:
[email protected] (John Boyd;LAHDI)
Subject: Re: AUX files (PC)
In your message of 13 Feb 1992 at 1548 CST, you write:
>
> Date: Fri, 07 Feb 92 05:52:49 -0600
> >From:
[email protected] (Terrence R. Redding)
> Subject: Re: AUX files (PC)
>
> Reference the AUX file in every directory. Check the date each file
> was created. It may simply be a reflection of the way the software
> was installed on the HD. If each software package was installed as if
> it was the only software on the drive then a separate AUX file might
> result.
>
> - ---
> DOMAIN:
[email protected] (Terrence R. Redding)
> UUCP: ...!rwsys!lawton!terry (Terrence R. Redding)
> Good News II BBS Lawton, OK USA +1 (405) 357-0478
>
One other bit of weirdness I'd like to inject here. At home I have an
ATT 6300 PC, it's an XT compatible, running ATT's MSDOS 4.01, and NDOS
6.01. Just for the halibut after you guys started talking about this,
I typed
dir aux /s
or something like that in my root directory, and lo and behold, in
every directory it showed an 'aux' file that, if you went to any
single directory and issued a dir, would not show. This same behavior
was exhibited with the 'filenames' lpt, con, etc. BUT, I tried it on
my Zenith Z-248 @work, running MSDOS 3.2, and it chokes (of course!).
I don't understand it either, and wouldn't have tried it if I hadn't
read the discourse. Just when you think you've seen everything.....
B-{).
------------------------------
Date: Thu, 13 Feb 92 20:58:19 +0000
>From:
[email protected] ( Richard Pavelle)
Subject: WDEF infection at a school (Mac)
My 4th grader uses one of ten Macs at her school and often when she
brings home her floppies they are infected with WDEF A. The Macs do
not have hard drives and I checked to verify that all startup disks
are indeed infected. Is there a small program I can install on each
startup (after I have disinfected them) to keep this virus off? Or is
there a better way to deal with this problem? Thanks.
------------------------------
Date: 10 Feb 92 20:21:20 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Cohen's error
[email protected] (Y. Radai) writes:
> Vesselin Bontchev has demonstrated an error in Cohen's original
> proof of undecidability of whether a given program is a virus, based
> on a two-sentence remark in a paper by Steinparz. Since Vesselin has
> not quoted that remark, I have no idea what Steinparz's paper itself
I'll show you a copy of the paper the next time we meet personally.
Since it is a pre-release version, I felt somewhat unetical to quote
the whole thing publicly.
> main program executed from the command line. Yet, at least in Vesse-
> lin's schema, D is an *internal* procedure *embedded within* P.
> This seems rather unnatural to me, but, as David Chess has pointed out
> in personal correspondence, this is necessary for Cohen's proof to
> work; otherwise, if S1 is the operating system in which programs which
> are to be checked for viruses are run, then D might be written so as
> to run in some other system S2. The programs would be transferred to
> S2 for checking, where they would be unable to call D.
> David also points out that even in the same system, such a D could
> be stored encrypted so that it could be run only if a certain password
> is entered. Not knowing the password, no virus or program such as P
> could execute D, so Cohen's proof wouldn't go through.
Well, to be honest, I have't thought about this possibility at all...
:-)
> Aside from its much greater conceptual simplicity, this proof has at
> least two advantages over Cohen's: (1) It applies just as much when D
Well, the greater simplicity is arguable; I guess that Cohen has been
charmed by the elegant way to reduce the virus problem to the halting
problem (or more exactly, by the elegantness of the proof for the
halting problem, so he tried to apply the same method)...
> is an independent main program as when it is an embedded function
> (without failing because D is run on a different system or requires a
> password); (2) it applies just as much to real computers as to Turing
> machines.
Especially (2) is extremely useful from the practical point of
view...
> More precisely, if intelligent beings exist arbitrarily long, they can
> supply programs of arbitrary length, and even though memory in a real
> computer is finite, any such program can be continually read into
> memory as a series of overlays.
Wait a minute; there is still something that I do not understand. The
computer has a finite amount of memory. Any program (or overlay) is a
particular configuration of states of the memory cells. However, since
the total amount of memory cells is finite, then the total amount of
permutations of the states of these cells (which represents the total
amount of possible programs/overlays) must be also finite. Therefore,
the total amount of possible programs is finite for the real
computers. Or do you consider the two-times load of one and the same
program to be some kind of super-program, which is loading its two
overlays?
> >The second kind of infinity is e.g. a class, which has an infinite
> >number of elements, but for which you have a determined rule or set of
> >rules how to obtain the next element. A typical example is the class of
> >natural numbers. There is infinite number of natural numbers, but you
> >can always obtain the next element. It seems that the computer with
> >finite munber of memory cells, combined with a civilization, which
> >produces programs is an infinite computer of this class.
> >
> >And, at last, there is the infinity in the mathematical sense.
> I don't understand the distinction you are making between these two
> kinds. Are you saying that the second kind *isn't* infinity in the
> mathematical sense? Perhaps the difference between your second and
No, I wasn't saying that the second kind of infinity is not infinity
in the mathematical sense. I wasn't clear enough, I must admit. But I
- -do- make a difference between the two kinds of infinity, because the
second kind provides a compact way to express all its members (via the
generation rule), while the third kind is a more general one.
> third kinds consists in distinguishing between denumerable and
> non-denumerable infinities, or between cardinal and ordinal numbers,
No, numerability was not what I meant... Maybe the difference between
the cardinal and ordinal numbers, yes...
> but the second kind is certainly a mathematical one.
Certainly; I agree with that.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN, rm. 107 C
Tel.:+49-40-54715-224, Fax: -226 Vogt-Koelln-Strasse 30, D-2000, Hamburg 54
------------------------------
End of VIRUS-L Digest [Volume 5 Issue 32]
*****************************************
Downloaded From P-80 International Information Systems 304-744-2253
