VIRUS-L Digest Thursday, 30 May 1991 Volume 4 : Issue 93 Today's Topics: VSUM Format (PC) Re: Hard Disk R/W errors (PC) Re: Software Upgradable BIOS re: FSP and sales figures (was: Into the 1990s) Re: Chinese Bomb (PC) Followup to my STONED problem (PC) In the past year... (PC) Wildcards (Was: Re: Tequila virus) (PC) Re: Question About Stealth Viruses Re: MS-DOS in ROM; Re: NVMs (PC) Re: Hoffman Summary & FPROT (PC) Re: Virus-Buster (PC) virii vs System 7.0 (Mac) Re: Dead vs Live: Commercial Necessity?? (some philosophizing added.) 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, 29 May 91 15:55:27 +0200 From: Mikael Larsson Subject: VSUM Format (PC) Posting this message from a friend that will soon get an own account! ***** > 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. This file comes with an > executable portion and separate datafiles for each virus. > This is a well written program that is easy to use. 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. If the demand rises someone will write a program to access VIRUSSUM.DOC on any platform, just as I am currently doing for the PC:s with my VSUMBROW program. Regards /Jonny Bergdahl FidoNet: 2:204/503 VirNet : 9:463/101 BBS: +46-36-121323 Virus-L Digest => VirNet echogate Rgds, MiL Virus Help Centre Phone : +46-26 100518 Box 7018 Fax : +46-26 275720 S-81107 SANDVIKEN BBS : +46-26 275710 (HST) SWEDEN FidoNet : 2:205/204 VirNet : 9:461/101 SigNet : 27:5346/108 Email : vhc@abacus.hgs.se ------------------------------ Date: 29 May 91 14:20:32 +0000 From: rich@ersys.edmonton.ab.ca (Richard Hempsey) Subject: Re: Hard Disk R/W errors (PC) DUG@CZHETH5A.BITNET (Schwegler Ralph) writes: > Hello, > > When i first switch on my computer, my HD (Seagate SR-238) works well. > But after some minutes, there are many R/W errors. I am using DOS 3.21; > i have low level formated my HD as a SR-238R HD, with Seagate's > Diskmanager. > > I could not find a virus, either with f-prot 115 or scan 77. If i list > the TSR, there is a 3120 bytes long file labelled ?. > > Could that be the cause of the harddisk problems ? > > Thanks for your advices. > > Ralph Schwegler, student at University St.Gallen for Economics (CH). > E-Mail : 89611628@csghsg54.bitnet / 89611628S@gamma.unisg.ch The problem might simply be thermal expansion of the platter in the drive. As the drive warms up, the platter expands, and the heads are now mis-aligned. I had the same problem with my Miniscribe 8438. A very simple cure: I never turn my computer off! Well, except for thunderstorms... If you have to turn the computer off, then boot from a (clean, of course!) floppy, and wait for the computer to warm up before using the hard drive. Suggestion: Buy a copy of Spinrite II and use it regularly. Best $80 I ever spent. (I am in no way affiliated with Gibson Research, just a satisfied customer) Richard Hempsey at ersys!nowhere!rich@nro.cs.athabascau.ca or rich@ersys.edmonton.ab.ca or ...!alberta!aunro!ersys!nowhere!rich - ----------------------------------------------------------------------- "If my theory of relativity is proven successful, Germany will claim me as a German... Should my theory prove untrue... Germany will declare that I am a Jew." - Albert Einstein ------------------------------ Date: 29 May 91 08:15:00 -0500 From: "William Walker C60223 x4570" Subject: Re: Software Upgradable BIOS Vergil William de Comyn ( decomyn@phoenix.css.tek.com ) writes: > Intel is planning on using Flash EEPROM technology, but, as I > understand it, with a twist -- The user will have to explicitly > activate the reprogramming function by pressing a button, flipping a > switch, or some similar physical function. It's good to know that they are tying the BIOS upgrade to hardware in some way. One interesting feature of this would be that knowledgeable users could make BIOS patches rather simply; and it would make bug fixes easier. One drawback would be that pirating of the upgrades would be easier, which may end up making the upgrades more expensive. I still think there's too much inherent risk in it (my opinion), and would prefer a ROM BIOS (also my opinion). Also, I find fault in the logic behind one of the reasons for making an upgradable BIOS: "to get the full benefit of a CPU upgrade" (no, I don't find fault with the benefit itself -- read on). This is in reference to the newer machines which have a replacable CPU on a little card. Glenn Henry, Dell's VP for marketing, says, "You can run your old 386 BIOS with a 486 upgrade card, but you'll pay a performance penalty unless you install a fully coded 486 BIOS." If you're gonna have the case open to replace the CPU, how much trouble would it be to replace the ROMs while you're at it? For that matter, why not design the replacable-CPU system so that the BIOS is on the replacable card, to automatically upgrade the BIOS too? Cost shouldn't be a factor, since compared to the cost of the machine and the CPU upgrade itself, a ROM BIOS upgrade would be inexpensive. One last thing before I shut up. I wrote: > > The term I saw was "erasable programmable > > read-only memory (EPROM)," but more likely the actual technology > > in the chip is EEPROM (electrically erasable programmable ROM) or > > EAROM (electrically alterable ROM). and Jeroen. W. Pluimers wrote: > From what I understand this is quite common, most ROM BIOS > manufacturers use EEPROMS which can be repogrammed when you have: > a) the new EEPROM image (on disk or as an (EEP)ROM) > b) and EEPROM programming device that can program that kind of EEPROM > c) a very strong UV lamp to erase a programmed EEPROM EPROMs are erased by UV light and are programmed from disk or ROM with a programming device. EEPROMs ( ELECTRICALLY erasable programmable ROMs ) are not UV-erasable, and a programming device is not used to program them (normally). They are erased by a signal on one of the leads, and are reprogrammed in place in the circuit. EAROMs operate similarly. That's the whole idea behind Intel's plan -- to reprogram them in place in the PC from software, to save having to remove and replace them. Anyway, I've said probably more than my share on this, so I'll hush ("...and there was much rejoicing." -- Monty Python) 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: Wed, 29 May 91 12:32:46 -0400 From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: re: FSP and sales figures (was: Into the 1990s) >From: microsoft!c-rossgr@uunet.uu.net >... 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. >Not quite. However, a real dog of a product that simply doesn't work >is, eventually, gonna be found out and will have zero sales volume. The hooker here is "eventually". Besides, few products don't work at all and the first indication the poor sap who bought it may not come until he gets hit by something that is not caught or a manager finds out what it costs to update the software periodically on 5000 PCs. Anti-Viral software should now be in its third generation: 1) Initial design 2) Take care of exceptions & annoyances 3) Make it "user-friendly" but, except for those who are very deep into the subject, it is difficult to determine the "exception" cases and which products have the third generation look but skipped the second. I know of at least five software packages and several BIOSes & disk controllers that will give a good integrity checker fits (second generation problems) but have not seen any advertising by anti-viral products that give me a "warm" feeling. In the last month, I have returned two different Windows word processors to their respective manufacturers, one because it thought WordStar 4.0 was the last version (5.0 came out in 1988), another because the driver I had to use for my Panasonic printers (Windows doesn't list any Panasonics) caused the second to produce pure gibberish on the screen. These are second generation problems. >It's tough to decide on what determines the relative quality of a >product, though: if a scanner does 500 viruses and scans your disk in >two minutes and another scanner does 600 viruses and scans your disk >in three minutes, which one is a "better" product? Does making it >pretty, with a cool/spiffy GUI make it a "better" product? Consider quantum economics: first the process must be "good enough". Then linear comparisons become important. A minute is lost in the noise to a tech checking out a problem. If it occurs every time a user loads a file, it is liable to be noticed. 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. I will make a stab at some targets: 1) Simple to install - should only give user opeions that are based on the machine in question. 2) Should recognize incompatable products 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 4) Each machine should have a different algorithm if only a unique seed. 5) Must make provision for routine mainenance (defrag, etc.) while maintaining functionality 6) Must be easy to remove for troubleshooting 7) Must recognize ANY change and be smart enough not to bombard the user with notices when authorized. Wish list: program privilege (e.g. rwe) interpreted and enforced by the program manager. Unknown programs have no privilege. Disk access enforcement is easy. Memory access enforcement is more difficult (but possible with 386 or good memory manager hardware). We will probably not be there until every new program is distributed on non-volatile media (e.g. notchless floppies) with authentication documentation, certification that what was received was what the manufacturer meant to send out, and a list of specific permissions the package requires. Unfortunately, I know of many mainframe packages that do not meet these criteria. ------------------------------ Date: 29 May 91 17:21:40 +0000 From: nolan@helios.unl.edu (Michael Nolan) Subject: Re: Chinese Bomb (PC) ADMN8621@RYERSON.BITNET (Larry Anta) writes: >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.) There was a story on the radio this morning about a 'BEIJING' virus, set to go off on the 2nd anniversary of the Tienimen Square Massacre. The story went on to imply that this virus is on hundreds of thousands of computers all over China. (I didn't know there *were* hundreds of thousands of computers in China...) Is this related? Michael Nolan nolan@helios.unl.edu ------------------------------ Date: 29 May 91 13:40:36 +0000 From: aeshq!harry@uunet.UU.NET (Harry Pulley) Subject: Followup to my STONED problem (PC) Last night I used scanv72 on my floppy (the one that gave me the famous message in the first place). It was in the boot sector! I had heard that scanv76 was buggy, but I thought that STONED was an old enough virus that it would still be able to detect it. Oh well, a few hours were wasted scanning floppies with v76 -not a big loss. I will take home a copy of v77 today. N.B. this system was at home, not in a gov't building (we only run UNIX in my project, so I don't think we have the right to use scan/clean/etc...). Thanks for any replies, I'm still interested in the way that STONED works. [Ed. There's a great description (IMHO) of the Stoned virus available for anonymous FTP on cert.sei.cmu.edu. The file name is stoned.descript.lawrie and it is in the pub/virus-l/docs directory. The description was written by Mike Lawrie (ccml.rures@f4.n494.z5.fidonet.org) - Thanks Mike!] Harry. ------------------------------ Date: 29 May 91 14:59:55 -0400 From: "David.M.Chess" Subject: In the past year... (PC) Below is a list, in roughly descending order, of the PC-DOS viruses that we've actually seen in real-life incidents in the past year (to eliminate "one-off"s, and try to get just the important ones, I've only listed the ones that we've seen and verified in at least three incidents over the past year; this technique of data-reduction is open to modification!). I'd be very interested in similar lists from other folks, especially if there are significant differences. The population that we see reports from, as we've said before, is heavily weighted towards Fortune-500 companies and suchlike, but has some of everything. I've only counted incidents in which we were able to get a sample and verify (by hand, or with a CRC-based automatic verifier) that it really was that virus; I'm not counting "I've heard that Wuga is widespread in the Arctic" or "my cousin ran a virus-scanner, and it said he had the GaBooo virus, so he formatted his hard disk" sorts of reports. (I'd appreciate it if other folks who are kind enough to make their lists available would indicate whether they're using similar standards for what to count.) Here are ours. 28 different viruses (I've folded together the 1813 and one tiny variant of it, that we call 1813-00). Note that the slope is very steep here; the Bouncing Ball accounts for fewer than one-third as many incidents as the 1813. Stoned (Marijuana) 1813 (Jerusalem) Bouncing Ball (Ping-Pong) JOSHI Yankee Doodle-2885 (TP44VIR) 1701 4096 (Frodo) 1704 Sunday Dark Avenger Vacsina (TP05VIR) TP16VIR Slow Form Brain Keypress Flip-2153 Plastique (Anti-CAD) Disk Killer 1575 Microbe Liberty Yankee Doodle-2772 (TP39VIR) 5120 (VBASIC) Ohio Anarkia 1381 (Internal Error) Is everyone else seeing similar things? DC ------------------------------ Date: 29 May 91 21:21:02 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Wildcards (Was: Re: Tequila virus) (PC) David Chess wrote: 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... Ross Greenberg wrote: We'll have to agree to disagree on this one, Dave. Well, tend to agree with David - I use wildcards in 15% or so of my search patterns - but only in the following cases: 1) When the pattern contains a reference to an address outside it. Example: : MOV AX,CS:[some_address_elsewhere] : or : JNE a_fairly_long_distance : 2) When the pattern contains an instruction which depends on the assembler used - Example: XOR AX,AX ; 31 C0 XOR AX,AX ; 33 C0 I have some variants of viruses where the only difference is due to this. Variable-length wildcards are in my opinion an absolute no-no...I never use them. For the viruses using the most complex types of encryption (Whale, Tequila, V2P2 and Adolph) I use an algorithmic approach, not a search string. I also try to avoid search patterns for viruses written entirely in a high-level language. - -frisk ------------------------------ Date: 29 May 91 21:34:02 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: Question About Stealth Viruses 76476.337@CompuServe.COM (Robert McClenon) writes: > I have a question, or probably a series of related questions. Can >someone please explain exactly what "stealth" viruses are? Is there a >standard definition of what characteristics make a virus a "stealth" >virus? To qualify as a "stealth" virus a virus must: A) Make any increase in file length disappear when a user checks an infected file while the virus is active. Viruses which do not change infected files ("companion viruses") are not included, nor are overwriting viruses. The "Number of the beast" virus is considered to be a stealth virus. B) Intercept any operation to read from an infected file or an infected boot sector, and make the virus code "disappear" by returning the original program. Whether this is done by actually disinfecting programs when they are opened for reading, or just by modifying the read buffers is irrelevant. According to this definition, "Brain" is a stealth virus, for example. > I have read that they delete themselves from the hard disk and hide in > memory when they are active. Totally incorrect. Some "stealth" viruses disinfect programs when they are read, so it is possible to remove them by simply giving a command like COPY *.* NUL: in every directory containing executable files, but this is certainly not an universal solution. - -frisk Fridrik Skulason Technical Editor of the Virus Bulletin (UK) (author of F-PROT) E-Mail: frisk@rhi.hi.is Fax: 354-1-28801 ------------------------------ Date: 29 May 91 16:10:00 -0500 From: "William Walker C60223 x4570" Subject: Re: MS-DOS in ROM; Re: NVMs (PC) A. Padgett Peterson ( padgett%tccslr.dnet@mmc.com ) writes: > ... > The answer is that while all of MS-DOS is used, part of it is only > necessary for start-up. Once these segments are complete, the memory > occupied by structures like SYSINIT is released back into the free space > for re-use just like when an application is complete, the space occupied > is reuseable by the next program. With ROM this is more difficult. > ... and I wrote > ... > If the [ MS-DOS in ] 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.). > ... > It would provide SOME protection from viri, in that the DOS files > themselves, being in ROM, would be immune from infection. > ... 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 running MS-DOS from ROM, as Padgett states, is currently used by some laptops, and also by some diskless LAN- stations and third-party boot cards. 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. Mr. Peterson and I are not arguing the point ( at least I hope not; sorry if it seemed that way, Padgett ), but we're presenting two different answers to the same question. Each method has its advantages and disadvantages, and each may be applicable in different situations. Since this may indeed be an ongoing discussion, I thought it necessary to point out the differences in our solutions. Oh, BTW, Michael A. Maxim ( mmaxim@sc9.intel.com ) writes: > If some board maker actually > wanted to enable software modification to the BIOS EEPROM, there is no > reason that he couldn't do it; but that is a problem with the board > and manufacturer, not the chips. I had originally questioned the security of using EEPROMs and a software- upgradable BIOS, not the EEPROMs themselves. I had merely used Intel's announcement as a starting point for my discussion, and I apologize if I seemed like I was being critical of the chips or the technology. 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: 29 May 91 21:38:47 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: Hoffman Summary & FPROT (PC) rtravsky@CORRAL.UWyo.Edu (Richard W Travsky) writes: >I have the March 17th P. Hoffman virus summary in front of me and >something has attracted my notice: The version of FPROT she refers to >is version 1.07. The current release is 1.15A and 1.16 is due out in >June. Due out in just a few days..actually - as soon as I have finished analysing the 100+ new viruses I have received the past couple of weeks. >Any reason why such an old version is used? Well, I wish I knew - I always send her the latest versions... - -frisk ------------------------------ Date: Wed, 29 May 91 22:18:55 +0000 From: act@softserver.canberra.edu.au (Andrew Turner) Subject: Re: Virus-Buster (PC) phan@latcs1.lat.oz.au (Trieu B Phan) writes: > Has anyone ever used that(Virus-buster). > It seems strange to me,I have installed it on my PC and after I >reboot the PC is hang,I have to use a bootdisk to turn on. > Any ideas,please drop me a line. While this is not a 'plug' for Virus Buster I am concerned that such a simple statement as above could be seen as negative for what is, among the several anti-viral packages on the market, a basically good product. Furthermore Leprechaun Software, who market Virus Buster, are very approachable and will readily assist all users. I note that the poster is a down under person and thus can readily avail himself of this facility. FLAME OFF. Each of the anti-virals has its pros and cons - none are a 'complete' solution. We successfully use Virus Buster on student access PC's and are most happy with the results. DISMOUNT SOAPBOX. I will e-mail Triu B Phan and see if he can be helped. - -- Andrew Turner act@csc.canberra.edu.au Die, v: To stop sinning suddenly. -- Elbert Hubbard ------------------------------ Date: Wed, 29 May 91 20:19:11 +0000 From: geoffb@eleazar.dartmouth.edu (Geoff Bronner) Subject: virii vs System 7.0 (Mac) I recently had the pleasure of working with a hard disk running under System 7.0 which had been infected with the nVir A and B viruses. Disinfectant was able to remove the viruses without any problems once another disk was used as the startup disk. What was interesting to note however was what had been infected. Several applications including Microsoft Word had been infected (which is not surprising) but so had several Control Panels. Under the new system cDevs and DA's and such can be accessed like applications and it appears the nVir viruses are fooled into infecting them like applications as well! One other note. The virus was caught with a regular check and the workstation had shown no unusual behavior so nVir didn't appear to be causing problems. Has anyone else observed this kind of behavior under System 7.0? - -Geoff - -- geoffb@eleazar.Dartmouth.EDU Alpha Theta House Historian "Don't believe the hype!" -Public Enemy ------------------------------ Date: Wed, 29 May 91 12:32:46 -0400 From: Padgett Peterson Subject: Re: Dead vs Live: Commercial Necessity?? (some philosophizing added.) >From: mrs@netcom.com (Morgan Schweers) >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. Doubt it, I recall a bar in SEA in which automatic weapons had to be checked at the door, handguns were OK. > (A side and sad note... It is not us, the anti-viral researchers, >who will kill the viruses once and for all. It's the OS writers who >will finally produce an OS which supports the protections a machine >needs. It's the users who will finally leave this damned MS/DOS >troublemaker behind. THAT is when viruses will vanish, slowly but >surely, and then we can all have a beer together and laugh about the >nonsense of having to clean up behind Microsoft.) Unlikely that DOS will disappear, it is too much a part of the culture, just like the English language and SAE screw threads. However, nothing is stopping DOS from introducing anti-viral measures and self-checking boot sectors & MBRs. The key is in preservation of the applications and hardware. It is just not going to be in 5.0. Warmly, Padgett ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 93] ***************************************** Downloaded From P-80 International Information Systems 304-744-2253