VIRUS-L Digest Tuesday, 29 Oct 1991 Volume 4 : Issue 202
Today's Topics:
Harry Anto (PC)
New virus reported by John McAfee (PC)
When is VSHIELD scanning the bootsector? (PC)
Re: New virus-advanced syphtoms ( WAS: warning new virus (PC))
_Network_World_ Review of Virus Packages (PC)
Stinkfoot query (PC)
Forget Domani, er Turing
RE:Bloomington (NoInt,Stoned III) Virus? ? ? (PC)
Re: Interpreted things
Re: New virus - advanced symptoms (PC)
Re: Several subjects (PC)
Re: DIR II Removal Information (PC)
Re: DIR II virus and DOS 3.31 (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. 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: Mon, 28 Oct 91 10:03:23 +0000
>From:
[email protected] (-= WAD =-)
Subject: Harry Anto (PC)
I think we ( A friend and I ) have found a new virus for PC !!!!
The message it gives is as follows >
WEllcOmE tO hArYAntO's vIrUs V4.5. (c) 1990 by hAryWAre IntErnAtiOnAl Tm
I locks the machine (Vig III SL) the then on hard reboot it seems
somehow to disable the keyboard, thus giving an error at the self
test stage of the PC. This happened about five time and then, on
the next reboot I gave us a System Gateway Error. Thus the machine
was shut down and still is.
Please is there anyone there who nows of a cure to this virus. If
so please mail me.
Cheers
PS A copy is on its way to mcafee.
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
| Fleshy : -= WAD =- E-mail : csh060%
[email protected] |
| Voice : (0203) 449274 Quote : Sitting in the morning sun |
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
------------------------------
Date: Mon, 28 Oct 91 13:35:48 +0300
>From:
[email protected] (Eldar A. Musaev)
Subject: New virus reported by John McAfee (PC)
The virus very similar to reported by John McAfee have been detected
4-5 weeks ago in Soviet Union, Russia, St.Petersburg in International
Mathematical Institute. There were no contacts with Eastern Europe for
at least 2-3 months, only with Finland. There is no details for a
while.
Eldar A. Musaev Mathematical Institute, St.Peterburg, Russia
[email protected] 191 011 USSR St.Petersburg Fontanka 27 LOMI AN USSR
------------------------------
Date: Mon, 28 Oct 91 15:21:00 +0200
>From: Bjarne Hxgh Nielsen <
[email protected]>
Subject: When is VSHIELD scanning the bootsector? (PC)
Last night McAfee`s VSHIELD caught the FORM while it was trying
to sneak onto some of my floppies. Here`s three cheers for infec-
tion preventing programmes.
But the circumstances were rather strange. The floppy, on which
the virus were detected had been in use earlier on the same evening,
without any warning from VSHIELD. Knowning that FORM is a BSI, I
now wonder what made the alarm go off the second time (no reboots,
only reads (dir & copy)).
What took place the first time was a CD to a subdir and the
execution af a utility. The second time, I attempted a dir of
the root and suddenly found that VSHIELD was talking to me. Is
it, that a read of the bootsector is only nessesary, when
investigating the root dir?
BJARNE HOEGH NIELSEN
Student programmer
The Aarhus School of Business Administration, Aarhus, Denmark
E-Mail:
[email protected]
------------------------------
Date: Mon, 28 Oct 91 15:37:05 +0300
>From:
[email protected] (Shulman Ilya A.)
Subject: Re: New virus-advanced syphtoms ( WAS: warning new virus (PC))
[email protected](Vesselin Bontchev) writes:
>
[email protected] (Shulman Ilya A.) writes:
>> No, I mean that it is very simple to identificate is virus present
>> when it is active :-)
>What symptoms did you have in mind exactly? This one is pretty
>stealthy...
What do you mean "stealthy"? There are few symphtoms that can help us to
identify it while it is active. I donno does these symphtoms appears as
the result of errors in virus or not but they are reality.
1 --- Try to delete all files at the write protected disk. You don't get
any error if virus is active.
2 --- As I have already explain, start up NU or DiskEdit and compare last
(or prelast) not BAD cluster. If you found the mismatch then virus is
present with more or less possibily.
But anyway I think that the first step is the main symphtom. I had
observe only one strange thing. For instance while in the NC I delete
all files from the write protected diskette. (Not 3.5). Nothing
happenes. But if I try to do this from the 3.5 1.44 disk I'll get
garbage on this panel.I can't explain this but it has been so.
>I don't know, but I definitively have seen disks with the virus body
>marked as used in both copies of the FAT. Maybe it happens when DOS
>updates the same sector of FAT, where the virus mark resides?
I think that this may happens only if you had the file in the ended in
the last cluster before infection. Then virus update only the the
first copy in FAT and you'll have the EOF mark in the second. For
instance such files as the frecover placed in the last clusters. Any
way I haven't check this situation.
>> Yep. Two times I found virus on the hard disk in the cluster 714 and
>> 2371 (I can't remember this numbers exactly but) which are the last
>> clusters on the 5" 1.2Mb and 3.5" 730Kb diskettes respectivly. I can't
>> explain why there were the last clusters but not the pre-last but it
>> was so. Also I know the other abnormal effects when virus infects disk
>> but didn't write itself to the last cluster. May be it is an error
>> too, but anti-virus developers _HAVE TO_ know this.
>Maybe this referes to the COMPAQ DOS 3.31 situation that was described
>by Dimitri Gryaznov?
Pity (:-)), but there was dos 3.30 on the first machine and dos 4.0 on the
second. I tried to make virus to do it again modeling some situation but
I can't. Anyway it is not my dreams.
>Yes, the algorithm is: start from the last cluster of the disk; if it
>is marked as bad, move to the previous one; when you find a non-bad
>cluster, move one more cluster backwards if it is a high-capacity
>diskette (or, more exactly, if the cluster size is < 2 sectors).
As to me, I think that this algoritm is incorrect because of lot of possible
situations.
To my mind the most usefull algoritm is:
1 Check any directory as the one directory on disk. But not kill virus in it's
cluster location while not searching up to the end of the disk.
1.a Check all COM and EXE files (not SubDir Vol) due to it's crosslinked.
if found then get magic number and cure them and save virus cluster no.
if virus not found in the last cluster the you antivirus must
be able to analytically restore start cluster.
there is thefew ways to do it, I think.
if not found check all files due to the virus body. If found the
think yourself what to do. As to me, I was very angry when some
ANTI-DIR killed all virus bodies stored on my HD as a files
during checking, without any Q.
Process step 1 up to the end of the Sudirectries.
2. At this step you cure all files and have the virus cluster no. No it's
time to kill it.
Step 2 is required for one simple propose. As to me, I think that there
may be the situation when more then 2 copy of virus are at the one disk.
Oh,Oh. I can predict your feelings and answers to the previous sentence.
Take it easy.
As I previously explained, I had observe two situations when virus was
placed not in the last cluster(and not even in pre last). So I can imagine
that it is possible to infect disk two times with the to copies of virus.
Regards.
- --
/-----------------------------------|---------------------------------------\
| Ilya A. Shulman. | E-Mail:
[email protected] |
| Institute of Radio Engineering | :
[email protected] |
| & Electronics ACAD.Sci. of USSR. | phone :(7-095)203-17-16 |
------------------------------
Date: Mon, 28 Oct 91 09:21:00 -0700
>From: "Rich Travsky 3668 (307) 766-3663/3668" <
[email protected]>
Subject: _Network_World_ Review of Virus Packages (PC)
The October 21st _Network_World_ (volume 8 number 42) had another
review of virus detection/removal packages. This one was done with the
National Computer Security Association (NCSA). Eleven packages were
tested: Central Point's "Antivirus"; Computer Consulting Group's
"Virus Clean V2.10 Release A"; S&S International's "Dr. Solomon's
Toolkit V5.15"; Leprechaun Software International's "Virus Buster
V3.75"; McAfee Associate's "Scan V7.6/Clean V80" and "Pro-Scan V2.32";
Microcom Inc.'s "Virex-PC V2.00b"; Symantec's "Norton Anti-Virus
V1.5"; Fridrik Skulason's "F-Prot V2.0"; and Xtree's "ViruSafe V4.50".
The tests were designed by David Stang, director of research at NCSA.
Each package was tested against eighteen "common" and eighteen
"exotic" file viruses, and four "common" and three "exotic" boot
sector viruses (too few in my otherwise unqualified opinion). Points
were given for various categories with a total of 142 being possible.
Top scoring packages: 1. F. Skulason's "F-Prot" with a total score of
129; 2. Leprechaun Software's "Virus Buster" with a score of 116; 3.
(a tie) S&S International's "Dr. Solomon's Toolkit" and Microcom's
"Virex-PC" with scores of 103; 4. McAfee's "Scan/Clean" with a score
of 102. No other package scored over a hundred.
F-Prot was billed as being a "strong performer in almost all the
tests" and being a best buy at a dollar per license. A lack of a
domestic outlet other than bulletin boards was cited as a drawback.
Disclaimer:
See the article for full details. Don't flame me, complain to me, ask for
the full text etc. I didn't write the article nor am I distributing it.
Otherwise constructive comments, however, are still welcome. Thank you!
+-----------------+ Richard Travsky
| | Division of Information Technology
| | University of Wyoming
| |
| | RTRAVSKY @ CORRAL.UWYO.EDU
| U W | (307) 766 - 3663 / 3668
| * | "Wyoming is the capital of Denver." - a tourist
+-----------------+ "One of those square states." - another tourist
Home state of Dick Cheney, Secretary of Defense of these here UNITED STATES!
------------------------------
Date: 28 Oct 91 17:44:18 +0000
>From:
[email protected] (Tim Bouwer)
Subject: Stinkfoot query (PC)
Hi
A bug of sorts made its appearance at our campus today.
It was found in a few .COM files and some dissasembly reveals a message
that decodes to something like "Stinkwook has come to your PC".
The code is peppered with int21 calls and it appears that the program
looks for another .com file on the disk and infects it - increasing the
size of the file by a few kilobytes. The program doesn't appear to go
resident and at first glance strikes me as a rather poor example. I
think the intention is to slowly work its way through infecting .com
files ad infinitum. I have not inspected floppy boot sector code
changes or anything like that yet.
Before going off and wasting a lot of time on it, I thought I should
check to see whether this is local screwing around. Does such a virus
have any roots elsewhere? Any other people come across this signature
or similar?
Any feedback would be appreciated.
Tim
- --
| Tim Bouwer Computing Centre Tel: 27 [0]461 22023 ext 288 |
| Rhodes University Grahamstown FAX: 27 [0]461 25049 |
| 6140 South Africa Internet:
[email protected]|
- -----------------------------------------------------------------------
------------------------------
Date: Mon, 28 Oct 91 15:30:04 -0500
>From: padgett%
[email protected] (A. Padgett Peterson)
Subject: Forget Domani, er Turing
This is an interesting theoretical conversation which seems to be
valid only for a machine having only a single level of functionality
and which fails once multiple or reduced functionalities are
considered.
Consider a typical multi-user mainframe. Given the Turing/Cohen
arguments, it would be impossible to protect user A from the actions
of user B. Consider also "Orange book" compartmented (B2) access. This
would also be demonstratively impossible yet we have been doing both
for years. Paradoxical ? Not really once you consider that in both
cases while the total functionality of the machine is preserved, that
total functionality is not made available to the
users/programs/viruses.
Consider also that there are more similarities between the user on a
mainframe and a virus in a PC than are readily apparent. Both lack
physical access to the system and must limit themselves to electronic
access. Both must work with the system as they encounter it and can
have no influence on its development.
The simple fact is that the later in a start-up cycle a program
receives control, the less control it can take. Consider COMMAND.COM:
prior to invocation of COMMAND.COM, the computer will execute any
program passed to it as the "shell". Once COMMAND.COM is loaded,
programs must conform to its more stringent requirements or control
will not be passed to them. Add Windows (tm) and the header
requirements become yet more restrictive.
Similarly, the mainframe O/S has control of an entire system while
only part of that authority is routinely passed to applications and
violations are both detected and denied. Provision is also made for
reporting, all in software.
The key is in progressively reducing functionality and keeping only
those attributes which are necessary for accomplishing the work.
Properly done, the action is invisible to the user (of course
improperly done they can be quite annoying - why I always run under a
proposed shell for quite a while before releasing it to my user
population).
This does not have to be onerous, merely procedural. NoFBoot is
invisible unless an exception is detected and I was careful to limit
its trapping to a specific sequence.
As PCs gain the power of a mainframe (and will probably replace the
mainframe for interactive use), adoptation of the same techniques that
protect mainframes from "accidents" seems logical, all the tools are
already there (and usually free), it is just a matter of using them.
Padgett
------------------------------
Date: Mon, 28 Oct 91 15:43:00 -0500
>From: <
[email protected]>
Subject: RE:Bloomington (NoInt,Stoned III) Virus? ? ? (PC)
Frank:
Was able to dig up some basic info on the NoInt. It originated in
1991, and infects the master boot records of hard disks and boot
records of floppies. It does become resident in memory. That's all
the info I was able to find....hope it helps...
Charles
**********************************************************
Rutstein@HWS (Bitnet)g release
**********************************************************
------------------------------
Date: Tue, 29 Oct 91 15:25:00 +1300
>From: "Mark Aitchison, U of Canty; Physics" <
[email protected]>
Subject: Re: Interpreted things
[email protected] (David.M.Chess) writes:
> .... Most widespread viruses are not stealthed, most
> stealthed viruses are not widespread...
while that's probably right, how can we be sure that some stealthy
virus isn't very very common, but just undetected at the moment?
Estimates of the frequency of viruses rely on a statistically small,
biased sample of PC users, running virus detection software largely
keyed to reporting already-known viruses. It is possible, for
instance, that there is some well-hidden virus that has been spreading
for years, but hasn't done anything noticeable yet. Of course, this
isn't very likely, but there are good ways of obtaining statistically
significant checks of viral activity (using hardware, and randomly
selected computers) that, as far as I know, aren't being used.
Understandable, of course, since anyone concerned about viruses will
probably put the effort into stopping them, rather than counting them
& letting them continue, but the whole idea of what viruses there are
in what quantity, and measurements of how they spread seem to take a
back seat.
Mark Aitchison, University of Canterbury.
------------------------------
Date: 29 Oct 91 10:48:22 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: New virus - advanced symptoms (PC)
[email protected] (Dmitry O. Gryaznov) writes:
> >> No, I mean that it is very simple to identificate is virus present
> >> when it is active :-)
> >
> >What symptoms did you have in mind exactly? This one is pretty
> >stealthy...
> Insert write protected diskette into drive A: and try to delete a
> file from it - DOS won't report "Write protect" error.
Oh, I see... Indeed. I didn't thought about that, since it's
completely unreliable on most Bulgarian ("Pravetz") IBM clones. Due to
a hardware design bug, their floppy disk controllers do not return
write-protect error at all (!) and most people in our country are used
to that. If you try to delete a file on a write-protected floppy,
on a computer that has this kind of controller, the deletion might
even seem successful - if you do a DIR the file might seem to have
gone. This is because DOS keeps some info in its buffers and tries to
be particularly clever and not to update it all the time... Of course,
if you run CHKDSK (which flushes the buffers), you'll see that the
"deleted" file is still there. (Disclaimer: I haven't tested this with
file deletion. I -have-, however, tested it with file creation and it
works perfectly - the file seems to be present on the floppy.)
> The situation described by me refers only to hard disk partitions
> larger than 32Mb. I've also observed two strange situations with
> floppies. In first case on a 5.25" 720Kb (formatted using software
> similar to 800.COM) floppy all executable files were cross-linked to
> the proper clusters (two-clusters chain, the last being marked as
> 0FFEH) but those did *NOT* contain the virus. In second case a normal
> 360Kb floppy was infected properly but it wasn't possible to restore
> affected files since their real start clusters (being decrypted) were
> also cross-linked to the cluster appropriate for 720Kb floppy.
Hmm, this is a tough one.... I really have no insight what might have
caused these two cases... Maybe DOS itself? It is well known that it
sometimes screws up a disk, without any external help, let alone with
a virus lurking in memory... Otherwise it wouldn't be supplied with
CHKDSK... :-)
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 29 Oct 91 11:00:52 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Several subjects (PC)
[email protected] (Dmitry O. Gryaznov) writes:
> My latest acquisition is somewhat like 100 new viruses most of them
> being Soviet... New Soviet threat, eh?
I'm afraid, yes... I predicted something similar to happen about an
year ago, when I saw the level of the Soviet virus writing at the Kiev
conference. It's only strange that it took almost a whole year...
Can you tell us the names of these 100 viruses, so we can try to get a
bit oriented when large collections of them begin to appear? Thanks.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 29 Oct 91 09:47:45 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: DIR II Removal Information (PC)
[email protected] (Dmitry O. Gryaznov) writes:
> MY disinfectant does the same... But did you ever try to disinfect
> files after deactivating the virus in RAM without rebooting? The DOS
Sure, I do this all the time... :-) Most of my users too...
> will report an error when infected files on a hard disk will be
> accessed. The reason is that DOS continues to use an in-memory copy
> of BPB (or DPB following your terminology) modified by the virus. This
> BPB reports several blocks less than the actual size of a disk is.
> Hence, the last cluster (to where all infected files are cross-linked)
> will seem to be (partially) beyond the disk space. Since a hard disk
> is non-changable media, DOS normally asks driver to build the BPB only
Yes, of course, I know all this. But it won't happen if the
disinfector deactivates the virus -properly-. :-)
> once and then uses this BPB parameters. To force DOS to rebuild BPB
> you are to use the same trick the virus does - find an appropriate DOS
> Device Control Block and mark it as never been accessed.
Right. Exactly what I do.
> >Yeah, that's what I mean... My disinfector does not delete such files.
> >Maybe it should?
> Definitely *YES*! Such a file is just the virus itself - safe and
OK, will fix it in the next version of the disinfector. Maybe a
supplimentary option for such kind of action, I'll see.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 29 Oct 91 09:55:50 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: DIR II virus and DOS 3.31 (PC)
[email protected] (Dmitry O. Gryaznov) writes:
> >information in this case, but it will report that a mutation of the
> >virus has been found. It is not very clear how this situation could be
> I don't know the method your disinfectant uses to detect the DIR II
> virus but I doubt it'll report an infection in the case. The affected
> (not really *INFECTED*) files are cross-linked to the cluster which
> DOES NOT contain the virus body. Or does you disinfectant rely just
> on (F)FFEH mark?
On both! :-) More exactly, if checks for either the first few bytes of
the virus in the last non-bad cluster (after the virus has been
deactivated, of course), and for a mark in the last FAT entry, that is
between 0(F)FF9h and 0(F)FFEh. If either of them is found, I read the
two first sectors, starting from the last non-bad cluster, zero out
the variable fields, and compute a checksum on the whole 1024 bytes.
If it does not match, I complain about a mutation. Might give both
false positives and false negatives (if somebody modifies the virus
well enough), but hasn's yet and works pretty good - has discovered
already two variants of the virus in Bulgaria... :-)
> Rather simple - read sectors 0FFFFH-10000H and check whether they
> contain the virus body or not. If yes - compare the cluster number
> from the virus body with this from the directory entry, etc.
Not as simple as that, since my program follows the sectors that
belong to the directories, not all sectors of the disk... :-) But I
guess that reading two additional sectors in the special case when the
disk is large enough and check them too is pretty easy and elegant as
a solution... Thank you for pointing it out.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 202]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
