VIRUS-L Digest Wednesday, 11 Apr 1990 Volume 3 : Issue 74 Today's Topics: Signature Programs Re: Death of a Virus Re: Death of a Virus Re: Universal Virus Detector FTPing Disinfectant Re: Death of a Virus validation False Indications from VIREX 2.5.1 (MAC) Virus on Apollo? (UNIX) Re: Validating Virus Software 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: 10 Apr 90 09:36:58 -0400 From: Bob Bosen <71435.1777@CompuServe.COM> Subject: Signature Programs Several weeks ago, Ross Greenburg challenged me to obtain and post descriptions of tests and user experiences involving use of sophisticated authentication algorithms in the "real world" against real viruses. Because I represent a commercial software vendor I was hesitant to publish my own test results out of fear I would sound biased. Most of my clients are rather secretive, and it took a while before I was able to arrange for the following to be written and cleared for posting. The following is a message forwarded from Padgett Peterson, a well-known (in some circles) virus researcher, employed by a well-known Defense Contractor. He speaks only for himself. Padgett conducted a detailed evaluation of a great many viral defense products, subjecting them to a collection of viruses and stressing them in other ways. I am posting his words for him because at the moment, his internet access is rather awkward. He comments on valuable ways to use authentication algorithms at all ends of the spectrum, and I find his views similar to my own, inasmuch as my product offers authentication algorithms at all ends of the spectrum and allows users to "fine-tune" the sophistication of the algorithm to suit all the extremes and norms Padgett discusses. But there are things in his views that'll make a lot of folks happy. The following are his words: FOR POSTING A. Padgett Peterson Recently, following a hiatus from the VIRUS-L forum, I have had the opportunity to examine the continuing authentication (thank you WordStar) saga. All of the people involved appear to be knowledgeable and concerned participants, yet they seem to be arguing the same side of two different questions: 1) Authentication of known software in a controlled unique environment (Radai and Greenberg). 2. Authentication of unknown, publicly transmitted software (Bosen and Murray). The virus issue, while a valid concern, is just a complicating factor, since, if the software were trusted, by definition it could not be infected. The focus of the issue is what level of authentication is necessary for trust. All of the participants agree that some is necessary - the question is how much? My personal feeling is that an authentication algorithm may be very simple (CRC or less) provided that it is unknown (or unpredictable). Since my 4.77 Mhz/ST-412 museum piece is capable of a simple byte count/XOR/ROR disk file check at 50k bytes/second (and could be faster if done in RAM by a TSR between LORD and EXECUTE), performance concerns are unnecessary (quantum economics). This method is suitable for any physically controlled system. Unfortunately, Mr. Greenberg's algorithm fails this test because it is publicly known. A mechanism designed to subvert his programs is feasible (worm, trojan, virus, bomb, etc.). However, given a small number of different algorithms (ADD/SUB/XOR followed by ROL/ROR/NOP give nine easily) generated by a machine-unique seed (time hack at initial algorithm load would work), a non-resident intruder would have a very hard time subverting a system without generating a few errors first. This is particularly effective if even the creator of such a program cannot predict which algorithm/seed will be used on a particular machine. A procedure such as this is even workable in a networked/server environment: the file itself is stored en clair. Each authorized user has a unique signature file. No two signatures match yet each will authenticate the same file in the proper machine. A nightmare for intruders. Alternatively, a publicly transmitted file for which the algorithm/key is also public requires a much more rigorous algorithm to avoid spoofing or infection by a determined intruder. In this case ANSI or DES is appropriate. Taken together, the indication would be that for inter-machine transmission, the more rigorous public-key methods would be appropriate, while a much simpler one would be suitable for intra-machine retrieval. This would postulate a software package that: a: Uses a simple (fast) but unique algorithm for known files whose signatures are stored on the platform. b: Requires a much more rigorous authentication process for unknown files (possibly also requiring authorization for load). c: Once (b) is satisfied allows a file to migrate to (a). Considering the viral threat, if a virus is accompanied by a valid signature, ANY authentication scheme will pass it, however, as aoon as a resident file is infected, the unique resident signature will become invalid. The point was raised concerning Boot and Partition Table Infectors (Hidden Sector, FAT, Root, RAM-Resident, and Bad Sector Infectors are also possible). This is a different question from that of authenticating a file. At present I know of only one package that provides complete coverage: Enigma-Logic's Virus-Safe which I use. However, over 90% of all PC virii could have been caught early by a CLI that occasionally compares the Top-Of-Memory, the end of DOS/TSR memory, and the first byte of the Boot Sector against known values. MS-DOS doesn't. (END OF PADGETT PETERSON POSTING) Thank You, Bob Bosen Enigma Logic Inc. ------------------------------ Date: Tue, 10 Apr 90 11:39:00 -0500 From: HORN%HYDRA@sdi.polaroid.com Subject: Re: Death of a Virus A more accurate analogy might be the introduction of clean water systems rather than the elimination of smallpox. The widespread use of modern operating systems with memory and device protection will greatly hinder the spread of viruses, but by no means prevent their spread. I can think of methods to implement Unix and VM viruses. Most of these depend upon sloppy system administration methods for rapid spreading, but at least for now sloppy administration is the norm. Some of these have been demonstrated by attacks like the Internet Worm. But with a more modern hardware and operating system it is much harder to spread and easier to cure. This is similar to what you find today with water-borne diseases. Typhoid, cholera, and dysentery are by no means eliminated in the US, but they are no longer a normal cause of death. They promptly return after disasters break down the water systems (well cholera is still rare, but would recur if the breakdowns lasted long enough). Probably the greatest strength of most current systems is the diversity of hardware and operating system revisions. This forces the use of source (non-executable) for most inter-machine transfers and greatly hinders the spread of viruses and worms. The strong commercial push for standard binary interfaces is a danger in that it will greatly increase the size of the computer population that is vulnerable to any one specific attack. R Horn horn%hydra@polaroid.com ------------------------------ Date: 10 Apr 90 00:00:00 -0500 From: "David.M.Chess" Subject: Re: Death of a Virus kelly@uts.amdahl.com (Kelly Goen) writes, apparently in response to a posting of mine: > Yes dave but under environments which use say the VM8086 model on > the 386 (such as VPIX) file writability and/or hardware acces is > TOTALLY under the control of unix... weak unix security weak dos > security good unix security = good dos security in this case.... My point was that putting file access under the control of the operating system *doesn't help*, at least not as much as people generally assume. Viruses spread by writing to files that they are *allowed* to write to; they don't depend on a lack of security. If most programs have write access to only a few other programs, viruses may not be able to spread as fast; but lowering the exponent on an exponential spread helps surprisingly little. Now of course this may be what you were saying; I'm not entirely sure I understand the posting... DC ------------------------------ Date: 10 Apr 90 22:44:00 +0000 From: alpope@skids.Eng.Sun.COM (Alan L. Pope) Subject: Re: Universal Virus Detector A Universal Virus Detector? Go reread Goedel's Incompleteness Theorem. Alan Pope ------------------------------ Date: Tue, 10 Apr 90 15:49:57 -0400 From: ELOISE@MAINE.BITNET (Eloise Kleban) Subject: FTPing Disinfectant Someone recently commented on the difficulty of downloading Disinfectant from Simtel20. I would say it is easier to access sumex-aim.stanford.edu for Macintosh software. Simply FTP the files in ascii mode (non-binary) to your CMS account, then download them (again, in ascii) to your Mac. On the Mac use Stuffit to decode and un-archive the applications. I recently acquired Disinfectant 1.7 this way with no trouble. Eloise Kleban BITNET: ELOISE@MAINE Academic Coordinator INTERNET: ELOISE@MAINE.MAINE.EDU Computing Center Phone: (207) 581-3518 University of Maine Orono, ME, USA 04469 ------------------------------ Date: Tue, 10 Apr 90 22:50:39 +0000 From: Dave Ihnat Subject: Re: Death of a Virus CHESS@YKTVMV.BITNET (David.M.Chess) writes: >Unfortunately, viruses do not depend on this hardware model; viruses >can spread in any system that allows both programming and information >sharing, regardless of whether or not programs have direct access to >the hardware, whether or not the system is assumed to be single-user, >and so on. See various papers by Fred Cohen on the subject. As long >as (roughly) some programs sometimes have write-access to some other >programs, viruses can spread. >Dave Chess >IBM T. J. Watson Research Center As a practical matter, I was trying to not go into a lecture on the differences between the hardware and software models you bring up. But the baseline is this: All of the single-user machines which are currently the major targets of viral attack provide NO hardware model which allows preemptive control by the OS or monitor of program access to memory or hardware. Thus, in such systems, it is categorically impossible to provide a reliably virus-free environment. Systems which provide the underlying hardware CAN be made much more secure. In this environment, it is still possible to improperly use the provided capabilities and thus grant unauthorized access; but this is not a case of CAN be secure, but DIDN'T make it secure but had the capability. As a real- world example, Unix and VMS systems don't see the widespread attacks that single-user systems such as the PC and Mac have "enjoyed." Attacks on such multi-user/multi-tasking systems that are successful invariably result from either errors in the protection mechanisms (usually, not the hardware itself, but rather the operating system which utilizes it) or errors in application of the provided protections, either by programmers (privileged programs that don't properly control access, etc.), or by administrators and users who don't use such capabilities as ACL's and file permission settings. So the point I was making is that in an environment which doesn't even provide underlying hardware support for protection, it's impossible to make a secure, safe system no matter how good you are in software development. Having the hardware, however, does not guarantee such security; but id does make it possible. ------------------------------ Date: Wed, 11 Apr 90 01:05:41 -0400 From: *Hobbit* Subject: validation The best way anyone could validate his antiviral is to distribute the sources. Which most of these authors seem highly unwilling to do, for some odd reason. Did you ever wonder what they were hiding sometimes? This exe-file validation stuff is a crock. _H* ------------------------------ Date: Wed, 11 Apr 90 08:08:22 -0500 From: SDSV%ISEC-OA@IBM1.CC.Lehigh.Edu Subject: False Indications from VIREX 2.5.1 (MAC) HJC Software, authors of VIREX Virus Detection Software, has confirmed a bug in their software version 2.5.1, ALL software written in QuickBasic will give you a false msg of a Trojan Horse being detected. HJC Software will be releasing version 2.6 shortly which will correct this problem. It will be sent to all registered users. This was brought to my attention by a fellow ham radio operator, O.P., KF4TE, who attempted to use a program MacLogger. I have personally talked to Chris Lyons, VE3GUS, author of MacLogger and confirmed that his software WAS written in QuickBasic. JIM ************** 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: 11 Apr 90 12:28:16 +0000 From: nilsh@kuling.UUCP (Nils Hagner) Subject: Virus on Apollo? (UNIX) Does anyone know whether any viruses have been found on Apollo workstations? In that case, are there any available anti-virus tools? ============================================================== Nils Hagner | UPMAIL: nilsh@emil.csd.uu.se | | Infologics: nilsh@infolog.se | ============================================================== ------------------------------ Date: 11 Apr 90 12:55:19 +0000 From: berg@cip-s02.informatik.rwth-aachen.de (SRB) Subject: Re: Validating Virus Software In article (Gary Mathews) writes: >In fact, a list of must commonly used programs should be included on >such a list, but for now the validated strings of the lastest versions >for the scan and clean programs should be publically accessible. Many I always wondered: shouldn't the crc-32 and crc-16 of zip and arc files be unique enough to validate any file? Why can't we just put these checks and the length of a file on the net. If you insist, then of course you could add any propietary validation values like the ones obtained from the validate program. But I'm pretty sure that most people trust their favorite zip or arc program more than some kind of a so-called validate program. - -- 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