VIRUS-L Digest Monday, 30 Apr 1990 Volume 3 : Issue 83 Today's Topics: re: Write-access to Executables re: *really* fail-safe virus protection? Re: New Virus? (PC) re: *really* fail-safe virus protection RE: Virus protection for OS in ROM Mainframe viruses Re: Possible virus? (Mac) New files to MIBSRV (PC) virus-l reply Public Domain/Shareware Anti-Virus Tools for IBM PC Re: Update to Memo on Computer Viruses in Commercial Products 1704 Version B (PC) Re: *really* fail-safe virus protection 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 VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to LEHIIBM1.BITNET for 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: krvw@CERT.SEI.CMU.EDU. Ken van Wyk --------------------------------------------------------------------------- Date: 27 Apr 90 00:00:00 -0500 From: "David.M.Chess" Subject: re: Write-access to Executables "Pete Lucas" : > It seems to me that *no* executables should be > 'writable' by *any* program under normal circumstances.!.! ... > Now when you make a change to the source, you recompile and re-link, > and if you know what you are doing, *ERASE AND RECREATE* the executable > module. Isn't the power to erase-and-recreate functionally the same as the power to alter? If something has munged an executable by reading it in, erasing it, and re-creating it, the relevant consequences will be just the same as if it had directly patched it on disk, yesno? Are there operating systems that allow you to mark files as subject to erase-and-recreate, but not subject to zap-in-place? (That's just a curiousity question; a virus can happily use either method.) The power to erase-X-and-then-rename-Y-to-X is another functional equivalent to bytewise write access... DC ------------------------------ Date: 27 Apr 90 00:00:00 -0500 From: "David.M.Chess" Subject: re: *really* fail-safe virus protection? hobbit@pyrite.rutgers.edu (*Hobbit*): > Finally someone else comes up with the *correct* solution! ... > Simply opening this line prevents any writes to the hard drive. ... > Comments upon how this scheme could fail for any *one-time* run of > infected software are solicited. Well, a virus that infected the software while it was on someone else's machine could decide to go off (because of the date or whatever) and mess with your data files (which can't be readonly, in general?). But it's quite true that a virus can't spread to your programs if they're all on a readonly medium whenever the virus has a chance to be in control. Why are only one-time runs interesting, though? Most software gets run more than once. If you really do power down the machine before ever flipping the write-protect switch off, and only run utterly trusted software in that state, you're quite safe. Utterly trusted software is hard to come by, though! *8) If a virus ever gets to run while the switch is off, or is ever still around in memory or whatever while the switch is off, you're no longer protected. No amount of testing can reliably determine that a program deserves to be utterly trusted; viruses can spread as rarely as they like (the original carrier of the DataCrime had a month or so's delay before it started spreading). This isn't to say that a write-prot switch for the hard disk is a bad idea; if I got along better with hardware, I'd put one in myself. But I'd suggest using it along with other anti-virus measures (scanners, modification detectors, backups, etc), and not relying on it exclusively. I don't think it's *the* solution to the problem... DC P.S. The ultimate solution is of course John McAfee's "spackle". But it's difficult to get much actual use out of a properly-spackled computer, unless you have a door you want held open... ------------------------------ Date: 27 Apr 90 17:33:09 +0000 From: medici@elbereth.rutgers.edu (Mark Medici) Subject: Re: New Virus? (PC) Did anyone think of checking for a batch file called 123.BAT on this system? Or looking around on the disk with Norton Utilities (or some such) to try and locate the file that contained some of the text that was displayed. This sounds more like a the type of non-damaging pranks I've played (and have had played on me) than a a virus/worm/Trojan-horse. Unfortunately, since the disk was wiped, we will probably never know. - ---------------------------------------------------------------------------- Mark Medici/SysProg3 * Rutgers University/CCIS * medici@elbereth.rutgers.edu - ---------------------------------------------------------------------------- ------------------------------ Date: Fri, 27 Apr 90 10:45:10 -0700 From: teda!RATVAX.DNET!ROBERTS@decwrl.dec.com (George Roberts) Subject: re: *really* fail-safe virus protection > I.e. the write gate. This is an active-low line from the controller to > the hard drive which when disabled "floats" high. Simply opening this > line prevents any writes to the hard drive. I believe it's pin 6 of the WARNING! Although TTL logic floats high when open, it can (and often will) go low for a few microseconds (due to cross talk on the chip?). I've been burned a few times when I thought some signal would float high. I highly recommend that you use a pullup resistor to +5V (if you don't already have one). The value of the resistor would depend on the drive strength of the chip on the other side of the switch. 5000 ohms will work for most cases: chips with an IOL MIN of 1 mA or more. I would hate to see the write signal go low even for just a micro second when the head is over some random part of my disk! It may only happen on rare occasions, such as when someone turns on a heavy appliance on the same circuit. It may only affect 1 bit (or none). - George Roberts ...teda!ratvax.dnet!roberts ------------------------------ Date: Fri, 27 Apr 90 16:27:39 -0400 From: Arthur Gutowski Subject: RE: Virus protection for OS in ROM >With the entire OS in ROM, there is no >>longer a need for executable code the the partition/boot record >>... >What do you do for minor updates or patches, though? --a chip swap would >be frighteningto joe_user for every minor updgrade/bug fix though. There >has been some talk in the past about moving the standard libraries and >handlers into ROM. Maybe in 1.5 :) >Stephen Okay Well, back to my origional misconception about Amigas and using EPROMs. Even though they don't (yet), how much more of an undertaking, and how much would it boost the cost, to start incorporating EPROMs into future hardware for OS. We have the technology, why not start using it? EPROMs, with an external switch, Could enable you to install a new versions/updates/bug fixes without a major kinipshin by owners. Again, this makes the assumption that the distribution diskettes are clean. Another limitation would be the amount of writes you were able to do before frying the EPROM chip; I dont know hardware that well, so I have no idea what a reasonable estimate would be. Amiga appears to have its act together more than most PC/compatibles and Macs in that at least the low-level boot is done in ROM. Hopefully they will implement standard libs/handlers in the same way. What about interrupt vectors too? I dont personally see any reason for modifying standard OS interrupts (except with version updates); reserved/user programmable vectors, if needed, can still be implemented the old way. Hmmmmmmmmmm Art - -==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-== \c- /=====\ Arthur J. Gutowski, System Programmer : o o : MVS and Antiviral Group / Tech Support / WSU Univ. Computing Center : : 5925 Woodward; Detroit MI 48202; PH#: (313) 577-0718 : ----- : Bitnet: AGUTOWS@WAYNEST1 Internet: AGUTOWS@WAYNEST1.BITNET \=====/ Disclaimer: I think, therefore I am...(maybe). Have a day. ------------------------------ Date: Fri, 27 Apr 90 16:44:46 -0400 From: Arthur Gutowski Subject: Mainframe viruses David Chess: >...viruses don't have to get around security systems to spread; they >spread by writing to objects that they are authorized to write to. Let me restate my point: properly implemented and audited security systems tend to *restrict* the spread of viruses. I'll concede that security systems alone don't do the trick; you have to have people who use the mainframe system educated on how to protect themselves from being tromped on by others. This, of course, does not prevent them from stepping on themselves, but if they cannot write to another persons (or the systems) object libraries, he cannot spread the virus to someone else, can he? Mainframes use something that most pc-type architectures dont--protected memory. When a task enters the system under MVS or VM, the OS sets up an address space bounded in memory for that task (batch job, TSO user, etc.) That address space cannot be modified by other address spaces nor can it modify other address spaces (except for normal operator commands like display, cancel, etc). Forget security subsystems for the moment, this is supported solely by the OS. Under this type of system, there is *no way* for a normal address space, regardless of whether he is a "super-user", security id, or whatever, to even address outside of his own address space. The system maintains a set of page tables, and all of your addressable storage is maintained through these tables. They can only be modified through the system. If you need more memory, the system grabs more (if available), and sets up another pagetable entry for you. When your task terminates, the system deletes all of your entries, and returns all your memory to the free memory pool. None of this can be accessed directly by the user, period. There is no way for viral code to get control of system functions in this way. Now there are some special utilities out there that run under the OS that allow you to view or modify global storage areas, but these should be (and are at our installation) monitored for such activity. The only other way to introduce viral code into the system is to have system programmer abilities and access to make changes to the system load libraries. Not an easy task. Now, as Dave and others have pointed out, this type of knowledge is limited comparative to PCs, and the casual hacker is discouraged from such targets. Those that do have the ability and would be using it for dastardly ends, once caught would find themselves without the second necessary element--access. With regard to file copying, copy utility programs aren't other-modifying in the sense that I get from your posting, Dave. As far as a copy utility is concerned, all you're copying is pure text. A copy program don't know the difference between data and object, it just copies bytes from file1 to file2. When invoked, it makes a call to the system to allocate file2, then it writes. When it's done, both files are closed, and the program terminates. Now on a PC, object/data distinctions are easy (*.COM, *.EXE vs. *.DAT, *.DBF). On MVS and the like, that distinction doesn't exist. The only time the system knows the difference between the two is when it's told to EXECute a file. If it's not object or macro or script langauage, you'll know almost immediately. VM is different from MVS in that the MODULE and EXEC filetypes still exist to make things easy for you. Now, you could copy a program that contains a virus to another file, but again, whether you you infect someone else in this manner depends on what accesses are granted through your security subsystem. Again, mail viruses are a different story altogether. And I agree with the many recent postings about script viruses being a "fertile breeding ground". But whether that breeding ground exists beyond the single user is dependent on the file sharing (e.g., through mailings) between users (a Christmas tree, neat, huh?) and accesses granted throughout the system. >Intersting discussion whilst I was on vacation! I agree, let's keep it going. Arthur J. Gutowski, System Programmer MVS and Antiviral Group / Tech Support / WSU Univ. Computing Center 5925 Woodward; Detroit MI 48202; PH#: (313) 577-0718 Bitnet: AGUTOWS@WAYNEST1 Internet: AGUTOWS@WAYNEST1.BITNET -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "He's learning to match the feat of the Old World Man He's learning to catch the heat of the Third World Man He's a New World Man" ------------------------------ Date: Fri, 27 Apr 90 22:10:56 -0400 From: Yary Richard Phillip Hluchan Subject: Re: Possible virus? (Mac) I hope this answer doesn't insult your intelligence, but if you're using a system (or control panel) more than a year old you've got the problem. There was one setting of the keyboard- fastest repeat rate, shortest delay until repeat, I think- that would take any keypress and repeat it for as long at is was held down. That plus a sticky key could do it. Course I could be wrong. ------------------------------ Date: Sat, 28 Apr 90 13:32:35 -0500 From: James Ford Subject: New files to MIBSRV (PC) The following files have been downloaded directly from Homebase BBS on 4/27/90 at 8:00pm (April 27). These file have not been re-zipped in any way, just downloaded, transfered to a floppy, and uploaded to the RT. The files they replace will remain on the server for approximately one week, in case requests for them are pending at BITFTP@PUCC. At MIBSRV.MIB.ENG.UA.EDU (130.160.20.80) in pub/ibm-antivirus - ------------------------------------------------------------------------ CLEANP62.ZIP 46990 CLEAN-UP V62 Virus removal program. (04-25-90) SCANV62.ZIP 45680 VIRUSCAN System Scanner V62. (04-25-90) VSHLD62.ZIP 33323 VSHIELD Infection Prevention TSR Prog. (04-25-90) FSHLD12.ZIP 34693 FILE SHIELD - For Software Developers. (04-27-90) NETSCN62.ZIP 34654 NETSCAN Network Version V62 (04-25-90) VSUM9004.ZIP 35857 Virus Information Summary Listing (04-18-90) - ---------- The man who has accomplished all that he thinks worthwhile has begun to die. - ---------- James Ford - JFORD1@UA1VM.BITNET, JFORD@MIBSRV.MIB.ENG.UA.EDU THE University of Alabama (in Tuscaloosa, Alabama USA) ------------------------------ Date: Sat, 28 Apr 90 12:22:56 -0500 From: haley@sm-logdis1-aflc.af.mil (TSgt William Haley) Subject: virus-l reply The new PC Virus that Don Kazem writes about in Vol 3 Issue 82 is a prank/panic/trick program that will put the message on then proceed to act as if it is formating all hard drives in the affected system. To the best of my knowledge it does no harm to anything except the onwer's peace of mind and general condition of his/her heart for a brief period of time. I have a copy of the program if anyone is interested in obtaining same. Please contact me directly and not thru this list. Below is Kazem's message less the screen shot: >From: Don Kazem I received a call today from one of the local chain food stores about what could be a new virus. Since they have no connection to the network, I offered to post this. A user was running Lotus (by invoking 123.exe), and after a file retrieve, the virus was triggered. The following message was displayed: (The spelling errors are the same as they appeared). (edited out) After a while, the words "JUST KIDDING" appeared, and everything went back to normal. Although, it appeared as though there was no damage, they ran Wipedisk, and installed everything from the original disks. They ran SCAN61 both before and after reinstalling the software, and SCAN did not find anything. The have a backup of the hard disk, before they ran Wipedisk, and are willing to forward copies of their executables to researchers (lawyers permitting). Has anyone heard of this? Don Kazem National Academy of Sciences DKAZEM@NAS.BITNET - ------------------------------------------------------------------------------ \c- W. Rusty Haley, TSgt, USAF | This space reserved for future info. | 2852 Security Police Squadron/SPPC | | McClellan AFB, Sacramento, CA. 95652 | | INTERNET:haley@sm-logdis1-aflc.af.mil| | USS:haley@smdis01.arpa | | ALLIN1: HALEY.RU | | AUTOVON:633-5523 COMM:916-643-5523 | | - ------------------------------------------------------------------------------ \c- ------------------------------ Date: 30 Apr 90 01:13:47 +0000 From: jay@axiom.maths.uq.OZ.AU (Joseph Young) Subject: Public Domain/Shareware Anti-Virus Tools for IBM PC I have a couple of questions about Public Domain or Shareware anti- virus software. 1. I'm confused about the John McAfee product line ... is it share- ware or not? As you can see, I'm from an Australian University and we are interested in using SCANRES (/VSHIELD) on an institution- wide basis. Information we have received from McAfee Associates, suggests we need to buy a site/ corporate licence costing $5,925 (US) for say 500 copies (that's about $7,400 to us down under). A recent posting forwarded by Alan Roberts from John McAfee talks about 'changes to the SCAN shareware product line'. So, do we need a SCANRES license or is it shareware, am I talking about two sets of different products or is the price above the actual shareware price or what? If we need a license, are we talking a site license or corporate license for a multi-campus educational institution? 2. Are there any other public domain/ shareware products similar to SCANRES/ VSHIELD we should look at? 3. Finally, we're running Novell PC networks. What virus protection software are people using in this area? Again, McAfee Associates have NETSCAN for $2,000 (flat fee) according to their product listing. Can anyone help with more information about this? Do you need to buy a copy of NETSCAN for each network you want to protect? Are there any other anti-virus tools we should be looking at for Novell PC networks? Any information at all on any of the above would be greatly appreciated. If there is enough interest, I'd be only too happy to summarise for the net. Joseph Young, Queensland, Australia. E-Mail: jay@axiom.maths.uq.oz.au ------------------------------ Date: 30 Apr 90 03:33:19 +0000 From: woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) Subject: Re: Update to Memo on Computer Viruses in Commercial Products Gimme a break. No wonder our fine government is so screwed up. This is one of the worst cases that I have seen of complicating a written communication. Simplify this stuff. Certainly you can eleminate most of the jargon. There have been reports of commercial packages infected with viruses. Below is a partial list of them. There are legitimate uses and needs for public domain and shareware. Should be Army start random spot checking for these? The above 4 sentences are the gist of the message, and the entire message other than the list could be done in 1 clear paragraph, rather than "missions"...etc et. Cheers Woody ------------------------------ Date: Mon, 30 Apr 90 09:53:57 -0500 From: Ghost Subject: 1704 Version B (PC) Hi out there, we found the 1704 virus version B at RHRZ Bonn, Germany. We got it from a person who learned SPSS PC+ in our pool. The infection software was MIPS.COM, a program what shows the speed of the computer. He give it to the course leader and he give it round in our computing center. Because of the age of the virus i didn't found any comments to it. The infection was 10 month ago, and we didn't know it. Some machines, where public domain software was tested, were clean. They are clean yet. I tried McAfee's CLEANP61 to kill the virus out of the software packages without destroying them, but the software didn't run. I think, i make an error, but i there is somebody else, whop know this problem, please describe it. So long Thomas Friedrich RHRZ Bonn, Germany (UZR50F@DBNRHRZ1.BITNET) ------------------------------ Date: 30 Apr 90 10:15:43 +0000 From: berg@cip-s01.informatik.rwth-aachen.de (Solitair) Subject: Re: *really* fail-safe virus protection hobbit@pyrite.rutgers.edu (*Hobbit*) writes: > ... changed the keyboard key lock in that way that it now > controls the writing electricity cables of one hard disk so that no > writing operation can be done on this (bootable) hard disk. ... >If you install a switch, the >extra wiring should probably be made as short as possible to avoid timing >problems. Well, actually the wire needn't be so very short for a ST506 cable. The specs say the total cable length may be 3m (=10 ft), and you don't have to worry about EMI (electro magnetic interference) because the actual write gate signal doesn't carry such high frequencies. - -- Sincerely, | berg@cip-s01.informatik.rwth-aachen.de Stephen R. van den Berg | ...!uunet!mcsun!unido!rwthinf!cip-s01!berg ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253