VIRUS-L Digest Wednesday, 6 Nov 1991 Volume 4 : Issue 211
Today's Topics:
computer virus ^2
Taxonomy
Hardware...
Virus removals vs. Virus classification
Efforts
Re: where can I get a copy of "When Harlie Was One"?
Re: Disk Compression (PC)
Re: Questions about VIRLIST.TXT (PC)
Re: from fidonet virus conf: new virus found? (PC)
Re: Zipped files (PC)
Am I infected ? (PC)
Availability of "Harley" book
DOS viri on the MAC... (PC) (Mac)
Re: Regulation of (Medical) Software
RE: Virus Proof Machine Response
Re: McAfee84 failed to remove Joshi
Problem with Stoned virus (PC)
ViruShell - New Shell for SCAN - Great (PC)
fprot201.zip on risc (PC)
VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed. Contributions should be relevant, concise,
polite, etc. Please sign submissions with your real name. Send
contributions to
[email protected] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list. Administrative mail (comments, suggestions,
and so forth) should be sent to me at:
[email protected].
Ken van Wyk
----------------------------------------------------------------------
Date: Mon, 04 Nov 91 20:34:39 -0500
>From:
[email protected]
Subject: computer virus ^2
We've heard all about the usual stealth computer viruses and "armored"
viruses that are being written these days. It seems that in some
places the writing of nasty viruses has become a national pasttime.
Some of these authors delight in finding new methods of damage and
camouflage. The problem has mainly been for IBM PCs, and the most
sophisticated virus-writing has been in Bulgaria and the USSR.
Now, however, we have a new and far worse problem from South America,
according to the November 12th issue of the "Weekly World News."
[This is the "newspaper" you may find at supermarket checkout lines
with the kind of headlines you don't see in the more mainstream media.
Obviously, a conspiracy by the mainstream media. The November 12th issue
is headlined with "Ohio Woman has a 3rd Eye -- in the back of her head!"]
On page 7, there is an article by one Sally O'Day, "special to the WWN,"
and entitled: "Demon Computer Kills 2 Workers!" It is subtitled "Exorcist
called in after experts discover virus-bred evil spirit!"
The article goes on to explain how a computer system installed in a bank in
Valparaiso, Chile is possessed by a demon. A consultant from the computer
company that installed the system claims that it must be the result of a
virus installing an evil demon that has caused:
* observers to see a hideous horned demon appear on the screen
* anyone who tries to turn off the machine to black out and fall to the
floor
* Carmen de la Fuente to have a fatal heart attack within 2 minutes of
sitting down at the terminal
* Maria Catalan to be found sitting at the terminal with her head in her
lap [decapitated, I presume, rather than a contortionist]
* a computer expert to began babbling like a madman when he got within
10 feet of the terminal
This brings up many interesting questions:
-- How long before commercial anti-virus vendors start advertising
that their products work against this type of virus?
-- Does the exorcism ritual end with extinguishing the candle, closing
the book, and sounding the BEL?
-- Could this actually be the result of using Ada rather than a virus?
-- Do you know any computer experts who don't begin to babble when
within 10 feet of a computer?
-- Does normal business insurance cover an exorcism?
-- Maybe it's a Unix system and this is the first time they've seen
the sendmail daemon?
-- Will Fred Cohen allow this to be entered in his virus-writing contest?
Or, it could be that Ms. O'Day has recently seen the movie
"Evilspeak"?
[If you have yet to see the movie, rush right out and rent it. Lay in
a supply of beer and pizza, and invite the neighbors over. It is a
classic wherein a nerdy Ken Howard (Ron's little brother -- the one who
used to hang out with Gentle Ben) summons up the devil on an Apple II
computer. He should have guessed something was amiss when he started
getting Stardent-level graphics on his little Apple, and when it
started demanding blood sacrifices. The credits include mention of the
"stunt demons" and "Satan's Sows." Not to be missed.]
Hey, it must be true if they printed it, right? :-)
------------------------------
Date: Mon, 04 Nov 91 20:22:57 -0800
>From:
[email protected] (Fred Waller)
Subject: Taxonomy
Writes
[email protected] (Fridirik Skulason):
> Maybe the following may start some useful discussion.....here
> is a list of the PC virus families I currently recognize - in
> alphabetical order.
> ........................
(long list of virus names deleted)
> ........................
Those are not virus families, those are single virus names. Since
no information whatsoever is given as to which viruses he would like
included in each of these "families", the list is not very useful.
The list consists of over 270 names. How does it relate to the NIST
proposal? Is it being suggested that known viruses should be simply
divided into 270 "families", without any rationale being presented
for such division, without even listing what individuals fall in each
"family", or why? That seems rather sloppy.
At this rate, it might pay to just leave them alone, unclassified.
Who needs classification, if the first level of subdivision consists
of 270 taxa! :-((
Fred Waller
[email protected]
------------------------------
Date: Mon, 04 Nov 91 20:20:28 -0800
>From:
[email protected] (Fred Waller)
Subject: Hardware...
Writes
[email protected] (Fridrik Skulason):
> Correct - and this hardware already exists - it is known as
> the "off switch" - simply leave the computer off at all times,
> and it is 100% secure against viruses.
This is an original solution and should be implemented at once.
Thanks to Fridirik Skulason of Iceland. We need more suggestions
like this one!
> Protected mode is dependent on hardware capabilities
EVERYTHING that happens on a computer is dependent on hardware
capabilities. Including viruses. And antiviruses.
> (Protected mode) ...can be circumvented,
Correct. It can be circumvented, and offers no inherent protection
against malicious software, any more than any other software.
Which illustrates that no software protection is ultimately useful;
it can always be defeated by other, newer software.
> ...just as any hardware "solution".
False. Hardware offers inherent protection which is totally
undefeatable by software in the realm where applied. This is
not true of software.
Runtime software is a function of hardware, but not the other
way around. Hardware protection is permanent. Doesn't need to be
updated for each new software attack.
> If the computer is not an embedded system,
That's one "if"...
> if it ever runs programs "from the outside"
...and that's another "if"...
> and is designed to allow "useful stuff", like program
> development,
...and a third "if".
Fortunately, most computers in the world are not used for writing
programs, and some restriction of the other parameters is readily
allowable.
> it is possible to write a virus for that system,
> REGARDLESS OF ANY ANTI-VIRUS HARDWARE ON THAT SYSTEM!
Well, if I were a software publisher, I'd probably say the same
thing.
A virus can be _written_, of course (anything can be written),
but it cannot defeat sensible but simple hardware protection.
Ever.
Fred Waller
[email protected]
------------------------------
Date: Mon, 04 Nov 91 20:22:03 -0800
>From:
[email protected] (Fred Waller)
Subject: Virus removals vs. Virus classification
Writes
[email protected] (Fridrik Skulason):
> This is not what was being said -
What Vesselin Bontchev wrote was that because some virus-removal
program managed to remove a certain virus from an infected file,
then that virus must belong to the family of viruses for which the
removal program was designed. First, the inference is not strict.
Second, the "family" he was talking about remains un undefined
entity. Third, from a technical standpoint, the use of a curing
program to make a taxonomical classification is abominable.
> The program in question is able to determine...
A program isn't "able" to do anything. It does whatever it was
programmed to do. Period.
> ...that the Fu Manchu virus is related to Jerusalem, that it
> is structurally very similar,
It doesn't determine any such thing. It only determines its
infective effect on the file, not the virus' structure. A great
many viruses append themselves to the end of infected files and will
change the beginning of the program to point at the virus so that it
gets executed first. If the size of infection and other changes can
be determined accurately, the virus can be removed and the original
program restored. All this has little to do with "structural
similarities" of the code, except in a most general and elementary
way.
> and that it can be removed in a similar way.
Many viruses can be removed in a "similar" way. It doesn't mean they
are taxonomically related.
Note that I'm NOT SAYING that the Fu Manchu virus DOESN'T belong to
the Jerusalem family - it may or it may not. But using a virus-
removal program as a taxonomical tool is improper - it isn't intended
to be one UNLESS everybody agrees that all our virus classification
will be done not on the basis of virus structure, nor on the basis
of virus behavior, but on the ability of somebody's virus remover
to recognize them... clearly a ridiculous proposition.
Fred Waller
[email protected]
------------------------------
Date: Mon, 04 Nov 91 20:24:25 -0800
>From:
[email protected] (Fred Waller)
Subject: Efforts
Writes padgett%
[email protected] (A. Padgett Peterson):
> the effort required to breach a software defense is greater
> than that required to erect it. This comes about because the
> defender has the advantage of being on home ground & has a
> "world view" of the system.
I believe this is not true. As said earlier, virus-writing is not a
cost-conscious activity, while antivirus protection most definitely
is. Virus authors have the luxury of spending hours, days, weeks or
months probing and testing until they find a weakness. Antivirus
authors work to earn a living, sell their products and must perforce
be cost-effective. It's really just the reverse of what Padgett
claims. And it's not true that defenders are "on home ground" while
the attacker is not. Some virus writers seem definitely better
acquainted with PC hardware and software than any antivirus
publisher I know. Witness, for example, the Whale affair.
Anyway, the proof of the pudding is that, until now, the antivirus
publishers have been reacting to attack, and usually unable to keep
up. To this day, the antivirus publishers have been unable to take
the initiative in the virus/antivirus contest.
> The attacker on the other hand is faced with a two-dimentional
> viewpoint and must peel away a layered defense like an onion:
> each layer may reveal a new defense structure - a very hard task
> to automate since the attack being via software means that the
> attacker must anticipate ALL possible strategies while the
> defender needs only one (hopefully unknown).
If the attacker thought as simply as the defender seems to in this
case, the attack would indeed be made layer-by-layer, as Padgett
suggests. But it's often possible to bypass all of those "layers"
in one shot. Quite a few viruses have done that. It's all a matter
of ingenuity. All it takes is to find a new FORM of attack, and all
the layers become useless. It's been done many times, as Padgett
must know. For example: one can protect each and every executable
and data file on disk with CRC and checksum checkers, etc. Then
comes the Companion virus and blows right by all the defenses. So
one erects defenses against that. Then comes the DIR II and takes
care of _them_. Enough said?
Software cannot ever provide a permanent defense against software.
Fred Waller
[email protected]
------------------------------
Date: 05 Nov 91 09:12:25 +0000
>From:
[email protected] (Gene Spafford)
Subject: Re: where can I get a copy of "When Harlie Was One"?
[email protected] (JESUS BARRERA RAMOS) writes:
c...I've been lookin' for a copy of the book "When Harley Was One" but
I've found it yet...does somebody know where can I get it?...please..I'd
thank ya more than a lot..c ya. thanx.
I'd suggest a public library, or a bookstore that carries used
paperback books.
Note that there are two editions of Harlie....the second edition,
issued in the mid 1980s, was "cleaned up" by the publisher to remove
things they felt were too far-fetched. The whole subplot about Harlie
and the virus is not in this revised edition (I have been told), so
try to read the original edition.
- --
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: 05 Nov 91 09:35:07 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Disk Compression (PC)
padgett%
[email protected] (A. Padgett Peterson) writes:
> >Oh, no! It is enough that the users are trying to force the producers
> >of virus scanners to scan inside self-compressed executable files...
> >They really don't need to be forced to handle also Stacker/SuperStore/
> >DoubleDisk, etc. formats!
> They may not have a choice - I see this as the next real "must have"
> utilitiy as no-one ever has enough disk space. Meanwhile LZEXE and
> PKLITE have proven that the extra time required to decompress in
> memory is less than the time gained from reading half the number of
> sectors.
[explanation why compression is good deleted]
Oh, I didn't mean that there should not be an compressing programs!
What I think, however, is that all this has nothing to do with virus
scanning. Each producer of compression programs must provide a way to
decompress the compressed stuff. The virus scanners must only be able
to detect whether a file is compressed or not and warn the user.
Furthermore, we also need a shell that is able to decompress the
compressed programs, run a user-selectable scanner on them and delete
them if any viruses are found. Something like SHEZ does with the
archives.
Now, we don't require that scanners scan inside the archives, do we?
Or inside uuencoded, xxencoded, etc. files and all that jazz... We
only need a way to restore the original state of the program and then
we can scan it safely.
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: 05 Nov 91 09:54:43 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Questions about VIRLIST.TXT (PC)
[email protected] (McAfee Associates) writes:
> >and files? If this last hypothesis is true, why the Horse Boot,
> >Invader and Virus-101 (all listed as able to infect boot sectors and
> >files) aren't listed in the same way?
> The Horse, Invader, and V101 viruses are what's known as multipartite
> ("multiple part") viruses. What that means is that they infect both
> files and the boot area of disks when they are accessed once the virus
> has become installed in memory.
Sorry, but the Horse Boot virus is -NOT- a multi-partite virus!
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: Tue, 05 Nov 91 11:21:41 +0000
>From: Fridrik Skulason <
[email protected]>
Subject: Re: from fidonet virus conf: new virus found? (PC)
>com's with 1220. It shows a message:
> "TRAVELLER (C) BUPT 1991.4 don't panic I'm harmless."
>There is no ather payload then the messages. The virus infects
>infected files over and over and over end.... Question: Does ^[es
>BUPT ring a bell ???
This is not a new virus - It has been known since Aug. 5, when it was
first reported by RG Software. It is said to be known in the wild in
USA. F-PROT 2.01 can detect and disinfect it, but I don't know about
other scanners (except SCAN84, which doesn't).
- -frisk
------------------------------
Date: 05 Nov 91 11:39:55 +0000
>From: Daryanani <
[email protected]>
Subject: Re: Zipped files (PC)
[email protected] (Jeffry Johnson) writes:
>Are there any programs which will scan inside of Zipped files?
There are several menu-driven front-ends for archivers such as ZIP and
LHA, that can unpack and scan executables in archive files. One that
I've used is SHEZ, which can make use of McAfee's SCAN program to do
the scanning. Of course since during setup it asks you the name of
the scanner program you could substitute another one if you wanted.
It may be easier finding these programs on Fidonet.
Raju
- --
Raju M. Daryanani
[email protected]
------------------------------
Date: Tue, 05 Nov 91 12:32:00 +0000
>From: Old Baldie <
[email protected]>
Subject: Am I infected ? (PC)
My apologies to all and sundry if this is a FAQ, but I'm wondering if I am
infected :-).
My PS/2 55sx developed an odd condition without warning - memory is recorded
as 639K instead of 640K, but none of the anti-viral packages which I use has
been able to identify any virus being present.
It's a failure on my part, I know, but I wasn't aware that the RAM had been
reduced until I ran NEWDET (the only package which reports the size as being
suspicious) after installing a tapestreamer card.
At first, I thought that the newly-installed card was the culprit, but I have
printout (screen dumps) which record the 639K at an earlier point, and I do
recall seeing that size reported earlier without reacting to it.
I have asked around and discovered that a number of machines report 639K (one
reports 637) although none appear to have been infected. The owners/users are
not unduly alarmed.
Since my machine is a transfer point for sensitive data via floppy I have no
wish to pass any potential infection on to the rest of my unit or indeed to
departments outside, hence my mild paranoia.
I had wondered if a PS/2 specific virus had somehow got itself into battery-
backed system configuration RAM, but I can find no sources of information which
would confirm/deny this possibility.
I have checked through a list of known viruses looking for one which fits the
bill, but without success to date. If anyone can offer advice or (polite and
biologically feasible) suggestions, I would be grateful.
+--------------------------------------+---------------------------------------
+
| Peter G. Q. Brooks
[email protected] |
|
| Health Services Research Unit |
|
| Dept of Public Health & Primary Care |
|
| University of Oxford |
|
+--------------------------------------+---------------------------------------
+
| +44 (0) 865 224375 8.30 am - 7.30pm |
|
+--------------------------------------+---------------------------------------
+
------------------------------
Date: Tue, 05 Nov 91 10:11:42 -0500
>From:
[email protected]
Subject: Availability of "Harley" book
In response to Jesus Barrera Ramos' search for the novel "When Harley
Was One," it's available in paperback from Bantam Books, $3.95 (US).
It can be ordered from the publisher at: Bantams Books, 414 East Golf
Road, Des Plaines, Illinois 60016. If you need to have more ordering
information, there's a toll-free number for Bantam: 1 800 223-6834.
The ISBN number for the book (though it shouldn't be necessary to
order through its own publisher!) is 0-553-26465-6,Spectra. Hope this
helps!
Jeff Clark
Media Resources
James Madsion University
Harrisonburg, VA 22807
------------------------------
Date: Tue, 05 Nov 91 15:26:49 +0000
>From:
[email protected] (Chris Gleaves)
Subject: DOS viri on the MAC... (PC) (Mac)
Recently I heard a commercial for the Mac advertising a product called
"PC Soft" (I think...) it claims to run MSDOS software "just like the
pc's at the office" (I don't own a mac and NEVER would).
It occured to me...what if an infected program was run using such
an interface...would it infect other MSDOS software on the disk...
or would fail miserably, poosibly destroying the infected software.
I figured that someone here would have a comment...
Chris
------------------------------
Date: Tue, 05 Nov 91 15:24:50 +0000
>From:
[email protected] (Paul Stachour)
Subject: Re: Regulation of (Medical) Software
padgett%
[email protected] (A. Padgett Peterson) writes:
....
>Again IMHO, the first step must be some form of secure, certifiable
>operating system. Though much derided, MS-DOS (or DR-DOS), is an
>effective and widely used O/S. Most applications operate under these
>libraries & I would be surprised to see any sudden migration away from
>them.
>ERGO, what is needed is a certifiable (I know 8*) operating system or
>shell (more difficult but if MicroSoft & Digital Research continue to
>be disinterested -well, maybe not DR-, encapsulation will be the only
>answer).
>In any event, it may well be the Fed, in the guise of Medical safety,
>that will finally force integrity management on the PC. Well, we get
>tired of waiting for the lawyers to do someting useful 8*).
There are certificates of security.
They are provided though NCSC (the national computer security center).
In my opinion, MS-DOS does, and always will, have trouble getting
off the bottom-rung of the ladder.
However, as long as the acrediting agencies (hospital boards or
whatever) allow use of insecure, uncertified machines, in the
hospitals, we will have problems.
When/How/If the FDA or other agency choses to require some degree
of integrity, there will be a BIG shakeup in the way in which
information is managed.
Until then, I suspect they will continue in current ways.
Sigh! ..Paul
- --
Paul Stachour SCTC, 1210 W. County Rd E, Suite 100
[email protected] Arden Hills, MN 55112-3739
[1]-(612) 482-7467
------------------------------
Date: Fri, 01 Nov 91 14:26:46 +0000
>From: Chris Stops <
[email protected]>
Subject: RE: Virus Proof Machine Response
In answer to Vesselin's comments about my machine...
>
[email protected] (Chris Stops) writes:
>
>> (Side note : In fact, the 80286 had a back door, the LOADALL
>> instruction. [Rest of stuff, including the fix, deleted....]
>
>And how about the LIDT (Load Interrupt Description Table) instruction?
>It is supposed (to my knowledge) to in protected mode only, but on a
>80286 it runs perfectly in real mode. It allows you to swap the whole
>interrupt vector table with something totally different, which resides
>at a different address. Was this fixed in the 386? The author of the
>Vacsina/Yankee Doodle viruses had told me that one of his advance
>viruses (TP 50 or 51) uses this trick to avoid monitoring programs on
>a 286. Unfortunately, I never got a copy of that virus.
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.
Incidentally, I don't really like the 80x86 series. They all seem so
messy compared to more orthogonal processors, the most obvious example
being the 68000 series. I chose the 80386 simply because most people
reading this are probably PC people.
>> [Deletions]
>> ...the operating system limits the operations which can be
>> carried out on executable files. For example, executable files may be
>> created (so compilers still work) or may be executed (of course!). But
>> they cannot be opened for read access. Nor can their executable status
>
>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.
>> be altered to look like a data file (e.g. in DOS terms, *.EXE becomes
>> *.DAT, the 'DATA' file is processed, then *.DAT is renamed back to
>> *.EXE). If we still allow executable files to be deleted, then about the
>
>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.
>> only sort of virus left is an overwriting virus, which deletes an
>> application and then creates a copy of itself using the name of the
>> application. But since the applications will no longer run, it should be
>> obvious that something is wrong with the machine.
>
>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.
>Or viruses that infect
>.OBJ, .LIB, .BAT, .MAC, .INC, .H, .C, .PAS, .MOD, .FOR, .BAS, .PRG, or
>whatever else gets interpretted/executed... :-)
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
changed, or the files will grow etc. etc. And remember, there can be
no stealth viruses to cover up things like files growing!
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.
2) Computer USERs (e.g. people doing word processing) won't tend to have
OBJ files anyway, even less swap them.
3) Computer programmers in user clubs etc. can swap source code instead
of the .OBJs.
..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.
>> To allow copying of executables (e.g. from floppy to HD) there would need
>> to be a new operating system call for copying files, becuase, of course,
>> no application (e.g. COPY) can read the source file!
>
>This is no problem if you forbid only writing, but allow
>reading/creating.
See above for why I think we must forbid reading.
>> Now of couse, there will be some users who want/need read/write access
>> to their executable files. In this case, we could have a three position
>> switch inside the machine, mapped into a protected I/O location. It
>> functions as follows...
>
>Better implement it as a hardware switch. If it is software (even if
>it is protected) either (1) the user will not be able to use it, or
>(2) a virus would be able to use it too...
I think you got my point, but I don't quite understand your comment.
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!
>> Position A All attempts to read an executable file are stopped.
>
>> Position B All attempts to read an executable file result in a
>
>> Position C All attempts to read an executable file are allowed.
>
>Just replace "read" with "write".
Maybe I've missed something which you have thought of, but I still
think we must disallow reading of executables.
>> Now that the operating system is so well protected, we have a problem.
>
>Yeah, that it is not very useful... :-)
Well, I would'nt quite put it like that!
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 have we lost in the process?
1) We now pay a little more for some ROMs.
2) We pay a little more for a key-switch, but most machines already have
a keyboard lock. Maybe the two could be combined?
3) It is a *little* more difficult to write a TSR/device driver etc.
4) Technical Users who want to hack about with their machine have to
turn a keyswitch before they can read the executables.
What have we gained?
A massive improvement in security. I think that viruses would become
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.
So the machine is USEFUL in the sense that it can run all the
applications we ever need to with relatively good security.
But it is not USEFUL in the sense that it is not MS-DOS compatible. I agree
with this, but see my later comments...
>> Not only can no virus modify it, but no extensions can be added either,
>> for example, new device drivers. The virus proof way around this is that
>> new drivers are supplied on ROMs which can be plugged into the machine,
>> and patched into the O/S during initialisation. A slightly less secure
>
>Updating through ROMs has been already discussed here, as far as I
>remember... It is a good idea, but most computer manifacturers
>consider it as too expensive. Don't forget - a practicable anti-virus
>solution should be also marketable...
But please remember my comment about loading device drivers (and
indeed, other TSRs) off a disk.
>If the hardware supports memory protection, and if it is used to
>implement file-access rights, you can get a pretty secure system.
>Something like Unix... Ooops, there are already viruses that spread
>under Unix, so it doesn't seem to be -THE- solution. True, they spread
>very slow, true, they can be catched much more easily, but
>nevertheless they exist and they spread. Indeed, they use a completely
>different trick. While Mess-DOS virus rely on the abilities to bypass
>its protection (huh? what protection?), the Unix viruses rely on the
>fact that Unix users share resources intensively...
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.
>> Of course, my machine would probably be incompatible with Mess-DOS. But
>
>Almost certainly. Maybe OS/2 ver. 3.0?
>
>> then, isn't it about time we establised a new microcomputer standard
>> based on at least 32 bits of data and address?
>
>Good idea. It rests "only" to convince IBM about it... :-)
..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!
>Regards,
>Vesselin
Sorry I can't respond to this list very quickly. I'm not actually on
the distribution list. I read the articles when they eventually
appear on the Public Domain Software machine at Lancaster, here in the
UK.
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.
Chris.
------------------------------
Date: 05 Nov 91 17:13:31 +0000
>From:
[email protected] (Steve Rikli)
Subject: Re: McAfee84 failed to remove Joshi
[email protected] (McAfee Associates) writes:
>
[email protected] (Steve Rikli) writes:
><some of message deleted>
>>As the subject says, Clean v84 couldn't handle Joshi. It discovered
>>and claimed to clean it on an IBM PS2/30, but Scan discovered it
>>again. Repeated attempts failed.
>
>Can you please be more specific about what occurred? Did you receive
>a message that the virus could not be safely removed, did it say it
>was removed, or what? Where did VIRUSCAN (SCAN.EXE) find the virus
>after cleaning? In memory or on a disk?
What I said above is exactly what happened. SCAN discovered [Joshi],
and CLEAN said "1 virus found, 1 virus removed". Re-running SCAN
produced "virus found [Joshi]" again. In other words, CLEAN claimed
to successfully clean [Joshi] but apparantly didn't. Each time I ran
SCAN, I did so after a powerdown and reboot w/clean floppy, and each
time Joshi was found on disk.
>>Interestingly enough, Clean v76 DID handle Joshi on a CompuAdd '286.
>>I thought this was *really* strange.
>
>There are a variety of reasons that a virus could be reported after it
>was claimed to be removed, these range from actual failure to remove
>the virus to "ghost" images of viruses being reported as a result of
>remnants of viral code left in the system.
I thought about the "ghost" business, so I powered down the PS/2 and
rebooted from a clean floppy. The same episode I described above
happened again. Several times. I would say that CLEAN really was
failing to remove [Joshi] from the PS/2.
I dunno why, but I suspect it's some peculiarity of the PS/2 at work
here. Because all of the v84 programs worked beautifully on our
CompuAdd's and other clones. And not only on Joshi--I've also had
the opportunity to use them on Keypress and Sunday.
- --
|| Steve Rikli ||| Visualization Lab ||
||
[email protected] ||| Texas A&M University ||
|| (409) 845-5691 ||| College Station, TX 77843-3137 ||
------------------------------
Date: Tue, 05 Nov 91 18:48:26 +0700
>From: Cezar Cichocki <
[email protected]>
Subject: Problem with Stoned virus (PC) Problems with SCAN
Hi|
Small (?|||) problems with STONED virus. SCAN detect it, I used CLEAN
program, it raport me that CLEANED and... STONED was on disk again ||
I killed him with NoStoned programm (Polish cure for this virus).
Cezar
------------------------------
Date: Mon, 04 Nov 91 21:49:04 +0100
>From: Mikael Larsson <
[email protected]>
Subject: ViruShell - New Shell for SCAN - Great (PC)
ViruShell
(C) 1991, NewAge Productions and Virus Help Centre
ViruShell is a shell to simplify the use of McAfee's antiviral
products VIRUSCAN, NETSCAN and CLEAN-UP. It gives you a very
straight-forward and easy-to-use front to these programs as well as
adding som functions of it's own. ViruShell lets you setup all
options, path's and devices from extensive menus and then run the
McAfee programs in a window of the main ViruShell screen. These setups
can also be saved for later reloading in different setup files.
ViruShell is distributed as ShareWare, giving you a trial period of 30
days before deciding if the program suits your needs. Registration
unlocks a few functions as a reward for your support of the ShareWare
concept.
ViruShell incorporates among others the following functions:
* Automatically adopts to your system, sensing monochrome or color modes,
as well as adopts to the condensed line modes of EGA and VGA, giving you
43/50 lines on screen.
* A swift menu system that makes it easy to access the advanced functions of
the McAfee antiviral programs.
* Full mouse support, works with all MicroSoft compatible mouse drivers.
* Memoryswapping functions to reduce memory requirements while executing
external programs.
* Runs Scan, NetScan and Clean in windows on the main ViruShell screen.
* A context-sensitive hypertext format help system accessable from anywhere in
the program with the press of a key.
* Current version comes in two flavours, english and swedish, other languages
will follow.
Registered bonus features:
* Loading and saving of different setups.
* Autorunning of Clean to remove all infections found by Scan.
* Easy access to the VIRUSCAN AV functions, add and remove AV codes with the
press of a few keys.
ViruShell utilizes all functions of the latest McAfee versions and will be
updated as soon as any new function is implemented in the McAfee programs.
Available from the main distribution BBS'es:
Virus Help Centre NewAge Productions
Mikael Larsson Jonny Bergdahl
+46-26 275710 +46-36 121323
1200-14400 (HST) 1200-9600 (V32)
Will be released at Nov. 5th - 06.00pm (GMT+1)
ViruShell will probably be available at anonymous FTP withing 12 hours
after release.
Rgds,
MiL
------------------------------
Date: Tue, 05 Nov 91 11:42:57 -0600
>From: James Ford <
[email protected]>
Subject: fprot201.zip on risc (PC)
The file fprot201.zip has been placed on risc.ua.edu in the directory
pub/ibm-antivirus. Older versions of fprot (v116 and v200) have been
removed.
- ----------
Don't marry for money; you can borrow it cheaper.
- ----------
James Ford - Consultant II, Seebeck Computer Center
The University of Alabama (in Tuscaloosa, Alabama)
[email protected],
[email protected]
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 211]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
