VIRUS-L Digest Wednesday, 13 Nov 1991 Volume 4 : Issue 216

VIRUS-L Digest Wednesday, 13 Nov 1991 Volume 4 : Issue 216

Today's Topics:

Generic scanning - a small test (PC)
Re: Organ music/black monitor-Mac (Mac)
re; F-Prot 2.01 (PC)
Theory : definition & classification
Re: A couple questions (Mac) (Commodore)
Re: Only Scan Floppies? (general)
Re: A couple questions (Mac) (Commodore)
Re: Disk Compression (PC for now)
two (2) excerpts from FIDO VIRUS echo conference
Re: A couple questions (Mac) (Commodore)
Re: Virus Proof Machine Response
Re: Regulation of (Medical) Software
Re: Hardware? How about software...?

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: Sat, 09 Nov 91 17:39:08 +0000
>From: Fridrik Skulason <[email protected]>
Subject: Generic scanning - a small test (PC)

I just did a small test and I hope the results are of general interest.

In the week since I released version 2.01 of F-PROT I have received 16
samples of new viruses (in addition to a lot of "old" stuff of course).

I ran my scanner (as well as McAfee's V84) on the new viruses, and the
results were as expected - some were detected, but others were not.
I would have Included Alan Solomon's scanner as well, as I consider it
to be the best of the products competing with my own, but I am not sure I
have the most recent version of it.

I then ran my experimental ANALYSE (or ANALYZE, if you prefer) program,
which applies a set of rules to determine if a program contains a virus or
not.

It should be noted that none of the samples have been analysed yet, or
classified properly. In fact, I have not even verified that the viruses
work, but my (reliable) sources claim they do. I also want to point out
that these are new viruses, and there was no guarantee beforehand that they
would be detected at all with my scanner (or any other scanner for that
matter).

Finally - I just wanted to make clear that I made an effort to make this
test fair - I have not yet modified my signature tables to handle these
new viruses, and I have not updated the ANALYSE heuristics. Also, I have
not excluded any of the viruses I have received the last week.

And yes - "Sample name" is just the name of the sample file I received,
not the virus name - the viruses are new, and some of them don't have a
name yet.

Sample name: IRISH.COM
2.01-Secure: not detected
2.01-Quick: not detected
Scan 84: Found Irish Virus [Irs]
Analyse: No virus-like code found

Sample name: DAM-11.COM
2.01-Secure: Infection: Plovdiv
2.01-Quick: Infection: Plovdiv
Scan 84: not detected
Analyse: This program moves itself to a different area
of memory using a method which is normally
only used by viruses.

Sample name: DAM-13.COM
2.01-Secure: not detected
2.01-Quick: not detected
Scan 84: not detected
Analyse: This program contains several features which
are normally only found in virus programs.
It is almost certainly virus-infected.

Sample name: MURPHY5.COM
2.01-Secure: Possibly a new variant of Murphy
2.01-Quick: not detected
Scan 84: not detected
Analyse: This program contains very suspicious code, which
seems to have been added to the end of the file.
It is almost certainly virus-infected.

Sample name: TERROR-N.COM
2.01-Secure: not detected
2.01-Quick: Infection: Terror
Scan 84: not detected
Analyse: No virus-like code found

Sample name: BRAINY.COM
2.01-Secure: not detected
2.01-Quick: not detected
Scan 84: not detected
Analyse: This file appears to have been modified
by adding some code at the end.

This might be a virus infection or just
a harmless modification by some other
program.

Sample name: CD-10.COM
2.01-Secure: Infection: DIR-II
2.01-Quick: Infection: DIR-II
Scan 84: not detected
Analyse: No virus-like code found

Sample name: CD-11.COM
2.01-Secure: Infection: DIR-II
2.01-Quick: Infection: DIR-II
Scan 84: Found DIR-2/FAT Virus [D2]
Analyse: No virus-like code found

Sample name: CD-12.COM
2.01-Secure: Infection: DIR-II
2.01-Quick: Infection: DIR-II
Scan 84: not detected
Analyse: No virus-like code found

Sample name: KARIN.COM
2.01-Secure: not detected
2.01-Quick: not detected
Scan 84: not detected
Analyse: This program moves itself to a different area
of memory using a method which is normally
only used by viruses.

Sample name: STINK2.COM
2.01-Secure: Infection: StinkFoot
2.01-Quick: Infection: StinkFoot
Scan 84: not detected
Analyse: This program contains several features which
are normally only found in virus programs.
It is almost certainly virus-infected.

Sample name: QMU_COM.COM
2.01-Secure: not detected
2.01-Quick: not detected
Scan 84: not detected
Analyse: This program contains very suspicious code, which
seems to have been added to the end of the file.
It is almost certainly virus-infected.

Sample name: V-472.COM
2.01-Secure: not detected
2.01-Quick: not detected
Scan 84: not detected
Analyse: This program contains very suspicious code, which
seems to have been added to the end of the file.
It is almost certainly virus-infected.

Sample name: CS.COM
2.01-Secure: Possibly a new variant of Vienna
2.01-Quick: not detected
Scan 84: Found 1014 Virus [1014] Found Lisbon Virus [Lisbon]
Analyse: This program contains several features which
are normally only found in virus programs.
It is almost certainly virus-infected.

Sample name: 800_COM.COM
2.01-Secure: not detected
2.01-Quick: not detected
Scan 84: not detected
Analyse: This program contains very suspicious code, which
seems to have been added to the end of the file.
It is almost certainly virus-infected.

Sample name: NUMLOCK.COM
2.01-Secure: not detected
2.01-Quick: Infection: PC-Flu
Scan 84: not detected
Analyse: This program modifies itself in a highly suspicious
way. It is either infected, or a badly written program
which overwrites code with data.

So, what can be said about the results? Each of the three scanning methods
detected only a minority of the new viruses, but the ANALYSE tool was
able to detect 11 out of 16 infections, although it only claimed that
7 files were almost certainly infected. Nevertheless, this was better
performance than any single scanner provided. What is also interesting is
the fact that it totally missed 5 viruses, including all three versions of
the DIR-II virus.

Why ?

For a simple reason - it uses a set of rules to determine what a virus
looks like. The DIR-II virus is different from any other virus, and
ANALYSE has no rules covering its behaviour.

What is also interesting is that in four cases (DAM-13.COM, QMU_COM.COM,
V-472.COM and 800_COM.COM) ANALYSE was able to correctly determine that
the programs were infected, although scanning did not reveal anything.

Generic analysis is not yet a substitute for virus scanning, but it
is improving....

- -frisk

------------------------------

Date: Sat, 09 Nov 91 18:38:47 +0000
>From: [email protected] (Richard Johnson)
Subject: Re: Organ music/black monitor-Mac (Mac)

[email protected] (Sue Hay (tm)) writes:

>from Fran Holtsberry:
>>We have two systems playing organ music and no monitor response...

>That chord means that your Macintosh has a hardware problem and it
>needs to be taken to an authorized Apple service and repair technician.
>No virus is involved.

If your Mac is playing the normal startup chord one note at a time, it
doesn't always mean a hardware problem. We've had two instances of a
badly damaged SCSI driver on the internal hard disk causing the Mac to
fail its startup tests.

If you can, try swapping drives between one of the offending Macs and a
known-working one. If the problem follows the drive, then reinstalling
the driver or reformatting the disk might fix things up nicely.

Even if it is a hardware problem (bad SIMMs, SIMMs in the wrong slots,
etc.), it's almost certainly not a viral symptom.

>Susan Hay, User Services Consultant/Analyst, Brown University

- --
Loudyellnet: Richard Johnson
Internet: [email protected]
Phonenet: 303.786.8502 (USA)

------------------------------

Date: Sun, 10 Nov 91 09:00:00 -0400
>From: "Bob Martin --> [email protected]" <[email protected]>
Subject: re; F-Prot 2.01 (PC)

>Date: Thu, 07 Nov 91 11:06:37 -0500
>From: MONAT%[email protected]
>
>I have some questions/wish list for F-Prot.
>
>1. I have a lot of clients who work on their stand-alone computer
> for quite some time and then decide to access a network. They
> load virstop.exe at boot time but then at network time, the load
> gets rejected with an "already installed" message. Couldn't
> virstop.exe disable its first copy and then reload itself?
> (P.S.: Until this problem is resolved, I'm still loading
> f-driver.sys from version 1.16 at boot time, then virstop.exe
> at network login in).

You may have missed it in the documentation, which can certainly happen
to the best of us; VIRSTOP.EXE can now be loaded as a device driver.
I belive that is on stand-alone cpus, but I haven't had the chance to
try it on my networked computer at work yet -- it may still work okay!

>2. What are we suppose to do with the file virstop.bin? It's exactly
> identical to virstop.exe and both can be loaded at boot time.

If I remenber correctly, the BIN file is the 'uninstalled' verion of
Virstop. If you put a custom message in the program with the Install
part of F-prot, it changes Virstop to reflect your site's message.

[...] stuff deleted (because I didn't know the answer. :-)

Hope this helps a bit!

Bob Martin -- [email protected] --

PS. Thanks for the upgrade Frisk!

------------------------------

Date: Sun, 10 Nov 91 16:31:01 +0000
>From: [email protected] (Maxim Titov)
Subject: Theory : definition & classification

I'd like to propose some thoughts.

1. Formal definition

An automaton description D(A) is symbols's set for creating
the automaton A or its behaviour ( see von Neumann's works).

VIRUSABLE automaton is one can be able to modify descriptions of
other automata so that
(i) modified description contains the description of the modification
algorithm,
(ii) after modification, automata with changed descriptions can be able
to modify other descriptions in the way satisfied (i) and (ii) rules.

Denote the modification as INFECTION.

Consider rules of virusable behaviour to define a virus.
Consider three Turing machines TM1, TM2 and TM3. There're three
external TM programs (descriptions) D(Ak), k is in {1,2,3}.
There're they on a common tape.
There's non-empty description D(v1), and D(A1) includes D(v1).
D(A2) and D(A3) don't include D(v1).
There's a recursive function f (D(A1),D(A2)) = h(D(A2')) and
1
D(A2') is TM2's program (here h - morphism {D(A1),D(A2)} => {D(A2'}) ).
There're non-empty D(v2) ( D(A2') includes D(v2) ) and
recursive function f (D(v1),D(A2)) = h(D(v2)).
v1
There's recursive function f (D(A2'),D(A3)) = h(D(A3')) and
D(A3') is TM3's program. 2
There're non-empty D(v3) ( D(A3') includes D(v3) ) and
recursive function f (D(v2),D(A3)) = h(D(v3)).
v2
Finally, there's recursive function f (D(v1), ... ,D(vk),D(Ak)) = h(D(Ak'))
k
By Kleene's s-m-n theorem there's recursive function f such as
v
f (D(Ak)) = h(D(Ak')) , otherwise f (D(Ak)) = h(D(Ak'))
f (D(v1), ... ,D(vk)) f
v v

Let's minimize lengths {|D(vk)|} so that above mentioned rules are
acceptable.
Let D'(v min) conform to some "effective" algorithm U generated by
Markov's normalization principle applied to minimal |D(v)|.

Then

VIRUS v of automaton A (otherwise, automata's set {Ai}) in
environment E, which executes algorithm U ( denote as v (A ) ),
U E
i s either

(a) An automaton which realizes an algorithm of the A automata's infection
-1
over environment E (otherwise, some E' = h (f (E)) ) and
v
can be normalized to the algorithm U,

or

(b) A description with which some automaton B can be able to realize
an algorithm ... ( and so on as in (a) )

Denote set {D(vk)} as VIRAL set (See also F.Cohen's paper "Computational
aspects of computer viruses"...)

2. Classification ( Re: taxonomy ... )

Classification should combine as well as environments and viruses classifi-
cation.

I see four environment (E.) classes:

(I) Stationary E. Software is never modified.
(II) Computer time-shared systems with software under design and debugging.
(III) E. with self-modifying or/and self-reproducing software.
(IV) Viral E. Automata's modification by one to another is allowed.

a3
Use signature a1a2 a4a5a6 to denote viruses's classes.
Here
a1 - a way of structure modifications during infection
a2 - type of an attacked object's function change
a3 - infection intensity
a4 - degree of concealment
a5 - infected level's specification (in hierarchy systems)
a6 - sign of ability to recognize a previous infection

We may omit signs which are not vital important.

In brief, these signs are following.

a1. Denote "S" if virus Substitutes an attacked program's piece for own code.
Denote "I" if virus Inserts own code into attacked program.
There're prefix- (denote "p"), suffix- (denote "s") and kernal-
(denote "k") viruses in von Neumann's machines.

I.e. Insertable prefix-virus (Ip-virus) is such as if D(A) = "w1w2...wn"
and D(v) = "u",
Ip
U
then there's yield D(A) =>* D(A') : D(A') = uD(A) = "uw1w2...wn"

Denote "m" if virus is self-modified.

a2. Let there're morphisms h(D(A))=f , h(D(A'))=f , h(D(v))=f and
v (A) k m v
U
D(A) =>* D(A'). There's function g(f ,f ) = f
k v m

Denote "A" if virus "Add" its function to the function of attacked
automaton ( function f is union of functions f and f )
m ----- k v

Denote "S" if "power" of f is less than "power" of above union.
m

a3. W.Gleissner introduced an integral sign of infection process :
(v)
"Let p_ denote the probability that starting from viral state
v,k _
v viral state v will be reached after exactly k program calls."
(See W.Gleissner. Theory for Spread of Computer Viruses)
(v)
If there's function f(t) = k then denote p(v,t) = p _ .
v,k
Let It(v) = d p(v,t) / d t denote the intensity of infection
(if there's the derivative, of course).

Denote a3 = max It(v).

a4. Denote "C" (Conceal) if virus uses i-level and doesn't use
resources of another levels (not equal i) or use them by miss
all allowed procedures. You see, it's analogous to "stealth".
We can denote "pC" (partial-conceal viruses), "nC" (non-conceal
viruses). It seems the definitions are clear.

a5. Denote "m-n" if vurus infects m higher levels, current and n lower
levels.

a6. Denote "R" if virus can be able to recognize earlier own infections.

0.001
Example: Let IpmS C-1R denote an insertable, prefix, self-modified,
substitutional with intensity of infection 0.001, conceal,
infecting an initial and one lower levels, recognizeable VIRAL CLASS.

Thanks.
Comments are welcome.

ps Excuse my possible awkward style, please. May be above ideas will be
useful to develope a computer viruses's theory? I'd like to introduce
compact record to denote CV classes, and to make more precise Cohen's
formal virus definition.

MxT

Maxim Titov, software analyst [email protected]
International Centre on Informatics and Electronics (InEVM)
Moscow, Russia

------------------------------

Date: Sun, 10 Nov 91 23:49:08 +0000
>From: [email protected] (Robert Levandowski)
Subject: Re: A couple questions (Mac) (Commodore)

AB5891A@ACAD writes:

>constantly be shut off. On a Mac, (OR IBM for that matter) if you
>want to increase the ANTI-virus protection, just after EACH
>application shut the system off. The virus MAY still spread, but then
>again, it may not.

DON'T DO THIS ON A MAC! If you turn off a Mac without quitting to the
Finder and selecting "Shut Down" from the "Special" menu, you risk
corrupting your disk and damaging any files you may have been
using--including your application. Simply turning off the Mac after
using an application does not give the Mac the chance to properly
update the disk or any open files.

.and some Mac viruses will continue to spread anyway. In fact, most of
them will if you are using MultiFinder or System 7.

- --Rob Levandowski
Computer Interest Floor / University of Rochester

------------------------------

Date: Sun, 10 Nov 91 20:42:11 -0500
>From: [email protected] (Alan J Rosenthal)
Subject: Re: Only Scan Floppies? (general)

[email protected] (Jesse Chisholm AAC-RjesseD) writes:
>A perceived delay every time the user runs a program is sand in the gearbox.

agreed. But Disinfectant init on the mac scans each time the program is run,
and it is not a perceivable delay.

------------------------------

Date: Mon, 11 Nov 91 00:59:28 +0000
>From: [email protected] (Brian "Zamboni" Aslakson)
Subject: Re: A couple questions (Mac) (Commodore)

I tried to e-mail this, but all my attempts bounced.

In comp.virus [email protected] writes:
>Well, I use this MacIntosh SE that the school has provided me and it
>works nicely, but recently my roommate erased all of the anti-viral
>programs and thus I was prone for an attack, which occurred. An OLD
>virus, nVIR B, hit. No biggie, but the ANTI-virus program VIRUS
>DETECTIVE removed the virus resource, but didn't redirect the
>pointers, so I had a useless System, Finder, and Term program.

Why stress OLD? What makes it OLD anyway? (minor nit-picks)
Use Disinfectant and your chance of having the virus removed and your
System (and etc.) still working are greatly increased. 2.5.1 is
current, if you can't find it, let me know...

>I also own a Commodore 128. Strangely, over the 6 years I have had it

>What makes the difference between the two is this, one is constantly
>on - going from one application to another, while the other has to
>constantly be shut off. On a Mac, (OR IBM for that matter) if you

What??!! Are you wacked?

>want to increase the ANTI-virus protection, just after EACH
>application shut the system off. The virus MAY still spread, but then
>again, it may not.

Oh, I see your point. That is not the proper attitude to preventing
infection, and stopping the spread. If you have a virus-infected app,
it can spread to another app without it running (many IBM viruses work
that way). Also, viruses that infect the system won't care what app
you are running. Your solution doesn't provide anti-virus protection,
it just annoys the user and MAY slow the spread of a virus. BUT it
probably won't. If you let a virus sit on your machine, you are
making a big mistake.

The real solution: Use Disinfectant (or something current and respected
such as SAM 3.whatever) from a locked, known clean, bootable floppy. Boot
from it and check your harddrive and floppies (don't forget to check all
floppies). Install the Disinfectant INIT (from the menu, very simple),
and check new things coming in (including shrink-wrapped material). Also,
install GateKeeper (1.2.1 is current) in your system.

Disinfectant (& INIT) look (and watch) for known viruses, while Gatekeeper
watches for virus-like activity. Both products are FREE!!! Both products
are available on the net (both authors are on the net) and are well
respected.

>Another reason why my Commodore can't be infected is that it has its

Can't?

>DOS in ROM not in a modifyable DISK which is then loaded into RAM.

You don't know much technical about Macs then. There is a lot of the
Mac's Operating System in the Mac's ROM. In fact, the Classic can boot
from ROM. BUT ROM's _can_ be patched (otherwise bugs would kill you,
and old models couldn't be improved).

>Both are loaded into RAM, but on the Commodore, it cannot be changed
>with software.

What I think you mean is "If I boot from ROM only on my Commodore, the
ROMs can't be infected".

>ParaPsykotically Yours,

Uh-huh.

Brian
- --
signature: No such file or directory

------------------------------

Date: Mon, 11 Nov 91 16:59:00 +1300
>From: "Mark Aitchison, U of Canty; Physics" <[email protected]>
Subject: Re: Disk Compression (PC for now)

padgett%[email protected] (A. Padgett Peterson) writes:
>> [ what I wrote about viruses having trouble with compressed partitions]
> Doubt it - the Jerusalem (& any other virus that follows DOS Disk access
> techniques) will work just fine. What is going to have trouble is anything
> that tries to lock/access the FAT directly.

What I meant was the combination of compressed disks plus other
(simple) software protection. For example:

User programs --> DOS --> Compression system --> ReadOnly driver --> int 13

(Or, perhaps, DRDOS password protection in there as well). Obviously
viruses that go via DOS get blocked by the "readonly" software
protection driver (say, DMDRVR.BIN or DISKGARD or DS II?), but (as
many have debated recently) it is easy to bypass software protection
and call interrupt 13 directly. But in this case it doesn't do the
virus any good, since they bypass the compression system when they
bypass DOS and the Readonly driver. This leaves them with junk which
the virus will either not be able to interpret, or will make a mess
of, or will require much more complexity in the virus to do the same
job as whichever compression system was used.

Now, my worry is with viruses that do, in fact, try to manipulate the
disk behind a compression scheme. That's probably getting too far
ahead of the play, of course, since few people use the above
combination of software yet, so I doubt anyone has started writing
viruses to get around it! However, that is inevitable in the future,
if (a) such combinations of software block other viruses and (b) that
software becomes popular - not just with the relatively few people
that bother with anti-virus measures at the moment, but others
interested mainly in saving disk space, etc.

>... Windows...blows up & am left with a corrupt disk...

That might be the requirement that the TEMP dir be placed in a
non-compressed area, highlighting the problem some software has if it
tries writing directly to areas on the disk. In effect, Windows is
"naughty", I guess, since it tries to bypass too much. Programs like
Norton's DS are only slightly naught, and go in at the interrupt 26
level (I think), which is still possible - I don't know what fraction
of viruses use interrupt 26 instead of interrupt 13 or interrupt 21
(anyone with an approximate percentage?) but these are the ones that
probably get past a combination of compressed partition plus DRDOS
password protection, but not read-only software in conjunction with
compression.

Mark Aitchison.

------------------------------

Date: Mon, 11 Nov 91 07:12:00 -0500
>From: [email protected]
Subject: two (2) excerpts from FIDO VIRUS echo conference

- ----- begin forwarded message #1 ---

To: All Message #: 3574
>From: Gary Watson Submitted: 09 Nov 91 16:35:00
Subject: H/w anti virus idea Status: Public
Received: No Group: VIRUS (30)

I think I have a way to modify an existing product that we
manufacture at my company into a virtually infallable
anti-virus device for scsi disk drives running MS-DOS. We
currently build a RAID-0 controller, which is a device that
fits between a SCSI controller in a PC-AT and an array of
target disk drives. Our code name for this device is "SSPT."
The firmware on the SSPT is in EPROM. The SSPT intercepts all
disk requests and parcels them out to the target disks
according to certain rules. My firmware has the option of
rejecting operations that it doesn't like, and the PC can't
get around it. So here's the plan: the user flips a switch
on my SSPT board to the "System Configure" setting.

The SSPT allows all operations to go through, except a bit of
the disk is reserved for internal use. The user loads up
MS-DOS, including the boot sector and hidden files, and all
application software from KNOWN CLEAN master floppies. He
then turns off the "System Configure" switch. The SSPT then
goes out and makes a record of all .EXE, .COM and .OVL files,
the hidden files, and their corresponding FAT and directory
entries. This info is stored on the reserved disk area. On
subsequent boots, this information is loaded into SSPT ram.

Obviously the SSPT's job is to make sure that disk writes do
not hit any of the protected files, nor delete their directory
entries, nor fiddle the appropriate FAT bits. There could be
a "System Upgrade" switch that allows new .EXE etc. files to
be added to the protected list. The SSPT board as currently
produced has a microprocessor, eprom, ram, two scsi chips, two
scsi connectors, a serial port, a 2x20 char LCD display,
led's, switches, and a loud buzzer. It could be programmed to
raise hell when someone is trying to infect the scsi hard
disks. Or, in a university setting, it could send a signal
down the serial rs-232 link to a professor's office so he
could catch the culprit in the act.

This board would sell for about $400, so it would be most
applicable to network servers, bbs's, or large and expensive
scsi disks (say, 1.2 GB and up.) In the longer term future,
this stuff could be incorporated into the scsi controller in
the AT system, for little additional cost. The user would
have to insert an electronic key into a port on the board to
allow tampering with protected files. The only type of virus
that I can think of that this system couldn't guard against is
the one that adds a .COM file with the same name as a legit
.EXE file. But there are easy preventions for that trick,
like a program, included in the protected list, that on boot
up it scans all directories for any file that exists in both
.EXE and .COM form, and screeches at you if they are found.
Of course, a sloppy user could add add'l programs to his
system that are infected, but since the critical system boot
stuff is protected, the virus can't become memory resident
unless that program is executed after boot. Any comments?

- --- VP [DOS] V4.09e
* Origin: The Programmer's Inn - FeatherNet Home (619)446-4506 HST
(1:10/301)

- ----- end forwarded message #1 ---

Any comments from our resident hardware gurus? Seems an interesting
concept, except for its price, which will deterr a lot of individual
users...
Cl.

- ----- begin forwarded message #2 ---

To: All Message #: 4207
>From: Antony Purvis Submitted: 09 Nov 91 19:02:00
Subject: Destruction! Status: Public
Received: No Group: VIRUS (30)

The news agency NEWSBYTES recently carried this report:

VIRUS UPDATE Canada
Virus kills FDD

A particularly nasty virus has forced Queen's University to replace
diskette drives in three personal computers. A fourth infected
machine was caught in time to save the drive.

Doug Crowe, manager of computing services at Queen's, told
Newsbytes three personal computers from a public lab were brought
in with their diskette drives "just cooked."

Apparently the virus, a variant of the 1575 virus also known as the
Green caterpillar virus, forces repeated accesses to track 0 of the
diskette until it wears out the drive mechanics if not stopped in
time.

Crowe said the IBM diskette drives cost C$375 each to replace.

Publicly accessible computers at Queen's are protected by virus
detection software, Crowe said, but the software failed to catch
this particular virus.

A fourth PC was brought to computing services staff with its
diskette drive making a repeated clunking noise.

Crowe said the noise was rather like that of an eight-inch diskette
drive like those used on minicomputers, word processors, and early
personal computers in the late 1970s and early 1980s, but
definitely abnormal for today's 3.5-inch drives.

In this case staff were able to remove the virus before the drive
was destroyed.

-----

Anyone got any comments? Newsbytes isn't exactly the most reliable
of agencies, it must be said. (No disrespect to them)

Ant

* SLMR 2.0 * House House House House House <Piano> ... ARGH! AAAGH!

- --- WM v1.01c/91-0104
* Origin: SANCTUARY BBS 44-329-236612 HST/DS (2:251/17)

- ----- end forwarded message #2 --

I know nothing myself about "Newsbytes". Our Canadian readers may be able to
give us more details about that new/mutated (?) virus.

I myself found information about the so-called "ansi-bombs" (embedded escape
sequences doing dirty tricks), but nothing like that. The closest description
to the above mentionned virus called for an ansi-bomb capable of doing the same
trick on a hd, and not a floppy. The usal target of ansi-bombs, btw, are
BBS's, where bombs left inside an e-mail msg can do a lot of damage (e.g.
refformatting the hd, creating enough files to fill the hd, etc).

Best to all, Claude.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Claude Bersano-Hayes HAYES @ URVAX (Vanilla BITNET)
University of Richmond [email protected] (Bitnet or Internet)
Richmond, VA 23173

------------------------------

Date: Mon, 11 Nov 91 11:20:19 +0000
>From: [email protected] (Alexis Rosen)
Subject: Re: A couple questions (Mac) (Commodore)

[email protected] writes:
>Well, I use this MacIntosh SE [infection story deleted]

>I also own a Commodore 128. Strangely, over the 6 years I have had it
>I have never once had a single virus in it. Recently a few trojan
>horses appeared, but they were easy to spot.

>What makes the difference between the two is this, one is constantly
>on - going from one application to another, while the other has to
>constantly be shut off. On a Mac, (OR IBM for that matter) if you
>want to increase the ANTI-virus protection, just after EACH
>application shut the system off. The virus MAY still spread, but then
>again, it may not.

Bad analysis. On the Mac, you will still infect the Finder, and in
many cases the system. From there, any binary you run will be
infected. On DOS, the possibilities are endless, and I'll leave them
to those better equipped to discuss them.

>Another reason why my Commodore can't be infected is that it has its
>DOS in ROM not in a modifyable DISK which is then loaded into RAM.
>Both are loaded into RAM, but on the Commodore, it cannot be changed
>with software.

Now, that's a lot more cogent. Unfortunately, there's little there to
help Mac users, or most DOS users (there are a few rare DOS machines
with DOS in ROM, but that's not likely to prevent many PC viruses from
attacking).

- ---
Alexis Rosen
Owner/Sysadmin, PANIX Public Access Unix, NYC
[email protected]
{cmcl2,apple}!panix!alexis

------------------------------

Date: 11 Nov 91 14:38:18 +0000
>From: [email protected] (Vesselin Bontchev)
Subject: Re: Virus Proof Machine Response

[email protected] (Chris Stops) writes:

> According to the '386 book I have here, LIDT is allowed in real mode
> so that the processor can be set up for protected mode. The '286
> should be the same. But once protected mode is established (as on my
> virus proof (?) machine), the LIDT instruction can be used only at the
> highest privilege level. So no virus hiding in an application program
> can do an LIDT.

Oh, sure, if the machine already is in protected mode, it can stop
that. I was talking about the current machines, running Messy-DOS.
What I had particularly in mind, was a virus I was told about by the
author of the TP family. I don't have an example of it, so I don't
know how exactly it worked, but I'm sure that it ran in real mode only
and used the LIDT/SIDT instructions. I thought that these instructions
are supposed to run in protected mode only, that's why I asked. I was
wrong, obviously.

> >Why not just deny the write access to the executables?

> I think you must also deny reading executables. If not, for example, a
> virus could READ an executable into memory and then CREATE a new copy
> of the executable which includes the virus. And to the machine,
> re-creating an existing executable would look innocently like someone
> re-compiling a new version of an old program.

Yeah, because a compilers fits Cohen's definition of a virus... :-)
But, you can deny file DELETION as well. Or ask for confirmation. Or
allow a program to write only to those files that it has created
and/or those that have been supplied at the command line as arguments,
when the program has been called...

BTW, even if you forbid reading from files, you still have the
possibility to build a virus that simply deletes the file and creates
a new one (with its body inside) with the same name... Something like
the current overwriting viruses...

> >It's enough to forbid the non-executable --> executable extension
> >renaming.

> I think you must also forbid executables being turned into 'data'
> files. If not, for example, a virus could turn an executable into a
> 'data' file, read the data file, and then CREATE a new copy of the
> executable which includes the virus.

It can CREATE it, OK, but it won't be able to WRITE it on the disk, if
you forbid writing to the executables... This will cause problems on
compilation, however.

> >Also, don't forget about the companion viruses.

> Could be knocked out by changing the file and/or executable naming
> system, so that two executables with the same name cannot exist. For
> example, if my machine has lots of memory, why don't we simplify
> things and forget about COMs, and just have EXEs (or their non-80x86
> equivalent)? It'll probably be OK, as applications continue to get
> bigger.

Hmm, the above seems a good idea... More exactly, one can rename all
EXE files to COM extensions and compile all BAT files with something
like BAT2EXEC... If all executable files have only COM extensions, the
companion viruses will simply not work. (DOS itself will be able to
recognize the file type, by the first two bytes of the file.) The
problem is: are the companion viruses such a threat that one must
perform the above operation? I don't know...

> Yes, I was aware of this. In reply, anything in source code or ASCII
> form should be easy to spot in an editor, or the file dates will be

"Easy to spot" is easy to say... Will you be able to spot a
source-infector if I give you the source of a chess program, which is
some 60,000 lines in C? And everybody who has won the "Obfuscated C
contest" is able to "hide" his/her source's meaning in a much smaler
program...

> As for anything like an OBJ or similar compiled code infector, I don't
> think it will spread because...

> 1) People don't tend to swap .OBJ files like they swap executables.

Yes, but they do swap the executable that are made from those .OBJs...

> 2) Computer USERs (e.g. people doing word processing) won't tend to have
> OBJ files anyway, even less swap them.

Yes, but even USERs love to play games that are linked from those
(possibly infected) .OBJs...

> 3) Computer programmers in user clubs etc. can swap source code instead
> of the .OBJs.

See my remark above about the possibility to hide a virus in source
code.

> ...And that leaves only infected .OBJ files from commercial
> programming packages being copied amongst users. I would not have
> thought a virus could spread much in these conditions. True, they can
> exist. But spread very far? I think not.

You are probably right, but I didn't say that the virus will spread
far, just that it will be possible to design it. And maybe, if
everybody relies on this protection and gets a false sense of
security, it will spread unnoticed anyway?

There is a Bulgarian virus, called Compiler, which infects only when
the files change their size or are created. This usually happens only
in program developpment environments. Nevertheless, this virus did
spread in Bulgaria, although not very widely...

> >This is no problem if you forbid only writing, but allow
> >reading/creating.

> See above for why I think we must forbid reading.

Note that Creating a file is not enough to put code in it. You have
also to Write to the created file...

> To reword my description: The switch is a hardware switch mapped into
> a protected I/O location. (Possibly a KEY switch to be secure against
> rogue users. But that's another matter). The I/O location is
> accessable only to the high priority O/S kernel. There are NO
> operating system calls to allow an application to interrogate about
> the state of the switch or to over-ride the state of the switch.
> Therefore, the operating system can read the switch, the user can
> alter the switch WITH HIS HARDWARE KEY, but no virus can have anything
> to do with the switch, apart from having its operation scuppered!

Oh, I didn't get that you're speaking about protected mode and memory
protection in general... Then indeed, you are right, it is equivalent
to the hardware switch and it will work as well.

> What we have achieved is:

> 1) Stopped all boot viruses.
> 2) Stopped all viruses hiding in the O/S code.
> 3) Stopped any virus going resident and patching into the O/S.
> 4) Stopped any virus attaching to an executable application.

What did you left?

1) Viruses that infect files that will become executables (sources,
OBJs, LIBs, etc.).
2) Viruses that infect interpretted code (macros).
3) Viruses that spread only when the protection is off.

Is it good? Sure, it is. Much, much better than the Messy-box. Sounds
much like a Unix-box. Did you stop the viruses completely? Of course
not, this is not possible. Did you get a useful machine? Yes! Is it
compatible with the Messy-box? No! and needs not to be... Now you have
only to convince all these Messy-box users to forget about their messy
programs and to switch to the much better conception... :-) A though
task, IMHO...

> 3) It is a *little* more difficult to write a TSR/device driver etc.

In fact, as you are going, you could implement multitasking, device
monitors and all that jazz and just forget about the TSRs... :-)

> A massive improvement in security. I think that viruses would become

But, in order to stop viruses, you need to improve the integrity...

> so difficult to write and spread that the machine would have no
> noticable virus problem, and certainly nowhere near today's scale of
> things for the PC.

True. They will probably become as widespread as the current Unix
viruses. Which is just fine for most users... :-)

> So the machine is USEFUL in the sense that it can run all the
> applications we ever need to with relatively good security.

The point is that you still haven't solved the problem with the
possibility of a virus attack. When Cohen pointed out this security
threat, he didn't have in mind that lots of smart kids with some (or
even none) system knowledge will begin to write huge lots of nasty
viruses, that exploat the total lack of protection on Messy-DOS. He
said that even the most well protected machines are not invulnerable
against this (completely new) form of attack.

> I'm a PC user doing university research in microprocessors. So I know
> a bit about DOS programming, what a mess PC's are, and I know about
> the 80386 protected mode. But I don't know much about Unix.

Oh, give it a try... You'll love it! It's an OS for REAL
PROGRAMMERS... :-))

> ...and about 40 Million PC users who probably don't want to upgrade
> their machines. Maybe if we could get more people to write
> disk-trashing stealth viruses, we could *DESTROY* the MS-DOS world and
> start afresh with *MY* new breed of machine? Oooops, now I'm starting
> to sound like a baddie from a James Bond film!

No, you are sounding like some people that created and distributed
sophisticated self-encrypted and mutating viruses just to show that
scanning is unreliable. Or that released a worm on 6,000 computers on
the Internet just to show that it's security is not good enough... No,
this is not an acceptable solution.

> If you (Vesselin) want to answer any of my points, but you think the
> list readers are fed up with this hardware vs. software discussion,
> feel free to mail me directly.

Oh, I don't mind if this arrives to you late. I just thought that some
of the points expressed here might be interesting to the other readers
as well...

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: 11 Nov 91 13:46:20 +0000
>From: [email protected] (Vesselin Bontchev)
Subject: Re: Regulation of (Medical) Software

[email protected] (Paul Stachour) writes:

> There are certificates of security.
> They are provided though NCSC (the national computer security center).

It depends on what do you call "security". The guys at the NCSC seem
to mess "security" with "integrity". In fact, what most people
understand under security is secrecy, not security. This is normal,
since before the advent of computer viruses, most of the demands of
the market came from the military, who needed secrecy.

Just an example. The Bell-LaPadulla model of secure computer
environment, on which (I was told) the most secure military computers
of the USA are based, is just as helpless aginst a virus attack, as
any IBM PC computer. The protection protects the information on these
systems from being leaked, but it does not protect it from being
infected... since computer viruses are not a secrecy problem, they are
an integrity problem.

Now, there is also the so-called Biba model of integrity protection.
It can stop viruses from infecting protected areas, but does not stop
the information from being leaked from these areas.

At last, one could combine both models and achieve a system, which no
virus can prenetrate, and from which no information may be stollen. As
a side-effect, unfortunately, you also get a pretty useless system, on
which no user can send any information to another, or even get any
updates of any programs. Not to speak that no information about the
system resources is available (that is, you are forbidden even to
ask about the available disk free space), in order to close the covert
channels... :-(

> In my opinion, MS-DOS does, and always will, have trouble getting
> off the bottom-rung of the ladder.

IMNSHO, Messy-DOS does enven have problems to climb to this
bottom-rung... :-)

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: 11 Nov 91 13:13:49 +0000
>From: [email protected] (Vesselin Bontchev)
Subject: Re: Hardware? How about software...?

[email protected] (Fred Waller) writes:

> > We have UNIX systems with a Software-switch-off function. If an
> > "Antiviral" package immediately activates this function the system
> > will be switched off and can not be infected. Is this Hardware
> > protection? No, because Hardware alone can not do it (it will not
> > switch off by itself). Is this Software protection? No software
> > alone can not do it (after software triggered the hardware, the
> > hardware will switch the system off).

> Fascinating. That's exactly how Mark Washburn's SECURE program
> works under MS DOS, only I was led to believe here that SECURE

Yes, SECURE is not useful, since it works under MS-DOS, where there is
no memory protection, so any sufficiently clever program can disable
it. This does not mean, of course, that the -method- on which SECURE
is based is also useless. It can be pretty useful (although not virus
proof!) if implemented correctly under a correct operating system.
Unix has had something similar for years. And it was even not the
first one...

> wasn't useful. Could it be that such methods, first pioneered by
> Ross Greenberg in FluShot, and then expanded by Washburn in SECURE,
> are a good way of doing things, after all? Better than string
> scanning?

These methods are just one of the good ways to do things. The problem
is that because of the lack of memory protection, they all can easily
be circumvented on a PC, and updating them is much more difficult than
updating a scanner. As a result, the scanners are easier to produce
and sell. Neither of the methods (capabilities or scanning) is
virus-proof, regardless of the memory protection, but you said that
you want only virus-resistence, not virus-proofness...

> I always thought it was better, but with all the protestations here,
> I had more or less given it up. Should we retake the subject of
> SECURE, then? If it's good, then we should look at it much more
> carefully, even as a model for other antivirus software.

No, it is not good, unless there is a method to protect the program in
memory. A version of SECURE that runs in virtual mode might be a good
idea. Again, I repeat that it won't be able to stop all possible
viruses. Another useful idea is the integrity shell, according to Fred
Cohen...

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 216]
******************************************

Downloaded From P-80 International Information Systems 304-744-2253