VIRUS-L Digest Monday, 23 Sep 1991 Volume 4 : Issue 169 Today's Topics: OS/2 Viruses (OS/2) re: Scanning LZEXE and PKLITE'd files (PC) Re: SCAN version 83? (PC) re: Scanning LZEXE and PKLITE files (PC) Re: BIOS Viruses (PC) Re: Viruses more common in Mac environment? DOS Executable files (PC) Belch_Virus? (Mac) Equal time for Virus Simulator Re: bogus scan?? (PC) Testing methodology 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 VIRUS-L at LEHIIBM1 for you 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: Fri, 20 Sep 91 14:46:00 -0400 >From: Seanor@DOCKMASTER.NCSC.MIL Subject: OS/2 Viruses (OS/2) Does anyone have information on computer viruses that infect OS/2 files? I thought I had heard something about an OS/2 virus. If anyone has any information I would like to hear about it. Thanks! Joe Seanor [Ed. FYI, Kevin Haney will be presenting his paper, "Viruses in an OS/2 Environment: Remembrances of Things Past and a Harbinger of Things to Come", at next month's NCSC/NIST conference in Washington, DC.] ------------------------------ Date: Fri, 20 Sep 91 17:30:42 -0400 >From: pshuang@ATHENA.MIT.EDU Subject: re: Scanning LZEXE and PKLITE'd files (PC) > I would think that a scanner could also extract the decompressing code > from the executable, remove the jump to the expanded program, and use > that to expand without executing. This solution has the problem that it would make the scanner sensitive to the version of PKLite which was used on the executable, which is not a good thing. Also, it would mean that it is possible for the scanning process to *ACTIVATE* a virus, if a new unidentified virus was embedded in the code which the scanner thought was the decompressing code, whereas normal scanning does not. Of course, shelling out to PKLITE to decompress an un-encoded file runs the same risk. There's always a price. - --- Above text where applicable is (c) Copyleft 1991, all rights deserved by: UNIX:/etc/ping instantiated (Ping Huang) [INTERNET: pshuang@athena.mit.edu] ------------------------------ Date: Fri, 20 Sep 91 22:30:59 +0200 >From: Mikael Larsson <@sunic.sunet.se:vhc@abacus> Subject: Re: SCAN version 83? (PC) HAYES@urvax.urich.edu Wrote: > Does anyone on this list know something about either a "windowScan" or a > version 83? Current version of SCAN is Scanv82, it was released 15th of September. It's available at HomeBase or from some BBSes, for example mine... HomeBase 2400 +1 (408) 988 4004 HomaBase 9600/HST +1 (408) 988 5138 HomeBase 9600/V32 +1 (408) 988 5190 or Virus Help Centre +46 (26) 275710 About WindowsScan, yes! There is a product called 'Scan for Windows' but it's still a Beta version. It will be released sometime in September I think... Hope this will help You! > Best to all, Claude. Best Regards, MiL --------------------------------------------------------------------------- Virus Help Centre BBS Line #1: +46 26 275710 P.O. Box 7018 BBS Line #2: S-811 07 Sandviken FidoNet : 2:205/204 Sweden VirNet : 9:461/101, 9:9/0 Phone: +46-26 100518 Home of VirNet Fax : +46-26 275720 McAfee Associates Agent Sweden VSUM Agent Sweden Thunderbyte Support Sweden Member of PCVRF ---------------------------------------------------------------------------- ------------------------------ Date: Fri, 20 Sep 91 17:42:44 -0400 >From: pshuang@ATHENA.MIT.EDU Subject: re: Scanning LZEXE and PKLITE files (PC) > Furthermore, it's stupid to claim that files compressed by the > customized version of PKLite are unexpandable. They have to be > expanded in memory when run, don't they? Yes, it is true that PKLite'd programs have to be unexpandable so that they may be executed, but your statement is more or less equivalent to "Encryption isn't effective because the receiver has to be able to recover the plaintext." Any decent encryption makes the decryption process non-trivial. In this case, I don't know exactly what PKWare does for these customized, numbered versions of PKLite, perhaps crpyotgraphically it is a trivial change which can be broken, but it is non-trivial to the end-user to recover the original. > They're just not expandable to their -exact- (byte by byte) original > source. But, of course, the code (which contains the instructions and > where the virus hides) -can- be expanded exactly. Out of curiosity, if you state that the code can be expanded exactly, then what is your intended pronoun reference in "They're just not..."? > Besides, Ross Greenberg's VirX scans in such "unexpandable" programs > perfectly. I had not had direct experience with Greenberg's VirX. I'm sure that it is technically feasible to break whatever scheme PKWare used, though. I'll try to remember to grab VirX to look at its documentation, but does anyone know of shareware/public-domain programs which have been compressed with a customized PKLite which I can play with? - --- Above text where applicable is (c) Copyleft 1991, all rights deserved by: UNIX:/etc/ping instantiated (Ping Huang) [INTERNET: pshuang@athena.mit.edu] ------------------------------ Date: 20 Sep 91 22:09:18 +0000 >From: vail@tegra.com (Johnathan Vail) Subject: Re: BIOS Viruses (PC) privsec!guillory@uunet.UU.NET (guillory) writes: users upgrading system BIOSes by floppy disks. Quoting from the article: "The Powerline 450SE also features a proprietary firmware system that uses Intel Flash memory to store the system BIOS. In the future users will be able to upgrade system BIOS by installing a new file from a floppy disk." The one thing you could always trust to be safe from viruses was the system BIOS. Can this be exploited by virus writers? If so, how long before they do? Although FLASH memory can pose a real danger in terms of viruses, it is not quite as bad as people think. As I understand it, in the chip there is a non-erasable ROM portion, which can provide a "safe" way of booting the machine from a known floppy. Makers of the PCs with FLASH can disable writing the memory in hardware, making updating the BIOS impossible without a specific action by the user. Similar to a write protect tab for a floppy. In summary, yes FLASH memory should be a concern, but it is not the end of the world for safe computing on PCs. jv "Frisbeetarianism is the belief that when you die, your soul goes up on the roof and gets stuck." -- button _____ | | Johnathan Vail | n1dxg@tegra.com |Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet) ----- jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail ------------------------------ Date: 20 Sep 91 22:15:55 +0000 >From: vail@tegra.com (Johnathan Vail) Subject: Re: Viruses more common in Mac environment? bdrake@oxy.edu (Barry T. Drake) writes: I was not trying to claim that Mac viruses are more prevalent in general; I was relating our experiences here. We have had PCs since '85 and college- owned Macs since '88. I made a similar claim here and even went so far as to assert that I had never run across a PC virus. Several people agreed, several disagreed with my experience. This week one of the PCs here became infected with the "Dark Avenger" virus. I can now retract my second claim. Out of curiosity, can anyone tell me more about this virus. What it does, how it works, its history? jv /|/| _______/ | | ( ) \ | | \|\| _____ | | Johnathan Vail | n1dxg@tegra.com |Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet) ----- jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail ------------------------------ Date: Fri, 20 Sep 91 20:53:57 -0400 >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: DOS Executable files (PC) > From: bob morales <7340P@NAVPGS.BITNET> (re: NAV-PC) >According to the programs Scan Options, I may set it to "Scan >Executable Files Only" (or words to that effect) which tells me that >virus programs can only be transferred via executable files only, >i.e., files ending in .COM, .EXE, or .SYS. My questions are: (1) is >this a safe bet? and (2) is my assumption correct? Not exactly. While COMMAND.COM only recognizes .COM, .EXE, and .BAT files, DOS really could care less what you call it so long as it can be loaded. For example, take a .COM file, rename it to any extention (or none) and then load it with DEBUG and issue a G (go). It will execute happily. Of course you could load a text file the same way and the PC would try to execute it, just without much success. I regularly give my device drivers funny names for CONFIG.SYS since the same is true, whatever follows a DEVICE= is assumed to be an executable that follows certain conventions. Similarly, one of my favorite integrity management programs (Enigma-Logic's Virus-Safe - plug) regularly informs me of all kinds of strange programs being submitted with extensions such as .MNU, .PRG, .BIN, and a myriad of .Oxx (overlays). Windows also adds its own suite of funny files. The good news is that viruses that take hold before DOS rarely infect files and those that infect executables will generally get a package's .EXE or .COM first. For this reason, generally, SCANing just .COM, .EXE, .SYS, & .Oxx files is enough for a warm and fuzzy feeling. Once a virus strikes, better use the /A (all) switch and have a cup of coffee handy. Padgett "I had all of the answers and then they changed the questions" ------------------------------ Date: Fri, 20 Sep 91 21:44:10 -0500 >From: APPLEREP%MTUS5.BITNET@BITNET.CC.CMU.EDU Subject: Belch_Virus? (Mac) No! Really! It's not a joke. I've got three macs sitting on the sales floor of our campus reseller that belch (literally) periodically. The belch does not replace the normal beep sound, it just 'compliments?' it. And if you turn the volume to zero, the belch still remains audible. I've looked in all the obvious places for inits, system extensions, control panels, etc. No Luck. I also used resedit to search for invisible files, no luck. I examined the system file but I don't know enough about normal vs. suspect resources, so that was to no avail. Any help will be GREATLY appreciated. Thanks. Shawn R. Joslyn Apple Student Rep Michigan Tech University ------------------------------ Date: Sat, 21 Sep 91 02:05:02 +0000 >From: as194@cleveland.Freenet.Edu (Doren Rosenthal) Subject: Equal time for Virus Simulator Virus Simulator Equal Time September 20, 1991 I've been asked to respond to a number of questions and comments on my Virus Simulator 2.0 and although my response may be lengthy, it will not exceed the length of postings of it's detractors. Like most users of this forum, I read far more comments than I post and for some time I've been following the endless "my anti-virus programs better than yours" debates. Each purchaser of software should have the right to make that determination for themselves, but had no hands on basis for comparison. I wanted to participate in the debate but wished to avoid offering "opinion above knowledge", so I wrote an information extracting engine. My engine runs an anti-virus program against real viruses and then reports not only how well the anti-virus program works.... But how it works and what it's looking for. Producers of anti-virus programs often go to great lengths to guard this information, but I found no encryption technique they used that could stand up to my engine.... none. (The existence of this engine was described in this public forum by Ross Greenberg some months ago.) It became obvious that my engine not only didn't allow end users to try anti-virus detectors themselves, but raised more security problems than it answered. Keep in mind that the author of a virus already has that virus, its source code and a demonstrated willingness to defeat security measures. My engine reports that missing information in considerable detail. Most suppliers are anxious to give prospective buyers a chance to try their products, and my Virus Simulator 2.0 makes some measure of that possible. Before writing it I contacted as many producers of anti-virus products as I could. I wrote letters, made phone calls, left E-MAIL etc. Most didn't respond. A few took a "wait and see" attitude and some gave me considerable support. Only one, Frisk (Fridrik Skulason), indicated his strong opposition. Out of the respect I have for efforts Frisk has made in this industry, and the strong desire he announced privately and on this public forum to not participate in my experiment, I removed his programs from the test. I have no desire to breach anyone's trust or divulge any secrets. Understand that the reason Frisk's program does not report a much higher percentage of discrepancies when used with my Virus Simulator 2.0, is that at his request, his program was not included. Any false alarms (as he calls them) are due to the common search strings his programs shares with other programs. For Virus Simulator 2.0, I did not run my engine with Frisk's program and any viruses. I consider the term "false alarm" to be somewhat misleading when applied to my simulations. I believe a false alarm to be when your virus detector stumbles across a legitimate application program and reports it as infected. Make no mistake, the file, boot sector, memory reports Virus Simulator 2.0 generates are not accidental. They are quite deliberate and can be directly related to their real virus origins by design. Room for improvement, you bet! That's why I made Virus Simulator available and solicited comments. I intend to make future revisions far more complete and validation to real viruses more formal. My collection of real viruses is very limited and far from complete, so many of the strings used in Virus Simulator 2.0 were supplied. To make future versions of my Virus Simulator more useful to its' users, my library of viruses will need considerable improvement. I've supplied copies of Virus Simulator 2.0 to Robert C. Bailes of the National Computer Security Association (phone (717) 258-1816, FAX (717) 243-8642, 227 West Main Street, Mechanicsburg, PA 17055). Mr. Bales will be discussing the participation of the NCSA in future revisions of my Virus Simulator with the Product Developers Conference advisory board Monday September 23, 1991. The choice of whether you use my present Virus Simulator, or not, is up to you. I make it available as shareware to all. Without access to a comprehensive library, I can't make a better version of my Virus Simulator, so in effect, the choice will be made for you by the same people who are asking you to purchase their products on faith alone. Let them know what you think. Doren Rosenthal ------------------------------ Date: Sat, 21 Sep 91 05:04:32 +0000 >From: mcafee@netcom.com (McAfee Associates) Subject: Re: bogus scan?? (PC) HAYES@urvax.urich.edu writes: >I found the following messages this morning in the FIDO echonet virus >conference: > >- ---- begin forwarded messages -- > >To: Olaf Greve Message #: 4877 3245 4878 >From: Martin Saintonge Submitted: 18 Sep 91 09:22:00 >Subject: Number of viruses Status: Public >Received: No Group: VIRUS (30) >I've got SCAN version 83 ! I don't think it's a fake, It works fine and >all the documentation is authentic. I got it from a friend from Montreal >and I verified it and performed a scan on it (with version 72) with no >problem. The current version of VIRUSCAN is Version 82. Version "83" has apparently been pre-empted by someone other than McAfee Associates. It may be an old version of SCAN renamed after the number of viruses it detects, or it could be a trojan horse, perhaps. I would recommend that anyone who comes across a V83 to delete it. >- --- via Silver Xpress V2.27 [NR] > * Origin: RAMBAB LE babillard du Haut-Richelieu 347-5983 (1:167/570) > >- ------ > >To: Volker Weber Message #: 4993 1204 5013 >From: Paul Ferguson Submitted: 18 Sep 91 20:43:00 > Subject: New McAfee's ?? Status: Public >Received: No Group: VIRUS (30) > >* In a message originally to All, Volker Weber said: > >VW> KH> CLEANBTA.ZIP McAffee Clean Version 8.2 >VW> KH> WSCANBTA.ZIP McAffee Scan Version 8.2b / WINDOWS >VW> >VW>Can anybody verify this? I can. These are beta versions of CLEAN-UP and SCAN For Windows, a shell to run VIRUSCAN under Windows 3.0. CLEAN-UP has been released. SCAN4Win3 hasn't. And he spelled "McAfee" wrong too. > >Does anyone on this list know something about either a "windowScan" or a >version 83? I hope this answered all your questions. If not, please feel free to email me. Regards, Aryeh Goretsky McAfee Associates Technical Support - -- McAfee Associates | Voice (408) 988-3832 | mcafee@netcom.com (business) 4423 Cheeney Street | FAX (408) 970-9727 | aryehg@darkside.com(personal) Santa Clara, California | BBS (408) 988-4004 | 95054-0253 USA | v.32 (408) 988-5190 | CompuServe ID: 76702,1714 ViruScan/CleanUp/VShield | HST (408) 988-5138 | or GO VIRUSFORUM ------------------------------ Date: Fri, 20 Sep 91 22:11:47 -0700 >From: turtle@darkside.com (Fred Waller) Subject: Testing methodology Writes walker@aedc-vax.af.mil (William Walker) regarding a comparison of medical testing methodology with virus detection: > There was an interesting post to comp.risks discussing the > statistics associated with false positives and false negatives > of a medical test.... An analogy can be drawn between it > and computer virus detection routines (I'll avoid the term > "virus scanner"). and further: > Similarly, the false positive rate of a virus detection program > is the number of T+ given D-, divided bGF the number of D-. If > you tested only programs without a virus, the false positive rate > is the rate of positive test results you would get. For this rate > to be accurate, the programs tested would have to be a suitable > sample from the entire set of programs (you can see it coming, > can't you). Virus Simulator creates a population of programs > including factors which make programs test positive to some tests. > Using this biased population, the false positive rates for > detection programs which use those factors will be abnormally > high. The rates for detection programs which don't use those > factors will be unchanged. Since none of the files contain genuine > infections, the false negative rates cannot be measured. Indeed, according to the goals and yardsticks decreed for the medical test to which a comparison is made, false negative rates arising from the use of the Virus Simulator cannot be measured. However, it's known _a priori_ that false negative rates should not exist, because it's known that each test file produced by the Virus Simulator is *expected* to give a false positive. This can never be expected to be the case in the medical testing mentioned. However, the inherent fallacy of the comparison arises from the following consideration: in the medical field, there are no _intelligently malicious_ diseases that intentionally set out to confuse and misrepresent diagnostic test results. It is valid to make the assumption that, if a given test result turns out to be falsely negative, or falsely positive, it is so because of primary deficiencies (inaccuracies) of the test. In the virus/antivirus field, such a consideration is invalid. Infective agents (as well as test agents!), may be designed with prior knowledge of weaknesses of the upcoming testing procedure, and made to avoid them or compensate for them with secondary, tertiary, etc. deceptive techniques. In such cases, false negatives could be much higher than expected and yet could not be considered "abnormal" or "false" - they were intended, as all other activities in this field. And, to the extent that the detectors fail to anticipate and neutralize such secondary, tertiary, etc. evasion, they fail in their purpose. Conversely, false positives, such as produced by the Virus Simulator, can themselves be used as an avoidance mechanism, by robbing the user of confidence in the antiviral product. THIS IS THE EFFECT THAT THE ANTIVIRUS PUBLISHERS OBJECT TO IN THE VIRUS SIMULATOR, not any lack of efficacy. How can such an action be accounted for by the above theory? It cannot be. And, to the extent that the detectors fail to anticipate and neutralize such false triggering, they fail in their purpose. They fail because they are not only technical detectors, but *detectors of maliciousness and of intentional deception*, and should be competent in this as well. Virus detectors do not only undertake to detect viruses, they also undertake to avoid deception tactics used by viruses. If they cannot do this, they may be said to have failed in their purpose, because so many viruses use deception techniques. As long as the virus scanners can be deceived by the Virus Simulator into believing that the simulations produced by the Simulator are actual viruses, they may also be said to have failed in their purpose. Analysts of the virus/antivirus contest might perhaps search for theoretical foundation not in the realm of medical diagnostics, but in the theory of warfare, whose rules and tenets more closely resemble our reality. Considering that the author of the article seems to have military affiliation, one is surprised that, in his search for theoretical justification, he was attracted by medical, rather than martial, theory. > Therefore, Virus Simulator cannot possibly be used to test > virus detection programs. I hope that this can help quantify > some people's reservations about Virus Simulator. It most certainly can be so used. However, the results of its use in testing are not what the author promises. The Virus Simulator does not test accuracy of diagnosis, but rather the overall "credibility" of the detectors. After such tests, the detectors emerge with incredibly low marks. ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 169] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253