Return-Path: Received: from IBM1.CC.Lehigh.EDU by abacus.HGS.SE (SunOS 4.1/SMI-4.1-01) with sendmail 4.1/SMI-4.1-01 id AA10708; Wed, 1 Jul 92 00:38:32 +0200 Message-Id: <9206302238.AA10708@abacus.HGS.SE> Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 8163; Tue, 30 Jun 92 18:28:36 EDT Received: from LEHIIBM1.BITNET by LEHIIBM1.BITNET (Mailer R2.08) with BSMTP id 1156; Tue, 30 Jun 92 18:28:19 EDT Date: Tue, 30 Jun 1992 18:24:39 EDT Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU Sender: Virus Discussion List From: "Kenneth R. van Wyk (The Moderator)" Subject: VIRUS-L Digest V5 #123 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L Status: RO VIRUS-L Digest Tuesday, 30 Jun 1992 Volume 5 : Issue 123 Today's Topics: Am I infected with Ping Pong? (PC) Info wanted. (PC) Re: 1530 Virus (PC) Re: Azuma (PC) Scanning under Windows (PC) Re: Hardware protection (PC) Re: Imprecise scanners (PC) Re: mutating - polymorphic (PC) Re: No Frills 2/3 Scanner needed! (PC) Re: Protecting windows from Viruses (PC) Re: Weak algorithms for checksumming (PC) Re: MtE analysis & report (PC) re: Viruses, Anti-virals, & change (PC) Scream II virus help? (PC) Re: Scanners & Integrity Management (PC directed but not specific) Re: MVS Virii (IBM MVS) OS Built in protection re: Virus-l stuf of late Looking for CRC checksum formula Re: Virus-l stuf of late 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. (The complete set of posting guidelines is available by FTP on cert.sei.cmu.edu or upon request.) 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. A FAQ (Frequently Asked Questions) document and all of the back-issues are available by anonymous FTP on cert.org (192.88.209.5). Administrative mail (comments, suggestions, and so forth) should be sent to me at: . Ken van Wyk ---------------------------------------------------------------------- Date: Fri, 26 Jun 92 16:19:00 +0700 From: XIB@IAEA1.BITNET Subject: Am I infected with Ping Pong? (PC) Hi all, Today, when running Windows 3.1 on my 386/25 PC as usual, after I issued a DOS command in a DOS window, the screen was frozen and my cursor started moving from corner to corner making a regular rectangle. All other DOS windows had to be cancelled but otherwise my machine behaved normally. I suspect I got a ping - pong like virus, but I am not able to find the infected file, even when scanning all files on all drives by the newest SCANV91. I do not know much about viruses, any hint from you, experts, would be greatly appreciated. Thanks for your time, Jaroslav Fukala XIB@IAEA1 ------------------------------ Date: Fri, 26 Jun 92 16:07:18 +0100 From: "Vaughan.Bell" Subject: Info wanted. (PC) I am looking for information on the following viruses or at least where I can get info on the following viruses. The viruses are : Virusoft 2 Scorpio No Rezid Clipper Beeper or Russian Mirror Bad Taste Anti Faggot VSUM does not have info on these viruses or not under any name I recognise, also I don't trust VSUM's info 100%. Thanks in advance... }===---> Vaughan Bell - vaughan@uk.ac.psw.cd <---==={ }===---> Polytechnic South West - Drakes Circus <---==={ }===---> Babbage Building - Room 112 - Plymouth <---==={ }===---> Devon - UNITED KINGDOM <---==={ Vaughan Bell - University of Plymouth - vaughan@uk.ac.psw.cd ------------------------------ Date: 26 Jun 92 15:10:31 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: 1530 Virus (PC) satmech@ecst.csuchico.edu (satmech) writes: > Just recently, I found a few .COM files on my system infected with the > 1530 Virus. Norton AV and an old version of scan wouln't detect it, > only scan90 and scan91 found it. Can someone tell me more about this > particular virus or where to find detailed info on it? According to VIRLIST.TXT, this is a non-resident EXE and COM infector, but this source of information is known to be very unreliable. Also, there have been several reports about false positives caused by the newest version of SCAN (91), so I cannot even confirm that what you have is a virus at all, if I don't see a copy of it. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 26 Jun 92 15:14:49 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Azuma (PC) POTACZAL@ucf1vm.cc.ucf.edu (Mike 'the one with the grenade' Potaczala) writes: > I am trying to find out more information about the Azuma virus. I > could not find anything on it in the McAfee documentation and McAfee > did not detect it. Norton Anti-Virus did find it, but the person who > has this virus problem does not have documentation for Norton > Anti-Virus and therefore I wasn't able to check it. I would > appreciate any information on this virus that is available. Hmm, there is a virus, called "Azusa", but SCAN should detect it. Are you sure that what your friend has is really a virus and not a false positive, caused by NAV? Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Fri, 26 Jun 92 11:21:00 -0400 From: Al Woodhull Subject: Scanning under Windows (PC) Scanning under Windows: bad idea? I've been a contented (and registered) user of McAfee's SCAN program for a while now, although I keep away from the more exotic features and have only had occasion to actually meet 3 or 4 real viruses. But it is a convenient and easy to use scanner. So when version 91 was announced as being available by FTP I got it, and, as people I associate with are more frequently using Windows now, I also downloaded WSCAN91.ZIP. I'm disconcerted to see that WSCAN comes with instructions for installation to the hard disk. I think the McAfee people ought to emphasize to their customers the importance of doing a virus scan following a clean system boot from write-protected media that hold known-good copies of all system files and the scanner program itself. At the college where I teach we have had much more trouble with viruses in the Mac clusters than in the PC clusters. One reason is that the friendly Mac makes what is really going on less visible to the user. I know the Windows tide is coming, there is no sense in fighting it, but those of us concerned with system integrity have to make a stand, and tell people what they may not want to hear: If you want integrity in the MS-DOS/Windows environment you have have to forego the friendliness of Windows for some purposes, most especially if you have any reason to suspect that you have a virus problem. The only safe way to scan for viruses under Windows is to start Windows itself from floppy disks. (I haven't tried this, I'm sure it could be done, but I think it would be pretty unwieldy.) I would suggest that McAfee should rethink and withdraw the Windows version of their program, or at least make it very clear how unsafe it is. Albert S. Woodhull School of Natural Science, Hampshire College, Amherst, MA 01002 413-549-4600 ext 581 (office), 413-549-4740 (home) awoodhull@hamp.hampshire.edu, woodhull@dawn.hampshire.edu ------------------------------ Date: 26 Jun 92 15:24:58 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Hardware protection (PC) raju@dcs.qmw.ac.uk (Daryanani) writes: > In recent weeks I've been seeing a growing number of advertisements > for boards that plug into PCs and supposedly protect the machine not > just from currently known viruses, but from viruses that have not even > been written yet. Nonsense. They often fail to protect you even against the known viruses... > The latest board I've come across is from Certus > and is called Novi (or something like that). I have the impression that this is a program, not a board, but I may be wrong. I.e., I know that Certus has such a program, but maybe they are also selling a hardware product with the same name. > virus activity at all times & hence stopped them from working. In > discussions with some other persons who were interested in stopping > viruses we came to conclusion that as far as detection of new viruses > was concerned this claim was a load of crap. To me these boards seem You have reached the right conclusion. Just a small remark - all those boards are more secure than any software-only -monitoring- program. > especially vulnerable since a virus writer who had access to one can > specifically write his virus to detect the presence of the board and > circumvent it. This is essentially true; just in some cases it is not so easy (to the virus writer, I mean). For instance, the ThunderByte card, produced by ESaSS in the Netherlands, has a different version of the EPROM BIOS extension in each different example of the card. This prevents the brute-force attack that you describe, but still leaves security holes large enough for a virus to penetrate. So, your final conclusion still holds. > Since I'm no expert on viruses, just someone who's has enough problems > with them already, I was wondering what those more knowledgeable about > viruses than me think about these boards. Hope the above helps. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 26 Jun 92 15:36:17 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Imprecise scanners (PC) MC0170@mclink.it (Stefano Toria) writes: > VIRUS-L or elsewhere. I would be very much interested in some detailed > facts, such as names of strains and variants that SCAN and/or Solomon > get mixed up with. At our ftp site (ftp.informatik.uni-hamburg.de; IP=134.100.4.42), in directory pub/virus/texts/tests there are several files, which present the results of running SCAN 89-B, Dr. Solomon's Anti-Virus ToolKit (FindVirus 4.15), and F-Prot 2.03a on our full virus collection. You will be probably most interested in the archive reports.zip, which contains the preprocessed and tabulated names as reported by those three scanners, as well as the standard CARO name for each virus variant (in fact, for each file in our virus collection). Since the lines in the file are very wide (> 200 characters), there is also a PostScript version that uses small fonts to print everything on one A4 page. I know that the versions of the three scanners are already out-of-date; I was waiting for all the three of them to be updated and for a large virus collection. I have received all this now, so new test results will be available soon. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 26 Jun 92 15:49:30 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: mutating - polymorphic (PC) KARGRA@GBA930.ZAMG.AC.AT writes: > I always thought, that after a discussion about 30 digests ago, the > difference between a mutating and a polymorphic virus is cleared and > defined. So if I read correct, the DAME is an encryptor. So these > viruses (dedicated et al.) are not necessarily polymorphic. A > polymorphic virus should be a virus using different code, to do the > same thing. So my conclusion: A polymorphic virus can be a mutating > one, too, by using the DAME. I'm afraid that you got the terms messed up.... Here is an explanation again. DAME (or MtE) is a library function. It is able to get a piece of code, encrypt it, and PREPEND A RANDOM DECRYPTOR TO IT. Therefore, if a virus uses MtE, it will be using variable encryption AND will be a polymorphic one (since the decryptor is different each time). In short: 1) All viruses which use the MtE are polymorphic. 2) All currently existing polymorphic viruses (MtE-based or not), use variable encryption, although this is not mandatory, in theory. 3) Not all viruses which use variable encryption are polymorphic (e.g., Cascade). > How about dropping scanstrings of old viruses, which are not likely to > reappear again? Just like in medicine: if the is an illness which > disappeared, why waste more serum than necessary? McAfee had this implemented in SCAN about two years ago, when it became obvious that the growing number of new viruses will cause troubles to the scanners. However, they decided to drop this option, since most users seemed to be against it. Indeed, a virus never disappears - it just circulates in the virus collections... :-) Anyway, having the option that you suggest would be nice, although I wouldn't advise people to use it. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 26 Jun 92 16:13:55 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: No Frills 2/3 Scanner needed! (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: > chore@neumann.une.oz.au (Prince Of Darkness) writes: > > I have a suspicion that i have the No Frills virus on my pc, i've been > 2) Why do you think that the virus is called "No Frills"? I have never > heard about a virus with such name... Meanwhile I got a report from Roger Riordan (the author of the Australian anti-virus program VET), who does not seem to have an e-mail address. According to him, No Frills is a virus, which belongs to the same group as K-Lame and X Fungus. Unfortunately, I don't have any of them, so I cannot provide further information. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 26 Jun 92 16:24:13 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Protecting windows from Viruses (PC) asuvax!gtephx!fraserr@windom.UCAR.EDU (Ross Fraser) writes: > I have seen recommendations that SCANV *not* be run from the hard > drive because a virus can trick the scan program, and then infect it, > and other programs on the drive. Does this same restriction apply to > WSCAN? The installation program by default installs WSCAN on the hard > drive. Sigh... Ah, virus protection and Windows... To those AV producers which supply such programs I would like to ask the following questions: 1) Before scanning for viruses, it is always advised to boot from a write-protected system diskette. Now, how do you boot Windows from a diskette? 2) If you don't boot from a diskette (bad idea!), you must at least scan the whole computer memory for resident, or at least for fast infecting viruses. Now, how are you going to check the memory (the - -whole- memory!), if Windows is running in protected mode? (It is possible, just not easy.) 3) Have you ever seen an infected Windows system which does work at all? I do not say that Windows-aware viruses are not possible. They are, even it is possible to implement them by using only the currently known virus techniques. However, such viruses do not exist yet (as far as I know), and scanners can scan only for existing viruses. So why providing a Windows-based scanner? Well, this is essentially a marketing trick - people are using Windows; people are scared of viruses; therefore let's sell them a Windows-based scanner. (Note: I am not entirely honest - there -is- sometimes a need for such scanners. For instance, if you want to scan the new software that you receive, without leaving Windows.) Regards, Vesselin > Secondly, can a virus infect the windows .ini files? how can a user > protect against it, since they are normally written by WINDOWS during > normal operation? Those of them (you mean the text .INI files, right?), which specify executable files that have to be executed, can be a subject for a companion-like attack. The same goes for the .PIF files. Currently no virus does this, and if a virus relies on this -only-, then it is unlikely to spread very far. But the general idea is realizable. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 26 Jun 92 17:04:05 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Weak algorithms for checksumming (PC) padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) writes: > This is something that Ross Greenburg and I discussed on V-L about two > years ago and bears a touch of repetition: consider a three by three > matrix with ADD, SUB, and XOR on the top and ROL, ROR, and NOP to the > side. This creates a fast (two instruction) mechanism for generating > a sixteen bit checksum. By utilizing a random seed for the calculation > on each machine this would make a "blind guess" of the algorithm difficult > even if all nine values for particular programs are known. Not secure at all. This lead to a total of 9 essentially different checksumming algorithms. All that change in one particular algorithm between installations is the seed for the checksum. Which means that it is possible to break the algorithm by just knowing two files and their checksums. It will involve only 9*2=18 computations, which can be implemented in a virus with a few instructions. A CRC with an unknown polynomial (not seed!) is much more secure, since you cannot determine the polynomial from just a few file/checksum pairs. > A significant increase in strength is added if two differing checksums are > simultaneously created (e.g. McAfee's Validate). At this point a directed This is an often made mistake. Even McAfee made it. In the case when you are using a CRC (as VALIDATE does), forging two different CRCs is no more difficult than the forging of a single CRC, which is based on a LCM of the polynomials of the two CRCs. > While a good Scanner can easily handle such weak encryption mechanisms (as > demonstrated by their ability to detect most mTe infections), the I can't help but noting that the -good- scanners have the ability to detect ALL MtE infections, not most of them... :-) > Some companies (but not many so far) have realized the need for self- > validation to prevent directed attacks and hve run into the anchient > question of "who watches the watchers ?". The self-checking is never 100 % foolproof, but it helps. At least, it is able to detect random corruptions and non-stealth viruses. If you refer to a safe distribution of a software package through insecure channels, it is possible only by using public key authentication. > This brings us back to a real problem of testing anti-viral programs and what > needs to be tested for. We now have more viruses than we ever wanted > (see Vesselin's disk space problem) or needed but little testing is done He-he... I got a 300 Mb disk now... I still have almost 100 Megs free... :-) > for the secondary (directed) attacks. For those programs that perform a self- > check, how strong is it ? Does the program checksum the signature strings > as well as the executables ? Individually or Collectively ? (Consider the > effect of a virus that recognizes certain Scanners and "fixes" the signature > strings so it is not found - not trivial but possible - will the Scanner > detect the change ?) Who can tell ? At the VTC-Hamburg we are working on a professional protocol for evaluating anti-virus defenses. When it is ready, we'll produce a technical report, describing it, and will make it available for anonymous ftp. The tests, conducted according to this protocol will be as professional and reliable, as e.g. NCSC's evaluations of secure systems. Unfortunately, I have the impression that it will be also about so expensive and time-consuming... I doubt that we (the VTC) will be able to evaluate anti-virus products, according to our own protocol... We just won't have the necessary hardware and man-power. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 26 Jun 92 18:39:20 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: MtE analysis & report (PC) > It seems that both F-PROT 2.04 and SCAN 91 misidentify some >Pogue mutations that are in plaintext. F-PROT "quickscan" missed >ALL mutations. You are advised to use SECURE scan mode of this >product. The extra speed comes with 0% hit rate on MtE-based >viruses! True, but Keep in mind that Quick scan is a very primitive "single-point" scanner - it is fast, but if a virus cannot be found with a single string, located a fixed offset from the entry point, Quick will not find it. Actually, I will probably drop Quick scan in the near future, as the speed of my secure scan has been steadily improving, and it is now almost as fast as Quick scan on certain machines. >F-PROT 2.04 missed three encrypted Pogue mutations. We >examined these samples and found them to be of Type-3, and >detectable using Method-3. The samples worked as expected. One of >those three that were missed was called "suspicious" and guessed to >be a variant of the Gotcha virus. It did not guess. Pogue IS a variant of Gotcha, just with MtE added. My scanner simply picked up the Gotcha signature, probably that part of the virus was not encrypted. This is also the reason the "non-encrypted" samples are identified as Gotcha-variants. > We can only speculate that F-PROT >lacks Method-3 detection algorithm and uses a heuristic in such >cases. Well, you may speculate, of course, but you are wrong :-) I have what you call a "Method-3", but I guess it is simply not perfect - I would have to look at those three samples, to determine where the flaw is - I simply am not going to disassemble the MtE! - I did spend two days on it, and that is far too much when 3 new viruses arrive every day.... PS: The heuristics are only used if specifically requested, and will never report a particular virus, just the presence of virus-like code... - -frisk ------------------------------ Date: 26 Jun 92 19:01:58 -0400 From: Wolfgang Stiller <72571.3352@CompuServe.COM> Subject: re: Viruses, Anti-virals, & change (PC) "David.M.Chess" writes: > In practice, I've found that integrity management software at current > tech levels is mostly usable only by people (like Padgett!) who know > quite a bit about their machines. I have yet to see a package that > would really get along with a non-hacker user; typical users simply > don't know whether or not "the file SYSEMM3.EXE has changed" is > something to worry about. The problem you expose here is exactly the problem that I found when I release the PCdata toolkit as a free integrity checker through PC Magazine. I released it in conjunction with the magazine article (Feb 3, 1990 (V9N03) PC Magazine), that I wrote in hopes that people would read the article and therefore know how to use the software correctly. I learned first hand how difficult it is for "non-techy" users to use this type of software. In addition to the problem of not knowing how to determine which changes may be due to a virus (in spite of explicit instructions in this regard), I found the following problems: o Most users are unwilling to read more than just a few lines of documentation. o The concept of boot sectors and other such PC esoterica is a level of complexity that most people don't want to bother with understanding. o Most people hate to cold boot from a diskette. o The ability to reload system sectors in untrained hands can lead to disaster. o Checking speed is critical to making sure that the integrity check is used. PCdata (which is already fairly optimal assembler code) was too slow for many people. The process of solving all these problems resulted in my development of Integrity Master(tm). Although Integrity Master comes with an 80 page users manual and guide to data integrity and viruses, I do not expect anyone to read the guide before using the product. It is designed to work "out of the box". A large part of the function of Integrity Master is educational so the customer can decide how they want to use it. This shields them from the complexity of the various options. Although context sensitive help is available all screens are designed to be used without resorting to help. I use a somewhat unusual menu structure to further this end. On many menus, an explanation appears corresponding to whichever item is selected. While Integrity Master certainly isn't perfect I've made considerable progress to solving all the problems associated with a generic integrity checker (such as PCdata). > I would love for this not to be true, and I > anticipate that we will eventually have smarter systems that help the > user decide between OK changes and suspicious ones, but I don't think > we're there yet for the average person. Integrity Master is such a system. It helps the user decide by identifying certain aspects of a change which may indicate it's a viral related change but beyond this the odds are very good that IM's internal scanner (which is invoked whenever needed) will recognize the virus by name. > If anyone can tell a story > about a large group of non-hacker users (e.g. a large non-computer > business site) that's using integrity management software and liking > it, I'd be very interested in hearing! Integrity Master is used by quite a number non-computer-savvy users as well as many businesses. I can vouch for the fact that you don't have to be a "techy" to use IM. If you haven't taken a close look at IM, please do so. It should be available on most sites including Simtel-20. The current version (just released 6/22) is 1.22a. Regards, Wolfgang Wolfgang Stiller Stiller Research 2625 Ridgeway St. Tallahassee, FL 32310 U.S.A. ------------------------------ Date: Mon, 29 Jun 92 00:09:57 +0000 From: mjbrown@magnus.acs.ohio-state.edu (Mike J. Brown) Subject: Scream II virus help? (PC) My PC is infected with what Scan91 reports as "SCR2" which I assume means Scream II (which is not listed in the virlist.txt file, of course). I've got 124 .EXE and .COM files infected so far on one of my hard drives. The question is: Can I get rid of it without deleting all the infected files? Btw, I couldn't even run Scan91 after unzipping it... it unzips fine, but the virus attaches itself to SCAN.EXE as it is executed. Before I renamed my autoexec.bat and config.sys to dummy filenames (hoping that would keep the virus from activating through things like the mouse driver or other programs run upon bootup) Scan91 would inform me it had been modifed and would not allow me to continue. After bypassing autoexec.bat and config.sys the virus still attached itself to SCAN.EXE as it was being executed, but this time it gave me a choice of continuing or not. When I said Yes, it proceeded to inform me of SCR2 being in about 75% of my .EXE and .COM files. If I do get a disinfectant, how can I expect to use it if the virus is going to infect it as it starts up? Scanners/Disinfectants tend to cease execution if they detect viruses in themselves... - -- Mike Brown mjbrown@magnus.acs.ohio-state.edu "The Universe is a spheroid region 705 meters in diameter." ------------------------------ Date: 26 Jun 92 16:42:03 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Scanners & Integrity Management (PC directed but not specific) padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) writes: > >2) "The only way to achieve 100 % detection of all possible viruses is > >through integrity management." Unfortunately, this is not true. There > >are several kinds of attacks against the integrity checking software. > Vess: The integrity management I was talking about includes knowlege of what > the processor memory is supposed to look like as well as the programs. This is not sufficient. The integrity checkers must know about the possible attacks against them and take the appropriate measures to counter them. Maybe what you are saying assumes that, for instance, they should know about the companion viruses and check for files with equal name, but I somehow failed to notice this. > Here, I was referring to an encouraging trend, not the current products. The > anti-viral product vendors are evolving, I agree they are not there yet, but > are now going in the right (IMHO) direction. I agree. And our duty as anti-virus researchers is to make enough noise and watch that the right idea is also implemented in the right way, before it is sold to the user... > >> systems first determine that *something* has happened before trying to > >> determine *what*. > Again, this includes memory changes as well as program. No, I meant that the integrity checking software can detect the infection only after-the-fact and most people want the infection to be - -prevented-. Of course, the latter is not possible in the general case, so we must have integrity checkers which detect the infection early enough. > For the so-called > "slow infectors" to infect-on-creation, they must be memory resident and > *that* can be detected. Not necessarily. Besides, it is also to use attacks against integrity checking of the memory. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 26 Jun 92 15:58:30 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: MVS Virii (IBM MVS) ranck@vtvm1.cc.vt.edu (Wm. L. Ranck) writes: > I was somewhat surprised that CHRISTMA never surfaced again. But it did. 1) It has been re-released onto BITNET on 5 December 1988, possibly from Louisiana State University. 2) A modified version (BUL EXEC) has been released from the EARN backbone site in Turkey on March 8, 1989 3) A trojan, releasing it, called DIR EXEC, has been reported on November 25, 1989 at BITNET node TECMTYVM. Other programs, based on the same idea have been released: 4) ORGASM EXEC, released from Pennsylvania State University on April 4, 1989. 5) HEADACH EXEC found at the University of Ottawa on April 8, 1989. 6) TERM MODULE was released from Turkey and spread to the USA and Canada. The above information is from David Ferbrache's excellent book "A Pathology of Computer Viruses", Springer Verlag, 1992, ISBN 3-540-19610-2. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Fri, 26 Jun 92 12:14:00 +0000 From: cpbeaure@cayley.waterloo.edu (Chris) Subject: OS Built in protection I know this popped up in the past but... Several queries on built in virus defense features of an operating system. What are the basic requirements that an OS should have for handling infections? Off hand, I can think of checking the integrity of a program before running (as an option - some software wouldn't handle this well), integrity checks of the boot sector, and seriously limiting things like direct disk access and access to the FAT. Then there's memory restrictions. What about restrictions on what interrupts can be hooked by a user program? A second question, for those familiar with DPMI. Would the protection features of DPMI constitute sufficient protection, or are there easy ways around these? Chris Beauregard cpbeaure@cayley.waterloo.edu Differently Expressed: The politically correct term for politically correct people. ------------------------------ Date: 26 Jun 92 14:16:47 -0400 From: "David.M.Chess" Subject: re: Virus-l stuf of late >From: fc Nice to see you on the net more often, Fred! >I am somewhat taken aback by the claims that integrity >checkers get substantial numbers of false positives or that they >require users to make decisions when they don't know how. IT has >never produced a false positive to my knowledge, and with a decent >implementation, we can easily automate all of the decisions to the >values set by corporate policy makers. I think it depends on exactly what we mean by "false positive". Certainly it's true that when a good integrity checker says "this file has changed!", it's always right, and when it says "this file has not changed" it's virtually always right. So there are no false positives in that sense. But the trouble is that "this file has changed!" isn't enough for most users to decide whether or not they have a virus. It's true that in some very closed environments, essentially nothing should change, and so any alert is most likely a virus. I don't know how common those environments are, and in any case much of the virus problem is in other environments (college campuses, public machines, machines on which programming is done, and so on). In environments where things do change (a programmer's machine, a personal or business machine that's frequently updated, a machine used for competitive evaluation, or available for public use, or etc), it's certainly possible to enforce whatever "policy" the owner of the machine has chosen, as long as that policy is worded as "only the following things should change, and only under the following circumstances". However, that's not the sort of policy that the user wants! He wants to say "anything can change, as long as the change is a legitimate result of something I did on purpose". *That* policy is the one we know we can't enforce (I know you already know this, Fred; it just fits nicely into the narrative flow here). So we can enforce change-management policies. But if that policy is (roughly) "nothing should change", there will be alerts that reflect legitimate changes, and, although they aren't false positives in the strict sense, because they are real policy violations, they act like false positives because they lead to investigation that determines that everything's OK. Or if the policy is "well, Joe's a programmer, so on his workstation everything but the system files and the boot records can change", a virus can spread around, which isn't a false negative in the strict sense, since the policy allows viruses, but it acts like a false negative because you've got a virus in Joe's system! It's fine to strictly enforce the policy that the system owner chooses, but to the extent that we restrict his choice of policies to just those that we know how to enforce, we get nice-sounding results ("Virtually Perfect Enforcement of the Policy YOU Choose!"), at the cost of not actually doing what the owner really wants (and -would- choose, if we gave him the option). There are heuristics that can help get the policy that's enforced closer to "allow only legit changes", and I think that's where the hope of integrity management lies. I haven't seen a product that has really good heuristics in this area. But then I haven't seen IT, either! We really ought to get a copy to look at. Does that, Fred, explain a bit of what I meant about the problems with the integrity checkers that I know of? When you say that IT has never had a false positive, do you mean that it's never claimed that something had changed that really hadn't (which I certainly believe!), or that it's never flagged/disallowed a change that was in fact the legitimate intent of the system's owner? (That'd be a very impressive claim!) DC P.S. I will be out all next week, so don't anyone expect any quick replies! Back in July... ------------------------------ Date: Thu, 25 Jun 92 09:49:19 -0400 From: SOUTHARDJ001@WCSUB.CTSTATEU.EDU (Ed Southard, Information Systems: Sys tem Support.) Subject: Looking for CRC checksum formula I would like to obtain the following formulas: a.) CRC-4 ?if possible b.) CRC-8 ?if possible c.) CRC-16 d.) CRC-32 e.) CRC-64 ?if possible Thanks. - -Ed [Moderator's note: Please reply directly to Mr. Southard via e-mail.] ------------------------------ Date: 26 Jun 92 21:25:37 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Virus-l stuf of late FBCohen@DOCKMASTER.NCSC.MIL (fc) writes: > false negative is quite low, but then, why do we need 100% detection > from scanners? I think when scanners get to where they miss only 1 in > 2^32 evolutions, they have met the same spec as an integrity checker > with 32 bits. Let's call for 99.99999999% accurate scanners, not > 100%!! Hmm, yes, I agree with this, but if a scanner achieves such a detection rate, it will be practically impossible to distinguish between it and a 100 % detector during the tests... > I am somewhat taken aback by the claims that integrity > checkers get substantial numbers of false positives or that they > require users to make decisions when they don't know how. IT has Mea culpa; I either used the wrong term, or failed to define it correctly. By "false positives" in the case of the integrity checkers, I meant when they raise an alert ("This file has been modified!"), and the cause of the modification has been natural (re-compilation or software update). In the same way, a false positive generated by a monitoring program is the message that a write attempt to an executable file occurs when you simply try to copy an executable file. > never produced a false positive to my knowledge, and with a decent > implementation, we can easily automate all of the decisions to the Automate?? Even having in mind that, in general, it is undecidable whether a program is a virus or not, either by considering its appearance or its behavior? How?? I am currently working on a set of heuristics that will help to decide whether the modification has been caused by a virus or not, but it will be nothing more than a set of heuristics... How can this be entirely automated? > they need to know automatically. The point is that the claims against > integrity checkers don't wash - they are apparently just product > specific problems that require some better design work. The main problem with the integrity checkers is that when the user gets the message "This file has been modified", s/he either ignores the message, or is ready to cry virus... :-) > On the other hand, OS/2 is such an improvement over DOS and Windows, > that I am willing to forgive, and even perhaps appreciate, their > protection against accidentally corrupting the file system by limiting While I agree that writing viruses for OS/2 is as difficult and protecting against them as easy as, say, in Unix, I'll argue that they are still completely possible (in both systems!) and -can- spread relatively well. > some low-level and undocumented DOS calls. It doesn't bother me even > a little bit that Norton utilities cannot corrupt my file system! Yeah, but if it is already corrupted, it cannot be used to fix it either... :-) Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 123] ******************************************