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 AA04526; Wed, 20 Jun 90 17:26:34 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA07116; Wed, 20 Jun 90 17:26:34 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA23378; Wed, 20 Jun 90 17:26:26 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa23261; 20 Jun 90 16:22 BST From: Anthony Appleyard To: DAVIDF@cs.heriot-watt.ac.uk Date: Wed, 20 Jun 90 16:32:36 BST Message-Id: <$TGWGCZNQBTQR at UMPA> Subject: Virus-L vol 0 issue #1018 Virus-L Digest Tue, 18 Oct 88, Volume 0 : Issue #1018 Today's Topics re: Yale locks?? Re: I am proud to be a hacker! Re: Another vote. Re: Yale locks?? Re: I am proud to be a hacker! Re: networks Micros and others (was: Re: networks) Re: Yale locks?? Re: I am proud to be a hacker! Re: Micros and others (was: Re: networks) ** no subject, date = Tue, 18 Oct 88 18:07:00 EST Re: Micros and others (was: Re: networks) RE:Peripherals Re: peripherals Infected peripherals Are so-called protected systems protected against viruses? Re: peripherals ------------------------------ Date: Tue, 18 Oct 88 14:30:00 CET From: Helmut Waelder Subject: re: > From: GATEH@CONNCOLL > Subject: another attempt at voting > I vote to move the hacker/hire-fire/definition-genealogy discussions to > another list (perhaps ETHICS-L, as other folks have mentioned), and > reserve this list for more technical topics. > that'll be two cents > Gregg TeHennepe | BITNET: gateh@conncoll I agree with Gregg. This here should be a virus discussion list .... Helmut Waelder -------------------- Date: Tue, 18 Oct 88 10:11:00 EDT From: EAE114@URIMVS Subject: Yale locks?? If I'm wrong, somebody correct me, but : The 'Yale lock' mentioned is not software, it's a physical lock, on a door. It was mentioned by way of analogy. -------------------- Date: Tue, 18 Oct 88 09:12:54 CDT From: Len Levine Subject: Re: I am proud to be a hacker! In-Reply-To: Message from "Grep the Peg" of Oct 17, 88 at 11:33 am >Right on. I lost my account on the University of Calgary vaxes four >times in my first year. Once because I used "rlogin" when I wasn't >supposed to. Three other times because of unfounded "rumour". It seems >the sysops fastest way to get me into his office was to turn off my >account. I don't even think what I did classifies as hacking... Us liberals (card carrying etc.) often find that the punishment is supposed to follow conviction, not precede arrest. Well, enough of the democratic process, and enough of this. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + -------------------- Date: Tue, 18 Oct 88 10:48:16 EDT From: "Christian J. Haller" Subject: Re: Another vote. In-Reply-To: Message of Mon, 17 Oct 88 13:53:48 EDT from >viruses, second ETHICS-L has been completely silent for months and ETHICS-L has been far from silent. Maybe you should resubscribe. Maybe some of the rest of you should subscribe. I'm enjoying the discussions and sharpening my sense of fairness/justice. On January 26, the host server became ETHICS-L@POLYGRAF (it had been UGA before). A reminder to others on the list: DO NOT SEND SUBSCRIPTION OR UNSUBSCRIPTION REQUESTS TO THE LIST unless you really want to make thousands of copies of a simple administrative request (and make yourself look dumb). The correct form is (assuming CMS, and that you do not know a list peer closer to you than POLYGRAF, wherever that is): TELL LISTSERV AT POLYGRAF SUB ETHICS-L your name Notice "AT" instead of "@", and of course substitute your name as you want it to appear in files sent to you, in place of "your name". You don't need to provide your Userid or node: the LISTSERV picks them up from the message envelope. -------------------- Date: Tue, 18 Oct 88 11:00:40 CDT From: Len Levine Subject: Re: Yale locks?? In-Reply-To: Message from "VIRUS-L@LEHIIBM1.BitNet" of Oct 18, 88 at 10:11 am >If I'm wrong, somebody correct me, but : >The 'Yale lock' mentioned is not software, it's a physical >lock, on a door. It was mentioned by way of analogy. Right, I mentioned it. The Yale lock is the conventional lock like you find on most doors. Blueprints of that lock are easily available and any person who wants to know how it works can find out. However the height of a pin (which determines the depth of the notch in the key at that point), can only be found out by disassembling that lock, and thus, unless you can examine carefully an individual lock, you cannot guess at the key. My analogy was to a software protection package, in which the technique is known, but the code word, or the file name used is an individual choice on an individual machine. Anyone can know that I use a CRC protection algorythm, but what value I use for the CRC polynomial is known only to me. If that polynomial were public, a virus writer could easily build a virus that overlays part of a program, and changes just a byte or two to regenerate the same CRC. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + -------------------- Date: Tue, 18 Oct 88 13:16:34 EDT From: Ed Nilges Subject: Re: I am proud to be a hacker! In-Reply-To: Message of Mon, 17 Oct 88 11:33:00 MDT from Here's hoping that the virus scare does not result in a witch hunt (and wizard hunt) for suspicious programmers, reminiscent of Joe McCarthy's crusade against domestic Communism of the 1950s. I don't mean to imply that actual perpetrators of viruses should not be detected and punished...I only mean that due process should be the norm. For example, no virus case should lack expert witnesses in the form of systems programmers testifying for the defense and prosecution. Administrative proceedings should mimic court proceedings, and give suspected programmers something like due process. This is morally justified by the fact that loss of a computer account can be a serious matter for an individual; this is pragmatically justified since it will prevent some unnecessary lawsuits by aggrieved individuals. I don't agree that this thread should move to ETHICS-L. We are writing at the intersection of viruses and computer ethics. If the thread moves to ETHICS-L, then technicians uninterested in broad ethical issues, who have administrative responsibility for the condign punishment of virus hackers, will not have the benefit of the most current legal and ethical thinking on this matter. At most, the discussion should be cross-posted to both groups. It is true that it raises the noise level of this group considerably, but this group contained a high level of opinions, flames, and assorted nonsense before the advent of this hacker discussion. Edward Nilges -------------------- Date: Tue, 18 Oct 88 13:21:05 CDT From: Len Levine Subject: Re: networks >Because of these thoughts, I would object (again) to any suggestion >that MS-DOS and MAC systems are more vulnerable to viruses >than are any other systems. How about changing the sentence >in question to read: >> No conventional computer installation that accepts >> executable files from another system is safe. >Forgive me if I harp on this, but I'm constantly reading and >hearing how it's just these silly micros that are vulnerable to >viruses, and that as soon as they get to be more like mainframes, >we'll be safe. It's not true... I believe that the micros, at least those that have no user-system differentation, like the PC and MAC, but unlike the microvax do have an inherent flaw. With these simpler systems, any code can do anything. Any program can wipe out the disk, change any file etc. With the more sophisticated system (microvax), there is a user and a system space, and the only way to affect system space is to be running as a manager. Of course we have seen how these systems can be infected, but it requires a combination of errors, not just one, and the careful user/manager can watch the system and keep it safe. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + -------------------- Date: Tue, 18 Oct 88 14:50:31 EDT From: "David M. Chess" Subject: Micros and others (was: Re: networks) Len Levine writes, about systems with more of the traditional protection mechanisms than most micros have: > Of course we have seen how these systems can be > infected, but it requires a combination of errors, not just one... I'm not sure I understand this. Any environment in which a user has normal write-access to executable files that other users have normal execute-access to can become thoroughly infected with a virus. It doesn't require any "errors" at all. Traditional protection mechanisms can certainly make it easier for people writing anti-virus software (because, for instance, if the anti-virus code is in a protected kernal, no user-run virus can turn it off), but by itself it doesn't do much to slow viruses down at all. In multi-user systems, where users typically use lots of "goodies" owned and updated by other users, I would maintain that a virus could spread *faster* than in a loosely-linked collection of single-user micros. See Fred Cohen's "Computer Viruses -- Theory and Experiments" for some confirmation of that... DC -------------------- Date: Tue, 18 Oct 88 13:08:51 MEX From: "J. Antonio D. Falcon Tena" <302581@VMTECMEX> Subject: Re: Yale locks?? In-Reply-To: Message of Tue, 18 Oct 88 10:11:00 EDT from Well I know yale locks are somo locks for doors, but maybe there have a new meaning, you know people use too much words, and use them with double or triple meaning. -------------------- Date: Tue, 18 Oct 88 12:56:00 MDT From: GORDON_A%CUBLDR@VAXF.COLORADO.EDU Subject: Re: I am proud to be a hacker! For what its worth, I am in agreement with Ed Nilges' discussion. To improve the signal to noise ratio and reduce the bandwagon effect, I am also in agreement - the signal to noise ratio we ought to reduce the bandwagon effect. -------------------- Date: Tue, 18 Oct 88 15:51:30 CDT From: Len Levine Subject: Re: Micros and others (was: Re: networks) In-Reply-To: Message from "David M. Chess" of Oct 18, 88 at 2:50 pm >Len Levine writes, about systems with more of the traditional >protection mechanisms than most micros have: >> Of course we have seen how these systems can be >> infected, but it requires a combination of errors, not just one... >I'm not sure I understand this. Any environment in which a user >has normal write-access to executable files that other users have >normal execute-access to can become thoroughly infected with a virus. >It doesn't require any "errors" at all. My point was that if you are working in an environment where you may log in as a user with limited privileges, then you may establish one "user" and run as him while you are testing software. If the system will not permit writing to a file without updating its last used date, then you can see what files were affected, and if you cannot write outside of the test directory, then you may be sure that no changes occurred except in that area. When done, the space can be cleaned. In an unprotected system, no such security is possible. Of course, if the virus is clever enough, then you can continue to use it and then you may well find that the infection will reach as far as you can reach. That continued use is the "error" that I referred to above. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + -------------------- Date: Tue, 18 Oct 88 18:07:00 EST From: Dimitri Vulis This reminds me of an old Trojan Horse (not really a virus) which hit some school (I forget which) many many moons ago. A student wrote a program (some kind of useful tape utility) and submitted it to the systems people who liked it a lot, installed it among public utilities and used it heavily. Now, the program, in addition to being a very useful tape utility, checked the date and user's privileges every time it was run; and when it was run by one of the priveleged users after the student graduated, it did some nasty things to the entire system. I guess there's a moral to it: if you can't trust the source of the program, no amount of testing with user privs will help. Re sysops locking out alleged hackers: if you use your mainframe account for course-related work, and you don't do anything illegal, and systems people interfere with your work (e.g. lock out your account, erase your files, etc) the proper procedure is to SUE. There was a case about 2 years ago when a CUNYVM operator nologged a student he did not like. The student sued (the operator, not CUNY) and recovered the tuition for his computer course plus computer usage fee plus damages plus legal fees. In my opinion, a systems person who does things like this is no better than a virus (Trojan) writer. I conjecture that they have similar personality traits. -DV -------------------- Date: Tue, 18 Oct 88 17:46:00 MDT From: Bernie Subject: Re: Micros and others (was: Re: networks) In-Reply-To: Message of 18 Oct 88 14:51 MDT from "Len Levine" I have to (really) disagree with the notion that mini's and larger are safer that MAC and PC types. Sure, with priv.s the system has a bit more security, but remember why that is so... Two people use the MAC in our classics lounge. Over 100 people use our Honeywell Multics machine on good days. On our suns and vaxes, the load isn't as much but there are over 200 students relying on these networked machines. Now the ration of two people losing a few files compared to two hundred people makes virus (especially worms) more dangerous on mainframes & mini's. Note 1: On the sun, priv.s don't mean too much. They are easy to bypass if the "true hacker" (no flames please) writes the virus. Most UNIX machines are designed to be open, thus the question "why have privs at all?" Note 2: Different tangent, when talking with WHMurray in private mail, he suggested that infact writing a virus is morally wrong. If ethical issues, like writing a virus don't belong here, I'm confused... Note 3: Using external devices for viral data is not a close topic, is it? I think it would be possible for things to hide in the laserwriter and imagewriter. Is it possible, using a smart device like a laserwriter, to actually have a destructive piece of code working separate from the machine? Ie. it could mangle all printouts etc........ -------------------- Date: Tue, 18 Oct 88 21:19:00 EST From: ACS045@GMUVAX Subject: RE:Peripherals "BSWIESER@UNCAMULT" writes: >Note 3: Using external devices for viral data is not a close topic, is it? >I think it would be possible for things to hide in the laserwriter and >imagewriter. Is it possible, using a smart device like a laserwriter, >to actually have a destructive piece of code working seperate from >the machine? Ie. it could mangle all printouts etc........ I don't know much about the internals of such things like laser printers, etc., but the idea seems sound...you could have one sitting off somewhere in memory, or maybe have it infect a driver that would trash font loads or refuse to accept them from the main machine,etc. People have done it with clock/calendar memory and even a first generation LaserJet is a lot smarter than that, so why not peripherals?? Why even limit it to printers???...how 'bout a modem??---We just got a whole bunch of new modems that have NO DIP switches, its all programmed from the software....sounds like prime breeding ground to me!...theres got to be enough memory in there to copy a whole command set which means there might also be enough to house a virus. Maybe something to echo a character or hangup or something every x # of bytes transferred. I don't claim to be a hardware expert, so pardon me if I screwed up and keep your flame thrower holstered.. - ---------- Steve Okay ACS045@GMUVAX.BITNET/acs045@gmuvax2.gmu.edu/CSR032 on The Source. "Ahh...the keyboard, how quaint!" -------------------- Date: Tue, 18 Oct 88 23:28:23 EDT From: me! Jefferson Ogata Subject: Re: peripherals Most peripherals, particularly modems, provide no code segment space for host writing; printers and some modems allow the host to install 'data' on them. The nature of the data used for these peripherals -- fonts, protocols, et al. -- is not rich enough to provide for self-replicating code, or even damaging code. In general, the worst a program could do with a laser printer is install a bad font, which would be stomped if a good font got loaded on top of it. With a modem, the host could define a bad protocol; this also would be temporary. While there may be peripherals where virus infection is possible, they are few and far between, from what I've seen. (Try infecting your accounting package with a data file. Not easy; usually impossible.) Drivers, on the other hand, can be infected, but this occurs on the host machine, not on the peripheral. - Jeff Ogata -------------------- Date: Tue, 18 Oct 88 22:06:00 PDT From: portal!cup.portal.com!dan-hankins@SUN.COM Subject: Infected peripherals Jefferson Ogata writes: >The nature of the data used for these peripherals -- fonts, protocols, et >al. -- is not rich enough to provide for self-replicating code, or even >damaging code. In general, the worst a program could do with a laser >printer is install a bad font, which would be stomped if a good font got >loaded on top of it. The Apple LaserWriter uses PostScript. PostScript is a complete programming language. The LaserWriter has a *significant* amount of memory on board, like a meg or two (I seem to remember it being a meg when I worked with one in 1986). I can very easily imagine a virus written in PostScript infecting a LaserWriter. Dan Hankins -------------------- Date: Tue, 18 Oct 88 21:01:29 PDT From: portal!cup.portal.com!dan-hankins@SUN.COM Subject: Are so-called protected systems protected against viruses? In-Reply-To: Message from "Len Levine" of Tue, 18 Oct 88 15:51:30 CDT In article <8810182114.AA16629@Sun.COM> Len Levine writes: "My point was that if you are working in an environment where you may log in as a user with limited priviledges, then you may establish one "user" and run as him while you are testing software. If the system will not permit writing to a file without updating its last used date, then you can see what files were affected, and if you cannot write outside of the test directory, then you may be sure that no changes occurred except in that area. When done, the space can be cleaned. In an unprotected system, no such security is possible.". Wrong. On an unprotected system (i.e. single-user micro) one does this: 1. Archive the hard file or write-protect it (physically disconnect it from the system if necessary). 2. Put the suspect program on a *copy* of one of your working disks. 3. Run the program as much as you want. 4. Compare the disk copy to the original. 5. Compare the hard file archive to the current contents, if practical. 6. If any files have been modified that should not have been, then you have a virus (or a buggy program). This is actually *more* secure than the multiuser scenario you described. In your scenario a virus could be sensitive to restricted environments and not do anything nasty until run in a 'target-rich' environment. In mine it is running on what appears to be an ordinary working system. My scheme is beatable also, in several ways. But the user privs and suchlike do *not* give the protected multi-user system more security than the unprotected single-user variety. Dan Hankins -------------------- Date: Tue, 18 Oct 88 23:56:00 MDT From: KEENAN@UNCAMULT Subject: Re: peripherals In-Reply-To: Message of 18 Oct 88 21:28 MDT from "me! Jefferson Ogata" Mainframe peripherals often have a very rich instruction set. As an example, tape drives are firmware-controlled and are basically computers, hence indeed subject to viral infection. We had a case once in which we lost the firmware in a tape drive and it kept a $3M computer off the air until we figured out how to put the firmware back in (via a card reader of all things...) so the loss of a peripheral in some cases could be quite serious. -------------------- *** end of Virus-L issue ***