VIRUS-L Digest Wednesday, 4 Sep 1991 Volume 4 : Issue 155 Today's Topics: Vshield not loading into high memory? (PC) Norton Anti Virus (PC) Re: Disassembler Info Re: Virus Bulletin search strings (PC) A rock :-) :-( :-) :-( a hard place Re: Viruses more common in Mac environment? False Positives in General Re: Virus Simulator available (PC) Re: Viruses more common in Mac environment? Re: Virus Simulator available (PC) Re: Disassembler Info Re: Virus Simulator available (PC) Re: Viruses more common in Mac environment? Re: Viruses more common in Mac environment? Boot sectors 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: 03 Sep 91 16:03:36 -0400 >From: Jon Freivald <70274.666@CompuServe.COM> Subject: Vshield not loading into high memory? (PC) Has anyone tried to load vshield (version 3.9B80) into high memory? I've tried MS-DOS 5.0 and Dr. DOS 5.0 and 6.0 BETA and nothing seems to work. MS-DOS doesn't load it at all and DR. DOS just loads it into conventional memory. I have tried it with many configurations on different machines. Any help would be appreciated. Could someone please forward this to Mcaffee..<< I use DOS 5.0 & QEMM 5.13 - no luck here either... What I have done is created a small (default 64K) ramdisk with the /e (use extended memory) that I copy it to & load from there with the /swap option. According to Manifest, this shrinks it down to 3.2K resident in the DOS 640... FYI, I can't get it to load high even if it's the only thing I'm loading... Maybe with the new QEMM 6.0..!? Jon (P.S. - Aryeh Goretsky of McAfee is fairly regular in this conference...) ------------------------------ Date: Tue, 03 Sep 91 13:03:39 -0700 >From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: Norton Anti Virus (PC) knutt@ifi.uio.no (Knut Torgersen) writes: > first thing I did, however, was to run the program on the diskette I > borrowed it on. First I used McAFee's SCAN.EXE. Nothing nasty showed > up. Then I asked NAV to scan itself. NAV told me that "NAV.EXE is > infected with an unknown strain." Did you, purchance, run SCAN with the /AV (if I remember correctly) switch? The one that adds self-checking code to the target file, and would therefore confuse NAV's *own* self check? ============= Vancouver p1@arkham.wimsey.bc.ca | "If you do buy a Institute for Robert_Slade@mtsg.sfu.ca | computer, don't Research into (SUZY) INtegrity | turn it on." User Canada V7K 2G6 | Richards' 2nd Law Security | of Data Security or try rslade@keadb.kea.bc.ca once in a while. ------------------------------ Date: Wed, 04 Sep 91 09:58:00 +1200 >From: "Mark Aitchison, U of Canty; Physics" Subject: Re: Disassembler Info >>What disassembler do you use? I have a disassembler specifically for scrutinising boot sectors, which is part of the CHECKOUT program I wrote. It is free, and a bit buggy, I'm afraid. I made CHECKOUT available a while ago - I'm working on a new version & will announce when it's available; in the mean time, the way to use the old version is: CHECKOUT/A A: and you might want the /D switch as well. What it does is work out what parts of the code get executed, what are the contents of registers at the time of interrupt calls (okay, this bit is pretty buggy), and puts in labels and BPB structure if appropriate, etc. Mark Aitchison. ------------------------------ Date: 04 Sep 91 18:14:32 +0000 >From: warren@worlds.com (Warren Burstein) Subject: Re: Virus Bulletin search strings (PC) frisk@rhi.hi.is (Fridrik Skulason) writes: >warren@worlds.COM (Warren Burstein) writes: >>The sunday virus has two entry points, one for a COM file (0 jumps >>to 95), one for an EXE file (at C4). It happens that the search >>string in the Virus Bulletin starts at the COM entry point, which >>means that if you were scanning starting at the entry point of >>an infecte EXE file, you would not find it. >This signature was defined before I started as the Technical editor, >so I am only indirectly responsible for it, but I don't quite >understand what you mean by "..you would not find it." The signature >string is present in all infected .EXE files too - and just look for >the virus in one fixed location does not look very sensibfle to me. Well sometime this year or last I called the VB, to ask how to use the strings. What I thought the person who I spoke to said was that you just have to start scanning from the entry point forward. Either I misunderstood or he misspoke. Sure you can find the string by scanning the whole file. I thought that significant time could be saved by scanning starting from entry point. I was wrong. Are "turbo modes" in virus scanners a mis-feature? - -- /|/-\/-\ The entire world Jerusalem |__/__/_/ is a very strange carrot |warren@ But the farmer / worlds.COM is not worried at all. ------------------------------ Date: Wed, 04 Sep 91 01:46:06 +0000 >From: userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) Subject: A rock :-) :-( :-) :-( a hard place Al Dunbar | Edmonton, Alberta | Disclaimer: "not much better than CANADA | datclaimer" - -------------------+------------------------------------------- ------------------------------ Date: Tue, 03 Sep 91 21:34:50 +0000 >From: plains!umn-cs!LOCAL!aslakson@uunet.uu.net (Brian Aslakson) Subject: Re: Viruses more common in Mac environment? delwiche@well.sf.ca.us (Aaron Delwiche) writes: >Somebody recently tried to convince me that viruses were more >widespread in the Macintosh environment than the PC environment. Is >this true? It seems to me that the opposite would be true. Viruses are more widespread, and common, in the PC world. If you (or anyone) wants details, send e-mail and I'll send details. - -- Brian Aslakson brian@cs.umn.edu (mail) aslakson@cs.umn.edu (talk) mac-admin@cs.umn.edu (Me!!) ------------------------------ Date: 03 Sep 91 23:37:53 -0400 >From: Robert McClenon <76476.337@CompuServe.COM> Subject: False Positives in General There have been many notes to this forum, many of them recently, on false positives of various sorts. I think that a taxonomy of viral false positives is indicated. I would suggest that the following major classes of false positive reports from anti-viral programs be defined: 1. Signature scan hits from anti-viral programs on anti-viral programs. Signature scan hits occur when one anti-viral program detects a viral signature that was used by another anti-viral program. These can only occur if two or more anti-viral programs are being used. The species would appear to be: 1.1 Signature found on disk. Reports that VIRUCIDE.EXE contains the 12 Tricks Trojan fall into this species. 1.2 Signature found in active memory, in use by a TSR virus checker. 1.3 Signature found in released memory, typically by a scanner. Class 1 false positives indicate that the anti-viral program generating the false positive is working correctly. They may indicate a vulnerability in the program being reported against, such as that it fails to clear memory or fails to encrypt its strings. They would be much more common except that anti-viral scanners usually encrypt their signature strings, partly to protect against Class 1 false positives. 2. Ghost hits from incompletely deleted virus fragments. Class 2 false positives occur when a viral infection has previously occurred and has been corrected in a particular way. The jump to the viral code has been corrected without overwriting the viral fragment. The viral fragment is physically present on the disk but has been deactivated. A Class 2 false positive similarly indicates that the anti-viral program is working correctly. 3. True false alarms. A Class 3 false positive occurs when a viral infection is detected but there is no viral infection and no deliberate presence of a viral signature. (The viral signatures used by a virus scanner are deliberate.) A Class 3 false positive indicates that the anti-viral program is "erring on the side of safety" but is an error. The frequency of false positives is a reason why (as Padgett Peterson says repeatedly) anti-viral software should not be used ignorantly. If a positive alarm occurs, expert analysis is required. Further comments on classification of false positives are welcomed. Robert McClenon Neither my employer nor anyone else paid me to say this. ------------------------------ Date: Wed, 04 Sep 91 00:25:28 -0700 >From: msb-ce@cup.portal.com Subject: Re: Virus Simulator available (PC) There is a conflict between the need to contain the spread of computer viruses and the need for end users to be able to test the efficacity of the anti-viral policies and procedures that they have established. Clearly the "bait files" produced by the recently released "Virus Simulator" are not reliable indicators since any actual alarms caused by them are, by definition false alarms. Let me propose that some agreed upon file name such as "VIRTEST.TXT" be defined by all anti-viral products as a test file and be identified as being such using the same mechanisms that are used to report a true viral infection, but using text that indicates that this is indeed a test, not a real virus. Disinfection of "VIRTEST.TXT" would consist in appending a line containing as a minimum a time stamp and the name and version number of the program performing the "disinfection". This approach would provide a standard method for users to cause the products to return ERRLEVELs indicating viruses, and to practice disinfection. It would also remove the temptation to use something other than live viruses to evaluate competing products. Comments? Fritz Schneider (msb-ce@cup.portal.com) ------------------------------ Date: 04 Sep 91 10:29:24 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Viruses more common in Mac environment? delwiche@well.sf.ca.us (Aaron Delwiche) writes: > Somebody recently tried to convince me that viruses were more > widespread in the Macintosh environment than the PC environment. Is > this true? It seems to me that the opposite would be true. Ha-ha.. It cannot be more false... Those that use Macs only live in a paradise - only about 30 viruses are known for these computers. Compare this to the about 800 known ones for PCs... :-( 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: 04 Sep 91 10:33:38 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Virus Simulator available (PC) CHESS@YKTVMV.BITNET (David.M.Chess) writes: > It cannot be used to correctly test other anti-virus products; in > fact, as Fridrik says, any anti-virus products that identifies the > output of the "simulator" as virus-infected will be, strictly > speaking, wrong! The results obtained from testing any anti-virus > product with this "simulator" will be essentially meaningless. I fully agree with you and Fridrik. > The "simulator" is not a bad idea at heart; people often want a way to > figure out if their anti-virus software is correctly installed and > working. But this particular approach, particularly given the tone of > the claims the author makes for it, is much too likely to mislead. I > think a more promising approach would be for each anti-virus program > to have a corresponding test suite, which would contain a few files > that the anti-virus program would report as infected (or as > "containing the test signature", or something like that). Any further > thoughts in that direction? Hmm, this also won't tell the users how good their anti-virus product really it... because the manifacturer will make sure that the product detects the test files. :-) A slightly different idea. How about a set of programs that simulate not virus behaviour (i.e., they do not spread), or virus signatures (what a rubish!), but the ways that viruses use to (1) install themselves in memory, (2) the ways they get control, and (3) the ways they write on the disk. This will provide a good tool to test "memory displaying tools" (e.g. MAPMEM), or monitoring programs and hardware (e.g., FluShot+, ThunderByte). Currently I have identified about a dozen ways to install a program in memory and about the same number of ways to get control. The number of ways to write on the disk are at least twice as many. Now I just have to implement all these... :-) 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: Wed, 04 Sep 91 12:08:34 +0000 >From: d89-zke@nada.kth.se (Zoltan Kelemen) Subject: Re: Disassembler Info swimmer@stage.hanse.de (Morton Swimmer) writes: >BOXALL@qut.edu.au writes: > >> To all virus researchers, >> >> What disassembler do you use? >> >> At the Queensland University of Technology we use Sourcer by V >> communications. Is there anything better? > >Well, there really in not a better disassembler as such, but Sourcer >is not the best for analysing viruses. I'm still waiting for the >disassembler that can handle viruses well. The best disassembler is your own brain, aided by DEBUG. I don't understand how on earth normal disassemblers can handle encrypted/self-modifying/bizarre code. ------------------------------ Date: 04 Sep 91 10:46:34 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Virus Simulator available (PC) as194@cleveland.Freenet.Edu (Doren Rosenthal) writes: > Although appreciated, your opinion seems to be overshadowed by the > overwhelming majority of positive reaction I've had from people who > have actually tried my Virus Simulator 2.0 for themselves. It would be a good idea to quote some names and how much professional experience do these people have in the anti-virus field indeed. Currently I've not seen even one positive oppinion from the most well-known anti-virus researchers... > Even though your comment that perfect virus detectors will not find these > simulations, and any that are reported are false alarms, I don't consider > those setting off your own F-PROT to demonstrate a defect. Rather, system I can't believe that F-Fchk has reported your simulation file to be INFECTED by any virus. Please, check again. Doesn't it report "possibly infected", "new variant of..", etc.? Does it try to disinfect you file? And does it succeed? No, I definitvely can't believe that. > administrators can use my Virus Simulator to determine if anyone is > actually following their security policies and really using your product. How? > They can demonstrate which products are the fastest and easiest to use > when considering vendor recommendations for a site license. They can > perform their own tests, and needn't take anything on faith to form their > own opinions. First of all, they do not need any virus simulator (or live viruses), in order to test the speed and easy of use of any anti-virus product. Second, the speed cannot be tested on ONE file only; you need huge amount of files to obtain a reliable average number. Third, any user (not only the administrators) is able to test the speed and easy of use of ANY product (including the anti-virus ones), WITHOUT having any kind of viruses - live or simulated. Reference: Prof. Harold Highland's article "How to test a computer virus without a virus" in Computers & Security. Don't have the exact reference right now, but I think that Prof. Hoghland is reading Virus-L, so he could supply more info. > It's not my intention that anyone be placed in the awkward position of > trying to convince potential customers that their product performs well > with real viruses, even though it fails to find the simulations. That's good, but as Frisk pointed out, the performence of an anti-virus product in a real-life situation has nothing to do with its ability to detect your simulator. > Especially when a collection of hundreds of real viruses is not available This is a serious and yet unsolved problem, indeed. My oppinion is that such collection should be a vailable at some central organization (VTC?, CERT?, NIST?, NCSC?), and this organization should perform an objective test of different anti-virus products. > So far the response and cooperation from producers of anti-virus products > to my Virus Simulator 2.0 has been overwhelmingly positive. I'll be Again, I'm waiting for some names. The feedback that you received in this forum (which I consider as highly professional) seems overwhelmingly negative... 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: Wed, 04 Sep 91 10:06:32 -0400 >From: Joe McMahon Subject: Re: Viruses more common in Mac environment? On Wed, 4 Sep 1991 09:49:57 EDT Alfred Porziella asked: > Also where can I get some Info on Mac viruses, I want to know how > widespread viruses are on the Mac compared to the DOS PC's. I think you'll find epidemiological data hard to come by on any ony platform; a *lot* of places hush up viral infections. I got some calls from places which asked not to be named in reference to major infection problems during the early days of Mac viruses. On Wed, 4 Sep 1991 09:49:57 EDT Norman Paterson asked: >Where did the idea that Macs are riddled with viruses come from? It's >not the first time I've heard it said. It may stem from the fact that the Mac community immediately began spreading the word as soon as the first viruses began circulating and that Mac dealers, users, and support groups emphasize the value of detecting viruses and preventing infections. The conclusion that concern = amount of infection is seductive, but if one thinks about it, the more care a population takes to avoid infection, the less likely they are to have one... One might also tend to think that this is another factoid on the order of "the Mac is not a serious business machine", "the Mac is just a game machine", etc., promulgated by thise who cannot conceive of any machine other than an IBM PC as being an adequate tool in any way, shape, or form. :-) --- Joe (donning Nomex) M. ------------------------------ Date: 04 Sep 91 10:26:30 -0400 >From: "David.M.Chess" Subject: Re: Viruses more common in Mac environment? > From: Norman Paterson > > I think the relative frequency of articles in this newsletter gives a > better picture - it should be renamed PC-VIRUS Digest. There are > about 50 times as many PC virues as Mac viruses: that is, there are > about 1000 PC viruses to the Mac's 20. But the original question was about whether viruses are more *widespread* on Macs than on PCs, not whether there were more different strains of virus. It's certainly true that there are more different viruses for PCs than for Macs. But that doesn't tell us whether or not there are more infected PCs than infected Macs, or a higher percentage. I'd be very interested in any data that anyone has on that question. (Remember: the vast majority of 'known' PC viruses have never been known to infect a real user. Is that also true for the Mac?) DC ------------------------------ Date: Tue, 03 Sep 91 13:09:18 -0700 >From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: Boot sectors FUNBOT1.CVP 910902 Boot sector infectors Every disk has a boot sector. Most disks are not "bootable" because they do not contain the necessary system files, but all disks have a boot sector. The boot sector is simply that place in which the computer, by default, looks for the starting point of the boot sequence. In saying that every disk has a boot sector, I am using the term "boot sector" in its most generic sense as being this initial starting point. In the MS-DOS environment, "boot sector" has a more limited technical definition, and hard disks actually start with a Master Boot Record rather than a boot sector. In either case, however, there is one spot which gives the computer some definition of the disk, and information about the next step in the boot sequence. In most cases the boot sector does not point to a boot sequence, because system files are not available on the disk. In the case of a bootable disk, the "bootable" sector points to the location of files containing the programming necessary for input and output activity and a program for the interpretation of operating system commands. A "data", or non-bootable, disk, however, may simply contain information on the disk specification, and a small program informing the system, or operator, that the disk is "non-system". The important point, however, is that a program is there in the boot sector, in every case. The existence of a boot sector on every disk is the major strength of boot sector infecting viral programs, and it is a psycological, rather than technical, advantage. Because a "data disk" does not contain any recognizable "programming", it is often seen as "safe". If there is no program, then there is no program to infect, right? However, since there is, in fact, a "hidden" program on the disk, it *can* be infected. By and large, boot sector infectors "displace" the existing boot sector, and move it to another location on the disk. This means that the viral program gets "first crack", and is able to install itself in memory, and then passes control to the original boot sector. Thus the disk appears to behave normally, unless the virus carries some visible payload. In addition to the psychological advantage, "BSI"s have some technical values as well. For one thing, they get the first chance at the system, before most "protection" has started. For another, a BSI, to be effective at all, must be memory resient. For a third, because hy make changes to system areas which are not normally seen, te changes are often undetected in normal operation. copyright Robert M. Slade, 1991 FUNBOT1.CVP 910902 ============= Vancouver p1@arkham.wimsey.bc.ca | "If you do buy a Institute for Robert_Slade@mtsg.sfu.ca | computer, don't Research into (SUZY) INtegrity | turn it on." User Canada V7K 2G6 | Richards' 2nd Law Security | of Data Security or try rslade@keadb.kea.bc.ca once in a while. ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 155] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253