VIRUS-L Digest Thursday, 10 Oct 1991 Volume 4 : Issue 186
Today's Topics:
re: Hardware, hardware...
Re: Hardware, hardware...
Recommend Anti-virus s/w for Novell Netware
SF Worms/Viruses (Re: HW not a solution)
Re: Morris worms through courts
Re: Forget Turing...
Re: DIR II (Cluster) Virus (PC)
Re: DIR II Removal Information (PC)
Re: HW not a virus solution
OS/2 2.0 (OS/2)
Re: Tequila virus (PC)
Virus Protection - Global Software Solution
Re: Stoned on preformatted Verbatim Disks? (PC)
Bontchev paper available
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: 08 Oct 91 09:59:34 -0400
>From: "David.M.Chess" <
[email protected]>
Subject: re: Hardware, hardware...
> From:
[email protected] (Fred Waller)
>
> ... No virus can defeat hardware protection by itself.
> It's physically impossible. No reasonable person could hold
> otherwise.
Sure, no one's disputing that. The point is, though, that that fact
isn't really interesting. It doesn't, for instance, imply that a
hardware-based protection method would keep a system free of viruses
in the real world. The "by itself" is, as you noted, the key. A
virus can't defeat hardware protection by itself; on the other hand,
it will invariably have help, because people always want to run new
software on their systems, or otherwise want to open up the
software-space of their storage media for writing now and then. (Or,
if they don't, they've got an "application machine" as Bill Murray
described; those machines you *can* protect, but they aren't the place
where we have the problem.)
So it's true that a software virus can't by itself get past hardware
protection. But it's equally true that on a general-purpose computer
you have to turn off the hardware protection now and then, and then an
appropriate virus can infect you. It's an open question whether or
not such a scheme would limit virus growth to below epidemic
proportions. But then, it's also an open question whether or not any
of various software schemes would. So, although they seem very
different, it's not clear to me that there's really a huge difference
in kind between hardware and software anti-virus schemes.
Your later posting ("Forget Turing...") is talking, I gather, about
physically write-protecting the disk with the programs on it? If I
may risk oversimplifying! *8) That works nicely until you have to
write-enable it for whatever reason, or until a virus shows up that
infects some sort of object that you forgot was an executable (.BAS
files or spreadsheets or whatever). As I said above, that -may- be
such a small window of attack that no virus will ever actually get to
you, but it's an open question.
DC
------------------------------
Date: 08 Oct 91 16:10:38 +0000
>From:
[email protected] (Henk de Groot)
Subject: Re: Hardware, hardware...
[email protected] (Fred Waller) writes:
>
[email protected] (Vesselin Bontchev),
> quotes from an article of mine:
> >> But hardware alone is enough. To illustrate: there's no virus
> >> in the world that can bypass a simple hardware device called
> >> a write- protect tab. This humble little piece of black paper
> >> doesn't care one bit about Cohen's theories. Disobeys them
> >> every time. :-)
> and replies:
> > Wrong. Completely wrong. There is a Bulgarian virus, called
> > Darth Vader, which infects COM files only when you copy them.
> Darth Vader can infect only AFTER becoming TSR in the system.
> HOW did that virus (of which I have some copies) would manage to
> become TSR on the system? During COPY? Certainly not. So why the
> attempt at confusing the issue with such misleading remarks: "Wrong.
> Completely wrong"..?
What you are saying is that a virus can never go resident on your system
and that you only remove the write-protect tab if you are copying files.
You are right that your system can not be infected but you DON'T NEED
A WRITE-PROTECT TAB either! If you claim that a virus can not go
resident on your system than that implies that your system is clean.
If your system is clean you can not infect a floppy, protected or not!
This mean that if you use your system with the software currently on
it and never add new software from the outside world (and only use the
floppy's you always used on your system without exchanging them) than
you are 100% shure you won't get a virus (and most certainly not new
strains) even if you don't use write-protect tabs or whatever measure.
This whole thread is rediculus. If you use your system as a standalone
system which never gets in touch with other computers by any means,
you will not get infected, never! This also applies to a group of
computers as long as it never makes contact with the outside world,
not ever!
Most people however use there computer differently, and that are the
computers that are threathend by viruses. People exchange disks with
others, upgrade their software. There is no write-protect tab that can
stop this because when data is exchanged via a floppy than the write
tab must be removed during the write action. At that point de disk can
be infected. The only thing a write-protect tab can do is prevent that
all your other disks get infected. Every infection via floppy went
trough the cycle:
write infection on disk -> read infection on uninfected system.
Simple but the write protect tab doesn't help because it's removed in
the first stage.
I hope this will stop this stupid converstion.
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: 08 Oct 91 16:34:56 +0000
>From:
[email protected] (Alberto Jose)
Subject: Recommend Anti-virus s/w for Novell Netware
Hi all,
Does anyone have info/recommendations on a virus detection/prevention
program for the novell netware environment (286Adv 2.15 rev.C)? I
heard the CENTRAL POINT's ANTI-VIRUS s/w is LAN compatible...I'd
appreciate any help/info anyone would have..thanx.
- - Archie
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|
[email protected] | <insert cute little phrase here> |
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
------------------------------
Date: Tue, 08 Oct 91 20:01:21 +0000
>From:
[email protected] (Rick Smith)
Subject: SF Worms/Viruses (Re: HW not a solution)
[email protected] (Jay Skeer) writes:
>P.P.S. I got the idea of a computer virus from an old S.F. book. In
>the book they actually describe a worm (and called it that) ...
>.... This was in 1983 or 4.
>Does any one know the name of that book, or of an earlyer reference to
>computer viruses?
There's Gerrold's "When Harlie was One" which dates at least to the
early 70s. There's "Adolescence of P1" (a Morris-like worm) which I
read in the mid-late 70s, but I don't remember the author.
I've heard people refer to "Shockwave Rider" as a classic example
of worm/virus SF though I've never read it and don't remember the
author's name.
Rick.
[email protected] Arden Hills, Minnesota
------------------------------
Date: 08 Oct 91 21:39:07 +0000
>From:
[email protected] (Gene Spafford)
Subject: Re: Morris worms through courts
For those of you who missed it, Morris's appeal to the Supreme Court
was rejected without comment or opinion. Thus, his conviction stands,
and the interpretation of 18 USC 1030 is now known to be that no
intent to damage need be proven in court -- only intent to access.
- --
Gene Spafford
NSF/Purdue/U of Florida Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-1398
Internet:
[email protected] phone: (317) 494-7825
------------------------------
Date: 08 Oct 91 22:02:19 +0000
>From:
[email protected] (Gene Spafford)
Subject: Re: Forget Turing...
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.
Now, this result has been misquoted and misinterpreted by nearly
everyone writing about viruses....including Fred himself in later
articles. It's not surprising, really, as the concepts of Turing
machines and intractability are not well understood -- especially by
systems hackers. :-) (That includes me, by the way.)
Let me throw out some observations on the situation:
#1. There is no similar proof (that I know about) for either
multi-headed automata, or multi-tape machines. Thus, I'm not sure
that a formal statement can be made about the detection of viruses in
the Turing machine equivalents of a multiprogramming system or in a
multiprocessor system. If anyone knows the status of these problems,
and can cite a publication addressing them, I'd be grateful.
#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.
#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.
Informally, a crude method would be to label all programs as infected,
but that would not be appropriate for general use; however, it is a
constant-time/constant-space solution to the problem -- not
intractable at all! The problem comes about when trying to reduce the
frequency of these errors to an acceptable threshold, and to be sure
that no Type II errors occur. Picking any arbitrary levels of
confidence may result in an NP problem, but not an intractable one.
So, could we please stop claiming that it has been proven that no
perfect virus detector can be built, or that finding viruses is an
intractable problem? We have an interesting theoretical result, but
it does not give us any particular result with respect to the problem
at hand.
- --
Gene Spafford
NSF/Purdue/U of Florida Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-1398
Internet:
[email protected] phone: (317) 494-7825
------------------------------
Date: Tue, 08 Oct 91 21:40:16 +0300
>From:
[email protected] (Dmitry O. Gryaznov)
Subject: Re: DIR II (Cluster) Virus (PC)
[email protected] (Vesselin Bontchev) writes:
>
[email protected] (Joe Wells) writes:
>
>> listed in the structure above. The original is scrambled by using a
>> straight forward rotating xor encryption. Once an altered entry is
>
>It's not that "straight forward"... :-) It's not easily computable by
>hand and is based on a key, which tends to be different for different
>disks. The key depends on the DOS partition size, the number of
>sectors in a cluster, etc.
For anti-virus researches: this key (2 bytes) can be found at
displacement 033FH inside the virus body ("infected" cluster(s) on an
infected drive).
>> last two bytes of the unused area is zeroed out. Viewing the last
>> cluster is also redirected.
>
>Not exactly. The virus intercepts the disk device drive call BuildBPB
>and modifies the returned disk size, so that the disk looks two
>sectors "shorter".
Two sectors if a cluster consists of not less then 2 sectors, three
sectors otherwise. Since the virus can use not the last cluster (in
case when cluster is not less then 2 sectors and several last
clusters are marked as bad) it doesn't *ALWAYS* hide his clusters.
>When a file, whose directory entry is infected is run on a clean
>system, the virus installs itself in memory, marking its current PSP
>as 0008 (as if it belongs to COMMAND.COM). MAPMEM will show that
0008 mark in MCB means *NOT* COMMAND.COM but DOS itself.
>COMMAND.COM occupies three memory blocks. Afterwards, the virus tries
>to execute a file with the name consisting of one character with ASCII
>code 0FFh in the current directory of drive C:. Of course, such file
Not in the current but just in the *ROOT* and not to execute but just
to open. Maybe we have somewhat different versions of DIR II ?
>will not be found, which will lead to the search of the current
>directory on drive C: and of all directories, listed in the PATH
>variable. Since the virus infects the directory entries on any sector
As I've mentioned above, a sample of the virus I have tries to *OPEN*
not to *EXECUTE* an unexisting file in the root directory. To enforce
DOS to call driver the virus marks an appropriate Device Info Block
as "never been accessed". So DOS will re-read the root directory and
the virus will get a good chance to infect all .EXE and .COM (except
System) files in the root including COMMAND.COM.
If your sample of the virus tries to execute an unexisting file via
DOS function 4BH it won't lead to the search of directories, listed
in the PATH variable - COMMAND.COM uses PATH, DOS itself never. So,
only files in the current directory and in directories on the way to it
will be infected. E.g. if the current directory is C:\ABC\DEF\GHI then
DOS will search root directory for ABC subdirectory, then ABC for DEF
and so on.
>When a machine with an infected command interpretter is booted, the
>virus detects this and installs itself in memory in a different way.
>It waits until the command interpreter's memory control block is
>created and then extends it and copies itself in the added space.
When the virus receives control, command interpreter's MCB is
already created and used - the virus was loaded as COMMAND.COM
and DOS Memory List is initialized *BEFORE* executing any
program. The virus just checks if its MCB is the next to DOS's
(as in the case of COMMAND.COM first loaded after bootstrap) and
in the case it extends DOS's MCB to include the virus.
Several things others forgot to say:
1) after installation in RAM the virus executes an original program -
just like the Jerusalem virus. Since the virus is active, a normal,
not infected program will be loaded;
2) being run under DOS 5.0 the virus will "hang" a computer due
to a method it uses to call DOS.
- --
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: Tue, 08 Oct 91 22:41:42 +0300
>From:
[email protected] (Dmitry O. Gryaznov)
Subject: Re: DIR II Removal Information (PC)
Joe Wells <
[email protected]> writes:
>The virus code will be found in the last cluster on the drive. It will
>occupy 2 sectors. The code is 1024 bytes.
First of all - a disinfection must be made only when there is no the
virus in RAM.
The virus code will not *ALWAYS* be found in the *LAST* cluster. In
fact on 1.2 and 1.44Mb floppies it'll occupy two clusters starting
with last-1. On a hard disk the virus can reside in a cluster far from
the last if all the following clusters are marked as "bad".
>To disinfect, read the virus code from the last cluster. Get the
>encryption key and save it.
>
>The key is the word at offset 33F in the virus code.
>
>The prototype simply checked all sectors and did simple testing to
>determine if it was a directory listing or not. Any other method of
>finding the sectors would work as well. Once a sector is found, set a
>pointer to the first entry. Check the word at [ptr + 1Ah] for the
>last cluster number. The word at location [ptr + 14] is normally 0 in
As I've written above the virus does not always use the *LAST* cluster
- - you can read the last cluster and find no virus there while the
virus *IS* on the disk.
This cluster number can be found in the virus body at offset 0334H.
And the easiest and correct way to obtain the virus body is to read an
infected file (we suppose there is no virus in RAM). So disinfector
can check all the .EXE and .COM files for the virus body. When found,
it is necessary to check if the cluster (its number is at offs. 334H)
*REALLY* contains the virus - you could get an infected file by
copying it on a not infected PC. In the latter case a disk most likely
is not infected and a file contains just the virus body, its directory
entry being quiet normal.
- --
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: Wed, 09 Oct 91 13:08:00 +1300
>From: "Mark Aitchison, U of Canty; Physics" <
[email protected]>
Subject: Re: HW not a virus solution
There are TWO solutions needed to viruses:
(1) "Smart" software that lets you write to some files, but not others
(2) "Smart" hardware (or maybe softare) that stops people by-passing (1).
There are a huge number of viruses that can easily be stopped by
software in the first category... not just detected, but stopped dead
in their tracks. for example, software that says "you cannot write to
this file", and other precautions that assume the virus goes through
normal channels, like DOS. There are no prizes for inventing such
software, since it already exists; what is needed is better and better
tests that, for example, allow programs that write to themselves to
store configuration information to keep working without an annoying
pop-up or a lengthy configuration session when you first install the
program. I can't see (1) being done with hardware, it is just too
complicated.
The worry some people have at the moment, quite rightly, is that
modern viruses can get past the software virus detectors, and (in
theoy at leat) past the best software-only solution you might ever
come up with. Hence the discussions that go along the lines "software
can beat software", and the worrying fact that viruses have the
advantage because they come *after* the anti-virus software they're
trying to circumvent - the next generation of a-v programs might beat
them but there will be a good time for them to spread before that.
Now, as pointed out, the hardware solutions suffer from the fact that
people will turn them off when they need to do something useful, at
which time the virus has a chance, or they will deliberately let
spreadsheets, .BAS programs, etc go through unhindered for
convenience.
The obvious answer is that a COMBINATION of hardware and software is
needed; the hardware to stop people getting around the software. You
might be able to think of some complicated software that will get
around particular combined solutions, but it doesn't have to be 100%
watertight - so long as the virus would have to be very big and
clumsy, or has a lower chance of spreading from machine to machine
than the chance of being spotted at any stage.
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. For that, we either
needed a lot of users to adopt pretty simple software solutions (the
type that MS or DRI could have built into their operating systems ages
ago for free), or we need that plus a bit more now, to knock the bulk
of the viruses on the head. I feel the DRDOS 5, with its password
protection system was a good first step, and DRI & Microsoft should be
encouraged to take more steps like that, since it is obvious the
average user won't.
Mark Aitchison.
------------------------------
Date: 08 Oct 91 22:09:09 -0400
>From:
[email protected]
Subject: OS/2 2.0 (OS/2)
We did some limited testing DOS viruses under a widely distributed
July 1991 Beta version of OS/2 2.0 (driver number 6.149, if anybody
cares). The following notes hold *only* for that Beta version; the
ship level version (whenever it happens) may be different in some
particulars. (I'm not in any way affiliated with the OS/2 2.0
development group, other than working for the same company.)
Positives:
(+)Direct writes to the disk at the INT 13 and INT 25 level were disallowed.
Bimodal viruses, and viruses that use INT 13 or INT 25 to do damage will
have a harder time than under DOS. (We didn't try calling the BIOS
INT 13 routines directly.)
(+)OS/2 DOS sessions go away, completely, when you double click on them.
A memory resident virus active in a DOS session will not remain in
memory after the DOS session is terminated.
(+)Boot sector viruses don't survive the OS/2 2.0 boot process. A system
can still be infected, particularly with a master boot record virus
such as the Joshi, but it won't spread the infection to diskettes
while OS/2 is active. I know of an instance where an OS/2 1.3 system was
infected with the Campana (Telefonica) virus. It was set up for "Dual
Boot", which is crude support for booting OS/2 from DOS and DOS from
OS/2. When OS/2 was booted, the Campana was inactive; when DOS was
was booted, the Campana became active and spread to other diskettes.
(The Campana is a master boot record virus.)
(+)If you try to run a DOS program from an OS/2 session, the command
interpreter (or something) recognizes it, and starts up a DOS
session just for that program. When the program terminates, the
DOS session goes away, including any virus resident in memory.
(+)The few anti-virus tools that I tried in this environment worked
fine. IBM VIRSCAN runs in both OS/2 DOS and protect mode sessions.
(This particular driver had a bug in the DOS session
findfirst/findnext INT 21 call, with a simple workaround.)
Minuses:
(-)No file-level access controls. (Arggghhh!)
(-)Unfortunately, while the address space isn't shared among DOS sessions,
the filesystem *is* shared. This includes everything in the /OS2 and
/OS2/MDOS directories (/ == backslash), which are in the default DOS
session PATH. For instance, this means that a memory resident virus
that attaches itself to COMMAND.COM (such as the 4096) will become a
permanent feature of any DOS sessions started subsequently.
Bill Arnold
------------------------------
Date: Wed, 09 Oct 91 06:17:39 +0000
>From:
[email protected] (McAfee Associates)
Subject: Re: Tequila virus (PC)
rsr%
[email protected] (Roger Rosenblum) writes:
>Patricia Hoffman's virus summary indicates that the Tequila virus
>can be detected/removed by McAfee & Associates SCAN/CLEAN programs
>(Version 80+), yet I see no mention of this virus in the documentation
>(VIRLIST.TXT) for version 80 or 82. Am I missing something?
Just that it wasn't put into the documentation :-) Seriously, my
workload (not to mention the number of viruses) has been increasing
and I have not had as much time to work on the documentation as in the
past. I've just returned from my vacation to find thatVersion 84 was
released. I'll put some sort of comment in to the docs on the next
release.
Regards,
Aryeh Goretsky
McAfee Associates Technical Support
>
>Roger Rosenblum Internet:
[email protected]
>Workstation Software Support Bitnet:
[email protected]
>University of California at Berkeley
- --
McAfee Associates | Voice (408) 988-3832 |
[email protected] (business)
4423 Cheeney Street | FAX (408) 970-9727 |
[email protected](personal)
Santa Clara, California | BBS (408) 988-4004 |
95054-0253 USA | v.32 (408) 988-5190 | CompuServe ID: 76702,1714
ViruScan/CleanUp/VShield | HST (408) 988-5138 | or GO VIRUSFORUM
------------------------------
Date: Tue, 08 Oct 91 15:41:47 -0400
>From: padgett%
[email protected] (A. Padgett Peterson)
Subject: Virus Protection - Global Software Solution
>From: Jay Skeer <
[email protected]>
> Jay's Virus Proof Machine
> Jay's Virus Proof Machine has two disk drives a "program" disk and a
>"data" disk. It also had a big red switch labeled "install/run".
> Sounds good huh? It wont work. It WILL make the life of computer
>users miserable, but it WONT prevent the spread of viruses.
> This scheme fails because it does not take into account the
>observation (invention?) that some bright guy (Von Neuman?) made in
>the 50's -- You can't tell program from data. You just can't.
- -------------------------------------------------------------------
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.
>From:
[email protected] (Fred Waller)
>Subject: Hardware
> Fred's Virus-Resistant Machinee
> ------------------------------
> Fred's Virus-Resistant Machine also had two disk drives, a "program"
> disk and a "data" disk. It, too, had a _small_ switch (not red),
> labeled: "Install/Run".
> Unlike Jay, Fred (Waller) also had this silly idea that it isn't
> necessary to make viruses impossible in order to provide adequate
> defenses against them. He didn't care if they existed, as long as
>it was somewhere else.
> In this way, while Jay decided that his machine couldn't possibly
> work, Fred discovered that his machine (which wasn't virus-proof,
> but only virus-resistant) *did* work, and extremely well. None of
> his favorite viruses (hundreds of them, my goodness!) succeeded in
> infecting it. Since he always booted from a clean disk (the safe
> "program" disk or a trusted diskette), he had no Boot infectors
> in RAM. Some of his viruses did freeze the machine but he was
> able to reboot without infection and kept smiling.
(lots of intermediate stuff deleted)
Here we have two very good very logical postings. I agree with Fred
(Waller not Cohen) and disagree with Jay's conclusions but the hinge
is on a minor point: Jay's concept required a separate boot mechanism
(the tiny IS) to install/update files to the program area.
It would be understandable that making a system unable to update LIST
or WORDSTAR files would be objectionable to users since occationally
tastes change.
As mentioned previously I use a special program (BYPASS) to allow
updating of my ProgramDisk rather than requiring a reboot. Along with
encapsulating the tinstalling application, BYPASS also checks the
environment before and after the application. The hardware switch is a
good idea if you are really worried (lead #6 on the 34 pin cable of an
MFM/RLL drive) but I have never found it necessary.
Thus the disagreement stems from implimentation rather than concept
since all of them (Jay's, Fred W's, and mine) are the same. (Great
minds think alike <grin>).
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."
While viruses are programs they do things that programs should not do
except in special (and trackable) cases: one of these is to attempt to
write to executable programs, another is to go resident (at least
sucessful viruses do). Both of these are detectable and flaggable.
(The flagging is where many early programs failed since it was not
selective. BYPASS makes it selective.)
More important, it makes it difficult for a logic bomb to work - try
to delete executables, it fails. Try to encrypt a disk, it fails, Try
to format the disk, it fails - so even if a trojan gets in, it will
likely fail. (Data is backed up isn't it - much easier than backing
everything up: my executable drive (also contains clip art, help
files, .mnus, etc.) is 40 Mb, the DataDisk is 20 MB and has more free
space.)
The point is that my ProgramDisk traps all write and format attempts
just like DiskSecure traps them for the MBR, hidden sectors, and Boot
Record. In my viral demonstrations at conferences I normally just turn
on full protection and use a RamDisk for the demos - so far so good.
Thus: both Jay and Fred W. make valuable points in this connection -
pay attention to what they are saying & consider that the problems
mentioned are just ones of practise not concept.
Padgett
ps It is interesting to see that all the principals seem to be classmates of
Dr. Cohen - having gone to school when FORTRAN II and punch cards were
popular, I must have missed something. 8*)
------------------------------
Date: Thu, 10 Oct 91 00:33:40 +0000
>From:
[email protected] (Andrew Turner)
Subject: Re: Stoned on preformatted Verbatim Disks? (PC)
[email protected] (Jeffry L. Johnson) writes:
>This is at least thirdhand information, but I am curious
>whether anyone else has heard this rumor:
>
> Some preformatted Verbatim floppy disks are infected
> with the STONED virus.
>
>I do not know what density or size of disk.
I suppose I acknowledge your anxiety but really IMHO:
a. Thirdhand rumours really don't warrant your posting. The virus scene gets
touchy enough without recourse to heresay three times removed. NB I have
nothing whatsoever to do with Verbatim.
b. Have you contacted Verbatim to check it out? Your rumourx3 may have some
basis, but lets have facts!
- --
Andrew Turner
[email protected]
Die, v: To stop sinning suddenly.
-- Elbert Hubbard
------------------------------
Date: Tue, 08 Oct 91 10:52:46 -0400
>From: Kenneth R. van Wyk <
[email protected]>
Subject: Bontchev paper available
Thanks to Vesselin Bontchev for contributing his paper, "The Bulgarian
and Soviet Virus Factories" to the archives! The paper is available
by anonymous FTP on cert.sei.cmu.edu (192.88.209.5) in
pub/virus-l/docs. (I will gladly e-mail the paper out to any archive
maintainers who can't access it via FTP.) Two versions of the file
are on-line:
bulgarian.factory.tex - original document, formatted with TeX
bulgarian.factory.doc - ASCII version of same
A brief abstract follows:
It is now well known that Bulgaria is leader in computer virus
production and the USSR is following closely. This paper tries to
answer the main questions: Who makes viruses there, What viruses are
made, and Why this is done. It also underlines the impact of this
process on the West, as well as on the national software industry.
Enjoy!
Ken
Kenneth R. van Wyk
Moderator VIRUS-L/comp.virus
Technical Coordinator, Computer Emergency Response Team
Software Engineering Institute
Carnegie Mellon University
[email protected] (work)
[email protected] (home)
(412) 268-7090 (CERT 24 hour hotline)
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 186]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
