Return-Path: Received: from IBM1.CC.Lehigh.EDU by abacus (SunOS 4.1/SMI-4.1-01) with sendmail 4.1/SMI-4.1-01 id AA09963; Fri, 22 May 92 04:56:50 +0200 Message-Id: <9205220256.AA09963@abacus> Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 4075; Thu, 21 May 92 22:36:16 EDT Received: from LEHIIBM1.BITNET by LEHIIBM1.BITNET (Mailer R2.08) with BSMTP id 0939; Thu, 21 May 92 22:35:58 EDT Date: Thu, 21 May 1992 22:26:40 EDT Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU Sender: Virus Discussion List Comments: Warning -- original Sender: tag was krvw@CERT.ORG From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V5 #108 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L Status: R VIRUS-L Digest Thursday, 21 May 1992 Volume 5 : Issue 108 Today's Topics: RE:Question about Michelangelo (PC) Re: Authentication of resident Anti-Viral programs (PC) "DIR" viruses (PC) F-PROT says suspicious file (PC) Vshield delays on boot (PC) Re: Clarifications... (PC) Re: COPS for Novell? (PC) (Novell) correction to infect. by DIR... (PC) Anti-viral defenses: Backup (PC) Re: Infection by DIR (PC) re: Help! Pain virus? slow system? CPAV infected? (PC) re: Infection by the DIR command (PC) re: Question re Tequila (PC) re: Can a virus survive being pkzipped or otherwise compressed? (PC) re: clock ram resident virus (PC) OS/2 2.0 questions. (OS/2) printers, riiiiiight Taxonomy of viruses BAD IDEA (was: Where can I find Virus signatures?) Call for Papers 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. (The complete set of posting guidelines is available by FTP on cert.sei.cmu.edu or upon request.) 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: Tue, 19 May 92 01:41:00 +0000 From: mccd@rosie.uh.edu (Reza Golshan ACUS 743-1587) Subject: RE:Question about Michelangelo (PC) ============================================================================ ==========> I have recently responded to a posting, regarding problems with ==========> Michelangelo & Stoned multiple infections. The following response ==========> was then sent to me which I found it necessary to comment on. >mccd@rosie.uh.edu (Reza Golshan ACUS 743-1587) writes: > >> The following is the information that we released after some >> modifications, for the University of Houston(Park) community on March/2/92. > >The information is not quite correct, see below. > >> If your IBM_PC(compatible) is being infected by both the Michelangelo >> and Stoned, a reinfection by the Michelangelo would make the Michelangelo's >> removal impossible. > >First, it should be mentioned that in this case the disk becomes >non-bootable and second, of course it is possible to remove the virus! ==========> I meant with what I had for DOS 3.0&up and DOS 4.0(Clean ==========> and Fprot), I could not remove the virus, without making the ==========> the disk unaccessable. My approach was to copy the files to ==========> another disk, and then fix the disk by using the utilities. >> At this stage, by using an antivirus software, the Michelangelo virus >> is then removed, which would be; >> >> [ EVENT ] [ AREA 1] [ AREA 2 ] [AREA 3] >> ***************************************************************************** >>* > >> Michelangelo Stoned Michelangelo nil >> Removal >> ^______________________________________________| > >It depends on the disinfector. With some extremely silly disinfectors, >which do not attempt to wipe out the virus code, the picture will be: > >>[ EVENT ] [ AREA 1] [ AREA 2 ] [AREA 3] >>****************************************************************************** >> >>Michelangelo Stoned Michelangelo Stoned >> Removal >> ^______________________________________________| >> >> Do not proceed with the cleaning of the Stoned at this point and it >> is highly recommended that you contact the Academic Computing User Services >> >Much faster is just to boot from the system DOS 5.0 diskette and to >run FDISK /MBR. This will remove the virus. ==========> Well the point in here is that not everyone is using DOS 5.0, ==========> and they are mostly(specially students), are using DOS 3.0&up and ==========> also 4.0 in some cases. The reason that I always ask people to ==========> call us is to make sure they would not make the matters worse. >> When the antivirus program is run again the Michelangelo would be >> detected, and removing Michelangelo would be refused by the antivirus program >> since there is no original bootsector to replace it. It is possible at this >> >Yes, if the anti-virus program is silly (but not extrememly silly). If >it is intelligent enough, it should be able to detect that no valid >master boot sector is present and to create one. ==========> I have always recommended the use of McAfee or the Fprot, since ==========> they have always detected the viruses for me for the past few ==========> years. However, if there is a recommendation for an anti-virus ==========> program which is not 'silly', I would be more than glad to try ==========> it. >> point that the disk would be beyond repair(Due to the possible loss of the >> file allocation table), however, if you are at this point, you may call the >> ACUS or the Administrative Computing for help. The SYS.COM can be used >> in this case in an attempt to transfer back the system, in addition to some > >If this is what the Administrative Computing is going to advise you, >forget about them. SYS.COM does not touch the MBR (where the virus is) >at all. ==========> Point well taken, but this was released in the beginning of the ==========> March and I could not come up with any better solution. Also ==========> the point of discussion groups like this is to 'exchange' ==========> information. I do not believe that anyone in here is trying to ==========> claim that he/she is a scientist. >> other procedures that might be necessary to take to recover the files. Those > >No need to recover the files, since they are not damaged. ==========> If someone could not access a disk, and DOS tells me that ==========> there is no harddisk present, then eventhough files ==========> are there I would not be able to 'see' them. This would be ==========> the case until I try to 'recover' them(and if it makes you ==========> happier, to recover the undamaged files) by using utilities ==========> like Norton and PCTools. >> procedures are beyond the scope of this briefing and should be handled by >> our consultants only. > >Just running DOS 5.0 FDISK /MBR will do the job. ==========> Again, as I have mentioned many people are using lower ==========> versions of DOS. When they call and ask for help, they ==========> would 'not' want to hear someone to tell them that they should ==========> have had upgraded, and since they have not, then they should ==========> suffer the consequences. ==========> The following is the original question which was posted: >> A friend of mine's machine recently stopped booting from the HD, so we >> ran scan, and it reported that he was infected by Stoned. We cleaned >> that, ran scan again, and it reported that he was bitten by Mich. We >> tried cleaning that, and even though clean reported that it was >> successful, upon rescan it was still there. Even Norton Anti-virus >> Michaelangelo didn't clean it correctly. Any explanations and >> solutions? > >The explanation was included in your message... Read it again. :-) And >your experience shows that NAV and CLEAN (at least the versions you >used) are silly programs for the reason explained above. > >Regards, >Vesselin ========================================================================== == Reza Golshan | <<<<>>>> == == University of Houston(Park) | <<<>> == == Academic Computing User Services |================================= == 36, Heyne Building | "A little more than kin, and == == Houston, Texas 77204 | less than kind." == == ph# (713)-743-1587; FAX: (743-1542) | Bill Shakespeare, Hamlet == ========================================================================== ------------------------------ Date: 18 May 92 23:47:56 +0000 From: jesse@gumby.Altos.COM (Jesse Chisholm AAC-RjesseD) Subject: Re: Authentication of resident Anti-Viral programs (PC) padgett@hobbes.dnet.mmc.com (A. Padgett Peterson) writes: : >From: "Norm J. Harman Jr." : >Subject: F-Prot & DATAMON (PC) : : > In general how can a user verify that the : >anti-virus software he/she has installed is actually operating as expected? : : This is something that I have had a number of discussions with various : vendors over the last year or so. At present I know that McAfee Vshield and : Roger Thompson's VirusBuster have this capability (as my products do of course : 8*). There may be others with this capability that I am not aware of. : : Usually such authentication is via a separate .COM or .EXE file that knows how : to find the anti-viral product in memory and will verify its presence. Just : how far this verification goes depends on the product. Obviously it could : range from trivial to very complex. : :... : : IMHO, such a capability is vital to the authentication of a machine from : a network server level on login (ref an equal number of comments reguarding : the virtues of client-server networks over peer-peer systems) Verifying its presence and activity in memory is an important first step. How can a user test to see if the software is doing its job? If they have been hit by a virus before, and saved an infected floppy, then this could be used to see if the anti-viral software can detect it on the floppy. I do not recommend that the typical user keep known infected floppies around, though. There was some discussion a while ago about a product (sorry, I can't recall its name ;-) that made files that "tricked" scanners into thinking they were infected with various viruses. This either gave the user warm feelings if the scanners did find all the bogus files, or scared their pants off if the scanner correctly ignored the bogus files. The question remains open: Is there any way for the typical user to know that whatever anti-viral product they are using is actually working? I fear the answer will be: "You gotta trust somebody!" Jesse Chisholm | Disclaimer: My opinions are rarely understood, let | tel: 1-408-432-6200 | alone held, by this company. jesse@gumby.altos.com | fax: 1-408-434-0273 |----------------------------- ======== This company has officially disavowed all knowledge of my opinions. - -- === Confucious say: "He who bowl perfect score need no time to spare." ------------------------------ Date: Wed, 20 May 92 08:31:15 -0400 From: padgett@hobbes.dnet.mmc.com (A. Padgett Peterson) Subject: "DIR" viruses (PC) From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) >2. If you have the ANSI.SYS driver installed and it allows keyboard >reampping, then a clever volume label of the diskette, containing ANSI >escape sequences could remap one of your keys (say, Enter or >Backspace) to start a single-character named program which might >contain a virus. Just a comment before everyone starts ditching ANSI.SYS & going back to white on black screens: a one byte change to ANSI.SYS (published it the last time we got into this) will make it ignore keyboard remapping but keep the rest of its features (I change the "p" to an unused character so remapping is still available, just different). Second, if ANSI is patched, the volume label of a disk "infected" this way will show up as a set of alphanumerics beginning with a "[" & ending with a "p". If a normal ANSI driver is used, such malicious software is still discernable to the wary since the volume label will show up as: "Volume in drive X is" followed by blanks instead of "Volume in drive X has no label". Finally, if the disk door is opened or the disk changed before striking the fatal key, all that will happen is that a "Not ready reading drive X" or "Bad command..." message will occur instead of an infection. Given all of the above, while ANSI bombs may go into the catagory of "Stupid PC Tricks", it is hardly likely to be effective for spreading viruses, something is going to get noticed too quickly. Now use of an ANSI bomb to trigger malicious software resident in a printer... Nah: there are easier ways involving weather stations. Warmly (90 today) Padgett ------------------------------ Date: Wed, 20 May 92 12:53:10 +0000 From: akugel@genius.tau.ac.il (Alexander Kugel) Subject: F-PROT says suspicious file (PC) Hi there ! I used FPROT203a to check my hard disk. When I used the Secure method, everything was OK. When I tried the Heuristic method, I got a report that I had a file that was "almost certainly virus-infected." It's a program from the x_USSR and I do believe that it might be infected by an unknown virus. Anyone interested ? I'm ready to send the UUENCODE'ed copy of that suspicious file. Here is the report from F-prot. >Virus scanning report - 20. May 1992 14:30 > >F-PROT 2.03a created 5. April 1992 >Virus signatures created 2. April 1992 > >Method: Heuristics >Search: C:\UTIL\MUSHROOM.* >Action: Disinfect/Query >Targets: Boot/File >Files: Standard executables > > >Analysing C:\UTIL\MUSHROOM.COM > >This program contains very suspicious code, which seems to have been >added to the end of the file. It is almost certainly virus-infected. > > >Results of virus scanning: > >Files: 2 (82 KB) (The second file is Mushroom.ovl) >Scanned: 1 (21 KB) >Infected: 0 >Suspicious: 1 >Disinfected: 0 > >MBR's: 1 >DOS boot sectors: 1 >Infected: 0 >Suspicious: 0 >Disinfected: 0 > >Time: 0:00 Alex. ------------------------------ Date: Wed, 20 May 92 09:20:49 -0400 From: padgett@hobbes.dnet.mmc.com (A. Padgett Peterson) Subject: Vshield delays on boot (PC) >From: st10m@rosie.uh.edu (Chacko, Finney T.) >Subject: Help! Pain virus? slow system? CPAV infected? (PC) Boy, this soul has really been the route. Asside from what appeared to be a real problem, he recounts nearly every case of anti-virus programs conflicting known. One item I can help with: >else..i think....i install vshield it scans memory on boot up and >everything seems peachy keen except when i press control-alt-delete it >takes a couple of presses to reboot WHY? the screen scrunchs up >before the sluiggish reboot also? why? This occurs for the reason my NoFBoot does the same thing, VSHIELD is trapping the ctrl-alt-del reboot sequence and making absolutely sure that there is not a disk in drive A:. The problem is while a disk in the drive will usually respond very quickly, there are some cases where it may not. The technical manual recommends that you check three times but to be sure may take five accesses in the cycle of: 1) Interrogate drive A. 2) Interrupt allows time for disk to spin up. 3) On failure, reset the disk controller. 4) Try again. This may take 5 or even 10 seconds on an old system - early 360k floppy drives are notoriously slow: the clue will be that the drive light is on. The screen "scrunch" may be because nothing is maintaining the display (mine just does nothing for a few seconds, when the screen blanks is the indicator that NoFBoot or Vshield has released the machine to the normal boot process). One thing NoFBoot and Vshield do differently is that VSHIELD triggers a cold (memory check) boot while I consider a warm boot adequate so I load NoFBoot after loading VSHIELD so my stuff handles the boot request. Incidently, repeating the "three finger salute" is just going to slow things down further. "Eternal vigilance is the price of peace" Warmly, Padgett ------------------------------ Date: 20 May 92 16:39:19 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Clarifications... (PC) (Note. Due to its huge volume, I had to split this message into several parts. Sorry for the inconvenience. Since this discussion begins to become non-interesting to the general public, I strongly suggest to my opponent to switch to private e-mail.) TYETISER@ssw02.ab.umd.edu (Tarkan Yetiser) writes: > > By "special" I meant that I was not able to find even -one- computer > > here in our VTC, on which the package would run without problems... I > Whoah! What do you guys use up there? Next machine? Or all hard drives > are compressed? We had little trouble at this part of the planet :-)) We are using all kinds of machines. PS/halfs, '386s, a few clones... (This is the MS-DOS department, the Amiga, Atari ST, Mac, and Unix people have the appropriate machines.) The DOSes are PC, MS, DR, Toshiba. Versions vary from 2.11 to 6.0. Some disks are Stackered, others are SuperStored (not all). Most machines (not all) are networked with Novell NetWare... Your program (out of the box) couldn't be used on any of the machines (as is), but I could combine the existing hardware/software in order to have a computer on which it did. > It was my personal bias against some setups that caused that response. > VDS 2.10 works even under MS Windows 3.1 without shelling out to DOS, Please don't forget that my initial comments concerned version 2.0 which was the only available at that time. Version 3.0 might invalidate all my remarks and be an excellent product, I don't know. I just reviewed what was available. > though we recommend it. The other day, one of our associates (advocate of > Win30) showed me the books on the shelves of a local book store's computers > section. Almost 1/3 was Windows stuff! It's catching on fast. I still do No, it just means that the wannabe Windows users must learn a lot... :-)) > not like Windows personally, but you're right, compatibility is > very important. We agree here (that Windows is crap, but compatibility is important). > > It's good that it refuses to run when non-installed; I don't object to > > that. However, it -does- try to run in the case I described and fails > Hmm. It should've displayed a message and then aborted, not hung up. Why aborted? The docs say that the scanner part -does- run uninstalled (and it should be so, of course, or how else are you going to scan before installation?). > Was it on a PS/2 by any chance? It was a 20 Mhz 386SX HIGHSCREEN notebook with AMI BIOS and a 40 Mb harddisk. > Not exactly partition-dependent. Let me put it this way. The device > driver tries to determine if the MBR, BR, etc. are modified. If so, it puts > a copy of the affected area in a file for further examination, then > attempts to recover. Oh, I see. There is a similar program (ShrDog) on our ftp site, but it is not a device driver... Well, how about the idea to put the information that is saved during the installation in an external data file (encrypted and with a file name selectable by the user during the installation process)? Then you mention in the documentation that this data file must not be moved across the machines and explain exactly why. Gives much more assurance to the user that s/he knows what's happening, instead of just scaring him/her... > If only the partition table is modified but not the > code, it will warn that it was not properly installed on that system. Of Nice! The program that is available here which I mentioned above, does not have this feature... (It also does not work under DR-DOS 6.0. Unfortunately, this is not my program and I don't have access to the sources, so I cannot fix it.) > course, this will miss an indirect BSI that only modifies the active > partitions entry. It will also miss a StarShip-like MBR infector (will just say that it needs re-installation), but this is non-essential, since as you say > But it will be caught on the second pass which checks the BR. > VDS.EXE is a little smarter. It actually tries to determine if the > partition sector matches the disk layout as indicated in the backup copy > of the MBR. If not, it does NOT attempt to recover, to avoid such damage, > and only posts a warning message. Very nice, as I said... Now why not explaining it in the docs? Sounds much better if I know what the program is doing and under which conditions exactly it might cause damage, instead of "if moved to another computer it might cause damage in some cases"... > > No, they are not totally wrong. They are even mostly correct. However, > > as I said, they contain several blatant claims which help the user to > > develop a false sense of secutity. Similarly to the advertisements > I disagree. The documentation tries to promote a sensible approach to > anti-viral security. It does not overemphasize the problem, not does it > underestimate it. Read what I said again. I reproche it the claims to "bypass any stealth virus" and be "the strongest anti-virus product". I could post here what's wrong in the whole documentation, but it will be a too long message, if I include the appropriate quotes. > Your example of people switching to VAXes because they had a bad > experience with a PC virus was not realistic. But an example of a PC infected only once in the beginning of the 2-year period by a well-known virus isn't... > they deal with the problem by running a scanner/cleaner (or even > formatting their drives), and then forget about it. This behavior still > puts them in Category 3 (4 is the highest risk), unless they did take a > more reasonable approach to protect their PCs. Yes, that's right, and the test should concentrate on this - depending only on scanners, using non-up-to-date scanners, etc. > > It does not to describe how the stealth viruses work. All it needs is > > to mention that it takes some measures to bypass the stealth viruses > > of some kinds and that this is not always successful, so better don't > It is more than that. It tries to give unexposed users an idea about > such beasts. The concentration in that section is not whether VDS bypasses > everything or not (though this is mentioned :-)). First, I made a silly typing mistake, as I often do. My paragraph that you quoted should read "It does not have to describe....". Second, I insist that it is fair to mention in the docs that not all possible stealth viruses can be stopped by the technique that you are using and that it is still safer to use the program after ensuring that there's no virus in the memory (i.e., after booting from a clean floppy). > > rely on it but always boot from a clean diskette when performing the > > check. > Such idealistic usage is not common. So we gotto do the next best > thing: try to come up with something that is secure enough even when run > from the hard disk, even when there's a stealth beast in memory. I know that it is not common. But nevertheless, the fair approach requires that you tell the user what is the safe way to use the program and that relying on anything else might be wrong. I do not reproach your usage of anti-stealth techniques; I'm reproaching your attempt to make the user rely on them and to make compatibility their victim. > the time. Cohen has a funny suggestion in his Bootstrapping paper about a > snapshot of memory state saved on a write-protected floppy. Theoretically, > it may be feasible, but in practice it won't work well. If it is not used, It is not only theoretically feasable. It is also implemented in his ASP Integrity Toolkit. True, it can be bypassed by a direct attack, but he clearly states this in the beginning of the paper that you are mentioning, right? > what good is it? Kind of like discretionary access control :-) Exactly! And how many of us will object to have in MS-DOS the kind of discretionary access control that Unix provides? True, it won't stop the viruses entirely, as Cohen has proved, but it would be a much better to have than the current situation, don't you think so? (to be continued...) - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Wed, 20 May 92 15:07:00 +0000 From: Andrew Koran <0003967939@mcimail.com> Subject: Re: COPS for Novell? (PC) (Novell) My comment is on the following question/answer in VIRUS-L V5 N106: > From: "Tarkan Yetiser" > > bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: > > > Is anybody aware of a Novell NetWare-oriented program to check the > > security of a Novell LAN? Like the usage of obvious passwords, shared > > directories left writable by several people, possible virus infection > > paths, etc.? Something like COPS does for Unix? And, if there is no > > such thing yet, don't you think that it's more than the time to create > > I think this should go to FAQ. Anyone familiar with Netware knows that > it comes with a standard utility called SECURITY that does such > checks.It is located in the SYS:SYSTEM directory. You can use the > following commandto capture such info in a file: > > SECURITY > weakness.txt The Novell utility named SECURITY is at best a simple tool. It will not as asked provide the checking of bogus /obvious passwords. This appears to be a gap that could be filled by a third party Novell utility or better yet Novell themselves. The utility as a whole needs to be replaced with a program with greater flexibility and supervisor options. I have had the same wish in regards to checking for obvious passwords. I would also like a utility that would do some stats on intruder lock-outs and user login/logout demographics. A utility that would be NLM and provide a complete user audit would be necessary. There is such a system available to bring military operated Novell systems to the required C2 security posture. IUll check on the publisher. Andrew A. Koran, HM2 USN Navy Drug Screening Laboratory Oakland, California ------------------------------ Date: Wed, 20 May 92 13:30:50 -0100 From: Genaldo Subject: correction to infect. by DIR... (PC) I was totally wrong when said that in my last note to this list that I had a VIRUS that would infect the hard drive after the DIR command. Was many people pointed out it is impossible. What I got indeed was the message "virus active in memory..." from the scan program. There is no way that piece of code in that buffer come to be executed unless somewhere the processor had a JUMP to that region in memory, which is impossible by the DOS DIR. Genaldo mtm1gln@brufsc.bitnet ------------------------------ Date: Wed, 20 May 92 14:50:39 -0400 From: padgett@hobbes.dnet.mmc.com (A. Padgett Peterson) Subject: Anti-viral defenses: Backup (PC) Recently we have seen several sources including Vesselin & Rob Slade commenting that the best means of viral defense is Backup - but who wants to sit there for an hour with hundreds of floppies ? Luckily, the same technology that makes backup a simple mater for servers is now filtering down to the individual PC level. Readers may realize that for some month I have been moving Superstor container files around on Bernoullis and hard disks (much to the horror of the Addstor people) and have been discovering that it is possible to back up 70+ Mb of programs in about six minutes using the DOS BACKUP program (more horrors) onto a 45 Mb Bernoulli (would hold more but that was all I had). Admittedly, the old Iomega RCD BACKUP routine is better since it provides a complete disk image backup (format a disk, don't bother with /s, RESTORE from a Bernoulli BACKUP, and you have a fully bootable, preconfigured disk) & is why my drivers are 4.81c (beta) rather than the latest 7.xx or the new stuff (open something...), they stopped putting in image BACKUP. But much as I would like to have a nice 90 Mb transportable at home, they do tend to be a touch expensive & @ over U$100 for a floppy disk (street price) are a bit dear. Recently, I have seen the One True Answer (for the moment) 20 Mb Flopticals. It handles 720k 3 1/2s, 1.44 Mb 3 1/2s, & 20 Mb (the mfg. calls them 21 Mb, Dos format says 19.85 Mb, CHKDSK says 20.3 Mb so take your choice). Whatever they are, at under $20/disk, full backups become very, very easy and cost effective. I can see quite a few other advantages to the things also - with a floppy disk shortage looming (thanks to windows) consider the advantage of being able to put a complete 25 disk OS/2 installation on one disk (with just a bit of compression). Every Windows app I know of could fit on one disk without compression. No more shuffling, just a straight XCOPY would work. Right now am considering one of those new sub-U$300.00 V-32bis modem/ FAX/Voice Mail/ANI cards in an old XT chassis, a floptical, and a batch of I/O ports as an integrated office machine & print server. Given a cheap 20 Mb floppy, lots of things become possible & why tie up a 386/486 for this sort of distributed task ? Of course, all is not sweetness and light. The major problem I have with the flopticals is that the Floptical Standards Committee (Insite, Iomega, Adaptec, etc.) has adopted a SCSI interface standard & not just a standard SCSI interface, but a special one that recognizes the floptical drive as a removable drive. If not, the drive firmware is designed to treat the disk as read-only. (May be software "correctable" but am not sure). This means that you cannot just plug one into a U$39.00 Seagate SCSI controller & expect full functionality. Now my real problem with the drive is that it requires a SCSI interface rather than just plugging into a "normal" floppy controller which would have eliminated the "removable" question in the first place. I agree that the performance is probably better with the SCSI interface but think that many people would prefer something that could just be plugged into their existing PC for minimum cost. For those with notebooks (that IMHO would be the immediate market) this special SCSI requirement eliminates the floptical from consideration, even for those rare machines (NEC Ultralite, Apple Powerbook) that have built in SCSI ports. For those with "real" PCs there are other drawbacks: 1) The SCSI controller takes up a slot 2) The SCSI ROM uses up some high memory 3) Pre-existing SCSI cards are incompatable Now again IMHO, the floptical is one of the greatest quanta to appear recently and is the "right" size (have already put 40 Mb on one with compression). So a minor technical problem (a chip to make the SCSI firmware compatable with a "normal" disk controller) shouldn't slow it down for long. In any event, given "plug & play" compatability, this IMHO makes lots more sense than the expensive 2.88 Mb floppy (incidently, the floptical drive is said not to work with these - I still haven't even seen a 2.88 so cannot say) and can provide a very good media for backups as well as making special configurations a breeze. Certainly, they will be a tremendous asset for anti-viral researchers. I received quite a bit of static about my views on disk compression last year. Well, here we go again. Warmly, Padgett ------------------------------ Date: Wed, 20 May 92 14:35:35 -0700 From: tck@netlink.cts.com (Kevin Marcus) Subject: Re: Infection by DIR (PC) mtm1gln@brufsc.bitnet writes: > I have a virus which does just that. Absolutely not. It is impossible. When you execute a DIR command, here is the basic sequence of what happens. 1) DOS sees your command, and executes an INT 21h for findfirst() of the filespec you specified. It also does a findnext, if necessary. 2) These findfirst/next calls do a bit of translation, and eventually get to reading in the directory sectors to see what all is there, file sizes and dates, which it returned as DATA, and used AS DATA. 3) Then another int 21h {function is called to see how much disk space is remaining. In all cases, the information which is retrieves is used as data, and not as executable code. Since there is no executable code, and moreso, since there is no way to read in a boot sector of a disk through a "dir" and execute the code there, an MBR infector could never possibly load into memory. Nonetheless, it is impossible, except for as Vess pointed out, you are unfortunate enough to get ANSI-bombed, but you wuold still see what is going on for the most part unless it was explicitly designed. If you think it infected your hard drive, it might not have. Esp. if you used McAfee's scan to look. if you had a dropper or similar program on the disk, it is possible that some overhead from the dir command or perhaps even from scan (nah...) would be in memory, though not actually active. Scan will find it in memory, and tell you that you are infected with a virus though it's not actually so. It is not a bug in scan, just a mess from other programs. - -- INTERNET: tck@netlink.cts.com (Kevin Marcus) UUCP: ...!nosc!ryptyde!netlink!tck NetLink Online Communications * Public Access in San Diego, CA (619) 453-1115 ------------------------------ Date: Wed, 20 May 92 23:41:00 +0100 From: Anthony Naggs Subject: re: Help! Pain virus? slow system? CPAV infected? (PC) With regard to Finney Chacko's tale of woe: Sorry I don't have the info to hand to identify the virus, no doubt Vesselin has already done that anyway... > ...finally after 4weeks i decide to run scan with a memory > check...boom...I find the Israeli Boot Virus, Brain Virus, and some > other memory resident virus ..so..I try to clean them... > i am also using qemm memory manager throughout this whole ordeal. i load > everthing i can HIGH. QEMM can get very "clever" in loading stuff HIGH, particularly if the stealth feature is enabled. So programs loaded high might not be included in the memory check. > ...they can't be found on the hard drive... Scanners can only detect viruses already known to the scanner's author, or variants containing the instructions in the search string, perhaps you need to get a newer version. > ...i scaned the cpav directory..boom..it says > it found the Flip virus in twp sys files of cpav......i erase all cpav CPAV is notorious for causing problems with other scanners. CPAVs search strings used are not encoded at all, so if they match the strings used in other scanners they may be reported as being the virus(es). > one more wierd thing when i type dir |more...i > get the directory and two random files with the current date and time > tagged on to the end of the directory? why? when i do a normal > directory i don't see those files... The pipe (|) was imported to MS-DOS from UNIX. On UNIX systems dir & more would execute at the same time, with the operating system using the output of dir to feed the input of more. MS-DOS can only run 1 program at a time, (surprise) so it simulates the UNIX feature in several steps: 1 running dir with the output directed to a randomly named file, (dir >random1) 2 running more with the input directed from the file, (more Subject: re: Infection by the DIR command (PC) Genaldo (MTM1GLN@BRUFSC.BITNET) said: > I read in the last issue of this list that there is still doubt > about one getting infection from a diskkete after a DIR. Indeed > it can happen. No it can't. > I got a virus in a infected diskette that does just that. The > virus is in the boot sector and the scan89b tells it is the > STONED ... > The fact is: put a floppy infected by this virus into your PC > drive A (make sure the hard drive is free of virus beforehand) > and issue the dos "DIR" command and you will get a infected hard > drive. You have missed something very important: SCAN does not find Stoned on the hard disk, it finds it in memory. (You didn't need to run CLEAN or MDISK to remove it, did you?) There is a -very- good reason why it is in memory, DOS has just read the boot sector of the new disk in to one of its disk buffers. It does this in order to read a table of data (called the BIOS parameter block or BPB) which tells DOS what format the disk is. When Stoned infects a PC it becomes resident at the top of your 640 or 512k of main memory. Scan should only look in that area of memory for boot viruses, however it looks through other places as well including DOS's buffers. > ... scan89b tells it is the > STONED but I think it is not. That message "Your PC is now Stoned" > is not there and instead there is another message (dirt message > in fact, so I am not writing it here). There are many versions of Stoned, where only the text message has been hacked. Others have small or large changes to the function (eg Michaelangelo). Most scanners don't identify the particular version of the virus that was found, (one of my hobby horses). I don't remember having any versions of Stoned with rude messages. > Now just a theory about this virus: maybe the problem is in DOS > (I am using DOS 5.00). Some weird things happens in this version > of DOS. For instance: to make a bootable diskette you can just > copy the three system files to the diskette using the COPY command > and your are done. There is no need to use the SYS command or > to format the diskkete with the /S switch. Observe that this > only work if the diskkete was formatted with version 5.00 of dos. In MS-DOS 5 Microsoft copied what Digital Research had been doing for a while, the boot sector program searches the root directory for the system files. Old versions required the hidden system files IO.SYS & MSDOS.SYS (IBMBIO.COM & IBMDOS.COM) to be the first two entries. Most users still need to SYS or FORMAT /S to put the hidden system files on to the diskette, although tools such as Norton Commander or XTREE could be used. Regards, Anthony Naggs Internet: amn@vms.brighton.ac.uk or xa329@city.ac.uk Janet: amn@uk.ac.brighton.vms ( cbs%uk.ac.brighton.vms::amn ) or xa329@uk.ac.city ( cbs%uk.ac.city::xa329 ) ------------------------------ Date: Wed, 20 May 92 23:44:00 +0100 From: Anthony Naggs Subject: re: Question re Tequila (PC) Mr Gordon S Byron (gsb1@forth.stirling.ac.uk) said: > Could anybody let me know about the virus Tequila farm. viscan found > it but has no cure for it. I cleaned it from the MBR using the fdisk > /mbr. Good move. > Other files still infected were all exe files involved in the boot > procedure. these were network exe files. Is it safe to just delete and > replace the infected files or should we just fdisk the whole box and > restore? ... this is a suggestion i am at present resisting as i would > naturally prefer to just delete and replace the infected files. thanks > in anticipation Delete & replace should be just fine. Tequila works in 2 stages: * When an infected file is run it checks the hard disk MBR, and if it is not already infected it performs the infection. It performs no other action at this time, it does not become memory resident. * Booting from an infected hard disk places the virus in memory, where it makes itself comfortable. It waits for MS-DOS to load and attempts to infect programs when they are executed. Note that Tequila does not infect floppy disk boot sectors, although some have been hand patched. Supposedly to test the ability of virus scanners to detect the virus, without the inconvenience of an infected hard disk. Needless to say, any scanners that only look in the places that the virus can put itself will fail this test. Regards, Anthony Naggs Internet: amn@vms.brighton.ac.uk or xa329@city.ac.uk Janet: amn@uk.ac.brighton.vms ( cbs%uk.ac.brighton.vms::amn ) or xa329@uk.ac.city ( cbs%uk.ac.city::xa329 ) ------------------------------ Date: Thu, 21 May 92 02:34:00 +0100 From: Anthony Naggs Subject: re: Can a virus survive being pkzipped or otherwise compressed? (PC) Ken Brucker (kjb@calmasd.prime.com) asks: > A columnist in a local computer magazine (Computer Edge for those in > the San Diego area) mentioned that viruses can't survive or at least > typically don't survive compression into zip files and other archives. > > Has anyone had this experience? And has anyone seen the contrary? If a virus is in a file when the file is ZIP'd then it will be there when you unzip it again. The purpose of such archiving software is to maintain the integrity of the original files, usually in a reduced volume. What changes is the visibility of the virus, whilst inside the archive a virus would be invisible to virus scanning s/w. Scanners operate by examining programs for known sequences of operations, using a template of the bytes sought - these templates don't exist in compressed archives. To scan archives you must either extract the content so that the scanner can examine the original files, or use a scanner that incorporates an archive extractor to do this automatically. Note that the converse is also true, because many virus scanners examine the compressed data, rather than recreating the original, they often give false alarms. This is most likely for large compressed files where the file has a nearly uniform distribution of all byte values in nearly random sequences. (Especially those files holding the compressed disk volumes for programs such as Stacker). Regards, Anthony Naggs Internet: amn@vms.brighton.ac.uk or xa329@city.ac.uk Janet: amn@uk.ac.brighton.vms ( cbs%uk.ac.brighton.vms::amn ) or xa329@uk.ac.city ( cbs%uk.ac.city::xa329 ) ------------------------------ Date: Thu, 21 May 92 02:42:00 +0100 From: Anthony Naggs Subject: re: clock ram resident virus (PC) A.J. (amjad@ecst.csuchico.edu) asks: > does anybody know of any clock resident viruses for either > Amiga, Mac or PC computers ??? if so what viruses are they ... I think > my amiga is infectedwith one ... please send more information on these > type of viruses and procedures on removing them ... thankx ps. please > give names and complete discriptions of the viruses you know of and > how to remove them. (amiga,mac or pc) that infect the clock cmos ?? PC: There is an answer in the Frequently Asked Questions (FAQ), which explains why these don't exist. [Question E2) Can a virus hide in a PC's battery-backed CMOS memory?] Amiga: The MSM6242 clock chip does not have any RAM, so no virus can lurk there. A lot of Amiga viruses operate by tampering with the startup-sequence file, or attaching to a program called by the startup-sequence. I can't recommend any particular program as I have not carried out my product tests yet Hope this helps, Anthony Naggs Internet: amn@vms.brighton.ac.uk or xa329@city.ac.uk Janet: amn@uk.ac.brighton.vms ( cbs%uk.ac.brighton.vms::amn ) or xa329@uk.ac.city ( cbs%uk.ac.city::xa329 ) ------------------------------ Date: 20 May 92 22:40:27 -0400 From: barnold@watson.ibm.com Subject: OS/2 2.0 questions. (OS/2) OS/2 2.0's vulnerabilities and strengths v.s. DOS viruses haven't been adequately explored. I have done some limited testing of DOS viruses under OS/2 2.0, but not nearly enough. Here are some scattered notes. - - OS/2 DOS sessions can access files in an HPFS filesystem (partition if you will) as long as they conform to the old 8.3 filename.extension format. Files that don't conform to this format (e.g. files with long names) are invisible in DOS sessions. As far as DOS sessions are concerned, HPFS is just a somewhat faster filesystem with faster access to files in very large directories, less wasted space (allocation unit is 512 bytes) and better built-in caching. File infecting DOS viruses can infect from DOS sessions as long as they use normal DOS filesystem interfaces to infect. - - Pure OS/2 programs will be damaged if infected by many (most?) common file infecting viruses. "Family API" programs, that are "bound" to run under both OS/2 and DOS, will also be damaged by many file-infecting viruses. OS/2 programs are probably about a susceptable in this regard as Windows 3.X programs. As I recall, these programs have short stub EXE headers that make the program do something under DOS and another EXE header that defines what happens in OS/2 mode. Somebody else may be able to provide more detail? - - OS/2 2.0 can run multiple DOS sessions in multiple windows. Each DOS session has its own memory address space. The filesystem is the only thing shared between DOS sessions (that I know about; there may be sharing API's, but DOS viruses probably won't know about them.) When a DOS session is closed, it goes away completely unless it left something behind in the filesystem. Viruses that hang a session will generally just kill that session, in my experience. DOS viruses that infect COMMAND.COM, such as the 4096 (AKA Frodo, 100 years), can be a problem, since every DOS session uses COMMAND.COM. i.e. after the 4096 infects COMMAND.COM, every DOS session started subsequently will become infected. - - Full screen DOS sessions aren't particularly different, except that they can be considerably faster if a lot of screen I/O is happening. (The Jerusalem-b is a file-infecting virus.) Master-boot-record infectors like the Michelangelo that infect when an infected diskette is booted can be a problem. In general, direct writes to the hard disk using INT 13 are prohibited, so bimodal (multi-partite) viruses such as the Flip-2153 (or Flip 2343) will not be able to infect the master boot record. (I haven't tested Flip, to be honest.) - - Windows 3.X programs can't be infected by the Bouncing Ball (aka Ping-Pong), which is an partition-boot-sector/diskette-boot-sector infector that infects a system when an infected diskette is booted. - - Direct writes to the hard disk using a sector level interface (INT 13) are prohibited in DOS sessions. I don't know whether all disk partitions are protected, but certainly the C: partition is protected. - - Boot sector viruses can be a serious problem, though they will not be spread by OS/2 2.0. For example, the Michelangelo infects a hard disk when an infected diskette is booted. When the system boots, the Michelangelo gets control before the operating system. On March 6 (of any year) this would be bad. - - However, boot sector viruses are more worrisome for other reasons. OS/2 has two methods of supporting multiple operating systems. One is called Dual Boot, and lets you put DOS and OS/2 on a single system. In OS/2 sessions, you say BOOT /DOS, and the system obligingly saves the boot record in a file, overwrites the boot sector (with some undocumented OS/2-mode interface) and replaces the CONFIG.SYS and AUTOEXEC.BAT with DOS versions. In DOS sessions the reverse happens. If your DOS session happens to be infected with a DOS virus, and you "boot /os2" the system will obligingly save the infected boot sector in a file. When you do the reverse, it will restore the infected boot sector. The only partition boot sector virus that I've seen in OS/2 systems is the Form. The other is call the Boot Manager. (Originally called MOST, but I guess syllabic proliferation prevailed.) (Following details worked out by examination; I haven't found any documentation). The hard disk partition table is a normal partition table. There is a new partition type (type 0x0A in the partition type field in the partition table entry). This partition is marked the active partition. The boot manager partition is a megabyte partition invisible to DOS and OS/2 except through direct disk I/O. The Boot Manager partition is basically an operating system selector. When the system boots, you get a display of operating system choices, i.e. it asks which partition you want to boot. You can boot partitions in extended partitions if you like. (An enhanced FDISK allows you to specify what partitions should be in the menu, what the default partition is, etc.) With Boot Manager, a system with a large hard disk can hold multiple operating systems. The Form virus is a problem with systems that use Boot Manager. What happens is that the Form virus infects the Boot Manager partition. Most virus detectors don't detect it there. When an operating system that doesn't use BIOS (such as OS/2) is selected via the Boot Manager, the Form virus doesn't survive the boot process, the system will not spread the Form. When DOS is selected via the Boot Manager, the Form virus *does* survive the boot process, and the system will spread the virus to diskettes. This can be very mysterious to people that don't know what is happening. - - Another interesting feature is that OS/2 2.0 will allow you to "boot" a window from a DOS partition, a DOS diskette, or an image of a DOS diskette. If you *really* need a particular DOS environment, you can get it by making an image of a bootable diskette with your environment, and booting it. This facilitates testing of DOS software under multiple operating systems. In limited testing, we were unable to get boot sector viruses to spread to the hard disk by booting images of an infected diskettes. Bill Arnold ------------------------------ Date: Wed, 20 May 92 11:01:56 -0400 From: hobbit@ftp.com (*Hobbit*) Subject: printers, riiiiiight Schwartzkopf is going to speak Friday morning at Interop DC and then take questions. Why doesn't someone ask *him* about the printer virus? _H* ------------------------------ Date: Wed, 20 May 92 17:12:53 +0000 From: mkkuhner@phylo.genetics.washington.edu (Mary K. Kuhner) Subject: Taxonomy of viruses Norman Paterson writes, speaking on computer virus taxonomy: >One way to specify an Automatic Taxonomer is to define a measure of >distance or similarity between two strings of characters. >I believe there is a field of study for this called "Clusterr >Analysis". I don't know anything about it. >Is there any connection between this and DNA comparisons? I'm a post-doc working on taxonomy of this kind for biological organisms. The scheme Norman describes is similar to ones in use for analyzing DNA data. However, I'm dubious that it would be useful for computer viruses. The assumption in biological taxonomy is that changes in a DNA sequence generally occur one at a time and at random. Changes in computer viruses, on the other hand, occur in batches and generally for a purpose--and the purpose is often concealment of the virus' taxonomy from a scanner. Because of this, I suspect that numerical taxonomy will give disappointing results in classifying viruses. It will tend to consider viruses as very different which are simply rearranged or recoded versions of the same exact functional structure. It seems particularly iffy for polymorphic viruses, unless attention can be focused on a non-polymorphic region. (The same problem is encountered in classifying influenza variants, which use a scheme eerily similar to polymorphic computer viruses.) You might do better by hand-scoring each virus for the use of certain characteristic manuvers, preferred locations, type of file infected, etc. and then using that scoring as input to a taxonomy program. This approach is also used in biology, especially for fossil data. It's more subjective, and somewhat sensitive to the choice of characteristics to score, but it's more likely to create a taxonomy that reflects the intuitive relationships between viruses. If information about specific taxonomy algorithms and programs would be helpful, you can write to me. I think it's an intriguing problem, and it will be fun if some of our algorithms have computer science applications! Mary Kuhner Department of Genetics, University of Washington mkkuhner@genetics.washington.edu ------------------------------ Date: 20 May 92 12:01:00 -0500 From: "zmudzinski, thomas" Subject: BAD IDEA (was: Where can I find Virus signatures?) In VIRUS-L Digest V5 #106 Christopher Mateja asks: > 1. Are there any lists availible containing all known virus signatures? > 1a. where can I find them? > > and 2. How can I get them? Putting it as simply as I can, if you don't HAVE virus signatures as the result of taking an active role in anti-viral activities, you don't NEED them. And those persons/organizations who do, don't want their information posted in someone else's database. [Ken, can you synthesize a FAQ out of the above?] Tom Zmudzinski ZmudzinskiT @ UVAX.DISA.MIL Defense Information Systems Agency, "DISSS-ah" (703) 285-5459 [We used to be DCA, but DoD decided to make us a four letter word.] ------------------------------ Date: Thu, 21 May 92 09:50:00 -0400 From: "Dr. Harold Joseph Highland, FICS" Subject: Call for Papers ANNOUNCEMENT AND CALL FOR PAPERS ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ IFIP/Sec '93 in Toronto -- May 12-14,1993 IFIP/Sec'93, the Ninth International Computer Security Symposium and Exhibition, is part of a series of international conferences devoted to advances in data, computer and communications security management, planning and control. It will be held May 12-14, 1993 in Toronto Canada. This international conference, with the theme "Discovering Tomorrow", will encompass developments in both theory and practice and is intended for computer security researchers, managers, advisors, EDP auditors from government and industry, as well as other information technology professionals interested in computer security. The purpose of the 1993 International Federation for Information Processing Security Conference [IFIP/Sec'93] is to provide a forum for the interchange of ideas, research results, and development activities and applications amongst academicians and practitioners in the information, computer and systems sciences. IFIP/Sec'93 will consists of advanced seminars, tutorials, open forums, distinguished keynote speakers and the presentation of high-quality accepted papers. It is hoped that there will be a high degree of interaction and discussion amongst conference participants, as a workshop-like setting is to be promoted. The upcoming conference, IFIP/Sec'93, is jointly organized by IFIP/TC 11, the Canadian Information Processing Society [CIPS] and the Toronto Chapter of the Information Systems Security Association [ISSA]. Call for Papers Papers are invited in the areas shown and may be theoretical, conceptual, tutorial or descriptive in nature. Submitted papers will be referred, and those presented at the Conference will be included in the Conference proceedings.Submissions must not have been previously published and must be the original work of the author(s). Possible topics of submissions include, but are not restricted to: Auditing the Small Systems Environment Auditing Workstations PC and Microcomputer Security Security and Control of LANs and WANs OSI Security and Management Electronic Data Interchange (EDI) Security Management and Control of Cryptographic Systems Security in High Performance Transaction Systems Data Security in Developing Countries Software Property Rights Trans-border Data Flow Database Security Risk Assessment and Management Legal Response to Computer Crime/Privacy Smart Cards for Information Systems Security Biometric Systems for Access Control Security and Privacy in Electronic Mail Refereeing Process All papers and panel proposals received by the submission deadline will be considered for presentation at the IFIP/Sec'93 in Toronto. To ensure acceptance of high-quality papers, each paper submitted will be blind refereed. The papers presented will be included in the Conference preprint of the Conference Proceedings, copies of which will be provided to the Conference attendees. All the papers presented will also be included in Proceedings which will be published by Elsevier Science Publishers B.V. (North-Holland). Author(s) will assign copyright of the paper to IFIP. Additionally, one or more of the authors must present the paper at the conference. Presenters of papers are eligible for a reduced conference fee. Instructions to Authors Three (3) copies of the full paper, consisting of 22-26 double-spaced, typewritten pages, including diagrams (approximately 5,000 words), must be received no later than October 1, 1992. Diskettes and electronically transmitted papers will NOT be accepted. Papers must be sent to the Program Committee Co-Chairman. Each paper must have a title page which includes the title of the paper, full name of all author(s) and their complete address(es), including affiliation(s), telephone number(s) and fax number(s). To facilitate the blind review process, the author's particulars should appear only on the separate title page. The language of the Conference is English. The first page of the manuscript should include the title and a 300 word abstract of the paper. Abstracts may be submitted to the Program Committee if guidance and indication of appropriate content is required. Full papers must be received by: October 1, 1992 Conference dates: May 12-14, 1993 Papers Submission Mr. Graham Dougall IFIP/Sec '93 -- Program Committee Co-Chairman c/o Concord-Eracom Computer Ltd 7370 Bramalea Road, Unit 18 Mississauga, Ontario Canada L5S 1N6 Registration and Other Enquiries Those interested in additional information about the upcoming conference on May 12-14, 1993 should communicate with the Organizing Committee's Chairman. Mr. Dave Batchelor IFIP/Sec '93 -- Organizing Committee Chairman c/o Concord-Eracom Computer Ltd 7370 Bramalea Road, Unit 18 Mississauga, Ontario Canada L5S 1N6 FAX: (416) 672-0017 FOR IMMEDIATE HELP: Highland@dockmaster.ncsc.mil ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 108] ******************************************