VIRUS-L Digest Wednesday, 18 Sep 1991 Volume 4 : Issue 164 Today's Topics: Re: Virus Simulator Re: Virus Simulator Re: FAT Infection (PC) Re: Can a virus be LAGAL?! Heuristic analysis Re: Virus Simulator available (PC) Re: Scanning LZEXE and PKLITE files (PC) Re: FAT Infection (PC) BIOS Viruses (PC) Re: Disinfectant and students (Mac) Re: Scanning LZEXE and PKLITE files (PC) New anti-virus product reviews available 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: 17 Sep 91 16:27:06 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Virus Simulator turtle@darkside.com (Fred Waller) writes: > Well, it could also be said that the virus scanners are the ones > generating false security, and the Virus Simulator is exploding > that. The Virus Simulator may actually help remove some of that > false security. Regarding "false paranoia", all paranoia is, by > definition, false. I agree, in general, with the above. > I would say that the cause for much of the criticism (and some > of the abuse) heaped on Rosenthal is that the Virus Simulator > publicly exposes a known but generally-tacit weakness of all the > string scanners. Mostly, what we are seeing is a reaction by Nope, that main cause is the unfounded claim that it tests scanners' reliability to detect viruses. It doesn't. It just fools them to report a virus when there is none. It cannot fool them NOT to report a virus when there is one, and this is what most users are concerned about. That's why the anti-virus writers try to produce scanners that cause very few false positives on REAL files and just don't care about the virus simulator. The fact that it fools them does not prove that they will cause false positives with real files and cannot show whether or not they'll fail to detect a real virus. It does not test anything, countrary to the author's claim. That's what cause the anti-virus researcher's reaction. (Together with the author's claim that "most anti-virus researchers find it extremely useful".) > I think Rosenthal never said that his program could test the > _removal_ capabilities of virus scanners. It would have been nice I thought that you already agreed that it DOES NOT TEST ANYTHING. A scanner is reliable if it is able to recognize a virus. It is also desirable for it not to catch non-viruses, but this is not that easy for a simple pattern matching engine. What the users really want is a scanner that gives no false NEGATIVES, not no false positives. Unfortunately, this is also unachievable, but Rosenthal's program does not show it, anyway. > had it been able to, but it isn't. Many scanners have rather poor > removal capabilities anyway. Mostly, they are meant to act as Well, Frisk's program is a rather good disinfector... > their ability as detectors, not removers. Frankly, it doesn't really > test the scanners in quite the way Rosenthal said. What it does, and That's it! Maybe the cause of the whole misunderstanding is that Rosenthal's original claim was ill-formulated? How about him re-stating again publically what his program is meant for? That it does not, I repeat DOES NOT test scanners' ability to detect viruses, it just shows that it is possible to fool some of them to report false positives. And that it is an unvaluable tool for those users that don't already know that simple fact. If he does this, I thing that the misunderstanding will be considered closed; the usefullness of the program will be considered as a matter of taste/experience and we all can stop this stupid discussion. Mr. Rosenthal? > rather well, is expose a glaring deficiency of such software, and > shows that the scanners aren't nearly as reliable as their > publishers might have prospective buyers believe. Rosenthal's Virus > Simulator does this: it shows that virus scanners can be made to > produce false alarms at the incredible rate of 100%!!! Of course the > antivirus publishers have no kind words for it. Would anyone expect > otherwise? Wait, it just comes to me that maybe you just don't know a simple fact that I consider assumed by default. Virus detection programs can produce two kinds of errors. The first one (often called a false negative or error of type 1) is not reporting a virus when it is present in the file. It -is- possible to make a scanner that never makes this mistake for any of the known viruses. Unfortunately, not all of the popular scanners are totally free of such mistakes. If you find that a scanner causes a false negative, you should report it ASAP, since this could cause a large virus infection and false sense of security. The second possible mistake to called false positive (or error of type 2), and consists of reporting a virus when there is none. This is an annoying, but not a dangerous mistake. Most users can live with it. That's why, the producers of virus scanners try to avoid this kind of mistake, but don't apply too much effort to make it totally impossible. A lot of scanners give false positive, and is usually very easy to trick them to do so - what the virus simulator proves. > I have to disagree. While Hoffman's VSUMxx document makes colorful > occasional reading, it's not a serious substitute to testing > scanners to see whether they actually do or do not detect the > viruses they *claim* to detect. Hoffman's VSUMxx is heavily biased > in favor of one vendor (McAfee Associates), and has often neglected > to even mention up-to-date competitive products, as others have I tend to disagree with the above, but it doesn't really matter, since as you pointed out: > noticed here. Hoffman's VSUMxx contains many errors of fact; even > after being publicly pointed out, they have remained uncorrected. In Yes, this is the most dangerous flaw of VSUMxx. Pat never bothered to correct the bugs and at the current state her document is a wonderful piece of -disinformation-. I'm really sorry about that, since the main idea is extremely good and the possibility to use a hypertext interface is really a nice touch. I would only require a "string search" possibility - to locate pieces of information in the whole database... And of course - correct information. > evaluation. And it couldn't test a given scanner in every particular > environment that every prospective buyer might wish to test the > scanner in. No, I don't think there is a substitute for individual Agreed, but Rosenthal's program that we discuss here does not do all these things either... > The problem of testing antivirus software is not trivial. It is a > very real one and one that is bound to become worse as time goes on. Indeed. > Even assuming that all vendors agree on a standardized testing > protocol and agent, it would still be desirable for the larger > prospective buyers to conduct their own testing and evaluation. Yeah, but it is just unfeasable. It would be also desirable to have programs without bugs, but this is not achievable either. The users have just to learn to live with it. And a virus simulator certainly won't help. > are unable to tell a fake virus from a real one. The main task of a > virus scanner is, by definition, to identify viruses. They fail at > it, rather miserably, as the Virus Simulator demonstrates. Once again, you missed the whole thing. The main task of a virus scanner is to find all known viruses. The popular scanner usually do not fail at this task, or at least no such behaviour is demonstrated by the Virus Simulator. Not to find any non-virus files is a SECONDARY task for a scanner, and indeed, some virus scanners fail to achieve it IN ALL TIMES. They can also be intentionaly fooled, which is proved by the Virus Simulator. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 17 Sep 91 17:45:56 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Virus Simulator p4tustin!ofa123.fidonet.org!Ray.Mann@uunet.uu.net (Ray Mann) writes: > I run that test using FPROT 1.16 and the program reported many of > the fake viruses to be "possible infections". It also reported some > of them to be "Infected" for sure, with things like the MG virus, > the 600 virus, the Telecom virus, etc. Not all the fake viruses > triggered FPROT but about 50% did. Only about 10% were determined > to be certain infections. OK, now try to DISINFECT those 10 %. (You have to supply a special option at the command line with version 1.16) Does F-Fchk REALLY disinfect them, or does it say that "this is a new version of the virus; cannot be disinfected"? > Let's remember that speed and ease of use are not what we buy > scanners for - we buy them to detect viruses. Ease of use and > scanning speed are important, but they aren't the primary function Very true. > of a scanner. Incidence of false alarms is also an important > consideration. Any test that limits itself to speed and ease is > grossly inadequate. By the way, Rosenthal's virus simulator seems to > have disclosed a real weakness in the area of false alarms... Of FALSE POSITIVE alarms. These are in no way dangerous and I really don't see what the discussion is all about. > It might be difficult to find any organization with a large > collection of viruses that is not somehow part of the AV community > and, therefore, potentially biased. If a government agency were to CERT, NIST and NCSA are not part of the AV software producers... > do the testing, it'd be viewed as impartial, but I think it's not > a realizable hope. An AV consortium such as the NCSA has been > trying to setup will probably run into difficulties. If they test > severely and impartially, there'll only be one winner and many > losers. The losers will see ample reason to abandon the consortiom, > since it's hurting them. If they test less severely, there'll > be many "winners" and a loser or two but candidate buyers will > no doubt see through it and refuse to take the test results > seriously. Yeah, that's why such a testing organization shouldn't consist of people that have money interest in the AV software. > Regardless of any centralized tests, large organizations will > probably insist on running their own testing, as they've > usually done in the past with many other products. OK, but I cannot see how this can be harmful. > I'm not so sure that the Virus Simulator is such a bad idea. It's > no panacea, and it doesn't REALLY test anything, but it offers some > interesting possibilities. For example, it could be useful in > training sessions, where the fake viruses could be used by > instructors to teach scanning procedures, etc. without fear of > contamination with real viruses. Sure, we'll see a number of > pranks, etc., but I'd rather have pranksters using fake viruses > than real ones! OK, I admit that you're right here. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: Tue, 17 Sep 91 21:09:30 +0000 >From: moore@iastate.edu (Brian J Moore) Subject: Re: FAT Infection (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: >HTORRES@HELENA.HQ.NASA.GOV writes: >> I'd like to know if there is a possibility of a virus infection into >> the file alocation table. I understand that boot sector viruses are >Yes, it is, although it hasn's been implemented yet (to my knowledge, >of course). It is possible for a boot/partition table infector to >store its body in the first copy of the FAT, instead of allocating bad >clusters. >> known but I have not heard about a FAT virus. If this is true, will it >> infect the two FATs what a re thepossibilities of losing the index. >If it overwrites only the first FAT copy, you won't lose anything... >and you probably won't even notice that something nasty has happened. Running CHKDSK will tell you if the FATs don't match... - -- _______________________________________________________________________ / / / / Brian J. Moore / moore@iastate.edu / /__________________________________/____________________________________/ ------------------------------ Date: Mon, 02 Sep 91 10:58:16 -0500 >From: insider@subch.malg.imp.com (David Rosenthal) Subject: Re: Can a virus be LAGAL?! Yaron Bloom writes: >... but I haven't heard of a law agains viruses, have you? Yes, I have. Here what's going on in Switzerland (Europe) in regard of that: A new penal code is in preparation (in Switzerland our law consist mainly out of predefined rules [code law], not case law). Today, someone who destroys your computer (hardware) physically can be prosecuted. In other words: Physical property is protected against damage by others. With the new piece of law, data shall become protected too: "Any unauthorized person who is deleting, modifying oder making useless electronically or similarily [e.g. optically] stored data, can be be prosecuted on request." (Art. 144 Abs. 2 Swiss StGB) This covers authors of viruses too, even if they do not have direct access to your computer (if the virus is not authorized, of course). If they are catched (usually they are not ...) they face up to three years of prison. If there is big damage, the will be officially prosecuted (= even if not requested by the victim). Then they face up to five years. Another remark: Everything stored in the computer in a "coded" way is considered as "data", even a program or boot block is. That's why even harmless viruses are covered by the law, because they usually have to modify their host in at least some way (to get control). There are some more articles concerning computers and data, for example covering unauthorized use of computers, fraud, hacking, theft of data, manipulation of official computer data. Still, no such words as "virus" or "hacker" appear in the code directly. However, it will take some time for releasing this new criminal code; it first has to pass the parliament and has to be approved in a plebiscite (Switzerland has a direct democracy). This will take *at least* two years. Meanwhile, somebody would have to accuse somebody by citing the general article of "damage of property", which probably would be enough anyway. To my knowledge, there are similar penal codes in other european countries (Germany, Austria ...). However, they are older: Viruses and hacking probably has been an unknown subject (outside the computer world) the time their code was created, resulting in those two matters not beeing covered by law. David. - --- David Rosenthal, P.O.Box 231, 4003 Basel, Switzerland, Europe Voice: +41/61/224101 E-Mail: dr@insider.malg.imp.com ------------------------------ Date: Tue, 17 Sep 91 19:01:00 -0400 >From: Bob Babcock Subject: Heuristic analysis >> Frisk's "heuristic virus analyzer" >> is *extremely* prone to false alarms, much more so than his string >> scanner. >You probably tested it on some programs that were badly written, used >self-encryption or modification, modified executable files, and in >general behaved in an unusual way... I've written some code which does none of these things, yet it still triggers a false alarm. This is code which I sell, so I'm not going to be happy if customers start complaining that a heuristic scanner claims that it may be virus infected. Worse, I have no clue as to what the scanner is finding, so there's no way I can change the code to quiet the scanner. If the algorithm used by the scanner is released, or if the scanner is more specific about what code it found which indicates possible infection, then virus writers can use this information to write viruses which the scanner can't see. I raise this as a practical problem with this sort of scanner, distinct from the theoretical problem that a perfect scanner is impossible. ------------------------------ Date: 17 Sep 91 20:42:43 -0400 >From: ender2@husc9.harvard.edu (Matt Ender) Subject: Re: Virus Simulator available (PC) PHYS169@csc.canterbury.ac.nz (Mark Aitchison, U of Canty; Physics) writes: >Just wonderring... how many viruses exist that are trying to avoid >published search patterns? I still agree that serious virus scanners >should keep their scan details secret, by the way. There is a good >case for distributing the scan patterns for known viruses, for >identification purposes, and I almost hope that virus writers waste >their time tinkerring with viruses to avoid those strings, rather than >try to write serious new viruses. Of course, nobody should consider >virus simulators based on such strings as a good test of a scanner; >the only valid use of a virus simulator would be to demonstrate to the >unintiated what a virus looks like, so they can watch for it in "real >life". It would be easy for a person in possession of their virus, and a copy of the scanner, to determine which bytes are in the scan string, and re-releasing the virus with a subtle change to bypass the scan. To avoid this, either: your scanner is not free AND you use unpublished search strings -- it's more expensive for Mr./Ms. Virus Writer to purchase all sorts of scanners to protect against. Any published search pattern OR free program allows the author to bypass your scan. Actually, your scan can still be bypassed -- assumes Mr./Ms. Virus Writer is willing to shell out money to do it. Last note of interest: I don't notice too many new viruses derived from old viruses (example, the 'strains' of a particular virus.) Thus, I must deduce that the authors either have stopped writing viruses or don't bother watching the scanners and re-writing their viruses. - -- Matt ------------------------------ Date: Tue, 17 Sep 91 21:53:51 -0400 >From: pshuang@ATHENA.MIT.EDU Subject: Re: Scanning LZEXE and PKLITE files (PC) > Now, here's the question, or rather the challange: Someone convince me > I'm wrong; that such files /can/ in fact be scanned without risk, and > with accuracy, BY CURRENTLY EMPLOYED METHODS. You can employ programs like UNLZEXE and PKLITE's ability to decompress the file, then use your favorite virus scanner on them. You do *NOT* have to actually execute the programs in question. A subsidiary question is that the decompression process may have distorted the signature of the virus. But if so, the virus is unlike to work in any case. ------------------------------ Date: Wed, 18 Sep 91 15:18:00 +1200 >From: "Nick FitzGerald" Subject: Re: FAT Infection (PC) In VIRUS-L Digest V4 #162, bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) wrote: >HTORRES@HELENA.HQ.NASA.GOV writes: > >> I'd like to know if there is a possibility of a virus infection into >> the file alocation table. I understand that boot sector viruses are >[deletions - synopsis: "possible, but unknown"] >> known but I have not heard about a FAT virus. If this is true, will it >> infect the two FATs what are the possibilities of losing the index. > >If it overwrites only the first FAT copy, you won't lose anything... >and you probably won't even notice that something nasty has happened. At this point there is much potential for confusion. Some BSI/PTI viruses _affect_ (NOT infect) the FAT. This happens with Stoned and most of its derivatives, due to the "assumption" by its creator, that sector 0,0,7 is never used. This is true on HD's FDISK'ed with pre-3.0 versions of DOS, some OEM's DOS 3.X'es, and some third party partitioning progs that do not leave an unused track at the beginning of the disk. Stoned (and similar beasties) infections on such HD's will often be very quickly detected, due to the terrible FAT munging that their infection causes - cross-linked files, lost chains, etc. The possibility for confusion arises because many lay/naive/other users are heard bleating about getting Stoned in their FAT's, which is either a complete misunderstanding on their part, or confusion, due to the fact that what they saw (cross liking, etc) was due to FAT corruption. For what Vesellin is hinting at to work, I think what would be needed as part of the infection process would be a little "byte twiddling" in the partition table entry for the affected partition and the addition/ modification of some code in the MBR loader. >> What is the repair procedure to fix the FAT if an infection occurs? > >Boot from a known non-infected, write-protected system diskette and >run a non-infected copy of Norton Disk Doctor (part of the Norton >Utilities package) - also from a write-protected diskette. It is able >to repair such problem as unequal FAT copies. Yes - but note my warning above. If this was prompted due to corruption of the FAT by some (Stoned-like or other?) virus, you may not be able to "repair" the FAT by copying the second copy back on top of the first. Whether this succeeds or not depends upon many factors associated with file creation/modification following the infection, and where those files are physically located on the disk - in maintaining two copies of the FAT for you, DOS may have merrily corrupted your second copy following the virus's munging of the first. >Note however, that it won't help if a virus has been especially >designed to hide in the first FAT copy - you'll need probably a >specific disinfector. Huh - what I'm thinking of would be easily reversible by copying FAT2 back to FAT1 and fixing the PT entries. Aha - light bulb flashes in the minds eye ... Yes of course, because it would have to use some good (as in "well- implemented") stealth techniques (but wouldn't it then be slightly simpler to implement using FAT2 as the hiding place instaed of FAT1?). - --------------------------------------------------------------------------- Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z. Internet: n.fitzgerald@csc.canterbury.ac.nz Phone: (64)(3) 642-337 ------------------------------ Date: Tue, 17 Sep 91 07:17:07 -0500 >From: privsec!guillory@uunet.UU.NET (guillory) Subject: BIOS Viruses (PC) Time and time again the issue of viruses using a PC BIOS as an infection vector has been discussed. Opinion here is that this is not possible. Last night I was reading my most recent PC Magazine. In an article titled "50-MHZ 486 Debuts in Dell Powerline File Server" discuses end 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? ------------------------------ Date: Wed, 18 Sep 91 00:01:29 -0600 >From: martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences) Subject: Re: Disinfectant and students (Mac) LISSA@WHEATNMA.BITNET writes: >It has been my experience that, for as long as I have worked here, >that administrations of colleges try to keep the subject of viruses >low-key. They don't want to worry the students, and they don't want to >admit they have a problem. Hey, I thought it was only University of A****** administrators who were so short-sited! (Some people I know won't be pleased by this note! One doesn't bite the hand that etc.) In all fairness, things have improved, in the last months. I've never been able to understand that attitude, though. Especially at Academic Institutions. Colleges and Universities are THE place where computers are publicly accessed by large numbers of people, often with little monitoring. Surely it's no secret that they make for ideal virus breeding grounds? And it's not as if we are pushing software products whose reputation we must protect. Are there any Administrators reading this group, who can explain to me the logic behind such administrative head-in-the-sandedness? ------------------------------------------------------------- Tim Martin * Soil Science * These opinions are my own: University of Alberta * My employer has none! martin@cs.ualberta.ca * ------------------------------------------------------------- ------------------------------ Date: 18 Sep 91 08:58:36 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Scanning LZEXE and PKLITE files (PC) Eric_Florack.Wbst311@xerox.com writes: > I've recently gotten into a disussion, on another network, about LZEXE > and PKLITE'd files, and scanning inside of them. I take the stance > that there is no reliable way to scan inside them, with executing them > first, thereby infecting the system. As such, I have banned all such > treated files from my BBS's. > Now, here's the question, or rather the challange: Someone convince me > I'm wrong; that such files /can/ in fact be scanned without risk, and > with accuracy, BY CURRENTLY EMPLOYED METHODS. Yes, you're wrong, such files CAN be scanned. Consider this: each self-compressed file contains a small decompressor program, which decompresses it at run-time. Then, it should be possible to write a separate program that either (1) performs the same task off-line and extracts the original file to the disk, instead of in memory (and the file could be then scanned for viruses on the disk), or it just decompresses the file in memory, but DOES NOT PASS CONTROL to it (therefore if there is a virus in the file, it never gets executed) and then scans the memory buffer that contains the decompresses file for viruses. Currently there are several anti-virus programs that are able to scan also "inside" compressed files. Such programs are McAfee's SCAN, Fridrik Skulason's F-Prot, Ross Greenberg's VirX... There are, however, two problems. The first is that the decompression slows down the whole scanning process. Of the programs, listed above, only VirX is reasonably fast. The second problem is, that there are currently a lot of file compressors. To name a few, there are LZEXE, PKLite, Diet, TinyProg, Slim, PgmPak, ICE, EXEPack.... To my knowledge, currently only VirX is able to scan both LZEXEd and PKLited files, although the same should be expected with the new versions of the other two programs. Currently NO virus scanner is able to scan ALL kinds of compressed executables. My own oppinion is that all this is just not nessecary. What we really need is a shell program that is able to decompress any kind of compressed file and then run a user-selectable scanner on it. It is stupid to add the possibility to check inside compressed files to every virus scanner. Just as it is stupid to make scanners that are able to scan inside archives. We just need something like SHEZ for compressed executable files... Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: Tue, 17 Sep 91 15:11:50 -0400 >From: Kenneth R. van Wyk Subject: New anti-virus product reviews available I've recently received several new (and revised) anti-virus product reviews from Rob Slade and from Chris McDonald. Due to the size and number of the reviews, I've decided to simply put them in the VIRUS-L/comp.virus archives. Thanks to Rob and Chris for their continued efforts! The new files (in pub/virus-l/docs/reviews) are: mcdonald.index - Index of Mr. McDonald's reviews mcdonald.ibm.antivirus - IBM Anti-Virus Product 2.1.2 mcdonald.seer - SEER version 3.32 mcdonald.viruscan - VIRUSCAN version 7.6V80 slade.advanced.security - Advanced Security slade.central.point - Central Point Anti-Virus Ken ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 164] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253