VIRUS-L Digest Monday, 28 Nov 1988 Volume 1 : Issue 20
Today's Topics:
MACINTOSH virus(es)
Re: Hardware damage
New Member
re: ethics of a worm
---------------------------------------------------------------------------
Date: Wed, 23 Nov 88 14:22 EST
From: In search of the perfect Taco <ATKINSON@VCUVAX>
Subject: MACINTOSH virus(es)
We have recently here at Virginia Commonwealth University been
having troubles with viruses. First we got the nVIR, now we have one
as yet unidentified.
The questions: 1) Do we have uninformed users, or malicious vandals?
The attitudes of some of our MAC users leads me to believe that the
only good MAC user is a dead MAC user, but thats personal. It does
seem strange that our first case of infection resulted in someone
placing nicely laser- printed signs saying: 'I have been infected' on
all of our MACS, (We checked, they were right) without telling any of
our operators.
and 2) I keep seeing references to how the other schools are
identifying and fighting these things, BUT I am not finding enough to
get a clear idea how we can fix our problems. Example: nVIR can be
found with ResEdit, can they all be found that way? And if so, what
identification marks do they carry?
Would someone please digest the ways and means of identifying a virus,
and the best methods (and where to get the software) to eradicate
these pests? Maybe its because I subscribed to the list late, and
missed all the notes about all this I ask.
If it hasn't been done, send me what you know, and I will make a stab
at compiling it and send it back to the list.
Anyway, thanks for any help.
Luther Atkinson.
bitnet: ATKINSON@VCUVAX
i-net:
[email protected]
MAIL: BOX 16 MCV Station
Richmond, VA 23298-0016
------------------------------
Date: Wed, 23 Nov 88 14:15:59 EST
From:
[email protected] (Eric Roskos)
Subject: Re: Hardware damage
>If the testability features are serious enough, you might even
>be able to turn inputs into outputs ...
You don't even need test features to do this. General parallel
interface chips such as Motorola's PIA, Commodore's VIA, etc. have to
be programmed explicitly to specify whether each data line on the chip
is an input or an output. So it is easy to reverse the sense of those.
Another similar problem is that, in lower-cost microcomputers, they
don't always use complete address decoding, and it is sometimes possible
to address more than one device on the bus at once. If you cause two
devices to drive the bus at the same time, and one is driving a line
"high" and one is driving a line "low", and they use totem-pole outputs,
this results in a direct short through the driver transistors on the
two chips. However, this usually won't cause them to fail unless it is
sustained for a good while.
>In general terms, what can you do, and what do you need
>to know to try to configure an anti-vandal system? In a specific
>sense, you need to know how all of your chips work and what
>affects they can have if used in improper modes, but is there
>a methodology one could use to ensure a reasonably safe system
>in the general case?
The exact same methodology applies to hardware as applies to software;
after all, the hardware/software distinction is largely an
implementation choice, and many things people attribute to hardware
are actually done in software. You gave a general description of the
methods above: completely specify the functionality of the components,
insure that this specification doesn't allow any damaging states
(including cases in which several components interact with each
other), and then implement the hardware such that it is consistent
with the specification (e.g., make any "don't care" states be "safe"
states, don't take "shortcuts," etc.). However, it can be harder to
do in hardware since providing a completely "safe" system may take
more hardware, and thus increase cost (or be infeasible altogether).
So these problems tend to be addressed sometimes at a higher level, in
software, by not allowing the user programs to directly access the
devices.
------------------------------
Date: Wed, 23 Nov 88 15:19:31 EDT
From: John Planck <34TVIGX@CMUVM>
Subject: New Member
Hello,
I am currently a fourth year student at Central Michigan University.
I have been required for my CPS370 (file manipulation techniques) class to
subscribe to two discussion groups via BITNET. I am a Computer Science
and Computer Integrated Manufacturing major. A response from anyone would
be greatly appriciated. Please indicate location and university or
company in your response. Thank you!!
John Planck
Acknowledge-To: <34TVIGX@CMUVM>
------------------------------
Date: Sun, 27 Nov 88 21:07:16 EST
From: Theodore Ts'o <
[email protected]>
Subject: re: ethics of a worm
Reply-To:
[email protected]
Address: EC Bemis 301, 3 Ames Street, Cambridge, MA 02139
Phone: (617) 225-6361
I'd like to make a response to James Mathiesen comment that the sys
admins across the Arpanet are more to blame for the success of the
virus than the person who released it. (Note: it is _not_ clear that
whether it is a worm or a virus; depending on the definition, the
program which attack the internet could quite easily be considered a
virus instead of a worm) Mr. Matheisen makes the assertion that the
reason why everyone is out it "crucify" RTM was because "he rubbed a lot
of peoles' faces in the fact that their 'secure' systems were full of
holes," and all they should do is "swallow their pride, patch their
holes, and chill."
I think this is a terribly irresponsible attitude to take. First of
all, those holes in the system were not well known. Many of the sites
didn't even have source to those programs! How do you expect them to
find and fix these holes? Secondly, just because those holes exist
does _not_ give someone carte blanche to exploit them. For example, it
is a fact that the average lock on the entrance to the average American
home can be picked in thirty seconds or less. However, you won't find
any robber arguing that it was the homeowner's fault that he didn't have
a better lock on the door! If caught, the robber shouldn't be able to
get off because this incredibly silly defense. You can be sure that if
at MIT, somone were to somehow pick through a lock, cause some damage and
got caught; claiming that the lock was so easy to get through would
_not_ be considered a valid excuse.
Attitudes like this are sickening. Instead of blaming the criminal, you
blame the victim. Whether the crime is rape, robbery, or letting a
computer virus loose on the net, using that particular form of logic is
equally invalid.
- Ted
------------------------------
End of VIRUS-L Digest
*********************
Downloaded From P-80 International Information Systems 304-744-2253
