VIRUS-L Digest Friday, 31 May 1991 Volume 4 : Issue 94 Today's Topics: Re: Software Upgradable BIOS (PC) What is DOD? Re: Interesting advert (PC) Re: VIRUSSUM format (PC) noint virus (PC) Re: MS-DOS in ROM (PC) F-Driver.SYS and QEMM (PC) Network World Article (PC) Re: Tequila virus (PC) Re: Dead vs Live: Commercial Necessity?? (some philosophizing added.) re: FSP and sales figures (was: Into the 1990s) AIDS Information Trojan (PC) re: Addendum to FLU_SHOT+ Product Test (PC) re: In the past year... (PC) 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, 30 May 91 13:24:00 +1000 From: U5434122@ucsvc.ucs.unimelb.edu.au Subject: Re: Software Upgradable BIOS (PC) walker@aedc-vax.af.mil (William Walker C60223 x4570) writes: > Here's something that should make the anti-virus community cringe. > Intel has announced a chip which would allow users to upgrade their > BIOS using a floppy disk. The term I saw was "erasable programmable > read-only memory (EPROM)," > [bits deleted] > It does make sense to simplify the BIOS field upgrade, but to do it > using something as transient as software in this day and age probably > would not be wise. More logical would be a small cartridge, not > unlike an HP font cartridge, which can be changed without having to > open the case. Sure, it would be more expensive up front, but > compared to the possibility of a "BIOS resident" virus, it would be > much less expensive overall. The same type of thing could be used for > a ROM-based DOS cartridge, which could have a switch that selects > booting from cartridge or disk, much as Krishna E. Bera suggests. I have to agree that software changeable BIOS is a scarey thought, but an alternative to the 'catridge' idea would be the imposition of a hardware switch which permits BIOS writing. The update program could request the user to 'Press the button marked BIOS and hold it down until the update is finished.' Probably not as reliable as the 'BIOS cartridge', but still, it is a thought. Danny ------------------------------ Date: Thu, 30 May 91 16:07:36 -0500 From: Mac Su-Cheong Subject: What is DOD? Dear Netters May someone please give me information on DOD Computer Security Center ? Is it possible to get reports or papers of DOD ? Thanks in advance. MSC - --- Mac Su-Cheong nckus089@twnmoe10 msc@sun4.ee.ncku.edu.tw ------------------------------ Date: Thu, 30 May 91 15:52:00 +0300 From: Y. Radai Subject: Re: Interesting advert (PC) Kenny Stevenson writes: >Just read an interesting ad in Personal Computer Magazine, April 1991 >VNU 404, page 135. It seems that most of us can now sleep easy if the >claim made in this advert is true - what will all you EXPERTS do ?! ..... >Vaccine anti-virus system - "Vaccine is virus-non specific detection >software. It uses cryptographic checksums to monitor the state of >executables on a PC or file-server. Any change, however caused will >be detected. Since Vaccine does not need to know about particular >viruses in order to detect them, it is future proof. Once installed, >Vaccine will detect all viruses, past, present and future." ..... >Comments welcome ! (and I can't imagine that there woun't be some) There is absolutely nothing new in this ad. There are zillions of checksum programs for the PC which claim to do the very same thing. However, there are three things to note: (1) They cannot distinguish between an actual viral infection and (say) replacement of an old version of a program by a new one; this is left to the user to decide. (2) The vast majority of such programs cannot really catch *all* infec- tions because DOS has loopholes which the authors of these programs are unaware of. (3) This method only *detects* infections after they have occurred; it does not prevent or remove them, so there's still a wee bit left for the "experts" to do. Actually, there is one such program, V-Analyst, which goes a long way toward solving all three problems: (1) It can distinguish between the above two situations in *most* cases. (2) It checks for three loopholes and takes the necessary measures. (3) It contains a *generic disinfector* which, when a modification is detected, will attempt to restore the file to its original condition. If the modification is due to a virus, it can do this in the great majority of cases (regard- less of whether the virus is known or unknown). Moreover, there is never any danger of its performing an incorrect restoration. (Features (1) and (3) are available only in the new version 3.0, not yet offi- cially released.) I'm willing to bet that Vaccine doesn't come anywhere near this. Padgett Peterson to Kenny:: >Question: when does it go resident ? If from CONFIG or later, you know > my opinion. Answer: Who says a checksum program has to go resident at all?? Most checksum programs I know of (incl. Vaccine and V-Analyst) can (or must) be run without going resident. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ Date: Thu, 30 May 91 11:36:37 -0400 From: padgett%tccslr.dnet@mmc.com (Padgett Peterson) Subject: Re: VIRUSSUM format (PC) Mikael Larsson writes: > > From: Guillory@farwest.FidoNet.Org > > > > Other people may have beaten this to death but I propose that Patricia > > Hoffman change her VIRUSSUM.DOC to something similar to PC Virus Index > > (PCVI305.zip) by Dan McCool and Brian Clough. >I disagree with this because that means that You can only access the >database on a given computer platform. The VIRUSSUM.DOC should remain >in pure ASCII given the benefits of being able to read it from >whatever machine your using. For what its worth, the individual virus files in PCVI305 are in ASCII, it is the selector/viewer that is a program. Since I automatically filter VIRUSSUM and reformat with form feeds after each listing so that it goes into a loose leaf easily, I have felt for some time that this would be nicer and allow "updates" monthly rather than having to download/print the whole thing each month. Telco fees can add up. The only problem with such a flat file arrangement (access can be very fast) is that it takes up a lot of disk space (200 viruses @ 2k per cluster = 400k - smaller on floppy of course). The big thing to remember is that VIRUSSUM is copyrighted material and Patricia has put a lot of effort into it. Her decision on whether it exists at all is final. Warmly, Padgett ------------------------------ Date: Thu, 30 May 91 11:50:00 -0500 From: LEAVITDG@splava.cc.plattsburgh.edu Subject: noint virus (PC) If anyone has info on the noint virus I'd appreciate a copy. I do remember one posting recently, but I did not keep it. thankyou in advance. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Darrell G. Leavitt SUNY Empire State College (ESC) ESC VAX: DLEAVITT 403 Sibley Hall SUNYNET: SESCVA::DLEAVITT Plattsburgh, New York, 12901 INTERNET: LEAVITDG@SPLAVA.CC.PLATTSBURGH.EDU PHONE : (518) 564-2837 AMATEUR BitNet : LEAVITDG@SNYPLAVA PACKET: N2IXL @ KD2AJ.NY.USA.NA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------ Date: Thu, 30 May 91 11:47:13 -0400 From: padgett%tccslr.dnet@mmc.com (Padgett Peterson) Subject: Re: MS-DOS in ROM (PC) "William Walker C60223 x4570" writes: >We're writing from two different premises. Padgett is writing about >MS- DOS actually running from ROM, while I'm writing about the DOS >files, and the boot disk itself, being in ROM ( a ROM-disk, as opposed >to a RAM-disk ). ... The method of booting from >a ROM- disk ( with an infection-proof boot sector and system files ), >which I wrote about, is not implemented at this time, to the best of >my knowledge. While I follow the premise better now, what you are talking about is what I referred to in the third option - somehow swapping ROM addresses for RAM addresses or possibly a "page frame" approach such as used for expanded memory. It will take a special BIOS driver to accomodate just like a RAM-disk requires a special driver and the data areas will have to stay resident somewhere. The point is that there are a finite number of addresses available and if some are used for ROM then there are that many less for RAM unless some extra memory management scheme is used such as that used for "shadow RAM" on 386s - not difficult but requires a few extras. The point I was trying to make was that even with this type of mechanism, the same holes exist in MS-DOS as did before. Some have been moved (e.g. the first attackable point) so that specific malicious software will be thwarted, but the hole still exists and will just be exploited in the next crop. There is still NO integrity management in MS-DOS. Warmly, Padgett ------------------------------ Date: Thu, 30 May 91 09:02:00 -0800 From: Michael_Kessler.Hum@mailgate.sfsu.edu Subject: F-Driver.SYS and QEMM (PC) Yesterday I re-optimized my memory allocation on a Zenith 386-SX because it had lost 2K of memory. As it ran through the process, the Stoned virus was detected, and the system froze, as it should have. However, the station had been used on and off several times since its infection, with no detection by f-driver.sys (ver 1.15A), and I suspect that the reason for this is that it had been loaded into high RAM by QEMM when running OPTIMIZE. I do not recall reading anything about this in the F-PROT documentation. MKessler@HUM.SFSU.EDU ------------------------------ Date: Thu, 30 May 91 15:08:14 -0600 From: rtravsky@CORRAL.UWYO.EDU (Richard W Travsky) Subject: Network World Article (PC) The May 27th Network World has a nice article on viruses and networks/lans. It talks about how viruses have progressed from an annoyance to a major problem (surely news to everyone here), quoting a study by Certus International where 50% of 2500 selected sites (with 400 or more micros) had reported problems with viruses. Lans are stated to be a major conributor to the spread of viruses. The section of the article of some interest to me was a test of 21 virus scanning packages conducted by the NCSA. An accompanying chart shows the percentage of detection by the packages against 921 viruses. Here's how the rankings went (only 15 of the 21 were reported for some reason): Package Percentage of Viruses Recognized ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ F-Prot V. 1.14A 92% Sophos, Ltd. Vaccine V. 4.23 91% Solomon Software Toolkit 4.25 89% Thijssen HTScan 1.12 78% Thijssen HTScan 1.11 73% McAfee Assoc. Pro-Scan V. 2.01 73% Symantec Corp. Norton AntiVirus V. 1.0.0 72% WorldWide Software, Inc. Vaccine 3.0 70% Microcom, Inc. VPCScan V. 1.1A 69% IBM VirScan V 1.3 66% EliaShim Microcomputers ViruSafe 3.06/7 63% McAfee Assoc. Pro-Scan V. 1.4 62% Certus International Corp. V 2.1 61% EliaShim Microcomputers Inc. ViruSafe 3.05 57% IBM VirScan V 1.0 25% Hopefully there are no typos. I just report 'em, the interpretations are your job. Some of these packages I've never heard of. Towards the end of the article they spend a few paragraphs talking about SiteLock and its virus protection features for lans. Richard Travsky Division of Information Technology RTRAVSKY @ CORRAL.UWYO.EDU University of Wyoming (307) 766 - 3663 / 3668 ------------------------------ Date: Thu, 30 May 91 17:20:01 From: microsoft!c-rossgr@uunet.uu.net Subject: Re: Tequila virus (PC) >From: mrs@netcom.com (Morgan Schweers) > However, what I meant by >'psuedo-encryption' is a situation in which the METHOD is different >each time. For example, the Tequila uses XOR *OR* ADDitive >encryption. This is more than one form of encryption, so in referring >to the entire group I call it psuedo-encryption. The same with the >Whale, etc. It could also be called variable encryption if you wish. Hmmm. Interesting definition. I use "variable encoding" to indicate that something in the virus is designed to thwart scanners: variable "NOP" type instructions, that kinda stuff. I use "encryption" to indicate that the code has been mangled in some form, regardless of how many methods a given program uses. That would make Tequila a "variable encoding encrypted" virus, I guess. Pain in the butt, in any case. > Actually, if you are using five bytes to search for the virus, >and someone else is using 15 (interspersed with a few wildcards), is >it automatically to be assumed that the wildcarded one is going to be >less specific? Do you have any statistics behind it? That is too obviously backwards to require stats and is not what I was implying. Of course having 16 bytes with no wild cards *should* be more specific that 16 bytes with wildcards. > There is also a second trick, used by some. When the file is >detected as almost certainly being a virus, the decryption method is >used on a portion of the file. That portion is compared against a >standard, known block of code. If a match ISN'T made, the file is >ignored. Yeah, we use that for 1260 and Caspar and a coupla others. Another pain in the butt, frankly. Maybe I'm just getting burned out in the anti-virus arena and would rather be scuba-diving... Ross ------------------------------ Date: Thu, 30 May 91 17:53:09 From: microsoft!c-rossgr@uunet.uu.net Subject: Re: Dead vs Live: Commercial Necessity?? (some philosophizing added.) >From: mrs@netcom.com (Morgan Schweers) > > Goodness, the personality conflicts alone [in the AV field] >would make for an >wonderful novel, then we add in the hysterics of the commercial side >of the business... Of course, a fictional bar scene with all the >principal players would be...frightening. I picture these ten people >suddenly realizing who else is at the bar, and the temperature >dropping twenty to thirty degrees suddenly. *grin* Other patrons >diving for cover, and huddling behind tables suddenly. Yupyup... For >an industry this size, there's been a lot of backstabbing and >slandering, etc. Morgan, your drinks are on me at this bar! You've certainly said a mouthful. I'm amazed at the animosity between the various people in the field. To our credit, the majority of "outsiders" think we're all good buddies. Ross ------------------------------ Date: Thu, 30 May 91 18:23:56 From: microsoft!c-rossgr@uunet.uu.net Subject: re: FSP and sales figures (was: Into the 1990s) >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) >>... it should give different >>"seeds" for each system. I recall that discussion and that I felt >>(and still feel!) it's a good idea, but a tech support nightmare. >Doesn't have to be, Enigma-Logic's product uses a different "seed" for >each machine that is entered once by the user at installation time & >is never encountered by either user or tech again. >Also, about a year ago, we discussed a matrix method for a sinple checksum >algorithm to be produced on the fly. If the seed is entered by the user, then there might well be problems of getting "pre-installed" copies within an organization that al share the same seed. Just as an example: one site license on FLU_SHOT+ pre-installed it on about 300 machines. Just by chance the installer was running DOS 4.01 on his machine, everybody else was running DOS 3.3. Obviously, the checksums on the system files and COMMAND.COM were different and I got umpteen tech support calls on the "problem". Now, this was a major problem because of installation done beforehand. Imagine my problem if each checksum was altered slightly with a different seed? Unless they tell me the seed (or I play games to derive the seed), I have a major tech support problem. And if they have the seed stored on the system anywhere -- sorta required in order for it to work! -- then the bad guy can find it just as easily as my own code can. It buys the end user nothing, in my opinion, but causes a major support headache. Hey! Didn't I say that on the other side of the album or last year? >Anti-Viral software should now be in its third generation: >1) Initial design >2) Take care of exceptions & annoyances >3) Make it "user-friendly" Actually, I think each of those phases are sorta endless loops. Lots of changes in the next cut of my code due to enduser feedback, responding to competitors, etc. >To me "good enough" is a product that will detect any change to a system >or authenticated file that is unauthorized without flagging. At the same time >actions that are authorized for a product will be passed without challenge. >I haven't seen any yet though some come close. If you want RACF on a PC, you'll have to change operating system, I think. It looks like you're speaking of authenticity and access control -- these must be considered important *parts* of an anti-viral package. But not the whole thing. >I will make a stab at some targets: Forgive me if I "stab" you back? > 1) Simple to install - should only give user opeions that are based on > the machine in question. Pre-installed products will have a problem as mentioned above. Many sites don't want to install each package individually on individual machines. > 2) Should recognize incompatable products Once advised, sure. Until then...how does one know? This will always be a one-version-off problem. > 3) Should be robust enough not to require program updates unless new > features are added. Simple data files updates of new signature strings > should be all that is necessary See the compatability problem you mention above. A bug has to be fixed and not all compatability problems can be determined at release time. As for virus scanners: my first product in the arena used a brute force method of scanning, back when I had about 50 strings. I have about 500 now. The same technique would have you waiting ten times longer. One method was quite appropriate a year ago, a different one now. Once DOS 2.x ruled the earth, but lots of dinosaurs get extinct. Upgrades are required in many cases, says this mammal. > 4) Each machine should have a different algorithm if only a unique seed. See above. > 5) Must make provision for routine mainenance (defrag, etc.) while > maintaining functionality Difficult to maintain system integrity there while doing "dangerous" things, though. But agreed. > 6) Must be easy to remove for troubleshooting Hey, *my* code never needs to be removed! > 7) Must recognize ANY change and be smart enough not to bombard the user > with notices when authorized. Should be user selectable, allowing a sys admin (even on a PC!) to determine just how "loud" an alert should be. >Unfortunately, I know of many mainframe packages that do not meet these >criteria. Yeah, RACF. Remember: this is not your father's Oldsmobile... Ross ------------------------------ Date: Fri, 31 May 91 00:40:44 -0700 From: mcafee@netcom.com (McAfee Associates) Subject: AIDS Information Trojan (PC) Does anyone recall whatever happened to Joseph W Popp, the alleged mastermind behind the AIDS Introductory Information Trojan Diskette? Apparently he was arrested in late February or early March of 1990 on charges of extortion and blackmail, but I have not heard anything since. Was he convicted? Were the charges against him dismissed? If anyone could mail a reply it would be appreciated. Aryeh Goretsky McAfee Associates Technical Support ------------------------------ Date: Thu, 30 May 91 17:53:09 From: microsoft!c-rossgr@uunet.uu.net Subject: re: Addendum to FLU_SHOT+ Product Test (PC) From: Chris McDonald ASQNC-TWS-R-SO >ADDENDUM for Product Test PT-27, May 1991, subject: FLU_SHOT+ > Several days after transmitting PT-27 for FLU_SHOT+ the author >sent me an electronic message, also posted to Virus-L, informing me >that version 1.82 was now available. The author also advised me that >the "free" demonstration copy of Virex-PC would no longer be included >with FLU_SHOT+. Actually, to be more specific, it will merely be removed from the .ZIP file. It will still be available for download from my BBS and from other sites -- including SIMTEL-20, since I'll be loading it to Keith directly henceforth. And, please, take the quote from the word "free"? It really is free - it merely forces you to wade through some screens of advertising. It will still be distributed on the disks of registered FLU_SHOT+ owners. > While I was aware that a version 1.82 was available, I chose >to limit my comments to version 1.81 because I had access to it >through simtel20. As mentioned in the product test analysis, I have >never received any official notification of FLU_SHOT+ upgrades even >though I am a registered user. While INTERNET is usually faster than >U.S. postal channels, it was not fast enough in this instance. I'm working on simulataneously releasing code to SIMTEL-20 along with other sites so that this confusion doesn't happen again. As for postal notification: please send me your snail mail address for confirmation? If I'm sending out 50K+ pieces of mail, I'd sure like to make sure that they're actually being received! > The "free" Virex-PC demonstration is now available at many >locations to include simtel20 in the path: Thar ya go again with them quotes, dagnabit! It really is free. No hidden charges, no auto-decrement on your wallet or anything. > I apologize for any inconvenience. Me, too. Ross ------------------------------ Date: Thu, 30 May 91 18:23:56 From: microsoft!c-rossgr@uunet.uu.net Subject: re: In the past year... (PC) >From: "David.M.Chess" Microcom tech support in Virex-PC reports: 1. Stoned 2. Jerusalem (with varients) 3. Disk Killer/Ogre (yeah, surprised me, too!) 4. Joshi 5-10. Cascade, Fumanchu, Sunday (yeah...see 2., above), Yankee (and varients) Ping Pong, Ghostballs. My own tech support for FLU_SHOT+ shows: 1. Jerusalem (with varients) 2. Stoned 3. Joshi 4. Ping Pong 5. everything else. Ross ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 94] ***************************************** Downloaded From P-80 International Information Systems 304-744-2253