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 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: ATKINSON@RUBY.VCU.EDU MAIL: BOX 16 MCV Station Richmond, VA 23298-0016 ------------------------------ Date: Wed, 23 Nov 88 14:15:59 EST From: roskos@ida.org (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 Subject: re: ethics of a worm Reply-To: tytso@athena.mit.edu 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