VIRUS-L Digest Thursday, 10 Oct 1991 Volume 4 : Issue 187
Today's Topics:
re: DIR II removal (PC)
Re: Hardware
Re: DIR II (Cluster) Virus (PC)
Re: HW not a virus solution
Need help with Empire virus (PC)
Re: VIRUS-L Digest V4 #185
New virus - advanced symptoms (WAS: New virus warning (PC))
Re: DIR II (Cluster) Virus (PC)
Viruses and OS/2 (OS/2)
Stoned on 3.5" disks / "1590" virus (PC)
disable ctrl/break? (PC)
False Alarm (PC)
Hardware and Software; Re: Forget Turing...
Re: Forget Turing...
Psychology of virus writing (was HW not a virus solution)
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: Wed, 09 Oct 91 13:16:36 +0700
>From: Andrzej Kadlof <
[email protected]>
Subject: re: DIR II removal (PC)
Joe Wells <0004886415 at mcimail.com> writes:
>A disinfector should be written only by a qualifid (preferable asm)
>programmer and tested extensively.
This particular virus is extremaly easy to remove. It may be done
very quickly by any non qualified person in the following way:
1. Rename all executable COM and EXE file to something else (CCO and
EXX).
2. Reset computer from clean disk.
3. Run CHKDSK /F
4. Rename all CCO and EXX back to COM and EXE..
step 3 is necessary only if you want back two sectors occupied by
virus. DIR II will do the rest for you. But remember, above work only
with DIR II.
Regards,
Andrzej Kadlof
Department of Mathematics, University of Warsaw, Poland
Editor-in-chief of PCvirus bulletin
KADLOF AT PLEARN.BITNET
------------------------------
Date: 09 Oct 91 12:30:59 +0000
>From:
[email protected] (Henk de Groot)
Subject: Re: Hardware
[email protected] (Fred Waller) writes:
[Description of his super virus-resistant computersystem]
All Fred (Waller) makes clear is that he allows infected programs on
his hard disk (infecting his machine) but that the infection can not
spread due to the hardware-write protection.
He forgets that some data-files are also program files (not for the
cpu but for a program on the program-disk) and a virus written in the
interpreted language can infect all the other "data" files of this
interpreter.
Fred said he uses his spreadsheed whitout worrying, but if I write a
virus in his spread-sheed language and put it on his machine, than
after usgage all his spread-sheeds are infected. If it is a
distructive virus than I may distroy all his spreadsheeds on friday
the 13th.
Right, the speadsheed program itself is still clean, but still he lost
all his files on this "virus-resistant" computer-system!
Henk.
- --
/ / Henk de Groot | Department: PG 9000i - System Services
/---/ __ __ / V2/A12-A13 | Internet :
[email protected]
/ / (-_ / / /( Tel: +31 55 432099 | == PHILIPS INFORMATION SYSTEMS ==
Disclaimer: I only speak for myself, not for my employer!
------------------------------
Date: Wed, 09 Oct 91 12:08:45 +0300
>From:
[email protected] (Dmitry O. Gryaznov)
Subject: Re: DIR II (Cluster) Virus (PC)
In VIRUS-L vol.4 iss. 180
[email protected]
(Vesselin Bontchev) writes:
>with the FAT and to run Norton Disk Doctor. One more thing - the virus
>body is marked as 0(F)FFEh in the FAT. This is interpretted as EOF by
>DOS. In fact, DOS interptrets as EOF any value from 0(F)FF8h to
>0(F)FFFh, but uses only the last one. The virus does not check whether
>a disk is already infected (i.e., that the virus body is already
>present on the disk), so this marker cannot be used to "vaccinate" the
>disks.
And in VIRUS-L vol.4 iss. 183 :
>hex representation of the EOF mark in the FAT is 0(F)FFEh (means
>virus), or 0(F)FFFh (means normal EOF). Anyway, the virus does not use
>this strange mark for self-recognition, so IMHO the strange value is
>a bug un the virus code.
No, it is *NOT* a bug. The virus *DOES* check whether a disk is
already infected. In this case it neither updates FAT nor writes
itself to a disk. It is true, nevertheless, that such a mark ((F)FFEH)
cannot be used to "vaccinate" a disk. Such a "vaccinating" will cause
additional problems - the virus won't infect a disk BUT IT STILL WILL
crosslink all executables to the cluster. And since there will be no
the virus body on a disk - there will be much more difficult to detect
an infection and to repair files. COMMAND.COM being cross-linked to a
"vaccine" cluster without the virus body will be just corrupt as well
as other executables.
>in use or not. Therefore, it can destroy part of a file (or directory)
>which uses this cluster. Since the virus body is written on any
>accessed disk, regardless whether the latter contains executable
>files, the destruction of information described above occurs most
>often on backup diskettes or diskettes that contain only one large
>archive file, or that are otherwise full up to the last cluster. Since
>the DOS program BACKUP tends to write its control information in a
>small files -after- the backup, such destruction will damage the whole
>backup on the diskette.
One more tip to detect an infection. Suppose you have a disk similar
to described above. It mustn't be exactly BACKUP disk - it's enough to
have a file occupying the last cluster. Now suppose this disk is write
protected. Thanks to [cf. Fred Waller] "a simple hardware device
called a write-protect tab" (grin) the virus won't infect a disk.
Neither it will overwrite the file. But this file (using the last
cluster) becomes unaccessible - DOS will report "File allocation
error" while reading such a file. The reason is that the virus
decreases the actual disk size and, hence, DOS believes the last
cluster to be beyond the disk. It is not just an assumption - I've
tested this. Oh, yeah, as was already mentioned by others, DOS won't
report "Write protect error" due to the virus.
In the previous message on the same subject I wrote the virus tries to
open a file in the *ROOT* directory on C: not in the *CURRENT*. I
appologize. It really uses *CURRENT* directory. But the virus still
tries to *OPEN* not to *EXECUTE* this file.
- --
Sincerely,
Dmitry O. Gryaznov | PSI AS USSR
[email protected] or
[email protected] | Pereslavl-Zalessky
Phones: office: (08535)-2-0715 home:(08535)-2-1465| 152140 USSR
------------------------------
Date: 09 Oct 91 13:03:05 +0000
>From:
[email protected] (John E. Kabat Jr.)
Subject: Re: HW not a virus solution
The Name of the book is
The Shockwave Rider
by John Brunner
John E. Kabat Jr. <|> ...!uunet!telxon!teleng!johnk
Telxon Corporation <|>
P.O. BOX 5582 <|> 1-800-800-8001 x 3554
Akron, OH 44334-0582 <|>
------------------------------
Date: Tue, 08 Oct 91 17:07:16 +0000
>From:
[email protected] (Kees denHartigh)
Subject: Need help with Empire virus (PC)
I have been attacked by the Empire virus. Both fprot and scan detected
the virus in the boot sector of both my hard drives. fprot was unable
to remove the virus for the boot sector but clean82 reported successfully
removing it. The problems the Empire virus originally caused seems to have
dissappeared however fprot200 still reports the virus in the boot sector
of both drives. I backed up my D drive insuring that I the virus was not
infecting any backed up files and reformatted the drive and restored and
still fprot200 reports the Empire in the boot sector of the reformatted
drive. Is it really there or fprot200 lying to me. Scan82 detects no viruses
after clean82. Does anyone have any ideas?
- --
Kees denHartigh
[email protected]
Electrical Engineering Digital Labs alberta!bode!kees
University of Alberta 238 Civil Elect Voice (403)492-5421
Edmonton, Alberta Canada Fax (403)492-1811
------------------------------
Date: Wed, 09 Oct 91 13:14:34 -0400
>From:
[email protected]
Subject: Re: VIRUS-L Digest V4 #185
Jay Skeer:
In your posting about the book with the phone network worm, I
think you were refering to the S.F. book "The Adolescence of P1". I
have also read this work and found it quite interesting. I would
recommend it to others with hig regard not only for its storyline, but
also its insight for the time period it was written in.
If anyone has a problem finding the book, I might consider
parting with mine via mail - but please convince me that I will get it
back ASAP.
Happy hunting....
Chris
------------------------------
Date: Wed, 09 Oct 91 17:49:17 +0300
>From:
[email protected] (Shulman Ilya A.)
Subject: New virus - advanced symptoms (WAS: New virus warning (PC))
Vesselin Bontchev writes:
>> >The virus is also a stealth virus. While it is active in memory
>> >it is difficult to detect.
>> ^^^^^^^^^^^^^^^^^^^^ actual size of the disk :-) but
>You probably mean that if you know the exact full size of your disk,
>you'll notice when it changes. However, I don't think that many users
>will notice even when the size of 360 Kb diskette gets changed from
>354 to 353 Kb, let alone the larger media... :-)
No, I mean that it is very simple to identificate is virus present
when it is active :-)
>> 2 check last cluster in the 1 and 2nd copies of FAT if in first you found
>> EOF but in second not than it may be thesignal that those virus is hear.
>Sometimes DOS updates the second copy of the FAT itself, so this
>method is unreliable. I have observed several cases in which the EOF
>mark was present in both copies of the FAT. Better check whether the
Are you sure that "Sometimes Dos updates" all copies of the FAT up to
the end? When it happens? How I can initiate Dos to do it? I observed
this virus on the few computers and the difference in FAT was on each
of them. Two computers worked with this virus in memory nearly 1-1.5
month and users didn't know about it. To my mind the difference in
FAT is a stable symptom but not only _ONE_.
>Anyway, the virus does not use
>this strange mark for self-recognition, so IMHO the strange value is
>a bug un the virus code.
Anyway is it error or not, we can count it as one of the virus's
appearence.
>The virus has been named in SU ( as far as it appeared here in early
>summer) as DRIVER-1024 (due to scheme of infection) or DIR but not
>DIR-2
>...and if the file attributes for this entry do not indicate System,
>Directory, or VolumeLabel.
Naturally. Thanks.
>> 2 There were the situation when disk was infected and virus occypies not
>> the last cluster and not even near. That is why I think that there may
>> be situation when 2 or more copies of virus may be present on one disk
>Have you really observed such situation?! It shouldn't be possible,
>according to the virus code...
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.
Best Wishes.
- --
/-----------------------------------|---------------------------------------\
| 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: Wed, 09 Oct 91 20:26:01 +0000
>From:
[email protected] (Robert Smyser)
Subject: Re: DIR II (Cluster) Virus (PC)
For those epidemiologists who like to follow the spread of these
things, the DIR II virus has definitely reached MIT. Our Lab and the
one at the Sloan School both have machines with all the symptoms. I'd
say it first appeared in our lab on or about Oct 1, 1991.
At risk of seeming obtuse, I ask, just what is the method of
transmitting this virus from machine to machine? Is it by physically
transferring an infected executable from one machine to another?
Thanks for all the fine sleuthing!
- -Rob
- --------
Robert Smyser, Manager, Computer Resource Laboratories
School of Architecture and Planning, MIT
[email protected]
___
-=====-
| | |
| | |
=======
==M=I=T==
------------------------------
Date: Thu, 10 Oct 91 10:01:57 -0400
>From:
[email protected]
Subject: Viruses and OS/2 (OS/2)
Just to add a little to what Bill Arnold posted concerning the
question on whether DOS viruses and antiviral programs will work under
OS/2 2.0, most all scanning programs should work with no problem. DOS
system monitor programs that require a device driver will most likely
work under 2.0 unless they do something very abnormal. From what I
have seen and heard about OS/2 2.0, it should allow you to specify
device drivers that a DOS program needs, which are then started
whenever the DOS program is invoked. Antivirus drivers will only be
able to monitor activity for the single DOS program or session though,
since it will be running in the virtual machine mode of the 386 or
486. Thus, you will have to specify the device driver in the
configuration information for each of your DOS programs. I think you
will also be able to specify DOS device drivers in the OS/2
CONFIG.SYS, and they will then be available to all DOS programs
without having to set them up individually. I have done tests on the
effects of DOS viruses on OS/2 1.x systems, and the situation there is
bleak. As soon as I get the next OS/2 2.0 beta, I will be doing some
more tests on the effects of DOS viruses, and will keep the digest
posted.
To mount the soapbox for a second, it is indeed unfortunate that some
basic virus protection measures are not built into OS/2, which IBM
bills as an "advanced" operating system, e.g., partition table and
boot sector integrity tests and backup utilities, system file and .DLL
self-checks, and even a full blown "integrity shell". Hopefully, OS/2
developers will recognize the need to include such functions in the
operating system itself and include them in future OS/2 versions.
Until then, OS/2 systems are generally as vulnerable to virus
infections as is any DOS system. (And we're supposed to use OS/2 for
our mission-critical applications???)
Kevin Haney
------------------------------
Date: 10 Oct 91 09:56:35 -0500
>From: "Don Medal" <
[email protected]>
Subject: Stoned on 3.5" disks / "1590" virus (PC)
I am new to this forum, please forgive if these subjects have just
been covered. We are currently infected with an apparently new strain
of the "Stoned" virus. We ran tests last year and determined that the
Stoned virus we had at that time could not infect our 3.5" disks,
suddenly we are overwhelmed by Stoned on our 3.5" machines also.
Q#1: Is this a new strain???
Q#2: Any info on the "1590" virus? I can't find it in the McAffee list.
Thanks!
Don Medal
[email protected]
Computing Services
U of Minnesota Crookston
------------------------------
Date: 10 Oct 91 10:27:52 -0500
>From:
[email protected]
Subject: disable ctrl/break? (PC)
Our lab machines run a virus check at boot and are SUPPOSED to hang if
a virus is found. Unfortunately, our instructors have been saving
time by teaching the students to press Ctrl/Break at boot in order to
skip the test. The result is of course that the lab machines are all
infected. Can this (ctrl/break) be disabled?
------------------------------
Date: Thu, 10 Oct 91 11:40:00 -0400
>From:
[email protected]
Subject: False Alarm (PC)
I recently received a few diskettes which were reported to be infested
with the "Happy New Year" virus. I scanned the diskettes with
VIRUSCAN (McAfee), VIRUSAFE (Eliashim), Turbo Anti-Virus (Carmel),
Norton Anti-Virus, and Central Point Anti-Virus. All reported the
diskettes to be free of any viruses.
The product that gave the false alarm is called V-BUSTER, published by
Looi Hoong Thoong in Penang, Malaysia. It should not be confused with
VIRUS-BUSTER, distributed by Leprechaun Software in Georgia.
While a false alarm may seem to be a harmless event, it can have
serious consequences. It can cause the user to delete files or
reformat disks unnecessarily. Workstations may be taken offline from
networks or whole networks shut down. At the very least, access to
computer resources are denied while the user attempts to find and deal
with the phantom virus. Most importantly, from a vendor's
perspective, the reputation and reliability of the provider of the
suspect media are called into question until the true situation is
known.
All vendors of virus detection products should take as much care in
ensuring that false positives do not occur as they take in ensuring
that actual viruses are reported.
Gary Garb
Corporate Computer Security Officer
Unisys Corporation
------------------------------
Date: 10 Oct 91 11:32:00 -0500
>From: "William Walker" <
[email protected]>
Subject: Hardware and Software; Re: Forget Turing...
>From: padgett%
[email protected] (A. Padgett Peterson)
> This is the first time I have seen a reply appear in the same posting
> as the original - a dose of Asimov's endochronic somethingoranother I
> guess.
I have seen postings and their replies in the same issue of VIRUS-L
before. How does it happen? (Ken?)
> My real disagreement is this argument that "computers are made to run
> programs, viruses are programs, therefore computers cannot tell
> viruses from programs." This is wrong. Period.
> The same logic would state that "saddles fit horses, saddles also fit
> tigers, therefore horses cannot be distingushed from tigers."
No, the same logic would state that "saddles fit horses, saddles also
fit tigers, therefore saddles cannot tell tigers from horses."
The statement that the argument is wrong is itself wrong. If computers
CAN tell viri from [other] programs, then why are viri so widespread?
Now, computers CAN be made to recognize virus-like behavior, but since
viri are a subset of programs, it is possible for a non-viral program
to exhibit virus-like behavior. Take SideKick, for example. It goes
resident, it intercepts interrupts (and tinkers with them in real time),
and writes to disk (Notepad, which I think can be coerced into even
reading and writing an executable). DIET, Padgett's DiskSecure, and
other programs also exhibit some virus-like behavior.
The problem is finding some way to allow the known non-viral programs
which exhibit virus-like behavior to operate, while preventing other
programs which exhibit virus-like behavior (viri) from operating.
About the only way is to have a system which includes a series of
permissions and has trusted paths for assigning and enforcing these
permissions. About the only way to implement such a system is:
>From: "Mark Aitchison, U of Canty; Physics" <
[email protected]>
> (1) "Smart" software that lets you write to some files, but not others
> (2) "Smart" hardware [...] that stops people by-passing (1).
> ...
> The obvious answer is that a COMBINATION of hardware and software is
> needed; the hardware to stop people getting around the software....
The hardware and software will have to be designed keeping the trusted
path in mind. Perhaps unfortunately, they would have to be designed
together to work together, so retrofitting existing machines may be
difficult. Also, the security features would have to work continuously
and independent of the user. Jay's "Virus-Proof" machine and Fred's
"Virus-Resistant" machine may work okay, but they are user-vicious in
that the user plays a major active part in maintaining the security, and
the protection can be disabled via the "big red" or "small colorless"
switch. Padgett's machine is better in that a lot of the security is
now transparent to the user, but there is still no trusted path, and a
virus (or a Trojan horse) can still subvert the system (how well does
your machine hold up against 12 Tricks?).
It is mandatory that a system's security be independent of and
transparent to the user to be successful. From what I've seen, the vast
majority of viri have been spread by people who are either computer-
illiterate (don't know what they're doing), are as security-conscious
as a biscuit (are oblivious to what they're doing), or just lazy (don't
want to do anything more than they really have to). These people cannot
or will not use any security features if these features require them to
have an active role. Of course, this brings up two points which have
been brought up before by others on this list: implementation and user
education. For any security solution to be effective, it will have to
be implemented across a major portion of the installed base of machines.
Also, users would have to be trained in basic security measures as well
as use of the new features of their machine.
But that's a completely different matter. On to the next thing...
- - - - - - - - - -
>From:
[email protected] (Gene Spafford)
> What Cohen proved in his thesis was that a program to exactly detect
> all viruses on a Turing machine was an intractable problem. That is,
> you cannot write a program that will run on a Turing machine and will
> print "infected/not infected" with 100% accuracy for any arbitrary
> program on that same Turing machine.
> ... #2. The proof shows that you cannot build a perfect detector on a
> Turing machine. However, the proof depends on the fact that the
> theoretical Turing machine has unbounded space for programs/data, and
> has unbounded time to run. If you bound either, the proof no longer
> holds. For example, if memory consists of only 3 words, you can
> easily write a detector that knows if there is a virus present or not,
> and it runs in finite time.
> Now, consider that real machines have bounded time and space for
> execution of programs. The intractability result DOES NOT hold on
> these machines. The problem may be exponential in nature, or worse,
> but it is not intractable. The halting problem does not exist on
> machines with finite memory and/or execution time bounds.
This sounds similar to a problem I studied in Computability, which asked
if it was possible to write a program in some language to detect an
infinite loop in ANY program of the same language. The proof showed that
it was impossible to do so. While I admit that I'm not up to speed on my
formal proofs, it seems to me that it would also be impossible (or nearly
so) to write a program (NOT a signature scanner) to detect ANY virus,
known, unknown, or yet to be written, without error.
Bill Walker (
[email protected] ) |
OAO Corporation |
Arnold Engineering Development Center | AEDC -- Home of the "Chicken Gun"
M.S. 120 |
Arnold Air Force Base, TN 37389-9998 |
------------------------------
Date: Thu, 10 Oct 91 09:37:14 -0700
>From:
[email protected]
Subject: Re: Forget Turing...
[email protected] (Gene Spafford) writes:
>Without going into all the gory details....
>What Cohen proved in his thesis was that a program to exactly detect
>all viruses on a Turing machine was an intractable problem. That is,
>you cannot write a program that will run on a Turing machine and will
>print "infected/not infected" with 100% accuracy for any arbitrary
>program on that same Turing machine.
What is a virus (in Cohen's thesis). Further comments depend on a good
answer to this, but....
I don't think I'm originating this, but the way _I_ would show that a
program to check whether a program infects a system is impossible,
(assuming the system is sufficiently complex that infection _is_ possible)
is by assuming such a program P exists.
Write a program P' which does the following: apply P to P'. Infect if and
only if P reports P' clean.
I would have to see Cohen's thesis to see if it is only a more
sophisticated version of that. Is it available by ftp?
>...
However...
>#3. A perfect detector on a Turing machine is intractable. However,
>an imperfect program is possible. That is, you may write a program
>that makes either or both Type I and Type II errors in its
>classification scheme (Type I in this context would be labeling an
>uninfected program as infected, and Type II would be labeling an
>infected program as clean). Building a program that makes only Type I
>errors might be possible, and could be completely appropriate for our
>needs.
A very good point.
- --
[email protected] [email protected] [email protected] (personal)
[email protected] (work)
My opinions are my own, and do not represent those of my employer.
------------------------------
Date: Thu, 10 Oct 91 17:34:06 +0000
>From:
[email protected] (Kevin Buhr)
Subject: Psychology of virus writing (was HW not a virus solution)
[email protected] (Mark Aitchison, U of Canty; Physics) writes:
>Talk about the "psychology" of virus writing before leads me to think
>that all that is required is for virus writers to be faced with a
>pretty slim chance of success (and a good chance of being caught), for
>virus writing to suddenly go out of fashion.
On the contrary, I would suggest that the true virus "artists" would
be quite stimulated by the thought of working around a particularly
ingenious detection technique. The slim chance of success would drive
them to succeed. Consider the two clowns in Bulgaria who are foiling
detection methods that haven't even been implemented yet!
Of course, the relatively common phenomenon of virus "planting", by
which I mean the practice of placing someone else's virus on a target
machine to cause trouble, might very well go out of fashion. After
all, if new virus detectors can keep pace with new viruses, then there
is only a slim "infection window" which would generally be available
only to the virus writer.
Kevin Buhr <
[email protected]>
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 187]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
