From: Kenneth R. van Wyk (The Moderator) Errors-To: krvw@CERT.SEI.CMU.EDU To: VIRUS-L@IBM1.CC.LEHIGH.EDU Path: cert.sei.cmu.edu!krvw Subject: VIRUS-L Digest V3 #93 Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU -------- VIRUS-L Digest Friday, 11 May 1990 Volume 3 : Issue 93 Today's Topics: RE: Military Viruses (THE FACTS) Re: File Compression Program Re: FSHIELD (PC) McAfee's SCAN v61 and Zenith 386SX (PC) Two Random Comments RE: Military Viruses Re: Universal Virus Detector Computer Warfare / Software Sabotage Heriot-Watt Info server status ftp service moving Re: Military Viruses Re: device drivers/viruses/antiviruses (PC) CALL FOR PAPERS: Computers and Ethics Battle field virus / reply: mainframe viruses Re: device drivers/viruses/antiviruses (PC) Re: mainframe viruses 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: Thu, 10 May 90 13:43:15 -0500 From: "Mr. J. Vavrina" Subject: RE: Military Viruses (THE FACTS) After reading, in astonishment, Nick DiGionanni's input regarding Military Viruses, (VIRUS-L 3-90 8 May 90) the phone lines were burning up from my office to the DOD Information Systems Security Management Office checking on the validity of the story. No one had even heard of such a project being undertaken. A few more phone calls later generated a FAX to my desk of an article from the Phildelphia Inquirer titled, "Army Searches for new weapon: Computer Virus", written by Rory J. O'Connor. The article quoted an individual as being the adminstrator of the project. Now the hunt started to locate her. Within a few hours I had her on the phone. Needless to say, the reporter identified himself as a small businessman and was interested in this program. The information given to him was completely turn around so that he could make a big story out of nothing. HERE ARE THE FACTS: The Department of Defense published a booklet titled, "PROGRAM SOLICITATION 90.2 FY-1990 SMALL BUSINESS INNOVATION RESEARCH (SBIR) PROGRAM". On page 45 can be found the following: A90-217 TITLE: Computer Virus Electronic Counter Measure (ECM) CATEGORY: Exploratory Development OBJECTIVE: The objective shall be to determine the potential for using "computer viruses" as an ECM technique against generic military communications systems/nets. The goal shall be to determine the feasibility of remotely introducing a virus into a system/net and analyzing its effects on various subsystem components. DESCRIPTION: The purpose of this research shall be to investigate potential use of computer viruses to achieve traditional communications ECM effects in targeted communications systems. These effects can include data (information) disruption, denial, and deception, but other effects should also be researched such as executable code in processors, memory storage mamagement, etc. Research in effective methods or strategies to remotely introduce such viruses shall also be conducted. Efforts in this area should be focused on RF atmospheric signal transmission shch as performed in tactical military data communications. It continues on to explain what needs to be accomplished in each phase. As you can see, this is nothing more than a feasability study to answer the famous "WHAT IF WE COULD ?????" question. Admittedly, myself and many of my collegues are quite suprised that something of this nature would be put on the streets for research and not using the expertise internally available. Jim Vavrina, Computer Security Specialist, Intelligence and Security Division, US Army Information Systems Software Center. ************** From the Desk of Mr. James M. Vavrina ************** * Comm 703-355-0010/0011 AV 345-0010-0011 * * DDN:SDSV@MELPAR-EMH1.ARMY.MIL AMPR: KA4USE @ KA4USE.VA.USA.NA * ******************************************************************* ------------------------------ Date: Thu, 10 May 90 13:24:27 -0500 From: Naama Zahavi-Ely Subject: Re: File Compression Program >One wonders if a self-extracting archive (LHZ, PKZip, PKArc, etc) could become >a carrier of a virus.....ie, un??? a file, get some files plus (maybe) a virus ? >Or would the virus itself corrupt the EXE file, thereby not allowing you to >extract any files (but still be infected)? >---------- >---------- >James Ford - JFORD1@UA1VM.BITNET, JFORD@MIBSRV.MIB.ENG.UA.EDU > THE University of Alabama (in Tuscaloosa, Alabama USA) Hello! I don't know whether a virus can infect a self-extracting archive, but I assume it is possible. However, the virus can only infect the receiver's computer when the self-extractor is actually run. For that reason, I always check self-extracting archives with a virus-scanner before running them. And then, if the components include programs, I check the extracted programs as well. Better safe than sorry! Perhaps the folk on Virus-L will be able to shed light on the question? Best wishes, - -Naama + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + | Naama Zahavi-Ely | | Academic Computing Services e-mail ELINZE@YALEVM.BITNET | | Yale Computer Center Zahavi-Ely-Naama@Yale.Edu | | 175 Whitney Ave | | New Haven, CT 06520 | | (203) 432-6680 EXT. 341 | + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + ------------------------------ Date: Thu, 10 May 90 11:02:06 +0300 From: Yuval Tal Subject: Re: FSHIELD (PC) In reply to a message from David Chess: >Wild! Can you (or anyone else) say how it does that? For instance, Ah....it's hard to explain how it works. I suggest you add FSHIELD to one of your files and then infect it and see how FSHIELD gets rid of it.. >if the original file is > > A B C D E > >how does it tell whether it's been infected by a virus like > > B C D E A > >rather than a virus like > > C D E A B Note that FSHIELD cannot restore already infected file! It protects the file! If the file changes, FSHIELD tells you and you can restore the original file if you want. Also note that the shareware version does not have a device driver which is included in the registered version. The device driver can also check if files were changed even if the 4096 virus or any other stealth virus is in memory. About your question, FSHILED does not know how the virus is on the file! It only restores it. It of course cannot remove viruses which overwrite the beginning of the file but does not have the original at the end. But then, there is no anti-viral software (and there will be not) which can remove this kind of viruses (i.e. LEHIGH). - -Yuval Tal +--------------------------------------------------------------------------+ | BitNet: NYYUVL@WEIZMANN Domain: NYYUVAL@WEIZMANN.WEIZMANN.AC.IL | | InterNet: NYYUVAL%WEIZMANN.BITNET@CUNYVM.CUNY.EDU | +----------------------+---------------------------------------------------+ | Yuval Tal | Voice: +972-8-474592 (In Israel: 08-474592) | | P.O Box 1462 | BBS: +972-8-471026 * 20:00-7:00 * 1200 * N81 | | Rehovot, Israel | FidoNet: 2:403/143 | +----------------------+---------------------------------------------------+ | "Always look on the bright side of life" *whistle* - Monty Python | +--------------------------------------------------------------------------+ ------------------------------ Date: Thu, 10 May 90 11:04:00 -0800 From: "Chuck McDaniels" Subject: McAfee's SCAN v61 and Zenith 386SX (PC) Hi: I'm trying to use the McAfee SCAN program (version 3.1v61) in our computer lab. It works wonderfully with the IBM XT's and PS/2's, but seems to have a problem with our new, snazzy Zenith 386SX's. When it goes to scan the hard drive (C:), it says, "I can't figure out the sector size" (or words to that effect), and goes on to say, "Do you have a hard drive C:?" The 386SX has a 42MB hard drive (Zenith drive type 44). What do I need to do to get SCAN (or whatever program) to look for viruses on the hard drive? The whole 42MB is a single partition, thanks to Zenith's MS-DOS 3.3 plus. Any advice or horror stories are welcome. Thanks in advance for any assistance you can give me. Chuck ++++ Chuck McDaniels, Systems Consultant, Phone: (714) 787-4711 ++++ ++++ Univ. of California, Riverside BITNET: ChuckM@UCRVMS ++++ ++++ Thank you for not blaming UCR or anyone else for anything said here ++++ ------------------------------ Date: Thu, 10 May 90 13:48:56 -0400 From: Arthur Gutowski Subject: Two Random Comments RE: Military Viruses >From: "Charles Cafrelli IAQR100@INDYVAX" >Course there's also the example from Star Trek II:The Wrath of Kahn, where >Kirk and gang use the computer codes to turn off the shields on Kahn's ship, >when he thought he was getting the data of the Genesis program. But that >depended on an open system. Did you also see the New Generation episode (the title escapes me now) that involved a virus infecting the Enterprise's computer system? It required them to shutdown everything but life support, startup with clean memory banks, and reload from "backups". >From: jwright@cfht.cfht.hawaii.edu (Jim Wright) >Hmmm.. just how many viruses have been written in Ada? Yeeech, what a scarrry thought! Not only does it spawn into other programs, but spawns more infective processes while it's running. Sounds a lot like what the Star Trek: The New Generation virus did, since I believe their memory banks are primary storage rather than disk or tape. /=====\ 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 \=====/ AGUTOWS@cms.wayne.edu Have a day. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "It's so hard to stay together Passing through revolving doors" ------------------------------ Date: Thu, 10 May 90 12:11:39 +0300 From: Y. Radai Subject: Re: Universal Virus Detector Now that I finally have some time, I'd like to post my comments on the paper by Chris Ruhl and James Molini, "A Universal Virus Detection Model", an extended abstract of which appeared in V3 #71. (Note: The quotations which I reproduce below are from the full paper. Several of them are absent from the abstract.) I agree with the general idea of using a checksum type of detector and I appreciate the effort which the authors have made in formulating it in terms of a model. Nevertheless, I think that in many respects they have put the emphasis on the wrong points. I'll mention here only the most important of my disagreements: 1. In my opinion, the measures proposed by the authors are either too little or too much, depending on which part of the paper one looks at. Let's start with the "too little" part: >So to put our theoretical UVD into practice, on, for example, an IBM >PC, we would do the following: >..... >b. Validate the integrity of the read process by checking the > interrupt table and low memory for changes. This would stop the > 4096 and viruses of its species, which place themselves in the > memory resident read procedures and mask infections. A memory-resident virus does not have to modify any interrupt vectors. What better example than the very one they name, the 4096 (which in- stead overwrites the first few bytes of an existing handler with a jump to its own routine)? The surest way to ensure that memory (not only low memory, but *all* of RAM) is uninfected when the detection program is run is to keep the program and its database on a bootable diskette, and then to run the program only from that diskette and only immediately after cold-boot- ing from that diskette. (Russell Wallace claims that most users would consider this unaccep- table hassle. But if the checksum program is what I have called in previous postings the "static" type, then it's unnecessary to run it more than once per boot or per day, or even per week. I don't consi- der that unacceptable hassle at all.) True, the authors do say something like the above in their full paper when they write: > The following methods attempt to validate >the integrity of the detection code, or stored tables: > >a. Run the detector from a write-protected, bootable floppy, thus > assuring a validated run time environment and providing a constant > set of scan pointers. > ..... But the wording here (and in many other places in the paper) seems to me so unclear that I confess I have no idea whether the authors actually intend to implement Method (a) or not. If they do, why isn't this important instruction mentioned in their abstract and in their steps for "putting their theoretical UVD into practice"? The reason that this measure is important is that if they do implement it, then most of the remaining precautions (e.g. validating the integrity of the read and output processes and prepending the set of dynamic state vectors) become unnecessary. And if they do not implement it, then their measures are insufficient. In the one case, it's too much; in the other it's too little. 2. The authors write > Any program which >circumvents the modification of existing code is not a virus. Well, that may be correct *formally*, according to their definition of a virus. But from a practical point of view, I think it's the wrong approach, since under DOS one can construct replicating programs which do not modify existing code (hence may not be viruses according to their definition), yet which may get executed. Moreover, they could be detected by a properly constructed detection program. To ignore detectable pathogenic programs on the grounds that they don't fit the authors' definition of a virus is unrealistic. 3. They also write: > (Insert your favorite >Checksum/CRC/Cryptographic routine here.) This parenthetical remark requires a lot of elaboration. If we represent the checksumming routine by F, then at the very least the following conditions should be satisfied: (A) For any given file f, F(f) is (in general) different for each computer. (This condition amounts essentially to requiring a key which is chosen randomly or personally by each user.) (B) Given a file f, it is computationally infeasible (without know- ledge of the key) to construct a file f' from it containing the de- sired addition of (or replacement of ordinary code by) viral code such that F(f') = F(f). Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI1@HBUNOS.BITNET RADAI@HUJIVMS.BITNET ------------------------------ Date: Thu, 10 May 90 17:40:17 +0000 From: yamauchi@heron.cs.rochester.edu (Brian Yamauchi) Subject: Computer Warfare / Software Sabotage While "viruses" may not be particularly effective tactical weapons, and sending them over radio links may be impractical, software sabotage in general seems like a much more plausible military application. Assuming agents (CIA, Special Forces, etc.) can get behind enemy lines to tap into the enemy's computer network, they could do quite a bit of damage using worms, trojan horses, and time bombs -- especially if these programs were set to go off in conjunction with a conventional (or nuclear?) military offensive. Being able to fix the damage to your C3I system in a matter of days is fairly irrelevant if a major offensive is taking place _right_now_. _______________________________________________________________________________ Brian Yamauchi University of Rochester yamauchi@cs.rochester.edu Computer Science Department _______________________________________________________________________________ ------------------------------ Date: Thu, 10 May 90 19:40:39 -0000 From: David.J.Ferbrache Subject: Heriot-Watt Info server status >From 11 May the Heriot-Watt info-server mail based archive server will again be operational. Updated anti-virus utilities are being installed to again bring the archive up to date. In the meantime users are asked to retry requests one week later when updated versions of fsp, scan, cleanp etc will be available. The material available divides into: 1. Anti-viral utilities for Apple, Amiga, Atari ST, IBM PC and Macs (apple, amiga, atari, ibmpc, mac) 2. Various machine specific reports on viruses on the above PCs stored by machine 3. General documents on anti-viral measures and software integrity (general) 4. Project Athena reports and working papers stored in the athena directory (athena) 5. Computer Emergency response team advisories (cert) 6. Federal information processing standards (fips) 7. Request for comments on sercurity issues (rfc) 8. DDN security coordination centre bulletins (ddn) 9. Public CIAC advisories (ciac) 10.Backissues of virus-l from epoch (virus) 11.Logs of security-l traffic from epoch (security) 12.Backissues of risks-l from v4.30 (risks) 13.SPAN network operations centre reports on DECNET worms (span) 14.Various reports on the Internet worm (unix) 15.Fixes and binary patches for Sun 3/4, Pyramid and BSD standard systems relating to security (fixes) To retrieve a general index send a message containing the text: request: index topic: index to the address " info-server@cs.hw.ac.uk ". To retrieve an index on a specific topic from the above list send a message containing the text: request: unix topic: index where the request string is given in brackets after the description above. Specific issues of virus-l can be retrieved by sending a message of form: request: virus topic: v2.28 To all those who tried to use the server over the last few months, my apologies for the service interruption. All request received after May 1st have been reprocessed. Finally, if anyone has any material in the general areas of mainframe system security or personal computer security which they feel is acceptable for public retrieval, then please feel free to send me a copy. Software in binary form will be accepted only from known archive sites or authors. Normal service I hope! - ------------------------------------------------------------------------------ Dave Ferbrache Internet Dept of computer science Janet Heriot-Watt University UUCP ..!mcvax!hwcs!davidf 79 Grassmarket Telephone +44 31-225-6465 ext 538 Edinburgh, United Kingdom Facsimile +44 31-220-4277 EH1 2HJ - ------------------------------------------------------------------------------ ------------------------------ Date: Thu, 10 May 90 16:19:01 -0500 From: "Mark S. Zinzow" Subject: ftp service moving Most files available for anonymous ftp on our campus are moving to ux1.cso.uiuc.edu (128.174.5.59). The pc/virus files that were previously on uxe.cso.uiuc.edu have been copied to ux1 from uxe and updates are only being added to ux1. Next Monday we're scheduled to pull the plug on uxe. The rest of the Fred Fish and Amicus disks for the Amiga, and the Champaign Urbana Macintosh User Group disks are currently being moved from mrcnext.cso.uiuc.edu and doc.cso.uiuc.edu to ux1 as well. - -------Electronic Mail---------------U.S. Mail--- ARPA: markz@vmd.cso.uiuc.edu Mark S. Zinzow, Research Programmer BITNET: MARKZ@UIUCVMD.BITNET University of Illinois at Urbana-Champaign CSNET: markz%uiucvmd@uiuc.csnet Computing Services Office "Oh drat these computers, they are 150 Digital Computer Laboratory so naughty and complex I could 1304 West Springfield Ave. just pinch them!" Marvin Martian Urbana, IL 61801-2987 USENET/uucp: {uunet,convex,att}!uiucuxc!uiucuxe!zinzow Phone: (217) 244-1289 Office: CSOB 110 \markz%uiucvmd ------------------------------ Date: Thu, 10 May 90 16:21:19 -0100 From: Paolo Mattiangeli Subject: Re: Military Viruses Nick DiGiovanni writes: >Thought the following might stimulate some discussion. I just read in >a newsbrief that the U.S. Army wants to turn viruses into military >weapons. The idea is to use viruses to wreak havoc with computers in >the battlefield. The newsbrief points out viruses could be used to >disrupt military communications, impede weapons control and feed >misleading data to enemy commanders. Viruses could also be used to >alter programming of communcations satellites serving combat units. I think this would be very dangerous. Everyone who knows the basics of modern military systems can tell you that in order to avoid (if is possible at all|) the global holocaust, each conflicting part MUST NOT disrupt the enemy command, control and communications. If used in a nuclear exchange, such virii could raise down to zero the ability of the conflicting countries' commanders to keep the situation under control. This would be suicide. ------------------------------ Date: Thu, 10 May 90 18:56:41 -0400 From: flaps@dgp.toronto.edu (Alan J Rosenthal) Subject: Re: device drivers/viruses/antiviruses (PC) ISCDEC@UCCVMA.BITNET (Dennis Clouse) writes: > There are also empty EPROM sockets in my PC: would it be possible to produce >code for a viral filter on EPROM (which would activate prior to CONFIG.SYS)? For macs, I receive a new virus checker every few months which checks for a couple of new viruses. I expect the situation would be worse with ibm-pcs. Do you think it would be reasonable to have everyone reprogram their eproms (or receive new ones) every few months? This would be a major installation operation in a large centre. ajr ------------------------------ Date: 10 May 90 15:45:41 -0500 From: wsuiar!gotterbarn%sdcsvax@ucsd.edu Subject: CALL FOR PAPERS: Computers and Ethics The *Journal Of Systems and Software* is preparing a special issue on Computing and Ethics. Although the major emphasis will be ethical issues faced by the Computing Professional, other subjects will be considered. Please send your papers by July 1, 1990 to: Donald Gotterbarn The Wichita State University Computer Science, Box 83 Wichita, KS 67208 Send questions by email to: gotterbarn@wsuiar.wsu.UKans.EDU gotterbarn@twsuvax.bitnet ------------------------------ Date: Thu, 10 May 90 19:26:31 -0700 From: teda!RATVAX.DNET!ROBERTS@decwrl.dec.com (George Roberts) Subject: Battle field virus / reply: mainframe viruses Arthur J. Gutowski asks: >of their job. How do you maintain the integrity of a system that doesn't >have any security? Notwithstanding trust, what about innocent accidents? Do backups! Daily! ============================= Charles Cafrelli writes: > I'm curious as to how one would actually implant a virus over military > radio frequencies, especially if one were using a closed system. The only I'm sure you could really confuse things by uploading a program to their satelites with slightly altered code. But this wouldn't be classified as a computer virus. Sounds like they don't know what they are talking about maybe? Also, don't viruses take months to spread? Doesn't sound like a battlefield weapon! However, I remember reading an article (sorry don't remember where - Mass. high tech.?) explaining how a virus was successfully used to win a mock battle among Australian soldiers. The type of mock battle that uses real guns, tanks, radios, and battle computers - but fake bullets. I think they said they used a modified version of the STONED virus. Probably the virus was set to trigger at the same time as when the team made their main attack. - -George Roberts ..decwrl.dec.com!teda!ratvax.dnet!roberts ------------------------------ Date: 11 May 90 09:39:14 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: device drivers/viruses/antiviruses (PC) ISCDEC@UCCVMA.BITNET (Dennis Clouse) writes: > If CONFIG.CTL can hook the system prior to CONFIG.SYS installation, then so > can virus infections (including a tainted CONFIG.CTL), and it's much easier to > relocate and manipulate 200 bytes of CONFIG.SYS than an entire boot sector > (like BRAIN does) to disguise it's operation. No .SYS infecting file is known today, but I am expecting one soon. The reason: I received a call from a person in Iceland who said he had been infected with such a thing and asked me if I would like a copy. Of course I replied "Yes, sure" and he promised to send me a copy by mail. This was a couple of weeks ago, and nothing has arrived yet. He had given me his name, but not his phone number, so I attempted to locate him, by looking him up in the national registery. However, I found out that nobody with this name exists in Iceland. A fake name - a non-appearing virus......either it was a joke or the person who called me is writing such a virus. If so, I even consider it fairly likely that he may be the author of the other Icelandic viruses. > Are there any anti-viral PC products which load/activate via the CONFIG.SYS? Quite a few, actually. The anti-virus program by T.P. (the author of the Vacsina/Yankee Doodle series of viruses) is one. It had the name of 'VACSINA', which some of his viruses checked for, which was the reason the string 'VACSINA' appeared in the Vacsina virus. My own F-PROT package contains another .SYS file, a small 2000 byte program that monitors the execution of other programs and will stop any known virus, just display a message like This program is infected with the ......... virus Access denied when an attempt is made to run an infected program. As you say, the big plus with .SYS files is that they are currently immune to viruses, and are activated before any program virus gets run. I have no doubt that several other .SYS anti-virus products exist as well. > Could validation software be produced which checks ROM and/or custom EPROM > anti-viral code, or could the EPROMS be self-validating? They could, yes - but any modified EPROM could be made to appear normal, so it would not be of any use. - -- Fridrik Skulason University of Iceland | Technical Editor of the Virus Bulletin (UK) | Reserved for future expansion E-Mail: frisk@rhi.hi.is Fax: 354-1-28801 | ------------------------------ Date: Fri, 11 May 90 12:00:05 +0700 From: "Christian J. Reichetzeder" Subject: Re: mainframe viruses I use to say: there are no impossibilities in electronic data processing but some things take helluva time. There are backdoors and holes in operating systems and when you know one you can often easily exploit them. Even then it is not a simple task to develop a true virus. You may be able to crash remote systems, fake addresses or send Trojans around. Being a VM and MVS systems programmer I can only speak of these systems. From experience I'm more worried about software bugs than about viruses. There are other things making virus-writing complicated. On a pc you have full control over the environment and can play whatever tricks you want. On a mainframe it's near to impossible to have the environment under your exclusive control. It takes a fair amount of time to run the required tests and after that you probably have to restore the system to it's former state. I admit that a clever virus *could* go unnoticed for sufficient time. But it's rather unlikely that the *developement* of the virus would - unless the whole systems group is taking part. Well, 'nuf said for now, I'll wait for comments Christian ------------------------------ End of VIRUS-L Digest *********************