VIRUS-L Digest Tuesday, 28 May 1991 Volume 4 : Issue 90 Today's Topics: Re: Tequila virus (PC) Re: Virus Statistics Hoffman Summary & FPROT (PC) Re: Tequila virus (PC) VSUM Format (PC) Question About Stealth Viruses Re: Software Upgradable BIOS (PC) MS-DOS in ROM (PC) DISKSECURE 95 (PC) Re: "Horse" Virus Family (PC) Delta virus (PC) Review of SafeWord Virus-Safe (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, 23 May 91 16:39:24 -0400 From: Padgett Peterson Subject: Re: Tequila virus (PC) Ross: It would be interesting if you, Frisk, & I ever get together at a bar but they'll have to provide a padded room & unbreakable glasses. >From: microsoft!c-rossgr@uunet.uu.net >>From: mrs@netcom.com (Morgan Schweers) >> >> *Chuckle* It's a variant of the Flip virus, actually. A bit of >>psuedo-encryption code was added, and a bit of infection code was >>removed, but otherwise it's mostly flip-like. >Interesting phrase, "psuedo-encryption". What, exactly, does it mean? (Can't help myself, this is too much like "mock-swedish") Given that encryption covers both codes (breakable) and cyphers (less so), it would follow that a "pseudo-encryption" is neither a code nor a cypher but looks like one. EBCDIC & BAUDOT would probably fall into that category as would the raw output from most word processors. For that matter, a DEBUG U(nassemble) of a Master Boot Record) is gibberish to one who does not understand the conditionals but makes perfect sense once the constraints are understood. The output from a "Little Orphan Annie Secret Decoder Ring" would not be "pseudo" since it produces a real (though trivial) code. >Sorry: I don't count "wild card" strings as a search pattern. There's >too much chance for false positives. Why do you disagree with "wild cards"? For example, if I find a boot sector that contains MOV AX,[413] MOV [413],AX I would suspect a virus reguardless of what went on in the area. To me a variable length "wild card" to replace would be very useful in this case. I agree that the potential for false positives exists, but as an intial mechanism that determines a maxterm/minterm decision tree structure or to provide a public signature without revealing to much of the viral design, such a "wild card" function would be very effective. Warmly, Padgett ------------------------------ Date: Thu, 23 May 91 18:32:18 -0600 From: rtravsky@CORRAL.UWyo.Edu (Richard W Travsky) Subject: Re: Virus Statistics I've often wondered if anyone was keeping track of viral infections. Myself, I've wondered about the geographic spread (as in, a [new] virus shows itself here, then here, and then there). Would make some pretty plots, like the spread of killer bees ;) For the record, before last fall my site, the University of Wyoming, did not appear to have much in the way of virus activity - at least, none that anyone bothered to report to us. And also for the record, the two we have now are Stoned and Ping Pong (Ping Pong appears to be confined to the Law College - read in to that what you will! ;). A while back, Jerusalem put in an appearance, but it did not apparently spread. I've a couple of unconfirmed reports that MusicBug is in town (via FTP is what I've heard). I'm sorta curious about factors facilitating virus spread. The closest town to us is about 50 miles away - physically. Electronically, well, ftp makes for a small world. Our school size is about 10,000. What else might be pertinent? Perhaps a profile could be drawn up? +-----------------+ Richard Travsky | | Division of Information Technology | | University of Wyoming | | | | RTRAVSKY @ CORRAL.UWYO.EDU | U W | (307) 766 - 3663 / 3668 | * | "Wyoming is the capital of Denver." - a tourist +-----------------+ "One of those square states." - another tourist Home state of Dick Cheney, Secretary of Defense of these here UNITED STATES! ------------------------------ Date: Thu, 23 May 91 18:38:19 -0600 From: rtravsky@CORRAL.UWyo.Edu (Richard W Travsky) Subject: Hoffman Summary & FPROT (PC) 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. Any reason why such an old version is used? Richard Travsky Division of Information Technology RTRAVSKY @ CORRAL.UWYO.EDU University of Wyoming (307) 766 - 3663 / 3668 ------------------------------ Date: Thu, 23 May 91 20:45:22 From: microsoft!c-rossgr@uunet.uu.net Subject: Re: Tequila virus (PC) >From: "David.M.Chess" > >.... 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... We'll have to agree to disagree on this one, Dave. Ross ------------------------------ Date: 23 May 91 09:23:37 From: Guillory@farwest.FidoNet.Org Subject: VSUM Format (PC) kuhnle@ait.physik.uni-tuebingen.de (Volkmar Kuhnle) writes: >But over the months al lot of new viruses (and strains of existing ones) >have been uncovered, so that VIRUSSUM.DOC grew in size. Since the >current version is about more than 500 K in length, is is getting >harder and harder to find informations about a special virus in >a file of this size, since I have to use a normal editor. > >I came to the conclusion that an ASCII file is not appropriate for the >distribution of so much data. Therefore I would suggest to supply >future versions as DBF files (dbase format). 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. ------------------------------ Date: 23 May 91 23:21:40 -0400 From: "Robert McClenon" <76476.337@CompuServe.COM> Subject: Question About Stealth Viruses 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? If not, what are the alternate definitions? I have read that they delete themselves from the hard disk and hide in memory when they are active. If so, can't they be disinfected by simply powering off the workstation? If not, exactly what are they doing and how? I apologize if I am wasting the time of some readers, but I assume that there are others who also want to know this. Robert McClenon Neither my employer nor anyone else paid me to ask this. ------------------------------ Date: 24 May 91 05:38:55 +0000 From: decomyn@phoenix.css.tek.com 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)," but more likely the actual technology in >the chip is EEPROM (electrically erasable programmable ROM) or EAROM >(electrically alterable ROM). 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. Fortunately, since no forseeable virus technology will allow the little beasties to reach out and press a button, I don't believe there is that much to worry about in this technique. (I hope :-) >Bill Walker ( WALKER@AEDC-VAX.AF.MIL ) | >OAO Corporation | >Arnold Engineering Development Center | "I'd like to solve the puzzle, Pat" >M.S. 120 | >Arnold Air Force Base, TN 37389-9998 | Brendt Hess a.k.a. | Disclaimer: Opinions? I don't even work here! Vergil William de Comyn a.k.a. |----------------------------------------------- Payne Hirds | Life is not a zero-sum game: decomyn@phoenix.css.tek.com | don't treat it as such. ------------------------------ Date: Fri, 24 May 91 11:15:57 -0400 From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: MS-DOS in ROM (PC) I can see that some background is going to be necessary as this looks to be an on-going discussion. Firstoff, starting MS-DOSs not a single file, it is a collection of files, all of which are used yet not all of which remain resident. These include IO.SYS, MS-DOS.SYS, and the familiar COMMAND.COM. Even in DOS 3.3, probably the most common version, a little examination will reveal that these three files take up around 150k bytes on the disk. Next, if you look at the interrupt table and BIOS data structures, you will that another 3k are occupied before DOS ever starts. Yet on a 640k machine, there is about 595k free space left with a bare DOS loaded. This means that only about 45k of low memory is in use when the C:\ prompt appears (& no TSRs are loaded. Obviously this doesn't add up, where did the other 100+k go ? Part of it is in the transient part of COMMAND.COM loaded into the TOM (top of memory) but COMMAND.COM is only about 25k so even if all were transient, we would still have 85k or over half of MS-DOS unaccounted for. 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. Thus, while the permanent portion of MS-DOS is ROMable, the transient half must use one of three choices: 1) Keep on volatile disk & map in and out of RAM as is done now. 2) Place in ROM & reduce free memory space (high memory above segment C000 could be used but with the proliferation of memory managers to load TSRs "high", for many users today this would have the same effect as to reduce free "low" memeory. ROMed laptops generally use this technique. 3) Add circuitry to map in ROM to available address space & remap to RAM when done ($). The hooker is that the data areas (interrupt table, BIOS data, DOS data) MUST remain in RAM or undergo major structural changes (2k of CMOS is a possibility), and these are the areas that viruses generally attack. Unfortunately, in the case of many popular applications (1-2-3, Windows, etc.) these would also have to be rewritten to accomodate the new structure (see Apple III, LISA, Mac 128, DEC Rainbow & DECMATE for the effects of such changes/differences). Additionally, as AZUSA has demonstrated, even if the data was moved to CMOS it would still be attackable, just differently. Another problem would occur if the ROM were to "glitch", how would maintenance be performed ? A BIOS "switch" could be added, but we have these available in BIOS now from a few vendors, but the general public does not demand it. Also maintenance can take many forms: about once a week I boot from a floppy to perform defragmentation, backup, & compression since some of the 121k of TSRs loaded high are incompatable with this kind of operation (one of the first additions to DISKSECURE was the ability to create a boot floppy for this reason) and most users do not want to have to rename their CONFIG.SYS & AUTOEXEC.BAT before rebooting. It has been stated that ROM could be inexpensive. True, in production quantity the cost is less than a dollar, but take a look at BIOS upgrades with much less code than MS-DOS that are holding at about $70 for the two-chip set. The point has been made that MBR infectors such as the STONED would become obsolete since the MBR and supposidly the Boot Record would become mere tables. However, in this case, the first executable becomes CONFIG.SYS instead of the MBR. We would just see a "new" breed of infectors - like many "new" viruses today just a few changes would be necessary. Of course, it would depend on the implimentaion also, just to use the STONED again, the fact that it is so widespread has nothing to with any MS-DOS requirement: MS-DOS does not "require" hidden sectors, all versions will run without any. Yet most MBR & Boot Record viruses depend on them because they are usually there. If they weren't, the method used by the earlier BRAIN and attempted by the MusicBug would be much more widespread. Again: there is nothing basically wrong with MS-DOS (and DR-DOS) that has caused the incredible spread of viruses other than the total lack of integrity checking, something that can be easily corrected in the BIOS or by a BIOS extension. Putting MS-DOS in ROM will not itself reduce the risks, it will just transfer some holes for others while necessarily leaving most wide open. Warmly, Padgett Only a third of a good program's code is needed to accomplish its function the other two-thirds is to accomodate user's mistakes. ps very few viruses actually change any executable code belonging to DOS the common ones just change pointers that must be alterable to point to themselves or map themselves into executed volatile storage locations by reading (or knowing) the pointers. - app ------------------------------ Date: Fri, 24 May 91 13:13:11 -0400 From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: DISKSECURE 95 (PC) To those of you who have requested copies, I had wanted to get it out this week since Ken was nice enough to send the source to XXENCODE *however* my Fiero developed a cold in the alternator (the first symptom was when I took the key out of the ignition, the A/C blower kept running - try troubleshooting THAT). Having never seen the alternator, I consulted the service manual which told me where it was & to remove wires, two bolts, & the fan belt then "remove from bottom". Right. Also disconnect engine strut, rear suspension, remove right rear wheel, assorted brackets, splash shields, & the oil filter, mostly by feel. At 2 a.m. I saw the alternator. Just like writing software. In any event, am now a little behind & with the Muscle Car Nationals just up the road a bit this weekend, will probably not get to it before Monday but the requests are all in my "todo" bin. RSN. Warmly, Padgett "Somewhere West of Orlando" ------------------------------ Date: 25 May 91 09:02:39 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: "Horse" Virus Family (PC) I wrote: >> Horse (Hacker, Black horse) family: William Walker C60223 x4570 writes: >To further reduce naming confusion, might I suggest calling this >family the "Hacker" family ("Hacker-1," etc.) to avoid confusion with >Trojan Horses. I considered this, but decided to use the name "Horse" instead - the author, Martin Harizanov, uses the handle "The Horse", and there is already another virus known as "Hacker" (alias "Ohio") as well as one known as "Superhacker" (alias "Jerk"). Using "Hacker" would just increase the confusion, instead of reducing it. - -frisk ------------------------------ Date: Sun, 26 May 91 15:23:47 -0400 From: Alex Lopez-Ortiz Subject: Delta virus (PC) More than 50 of oour PC's (at the National University of MExico) have caught this virus who alters the partition table of the hard disk, trashes files that were to be saved, disallows booting from the hard disk, and copies itself or generates a file called Delta.com which is hidden and unerasable. Does anybody knows of any vaccines against it? Alex ------------------------------ Date: Thu, 23 May 91 11:54:27 -0700 From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: Review of SafeWord Virus-Safe (PC) I believe there was a recent announcement by Bob Bosen of version 2.0, but he has had this review for over a week now and I haven't heard anything back. Comparison Review Company and product: Enigma Logic Inc. 2151 Salvio Street, #301 Concord, CA 94565 USA Tel: (415) 827-5707 FAX: (415) 827-2593 Internet: 71435.1777@COMPUSERVE.COM SafeWord Virus-Safe release 1.12 (900831) Summary: Change detection software. Cost: not stated Rating (1-4, 1 = poor, 4 = very good) "Friendliness" Installation 3 Ease of use 4 Help systems 3 Compatibility 3 Company Stability 3 Support 2 Documentation 2 Hardware required 4 Performance 3 Availability 2 Local Support ? General Description: SafeWord (R) Virus-Safe 1.12 is a manual or TSR program file checking package based upon signatures which the program calculates when installed. Signature algorithms can include a DES or MAC based calculation. Enigma Logic makes similar programs for various mini and mainframe operating systems. As suggested by this association and the documentation, Safeword is best used in a managed environment. The package is, however, simple enough to give significant protection to a naive user. [Ed. Due to its size, the remainder of this review has been placed in the anonymous FTP archives on cert.sei.cmu.edu (IP#=128.237.253.5) in pub/virus-l/docs/reviews under the filename slade.virus-safe] ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 90] ***************************************** Downloaded From P-80 International Information Systems 304-744-2253