Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA19600; Wed, 6 Jun 90 11:39:35 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA03744; Wed, 6 Jun 90 11:39:33 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA17931; Wed, 6 Jun 90 11:39:07 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa20440; 6 Jun 90 15:30 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Tue, 05 Jun 90 14:01:20 BST Message-Id: <$TGVGDBVHCNWQ at UMPA> Subject: Virus-L vol 0 issue #0603 Virus-L Digest Fri, 3 Jun 88, Volume 0 : Issue #0603 Today's Topics re:re: mac SE hard drive disable Re: re:re: mac SE hard drive disable forwarded from RISKS... Re: Hard disk disable re: Connectivity suggestion #2 WAS: hard disk disable ** no subject, date = Fri, 3 Jun 88 14:41:12 MDT Re: Detecting damaged data ------------------------------ Date: Fri, 3 Jun 88 11:22:00 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: GREENY Subject: re:re: mac SE hard drive disable > hold down the Shift, Option, Command, and Delete keys to boot from a > floppy....Does this actually prevent the hard drive from working?.... Well, that's what it is *supposed* to do for ya. But who knows with Apple? At any rate, to avoid all of the mangled, popped out of joint fingers that some people who aren't too limber may get from the above sequence, just insert a trusted floppy disk into the floppy disk drive with a trusted system and then open the System folder on it. Hold down the COMMAND and the OPTION keys while double clicking on the icon of the Finder. This will force the mac to make use of the system on the floppy drive. After your finder comes back to life, close the folders, and drag the icon of the hard drive into the trash can. This will unmount the sucker, thereby preventing any read/writing from/to it. You can then make a vallient attempt to use an unknown piece of software. Just pray that the virus doesn't get stored in your parameter ram, or you will be really screwed because the battery back-up for the SE is *SOLDERED* to the mother board. Solution to this deal --> Run it on a Mac Plus, and if you suspect a virus residing in your parm ram, remove the battery from the back via the battery door. Wait 40 seconds for all to clear and then put it back in. Hope this helps.... Bye for now but not for long... Greeny Bitnet: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU Disclaimer: What? Who? Me? Nope...not me...you must have the wrong guy! -------------------- Date: Fri, 3 Jun 88 14:49:36 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: re:re: mac SE hard drive disable In-Reply-To: Message of Fri, 3 Jun 88 11:22:00 CDT from All this hard disk locking stuff is fine and all, and it is a good initial testing method for software, but Joe made a good point when he said (something to the extent) that a virus could very easily wait until it found a hard drive present before even attempting to propogate. Thus, the virus would only do damage to hard disk based machines (or at least only propogate on them). I know that's what I would do *IF* I were to write a virus; go after the people who have the most to lose. The best solution would be to test software on a machine which has a hard disk that is expendable. Of course, economic reasons often make that impractical. By the way, I've received a few requests to turn this list into a moderated list whereby submissions wouldn't go directly to the list until they've been screened and (perhaps) digested into one large message. I *DON'T* want to start a discussion of the pros and cons of this on the list. I *DO*, however, want to hear peoples' opinions on the matter - via direct e-mail. Please do not reply to this directly to the list. If you wish to voice your opinion, send it to , and I'll summarize the opinions at a later date to the list. Thanks. Ken - ---------------------------------------------------------------------- = Kenneth R. van Wyk = = = User Services Senior Consultant = This page intentionally = = Lehigh University Computing Center = left blank. = = Internet: = = = BITNET: = = - ---------------------------------------------------------------------- -------------------- Date: Fri, 3 Jun 88 15:03:48 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: forwarded from RISKS... I just saw this on the RISKS mailing list, and thought I'd repost it here. Opinions? From: ZSYJKAA@WYOCDC1.BITNET Subject: Virus-writing 101? Thought I'd relate a recent incident to the group regarding computer virus writing and propogation. Apparently we have a professor who thought it would be a good experience for his students, as a project, to write (each) a virus, and demonstrate that it works. OK, in my opinion we're already on shaky ground assuming the 20 or so different viruses can remain totally isolated within the student-instructor environment. As you can guess, some of them have "leaked" out of the "lab". One report indicates that the instructor's hard disk was erased, and another that one student's final project was eaten by his own virus. At least one unrelated PC was found to be infected (in the University's Micro Resource Center!). There are arguments going backand forth about whether this was blatantly irresponsible, or if viral education is a good thing. One can't even consider firing the instructor because he's already leaving to go to another institution. So, this might be a good topic to kick back and forth for a while? What are the ethics/legalities of such an incident? For instance, in American law & philosophy, freedom of information is nearly sacred; is propoagation of the knowlege on how to write a virus itself a bad thing, or only the malicious and/or negligent spreading of one and it's symptoms/damage? Is the passing of this knowlege to a "random" group of students (where the professor is probably unable to evaluate each one's future intentions or views of morality) an unethical, if not illegal, act? Disclaimer: The above are my views, not my employer; I have not had direct contact with the professor or his students. - ---------------------------------------------------------------------- = Kenneth R. van Wyk = = = User Services Senior Consultant = This page intentionally = = Lehigh University Computing Center = left blank. = = Internet: = = = BITNET: = = - ---------------------------------------------------------------------- -------------------- Date: Fri, 3 Jun 88 14:05:35 BST Reply-To: Virus Discussion List Sender: Virus Discussion List From: p.g.newman@ABERDEEN.AC.UK Subject: Re: Hard disk disable I recently read an item in the February 1988 issue of CONNECTIVITY, the British IBM-PC User Group Journal. I feel that a couple of points made in the item may be relevant to the ongoing discussion on the list. Two ways were mentioned: ................................................................. Extract from CONNECTIVITY (Feb/1988) pg23 : Dr Solomon's Surgery, in response to a query from Charles Guy re write protecting 30 XT's, each with a 20Mb hard disk: 1. "...replace INT 13H with your own version that filters out any disk writes." 2. "...make up a cable for the hard disk that disables writing to it...(by cutting) one of the lines in the cable." ................................................................. I'm not sure how effective item 1 would be, as presumably any virus, being software, can 'untrap' the trap, as it were, and still get on with its dastardly deeds. Item 2 seems more likely to be effective, but, as the article points out, would require a special cable for the administrator to be able to do his necessary routine updates, etc. This could mean an all-night or all-weekend job in a large teaching lab with numerous hard-disc machines. I don't know which of the lines is the WRITE line (no pun intended!) but surely it would be feasible to extend this line through a secure switching device on the outside of the PC. I know that in our setup, the keyboard locks on each PC are more or less redundant (who locks a class computer?) and with a little bit of nifty soldering, would provide the ideal means of control: the admin guy would just have a master key, no cables or messing around inside needed to get write access to the hard disk. Unfortunately: a) Who knows how to identify the DATA-IN or WRITE line on a hard disk in a PC? (I've got no technical docs.) b) Would the extended cable adversely affect the timing or proper operation of the disk? All views above, with the exception of the two quotes between the dotted lines, are my own. Any responses not relevant to the list but relevant to my queries gratefully accepted as personal mail. Sorry about the detailed reference...copyright regulations, etc. This time it's got my personal name on it. Previous copy sent from 'adscalgrp' by mistake. Funny things, aliases.....Regards, Greg N. -------------------- Date: Fri, 3 Jun 88 15:33:00 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: GREENY Subject: re: Connectivity suggestion #2 WAS: hard disk disable > 2. Cut the write line, and insert a switch.....would this [skrew] > up the timing or control of the drive.... I believe that it would most certainly do so. How would you be able to update your disk directory FAT, or change the comments of a file, or edit any files on the disk, or do anything that would require writing with the cable cut? When a drive is write protected -- by software -- you are not supposed to be writing anything to the drive. But the DOS itself may keep track of the last time the file was read or whatever, and that involves writing to the disk (i.e. it overrides the software protection mechanism...). How could it do this if you cut the write line(s)? Are you as quick as the computer is to be able to switch the lines back on when the DOS feels like updating something? I still think the only way to combat viruses is to check the source code for them by a competent programmer, and then recompile the stuff. Praying all the time that the compiler is not infested as well....*ho hum* Will we never be free of these things?! bye for now but not for long... Greeny Bitnet: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU Disclaimer: What? Nope...not me...you *MUST* have the wrong guy! -------------------- Date: Fri, 3 Jun 88 14:41:12 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: USERFLUF@UALTAMTS Our Telecommunications Staff set up a lab of IBM PC portables, each with a 20 Meg HardCard installed. They, in their usual brilliant manner, have disabled the write head. I cannot say exactly how they did this, but the people that did this did not seem to be overly distraught at doing this. -------------------- Date: Fri, 3 Jun 88 23:02:31 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Sam Weber Subject: Re: Detecting damaged data A while ago, Amanda Rosen wrote: >It seems to me that in order to check files sufficiently often, the CPU >overhead must be *very* light. Disk storage, however, is at much less of a >premium. This is probably something that differs between systems, but at least on my Amiga, this is not at all true. Very rarely is my CPU at 100% utilization. After all, for every compile I do, how many hours do I spend editing? Editing, and things like that, take up very little processor time. I have TONS of wasted CPU cycles lying around. However, storage space is more of a problem. I have only 512K of RAM, and no hard disk. Even if I had a hard disk, though, I still would want to keep my virus checking data on a write-protectable media, ie floppy. It seems to me that a good solution would be to start up a low priority process which will periodically go through my executables, ensuring that their checksums haven't changed. Since it is low priority, it will not affect whatever else I am doing, no matter how much a CPU hog it is. If it was small (say, <10K) then I probably wouldn't notice the memory loss. Notice, however, that this would require a short signature for each file (since the signatures will have to be in memory). This shouldn't affect its security, though, since each time it is run it can randomly choose a checksum formula (ie, each time it is run it randomly picks a CRC polynomial, checksums each file, and thereafter periodically rechecks each file). How about it? --Sam Weber "I never think of money, I think of milk and honey, sam@csri.toronto.edu Grinning like a cheshire cat!" --The Muppet Movie -------------------- *** end of Virus-L issue ***