VIRUS-L Digest Thursday, 23 May 1991 Volume 4 : Issue 89 Today's Topics: re: Tequila virus (PC) re: MS-DOS in ROM? (PC) Chinese Bomb (PC) Virus-l archive et al Anti-viral approaches (PC) Re: Tequila virus (PC) PKZ120.EXE trojan? (PC) "Horse" Virus Family (PC) RE: MS-DOS in ROM; RE: Software Upgradable BIOS (PC) re: PKZ120.EXE trojan? (PC) Re: Into the 1990s Unidentified virus? (PC) Re: Into the 1990s (ref IBM-type PCs) re: Product Test, Flu_Shot+ (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: Wed, 22 May 91 17:19:17 From: microsoft!c-rossgr@uunet.uu.net Subject: re: Tequila virus (PC) >From: "David.M.Chess" >While I know what you mean, Ross, I'd like to clarify for our readers: >the Tequila doesn't actually seem to share any code with the 1260 or >Virus-101 (no evidence that the author of the Tequila had seen either >of those), and a scanner that can handle variable-length "don't care" >areas can detect it with no problems. DC Whoops! You're write! I should right better and knot make so many misteaks! :-) I have an abhorrence for wild-carded scan strings -- too many false positives -- so I tend to not include them. I ended up going algorithmically on the Tequila in any case... Ross ------------------------------ Date: Thu, 23 May 91 09:54:00 +1200 From: "Mark Aitchison, U of Canty; Physics" Subject: re: MS-DOS in ROM? (PC) padgett%tccslr.dnet@mmc.com (Padgett Peterson) writes: >>From: "Krishna E. Bera" > >>Is there any effort underway to produce a ROM version of MS-DOS... > Not that I am aware of though several laptops have attempted this. yes there is; DRDOS 5.0 has been ROMable for about a year, and it seems MSDOS 5 will available in ROM as well. It is a good idea (even though I doubt it was planned as an anti-virus measure), but there are some popular simple virus methods it won't help against. The great benefit would be, I think (I haven't actually tried it though): (a) Viruses that change not the interrupt vector but substitute a jump at the start of the original code would be stopped, as would viruses that change specific locations inside specific versions of DOS to hook in virus code. (b) Viruses that modify executables (assuming all DOS utilities are in ROM) (c) Viruses that add new .COM files with the same name (assuming all directories in the path, and the current dir, are in ROM also) (d) Boot Sector & MBR viruses (again, with reasonable assumptions about the implementation) What this leaves is a few loopholes like blatently reducing the TOM or changing interrupt vectors, that are relatively easy to spot. > The major problems would be: > 1) Hardware is always more expensive than software to produce The cost of ROM chips is amazingingly cheap - most motherboards have empty ROM slots. Even if it needs an extra card with some fancing hardware for paging in and out large amounts of ROM (a la EMS), the cost of the card is likely to be small compared with modern costs of operating system software. The problem is that most people don't "see" the cost of the DOS because it is either lumped in with the cost of the hardware, or pirated. Software in ROM can be cheaper because the manufacturer doesn't need to charge more to get over half of the users not paying for the product. > 2) Would make it difficult to upgrade So long as it is a good product, like MSDOS 3.3 or DRDOS 5, people tend to stick with one version of operating system for a long time - long compared with the time before they wish they had a newer BIOS, for example. This is true for enough people to make it worthwhile; besides, the cost of the chips is very very small (say $10). > 3) Would provide no protection from viruses - too many popular programs > and peripherals rely on tailoring the BIOS (e.g. hard disk controllers) > MBR (e.g. FDISK), and DOS (most TSRs) in approved methods. Unfortunately > many of these methods can also be used by malicious software. The MBR need only contain the partition table - it need never be executed. A TSR or virus can't make "sneaky" hidden changes to DOS, they must result in obvious effects like changes to vectors, memory allocation, etc. The only worry would be a virus that targets specific TSR's. > 4) Undocumented necessities (such as necessary to use a CD-ROM or NETWARE). > 5) "Bug" fixes would be much more expensive. You would want to change the DOS fairly infrequently, but I dodn't see a big problem there. Perhaps some Digital Research bod could answer how CD-ROMS or NETWARE work in the ROM version of DRDOS, but I guess such things are possible. Of course, another option would be for a 386 CPU to manage memory so that it is as good as ROM - or possibly better (with IO trapping?), except for the time while it is loading the DOS, and so vunerable. In fact, a virus that makes full use of a 386 to protect itself would be very worring - perhaps enough added to teh BIOS to protect that stage would be the answer. Mark Aitchison, Physics, University of CAnterbury, New Zealand. ------------------------------ Date: Wed, 22 May 91 10:53:27 -0500 From: Larry Anta Subject: Chinese Bomb (PC) The following message appeared on one of our IBM PCs: VP 9z U( 5/ ---- C h i n e s e B o m b ---- ( Made in China 1989 ) C:\WORD> C:\WORD> According to one of our technicians, the hard disk was "trashed" at that point. (He says he had to format it.) Any help would be appreciated. (McAfee's SCAN V75 comes up clean.) ........................................................................ : Larry Anta, Data Security Officer Toronto Ontario CANADA M5B 2K3 : : Ryerson Polytechnical Institute Voice- (416) 979-5000 Ext 6797 : : Room S-341 350 Victoria Street Bitnet-ADMN8621@RYERSON : '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ------------------------------ Date: Thu, 23 May 91 12:43:25 +0100 From: David.J.Ferbrache Subject: Virus-l archive et al As a few of you may have noticed the archive service at Heriot-Watt University is no longer operational. This is due to a lack of disk space in the Computer science department, coupled with a change of employment on my part. From mid-July I will be leaving Heriot-Watt University to begin a new job which includes a remit to evaluate the security threat posed by computer viruses and to implement a range of suitable protective measures. This should permit me to take a far more active (and hopefully informed) role in this mailing list. My apologies for any inconvenience caused by the temporary closure (Again!!) of the archive site. Back soon. Dave Ferbrache ------------------------------ Date: Wed, 22 May 91 17:19:17 From: microsoft!c-rossgr@uunet.uu.net Subject: Anti-viral approaches (PC) >From: Padgett Peterson >For basic protection, almost all of the anti-viral software on the >market is adequate, just like few people take more than basic >protection from being stung by a wasp. More is considered >contra-productive & is an accepted risk in working in a garden. When >it happens, it is annoying but remedies are at hand. If everybody made backups, I'd be out of business. >To me, seven people stand out in this area ... >... not because they are necessarily wonderful people, meetings can >be explosive, but because they have made available to the public >information and programs specificaly designed to combat viruses as >shareware/freeware, not the best way to squeeze the last dollar out of >the public. Hey, I *am* a wonderful person, too! Now, I'm currently trying to squeeze as much money from the public as possible. Fortuneately, I code better than I market... Ross ------------------------------ Date: 23 May 91 10:56:12 -0400 From: "David.M.Chess" Subject: Re: Tequila virus (PC) >From: microsoft!c-rossgr@uunet.uu.net > >Sorry: I don't count "wild card" strings as a search pattern. There's >too much chance for false positives. But, true, if you don't mind the >occasional false positive, I guess you could state that a search >string was available for Tequilaa. A string with wildcards isn't necessarily more prone to false positives than one without, as long as there are enough additional fixed bytes in the one with wildcards to make up for the extra degrees of freedom added by the wildcards. I think? Any sort of less-than-virus-length scan string is somewhat prone to false alarms, but ones with wildcards, if properly chosen, aren't necessarily any worse than ones without... DC ------------------------------ Date: Thu, 23 May 91 10:37:40 -0400 From: Padgett Peterson Subject: PKZ120.EXE trojan? (PC) >From: There was a "hacked" PKZ120 a few months ago. The one I recollect was just PKZ110 with the names & authentication codes changed. I would be surprised if a real version 120 exists (expect Mr. Katz will skip that number) ------------------------------ Date: 23 May 91 11:07:00 -0600 From: "William Walker C60223 x4570" Subject: "Horse" Virus Family (PC) Fridrik Skulason ( frisk@rhi.hi.is ) writes: > The names below are the names Virus Bulletin will use in the next issue, > where the viruses are listed - hopefully this list (which I plan to post > monthly) will help reduce the naming confusion a bit. > ... > Horse (Hacker, Black horse) family: > Horse-1 (1154) > Horse-2 (1158) > Horse-2B (1160) > Horse-3 (1610) > Horse-4 (1776) > Horse-5 (1576) > Horse-6 (1594) > Horse-7 (1152) > ... To further reduce naming confusion, might I suggest calling this family the "Hacker" family ("Hacker-1," etc.) to avoid confusion with Trojan Horses. Some people refer to Trojan Horse programs simply as "Horses" instead of Trojan Horses or Trojans. Bill Walker ( WALKER@AEDC-VAX.AF.MIL ) | OAO Corporation | Arnold Engineering Development Center | AEDC -- Home of the "Chicken Gun" M.S. 120 | Arnold Air Force Base, TN 37389-9998 | ------------------------------ Date: 23 May 91 11:08:00 -0600 From: "William Walker C60223 x4570" Subject: RE: MS-DOS in ROM; RE: Software Upgradable BIOS (PC) Padgett Peterson writes: > Subject: re: MS-DOS in ROM? (PC) > The major problems would be: > 1) Hardware is always more expensive than software to produce Definitely. > 2) Would make it difficult to upgrade I'm not so sure. If the ROM upgrade is on a cartridge (similar to HP fonts), upgrading would involve swapping cartridges, which could also contain the other DOS-related files (CHKDSK, EDLIN, etc.). As it is now, upgrading DOS on a hard disk involves doing SYS and copying COMMAND.COM and the other files to the hard disk. Also, as I have found too many times, users have copied some of the DOS programs all over their drive rather than one location, and following a DOS upgrade, they call in with an "Incorrect DOS version" error. Swapping cartridges would be quicker and easier, and would eliminate "straggler programs." > 3) Would provide no protection from viruses - too many popular programs > and peripherals rely on tailoring the BIOS (e.g. hard disk controllers) > MBR (e.g. FDISK), and DOS (most TSRs) in approved methods. Unfortunately > many of these methods can also be used by malicious software. It would provide SOME protection from viri, in that the DOS files themselves, being in ROM, would be immune from infection. Also, since the remainder of the BIOS is also in ROM, it is immune as well (I'm aware of peripherals adding BIOS extensions, but not "tailoring" the existing BIOS). However, once in RAM, anything is fair game, and other program files on disk would not have the benefit of ROM protection. > 4) Undocumented necessities (such as necessary to use a CD-ROM or NETWARE). Items such as CD-ROMs have ROM BIOS extensions and/or drivers loaded by CONFIG.SYS. DOS in ROM would not affect their operation, so long as the boot process accessed the ROM extensions and used a user-modifiable CONFIG.SYS and AUTOEXEC.BAT. However, non-DOS executables stuck in CONFIG.SYS and AUTOEXEC.BAT would still be prone to infection if run from a disk. Netware, on the other hand, is a different puppy. Netware in ROM would be impractical, since it would have to be customized to each specific configuration, and there is a HUGE variety of configurations. I suppose it would be possible to produce a Netware kernel in ROM, but because so much configuration-dependent stuff would be left in software, it would probably be better to leave it all in software. > 5) "Bug" fixed would be much more expensive. Yes, indeed. But if DOS in ROM was on a handy cartridge, containing UV-erasable PROM, the old cartridges could be returned after an upgrade or bug-fix to be erased and reused by the manufacturer, thereby reducing costs. He also writes: > Subject: Software Upgradable BIOS (PC) > ... > if the hardware designers do their job. A EEPROM requires a special signal > on one lead to tell it to write. If that lead is under hardware control and > accessable only with the case open and a special plug in place that disables > everything except a "load & verify BIOS" program, risk can be minimal. Exactly. If the BIOS upgrade is tied to hardware control of some kind, then there's little problem. If it's COMPLETELY under software control, however, what's to prevent a virus author from writing a virus which can simulate a software BIOS upgrade? The whole idea that Intel has is to eliminate the need to open the case or do some complex hardware operation. A ROM cartridge still seems to be the better way to go; besides, how many times does one upgrade the BIOS during the life of a machine? > The point is not to "protest" the concept, it sounds like a good idea, but > demand adequate safeguards (dare I say "standards") for its use. OK, so I was a bit extreme. But we do need to DEMAND those safeguards or a more secure alternative. > ("flew" some digitally controlled gas-turbine engines with 8080s at > Tullahoma in the seventies - Hi Bill) Everybody sing - "It's a Small World after all." :-) These are, of course, ideas and opinions, and are subject to comment, criticism, or whatever. Bill Walker ( WALKER@AEDC-VAX.AF.MIL ) | "If you were locked in a room with OAO Corporation | Saddam Hussein, the Ayatullah, and Arnold Engineering Development Center | a lawyer, but you had only two M.S. 120 | bullets, which would you shoot?" Arnold Air Force Base, TN 37389-9998 | "I'd shoot the lawyer twice." ( somewhere near Tullahoma ) | ------------------------------ Date: Thu, 23 May 91 10:45:00 -0600 From: Keith Petersen Subject: re: PKZ120.EXE trojan? (PC) SIMTEL20 does not now, and never has offered PKZ120.EXE. That file is bogus and PKWare has offered a reward for information leading to the person or persons responsible for its creation. This is very old information. There has been a warning in circulation about this for almost a year. It was posted to the net. The latest version of the program is: Directory PD1: Filename Type Length Date Description ============================================== PKZ110EU.EXE B 140116 900402 Katz's ZIP archive package v1.10, export vers. This file was obtained directly from PKWare on diskette. Keith - - - Keith Petersen Maintainer of the MSDOS, MISC and CP/M archives at SIMTEL20 [192.88.110.20] Internet: w8sdz@WSMR-SIMTEL20.Army.Mil or w8sdz@vela.acs.oakland.edu Uucp: uunet!wsmr-simtel20.army.mil!w8sdz BITNET: w8sdz@OAKLAND ------------------------------ Date: Thu, 23 May 91 12:38:42 From: microsoft!c-rossgr@uunet.uu.net Subject: Re: Into the 1990s >From: Y. Radai > > Among Ross Greenberg's points in his reply last week to Padgett >Peterson was the following: >>...[my discussion on FLU_SHOT+'s integrity checking] > Sorry, but I just can't pass over that without comment. Oh. It's *you* again. Just when I thought it was safe to go back into the water. > (No offense meant, Ross, but I'm sure it won't come as a surprise to >you if I mention that in my opinion, a good example of poor product >quality despite presumably good sales figures is the integrity-check- >ing feature of FLU_SHOT+. But since I've discussed FSP enough in the >past, I won't repeat my arguments unless someone asks.) To paraphrase your past arguments for the readership, I believe you commented that FSP's installation was such a pain in the butt that few people used the integrity checking feature FSP includes. You're probably right there, by the way. I would hope that *quality* of the product is not an issue. We might have some disagreements as to whether "fast 'checksumming'" is better or worse than "complex 'checksumming'", but that's a good debate to have in September during the Virus Bulletin's Seminar -- over a coupla beers, I hope. (Hey! Could you bring me a bottle of Macabee? Love it, can't get it here. Bring one for Ken, too!) Quality is an issue that the market does decide, I think. Effectiveness is something that may or may not be related to marketshare. But the market does not buy low-quality products (unless it comes from my competetion, of course. :-) ). They may end up buying slicker *quality* products than less slick quality products, though. >>Resident integrity checking, and access control, is a worthy goal of >>any of the anti-virus products. However, remember that it can and >>*will* be circumvented the first time somebody boots off a floppy. > > That does not have to be true; details in a couple of weeks. This I look forward to hearing more about. Typical security that would prevent this would be either a)playing with the partition record, easily circumvented by a decent disk editor or b)encryption of the disk to prevent circumvention of a). I thought about crypting the disk and realized that I couldn;t afford the liability insurance..... Another option would be in hardware, one I'm starting to think more and more carefully about... L'itrot Ross ------------------------------ Date: Thu, 23 May 91 10:37:40 -0400 From: Padgett Peterson Subject: Unidentified virus? (PC) >From: ACDL004@SAUPM00.BITNET >This rebooting continued even when I was in Norton commander.. >I turned the system off and on again.. There were No problem at the >beginning.. But after 30 minutes( or so) It started rebooting as if >the reset button is pressed.. Sounds to me more like a marginal power supply. Try opening the case and running for a while and see if it changes (afer a thorough virus scan of course). 30 minutes seems to be a critical "warm-up" time when a power supply starts getting tired. ------------------------------ Date: Thu, 23 May 91 10:37:40 -0400 From: Padgett Peterson Subject: Re: Into the 1990s (ref IBM-type PCs) >From: Y. Radai >>Resident integrity checking, and access control, is a worthy goal of >>any of the anti-virus products. However, remember that it can and >>*will* be circumvented the first time somebody boots off a floppy. > That does not have to be true; details in a couple of weeks. Also agree with Mr. Radai. Hardware can block completely & software can detect (but not necessarily block) a cold floppy boot & changes. Both can control hot boots - . Both the hardware and the software exist but apparantly lack proper marketing (in defernce to Mr. Walker, development funds are finite & can be spent on marketing or development. Rarely is it split 50-50 [more like 100-0]). Will state again: Effective systems MUST start before DOS loads & do not have to be intrusive. Warmly, Padgett ------------------------------ Date: Thu, 23 May 91 12:38:42 From: microsoft!c-rossgr@uunet.uu.net Subject: re: Product Test, Flu_Shot+ (PC) >From: Chris McDonald ASQNC-TWS-R-SO >. The commercial firm is now Microcom Software Division which >markets Virex-PC. While Mr. Greenberg actually sold Microcom Flu_Shot++, not >Flu_Shot+, I was somewhat surprised when version 1.81 reached the repository i n >December 1990. This version came bundled with a demonstration copy of the >viral scanning capability of Virex-PC. Subsequent electronic communications >with Mr. Greenberg suggest that Microcom may view continued releases of >Flu_Shot+ as a commonsense marketing strategy to migrate users to their >commercial product. Yeah, FLU_SHOT++ got renamed to Virex-PC. I happen to *still* like the name of FLU_SHOT++ more, but offer me enough money and... Chances are good that future releases of FLU_SHOT+ (You're falling behind, Chris: Version 1.82 is out the door) will *not* include the bundle of the VIRX scanner. Bundling them together meaks it difficult to release one without the other and can create some auditing nightmares. Additionally, looking at people downloading from my BBS, everybody seems to download both the FLU_SHOT+ archive (which contains VIRX) *and* VIRX. By unbundling, the download time will be lessened (important on pay services) and the ability to update each independently of the other is enhanced. Microcom's permission to allow me to continue to enhance and release FLU_SHOT+ is a credit to their marketplace acumen, I think. Ross ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 89] ***************************************** Downloaded From P-80 International Information Systems 304-744-2253