Date: Fri, 28 Jun 91 14:24:52 EDT Subject: VIRUS-L Digest V4 #112 To: Multiple recipients

---
Master Index Current Directory Index Go to SkepticTank Go to Human Rights activist Keith Henson Go to Scientology cult

Skeptic Tank!

Date: Fri, 28 Jun 91 14:24:52 EDT From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V4 #112 To: Multiple recipients of list VIRUS-L VIRUS-L Digest Friday, 28 Jun 1991 Volume 4 : Issue 112 Today's Topics: Re: Can such a virus be written .... (PC) Re: VSUM accuracy and Microcom (PC) Version 80 VALIDATE Results (PC) Ross-bashing Encrypted strings Re: Can such a virus be written ... (PC) doom2:reply (PC) Self-Modifying SETVER.EXE (PC) Re: Can such a virus be written .... (PC) MacAfee Products (PC) Trojan horses in data files Interesting action with MACs (Mac) VIRUSSCAN 80 (PC) Virusafe 4.02 (PC) North American Distributor of Virus Bulletin newsletter 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: Thu, 27 Jun 91 13:41:35 -0400 From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: Re: Can such a virus be written .... (PC) Good grief - this question reminds me of John Carpwenter's "The Thing", it just will not die. >> Is it possible to write a PC virus which installs itself whenever >> you place an infected disk in the drive and do a DIR command ? NO, NEIN, NON, NEGATORY - you cannot write a virus to infect when an uninfected PC does a DIR of an infected floppy disk (unlike the Macintosh) I don't care about batch files (which also execute, just interpretedly), ANSI control sequences (which also execute), or 1-2-3 macros. In order to subvert the DIR command (not that difficult) something MUST execute and a PC will mot execute ANYTHING without being commanded to (boots result from a microcoded command designed into the CPU - part of the reason for the 640k "barrier". Of course, once resident, code can tell the processor to do anything it is capable of doing via software, the operating system doesn't care, and at any time. You want the PC to play "Yankee Doodle" at 5 pm? easy. You want all the letters to fall down in a pile on the bottom of the screen every half hour ? trivial. But they all must execute first and that takes human help either by leaving a floppy in A when booting, or by executing an infected file (.COM, .EXE, .BAT, .WK1, .SYS, .APP, or whatever). If DIR could infect, it would be easy for an infected user to say both/he/it she just put the disk in the drive to see what it was, but no, they HAD to have tried to run "ASTROT*T" or "Kermit vs the Naked Nazi Nymphs" or "1ON2" or that un-tested program with the hand-lettered label in Arabic/Swahili/Kanjii. While software commands could be hidden in a batch file with sequences that would prevent reading by TYPE (but not from LIST or even WordStar) and be passed as an unscannable uuencoded, packed, compressed file, at some point some person had to tell it to execute whether or not they knew thay were doing so. Only then can a virus (or any other malicious software) infect a PC. Padgett If this doesn't kill the subject, I'll have to use a lead pipe. ------------------------------ Date: Thu, 27 Jun 91 13:36:08 From: c-rossgr@microsoft.COM Subject: Re: VSUM accuracy and Microcom (PC) >From: "Bonnie Scollon" > >.... My copy of Virex-PC did not but >the dates on the files are over a year old, even though we purchased >from Egghead only 4 months ago. (I have never received any update >info).... Bonnie, please call 919-490-1277 and holler and scream at the folks at Microcom? I *know* that there have been many updates to the code in last year, especially in the last quarter. If you're a registered user and you didn't receive a free update to Version 1.2, there is something *very* wrong. Version 2.0 has *finally* entered into final beta, and should be available very shortly: for those who have purchased VIREX-PC recently, send in your registration card and you'll get a free update to Version 2.0. We've disinfected Joshi for quite a while and Egghead selling outdated code *really* burns my butt: please report the store number to Microcom as soon as you can? Thanks! Ross Author, Virex-PC, VIRx and FLU_SHOT+ ------------------------------ Date: Thu, 27 Jun 91 09:04:25 -0700 From: mcafee@netcom.com (McAfee Associates) Subject: Version 80 VALIDATE Results (PC) I've had a request from Europe to post the validation results for the new release of SCAN (et al) because they do not receive the "Authentic Files Verified" from the version of PKZIP distributed outside of North America. VALIDATE Results for Version 80 of SCAN/CLEAN/VSHIELD/NETSCAN CLEAN-UP V80 (CLEAN.EXE) S:119,999 D:06-24-91 M1: F8AE M2: 05DD NETSCAN V80 (NETSCAN.EXE) S:87,437 D:06-24-91 M1: 705F M2: 04F6 VIRUSCAN SCANV80 (SCAN.EXE) S:87,437 D:06-24-91 M1: 58A9 M2: 0538 VSHIELD VSHLD80 (VSHIELD.EXE) S:33,403 D:06-18-91 M1: 5607 M2: 0C19 VALIDATE Results for VALIDATE and VSHIELD1 (not changed since last release) VALIDATE V03 (VALIDATE.COM) CRC Add S:6,495 D:10-31-89 M1: 4637 M2: 1214 VSHIELD1 0.2 (VSHIELD1.EXE) S:11,281 D:02-14-91 M1: 6B40 M2: 103E Aryeh Goretsky McAfee Associates Technical Support (Sorry for the delay, Paul!) ------------------------------ Date: Thu, 27 Jun 91 16:00:34 -0400 From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: Ross-bashing Allright, enough already. So there was a conflict between two SCAN programs that caused a "false positive" when one was run immediately following another. This is nothing new to the anti-virus industry, a few months ago two products much closer related than Vir-X and whatever the other one was consistantly reported the "12-Tricks" when run one after the other. Until recently when memory scanning became de-rigeur, and thank goodness it did, no-one bothered to clean memory following a scan. Remember the Prodigy STAGE.DAT controversy a few months ago ? It all started when someone scanned the disks before installing the *P* upgrade and discovered a host of virus names and strings inside the .DAT file. Why ? My thought is that *P* needed to create a contiguous fixed-size file on disk and did it the simplest way possible: by just creating a giant memory buffer (without putting anything in it) and copying it to disk to create the STAGE.DAT file. Whatever happened to be in memory at the time was just swept along. Since a scanner had just been run that left all of the strings in memory, this became STAGE.DAT. Now clearing free memory is trivial, one easy way would be for a scanner to clear memory before loading, but then if a virus was present a) the system would probably crash and b) you would not get a virus report. I fully expect the next generation of anti-virus tools to be able to disconnect a virus from memory when found (if it can identify it, it should be able to remove it and at least determine if it is active or not). On the subject of encryption, I agree with Ross, a trivial one is sufficient to avoid false positives at least until signatures reach a significant portion of the number of ten-byte signatures - on the close order of 10^24 - which should take a while. To keep them encrypted at all times except when individually used would cause an extreme preformance loss for something that is already slow. Meanwhile, the real key piece of information seems to have been missed - - why the signatures were still in memory. When the second scanner loaded, it should have overwritten the RAM Ross was using therefore, for this to happen, Ross's code, when expanded in memory, had to be longer than the subsequent program. (why there probably have not been more "false positives" rather than any deliberate avoidance). I suspect that the "virus" string found was near the end of the expanded search string list and the list followed the executable code. Consequently, there may be an easier way than wiping memory - in a program you have a choice as to where buffers are placed. If the decrypted strings were kept in a buffer area at the front of the program and followed by the executable code that (hopefully) does not match anyone else's viral signatures, any other scanner that follows should overwrite all the strings before starting. Since when loading "high" a quick way to lock up a machine is to use expanding buffers beyond the file size, these concepts should also be considered by any memory resident routine. Just some thoughts, Padgett Somewhere west of Orlando ps Life is a learning process, when one stops, so does the other. - app ------------------------------ Date: Thu, 27 Jun 91 13:21:28 -0700 From: Eric_Florack.Wbst311@xerox.com Subject: Encrypted strings hi, Ross; - -=-=-= >On /DISK/, yes. But consider the amount of scanners, including MAcAffee that >look at RAM, as well. False trip city, as we have seen. Sigh. Look, I simply didn;t remove the strings from memory. What's your point? =-=-= Exactly this:False trips cause problems for both you and the person whose machine if falsely diagnosed as being infected. Such false trips cost both of you income. A point which, given the release info I've just gotten on v1.5 you tend to agree with. You say: =-=-= >As for your beta testers not finding the problem, I suggest to you >that perhaps they missed a major problem. WIthout being judgemental, >here, finding this problem after beta was complete would seem to call >into question the validity of certain of your test results. Actually, it just showed that our beta testers did not run into that problem (recall that the reports I mentioned above were limited in number). This implies that they don't use one of our competitor's products. So what? There are many people who opt not to use our competitor's products. =-=-=- The ` so what' is that many others /do/.... Allow me to explain that one of the things I do for a living is such testing. IMHO, interfacing with other, similar products , where possible, (even if only for direct a/b comparison) is part of a complete test. You say: =-=-= And, sometimes, a minor mistake is make and is blown way out of proportion. - -=-=-= Sorry, Ross, if you thought my posting was blowing your error out of proportion, but I honestly don't see how. Recall, please, that this thread started with a general post was directed at all of us for input on a specific problem. My intent was not to attack a particular program. (Indeed, the names of the packages the author mentioned were one point I didn't even consider.... ) but rather, my intent was a general answer. Good hearing from you. ------------------------------ Date: 27 Jun 91 15:41:00 -0500 From: "William Walker C60223 x4570" Subject: Re: Can such a virus be written ... (PC) Steven van Aardt (vanaards@project4.computer-science.manchester.ac.uk) writes: > Is it possible to write a PC virus which installs itself whenever > you place an infected disk in the drive and do a DIR command ? Lots of people replied: > Yes. But A. Padgett Peterson (padgett%tccslr.dnet@mmc.com) replies: > No ... you cannot BECOME infected in this manner. Padgett is right. To infect a PC, viral code must be executed from the medium on which it is stored. The DIR command does not execute any code from the disk or diskette it is viewing, but just displays the information contained in the sectors of the requested directory or subdirectory. Therefore, if you do a DIR of an infected diskette on a clean PC, there is no way to infect the PC. Someone else has mentioned the possibility of renaming a file to contain ANSI.SYS codes for remapping the keyboard, but this would not be transparent to the user, as the remaining information (date, time, and size) would be shifted to the left. Bill Walker ( WALKER@AEDC-VAX.AF.MIL ) | OAO Corporation | "Non sequitur -- your facts are Arnold Engineering Development Center | un-coordinated." M.S. 120 | -- NOMAD Arnold Air Force Base, TN 37389-9998 | ------------------------------ Date: Thu, 27 Jun 91 11:52:28 -0700 From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: doom2:reply (PC) Eric_Florack.Wbst311@xerox.com writes: > Ross says: > - -=-=- > The signature a scanner uses is of no use to a bad guy unless he or > she already has the subject virus on hand, in any case. > =-=-=- > Of course not. My point in this case was the person doing the altering > to routre around your code being the original author. Moreover, we > have seen several varieties of a particular virus around, indicating While this arguement has some validity, I would suggest that it only serves to reinforce a point made before in this forum, and which I very strongly emphasize in my seminars and consulting. The "my scanner is better than your scanner, nyaah" school of evaluation misses a vital point: any two scanners are better than either alone. Even though I feel that Ross's product is one of the best on the market, and I use it myself for my own testing and protection, I would hate to see the day when it became the only one available. As Ross has pointed out, no matter how well strings are encrypted, eventually someone will break the code, and then it is a trivial matter to write a virus that circumvents that package. However, with a number of scanner packages on the market (and even I don't have them all), the author of a virus can never know which package his code will have to go up against. ============= 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 ------------------------------ Date: Thu, 27 Jun 91 11:59:14 -0700 From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: Self-Modifying SETVER.EXE (PC) 76476.337@CompuServe.COM (Robert McClenon) writes: > This is very unfriendly behavior for users who try to maintain > any sort of discipline to control viruses, or any of various other > sorts of discipline. Virex-PC gave me multiple alerts telling me that Unfriendly and, unfortunately, all too common. Buried in the documentation for Mace Vaccine, which has a change detection component, you will find a note that self modifying programs will trigger false alarms, and that Mace Utilities itself makes such self modifying programs ... ============= 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 ------------------------------ Date: Thu, 27 Jun 91 16:17:25 -0500 From: THE GAR Subject: Re: Can such a virus be written .... (PC) >From: Doug Krause >> >vanaards@project4.computer-science.manchester.ac.uk (Steven van Aardt) writes: ># ># Is it possible to write a PC virus which installs itself whenever >#you place an infected disk in the drive and do a DIR command ? > >Doesn't STONED act that way? > >Douglas Krause One yuppie can ruin your whole day. NO! Stoned does NOT act that way. At least if I am understanding the question properly. If I am, then the virus is impossible. Let me make sure I understand. We have booted from some drive, C, and are now, after the COMMAND.COM from C has been loaded, doing a DIR on some infected disk, A. The question is, can the infected disk A, infect C. NO. The code that is being executed is in RAM, not on drive A. Without executing any code from A, we cannot invoke a virus. STONED works by executing the boot sector on the infected drive A, but this can only happen at boot time, not by executing a DIR command. Macintosh's CAN infect C from A in the above case, because inserting a disk executes the DESKTOP program on that disk. If the DESKTOP on A is infected, getting a listing will give you the virus (WDEF usually!) /++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\ ! Later + Systems Programmer ! ! Gary Warner + Samford University Computer Services ! ! + II TIMOTHY 2:15 ! \+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++/ ------------------------------ Date: Thu, 27 Jun 91 16:06:00 -0800 From: Michael_Kessler.Hum@mailgate.sfsu.edu Subject: MacAfee Products (PC) We investigated the issue of a license agreement with MacAfee, and it turns out that they will issue a "group" license limited to ten users who would have the right to do a virus check of the various LANs and all their stations. In other words, ten lab managers would have unlimited right to use the product once we pay a $1500 fee (approximately). At the same time, we are allowed to distribute the product as shareware for individual users. My interpretation: I cannot use the product, except on a single station like any other individual user, since we did not pay for the license, but I can make it available to others for their personal use, leaving the question of payment to their conscience. It also means that I do not "distribute" the copy to individual users who happen to be the office secretaries in the various departments. On the other hand, I do not feel overly pressured to use this product since F-Prot (we payed the suggested fee) seems to work just fine. MKessler@HUM.SFSU.EDU ------------------------------ Date: 27 Jun 91 23:57:00 +1700 From: VANVLECK_TOM@tandem.com Subject: Trojan horses in data files Mac and PC applications that read structured data files might be tricked into executing a trojan horse by an ill-formed input file. Given garbage input, word processors, picture displayers, and spreadsheets sometimes crash by executing an illegal instruction. If the bytes making up this instruction come from the data file, the data file can act as a virus installer. I don't know if a DIR A: command can be tricked in this way; proving that it can't be, no matter what's on the floppy in drive A, would be a hard job unless the code is thoroughly defensive. I do not believe such a trojan horse data file exists today. We should - - change scanners to scan all files, not just code - - identify applications that are vulnerable to this attack and suggest they be repaired or avoided Tom Van Vleck ------------------------------ Date: Thu, 27 Jun 91 22:25:22 -0500 From: Thomas Lapp Subject: Interesting action with MACs (Mac) This came from a colleague at work who works with our PCs. In a followup message she sent to me today, she indicated that a technician seems to think it is more a problem with some flakey hardware taking a bunch of other pieces out, and that it was just coincidence that System 7 was going in at the same time... If anyone else has seen anything like this, I'd be real interested in knowing more, and passing it back to Barbara. -tom From: NAME: Barbara J. Miller FUNC: ISD-P&DD/IT&E To: NAME: Thomas L. Lapp Thought you might be interested in hearing about a "potential virus". It has not been declared a virus by anyone at this point, but I always like to expect the worst until it is determined. From: NAME: Barbara J. Miller FUNC: ISD-P&DD/IT&E Date: 26-Jun-1991 Posted-date: 26-Jun-1991 Precedence: 1 Subject: Virus Alert - Mac's S7 To: See Below Virus Alert: I just received word of a virus that was encountered during a Mac System 7 installation. Both the keyboard and mouse DIED on three machines that just had System 7 installed on them. The customer then attached a voltage meter to the ADB port of a fourth machine only to find a unusually high reading. It appears the virus destroys chips on the mouse and keyboard. Suggestions: Be cautious when installing S7. Be sure it is a CLEAN copy - directly from Apple or from CD-ROM. Apple has been contacted. - tom - -- internet : mvac23!thomas@udel.edu or thomas%mvac23@udel.edu (home) : 4398613@mcimail.com (work) uucp : {ucbvax,mcvax,uunet}!udel!mvac23!thomas Location : Newark, DE, USA ------------------------------ Date: Fri, 28 Jun 91 10:58:34 +0000 From: t821431@minyos.xx.rmit.OZ.AU (Richard Clarkson) Subject: VIRUSSCAN 80 (PC) What ftp sites are VIRUS SCAN 80 available from? Can you supply the addresses? Thanks in advance Richard Clarkson [Ed. See Jim Wright's monthly VIRUS-L/comp.virus archive site postings. These are posted at the beginning of each month. The most recent one was V4I96 on 3 June 1991; it is available by anonymous FTP on cert.sei.cmu.edu in pub/virus-l/archives/1991] ------------------------------ Date: Fri, 28 Jun 91 08:17:33 -0400 From: HTORRES@LEDA.HQ.NASA.GOV Subject: Virusafe 4.02 (PC) Any product or beta test on Virusafe 4.02. I have used it for a while and it proves to be very reliable. They are in Florida on 520 west hwy. 436 suite 1180-30Altamonte Springs Florida 32714. Please, reply. Tito ------------------------------ Date: 28 Jun 91 13:19:01 -0400 From: Ray Glath <76304.1407@CompuServe.COM> Subject: North American Distributor of Virus Bulletin newsletter RG Software Systems, Inc. is pleased to announce our appointment as North American Distributor for the acclaimed "Virus Bulletin" monthly newsletter, published in the U.K. This 25+ page highly informative and unbiased publication (no advertising) contains detailed analyses of viruses, anti-virus product reviews, trend projections, and news events concerning viruses. Anyone wishing to subscribe should contact: Virus Bulletin c/o RG Software Systems, Inc. 6900 E. Camelback Road, #630 Tel. (602) 423-8000 Scottsdale, AZ 85251 FAX (602) 423-8389 One Year subscription cost: $ 350.00. Back issues (from as early as July 1989) are available for $ 35.00 each. Virus Bulletin states the following policy due to its editorial content: "Copies will only be sent to bona fide professionals. We reserve the right to request additional evidence concerning the subscriber's job function. Copies will not be mailed to private addresses without verification." ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 112] ******************************************

---

E-Mail Fredric L. Rice / The Skeptic Tank