VIRUS-L Digest Thursday, 19 Sep 1991 Volume 4 : Issue 166 Today's Topics: re: Scanning LZEXE and PKLITE files (PC) Scanning LZEXE and PKLITE files (PC) Re: Disinfectant and students (Mac) Re: Stoned virus (PC) When will FPROT 2.00 work with Zenith Dos 3.30.1 (PC) Re: FAT Infection (PC) F-prot, Clean, Joshi and DOS 2.0. (PC) Possible virus on Cypress Semiconductor 5.25 inch disks (PC) Re: Heuristic analysis Re: SunOS virus checker needed (UNIX) (PC) Re: Heuristic analysis The "Azusa" virus (PC) Re: FAT Infection (PC) Re: Virus Simulator available (PC) VIRUS-L is a moderated, digested mail forum for discussing computer virus issues; comp.virus is a non-digested Usenet counterpart. Discussions are not limited to any one hardware/software platform - diversity is welcomed. Contributions should be relevant, concise, polite, etc. Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU. Ken van Wyk ---------------------------------------------------------------------- Date: Wed, 18 Sep 91 17:09:03 -0400 >From: pshuang@ATHENA.MIT.EDU Subject: re: Scanning LZEXE and PKLITE files (PC) > Not altogether true, I fear. I'm hearing reports that some programs > don't work any more afer tering de-compressed as such, particularly in > the case of LZEXE. Certainly, just because a virus-scanner does not go off does not mean that you should feel complete confidence. It is true that LZEXE'd files often do not decompress back to their original parents. It is also true that UNLZEXE often botches things up such that the UNLZEXE'd file will not load and run even though the LZEXE'd file will. Most of this has to do with .EXE relocation information in the header (LZEXE is good at munging a lot of this), and should not affect searching for string signatures. PKLITE is better in that unless you choose the option which purposes strips the executable of extra data (such as debugging information inserted by CodeView), it is capable of decompressing files which it compresses back to the original, byte for byte. Testing this on many .EXE and .COM files seems to even corroborate PKWare's claim. ------------------------------ Date: Wed, 18 Sep 91 18:01:17 -0400 >From: pshuang@ATHENA.MIT.EDU Subject: Scanning LZEXE and PKLITE files (PC) > The dilemma really is that, for example, all PKLITE'd executables > cannot be expanded. Perhaps it wasn't such a hot idea to sell the > unexpandable compression version by PkWare. If you PKLITE an arbitrary executable, *ANYONE* can decompress it with their copy of PKLITE. Developers who wish to make it less easy for anyone who may wish to be able to examine their code may register for a customized copy of PKLITE whose output cannot be decompressed by end-user PKLITE. This is bad in that even the largest commercial developers have been known to be inadvertently infected and distribute infected applications, and if they choose to get the special PKLITE, we can no longer check the original code ourselves. However, it isn't easy for malicious virus-writers to insert their virii into such files at the source -- so I don't think this is much of a concern. ------------------------------ Date: Wed, 18 Sep 91 23:34:18 +0000 >From: ldg@bart.skidmore.EDU (Leo D. Geoffrion) Subject: Re: Disinfectant and students (Mac) Since folks are flaming sites that keep virus knowledge secret, I thought it might be useful to mention a slightly more enlightened approach... At our College, we install the disinfectant init in EVERY system disk given out to users. Whenever an infection is detected, we place a Mac next to the main door to the public user room and instruct the student assts. to check every disk that comes in. If it's clean, they install the latest edition of Disinfectant. Simultaneously, we send out e-mail notices to all of the academic departments whenever a new outbreak is detected. Over the past few years, there have been outbreaks of several Mac viruses (NVIR, SCORES, WDEF, ...) but we've usually managed to beat them back within a couple of weeks. Virus infections are most common after vacations or toward the end of the school year when most folks are hurrying to complete projects and get careless about their disks. ------------------------------ Date: Thu, 19 Sep 91 12:36:00 +1200 >From: "Mark Aitchison, U of Canty; Physics" Subject: Re: Stoned virus (PC) psgrbbc@prism.gatech.edu (Brian Cooper) writes: >... My system checked out fine. I used the /a and > /m options so all the files were checked as well as the boot > sector and memory. I then started scanning some old floppies > that I had. I found about a dozen floppies containing the > Stoned Virus in the boot sector... > What does it mean when a virus is in the boot sector of a floppy > disk? How could such a virus become active when there are no files > executable files containing the virus? Note that this sort of virus isn't found in programs, but in the "hidden" first sector of disks, and it hasn't become "active" in your computer (at the moment) but must have been in some other computer your diskettes were used in. If you can remember what computers they were used on (even to simply transfer data files), you should warn their owners to check for viruses (but, of course, it is hard to remember everywhere old diskettes have been, hence the success of boot sector viruses like stoned). What does this mean? Well, when most computers start up, they look at the first sector of the first track on the disk(s), and load whatever program is there; this should be a bootstrap program, to load the full operating system. If the operating system isn't there it should tell you to try another disk. Just to compicate things, modern MSDOS systems have another level inserted - the "MBR" or partition table contains a table of information about partitions on teh disk, plus a bit of code to load the bootstrap program (which pretty much carries on as if it were the first sector to be executed). Boot sector viruses act just like that - they inhabit the boot sector of a diskette (or one of the boot sectors - if you call the MBR a boot sector - of hard disks); they install the virus in RAM somewhere, and then call the original boot sector, which executes as if nothing was changed. A diskette can get a boot sector virus even if you put it in an infected PC to transfer data (or even do a directory listing!), but it won't transfer the virus onto another computer unless you try to boot from it (which includes leaving it in the drive accidentally when you switch on or do a Ctrl-Alt-Del). Notice, you only need to *try* to boot from it - if the diskette doesn't have an operating system (and you get the "non-system disk" message) your computer can still be infected. Hope this helps, Mark Aitchison. ------------------------------ Date: Thu, 19 Sep 91 01:10:29 +0000 >From: dab6@po.CWRU.Edu (Douglas A. Bell) Subject: When will FPROT 2.00 work with Zenith Dos 3.30.1 (PC) When will the fix be out? - -- Douglas Bell dab6@po.cwru I can only have a four line .sig I'll never make alt.fan.warlord ------------------------------ Date: Thu, 19 Sep 91 13:59:00 +1200 >From: "Nick FitzGerald" Subject: Re: FAT Infection (PC) In VIRUS-L Digest V4 #164 I wrote: >At this point there is much potential for confusion. Some BSI/PTI >viruses _affect_ (NOT infect) the FAT. This happens with Stoned and >most of its derivatives, due to the "assumption" by its creator, that >sector 0,0,7 is never used. This is true on HD's FDISK'ed with ^^^^^^^^^^^^ >pre-3.0 versions of DOS, some OEM's DOS 3.X'es, and some third party >partitioning progs that do not leave an unused track at the beginning >of the disk. ... The gremlins got me 8-). Despite several re-readings, I missed an obvious blunder, which probably rendered this paragraph unintelligible. The highlighted part should read "This is _not_ true" Sorry, - --------------------------------------------------------------------------- Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z. Internet: n.fitzgerald@csc.canterbury.ac.nz Phone: (64)(3) 642-337 ------------------------------ Date: Thu, 19 Sep 91 01:12:00 -0400 >From: George Svetlichny Subject: F-prot, Clean, Joshi and DOS 2.0. (PC) Last week I was asked to disinfect a 5 1/4 in. - 360K bootable floppy with Print Shop installed and infected with Joshi. I was told that the user had tried to remove the virus but was unable to do so. I started with Fridrik's F2 (Part of FPROT 2.00) as in the past I've had the most sucess with F-prot in removing Joshi. The program identified the infection and reported removal, yet a repeated scan again reported the presence of the virus. The disk would not boot, though I don't know if it would have booted before I ran F2 on it as I didn't try to. Passing on to McAfee's SCAN and CLEAN I had the same experience, the CLEAN programm reporting removal, and a subsequent scan reporting continued presence. Examining the boot sector I noticed that it was formated with DOS 2.0, and the system files were DOS 2.0 also. Luckily enough I had a copy of DOS 2.11 stashed away and a simple SYS command (well, not *so* simple, I had to manually free the necessary space - later DOS version could not have fitted on the disk along with all the other files) seems to have resolved the problem and I was able to return a functioning floppy to the owner (Print Shop uses a rather silly copy protection scheme so I couldn't just copy all the files to a clean disk; one more reason to say no to copy protection.). What intrigues me though is the thought that the problem could have been due to the old DOS version. Could F2 and CLEAN have some problem with DOS 2.0?. As there are probably still a lot of bootable floppies with old DOS versions in action, such a situation would be at best an inconvenience. George Svetlichny | Departamento de Matematica | Pontificia Universidade Catolica | Rio de Janeiro, Brazil | | usergsve@lncc.bitnet | ------------------------------ Date: Thu, 19 Sep 91 09:42:15 -0400 >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: Possible virus on Cypress Semiconductor 5.25 inch disks (PC) We have received notification of a possible virus on Cypress Semiconductor 5.25" floppy disks identified as MAXPROG version 2.72C dated May 1991. It is said that these disks contain the STONED virus in the boot sector. 3.5" disks and programs downloaded from the Cypress BBS are said to be clean. Since this is specialized software used in the programming of memory, it is doubtful that many copies have been sent out. Cypress is reported to be in the process of contacting known recipients of the disk. Padgett Peterson ------------------------------ Date: Thu, 19 Sep 91 16:59:00 +1200 >From: "Mark Aitchison, U of Canty; Physics" Subject: Re: Heuristic analysis PEPRBV@CFAAMP.BITNET (Bob Babcock) writes: >>> Frisk's "heuristic virus analyzer" >>> is *extremely* prone to false alarms, much more so than his string >>> scanner. >>You probably tested it on some programs that were badly written, used >>self-encryption or modification, modified executable files, and in >>general behaved in an unusual way... > > I've written some code which does none of these things, yet it still > triggers a false alarm. This is code which I sell, so I'm not going > to be happy if customers start complaining that a heuristic scanner > claims that it may be virus infected... Of course, remember his program gave plenty of warnings that this was only experimental, and it isn't called in by default when scanning for viruses, so there should be little worry on the part of uneducated users. >... I raise > this as a practical problem with this sort of scanner, distinct from > the theoretical problem that a perfect scanner is impossible. Hmm, this sort of thing is likely to happen a lot now, as we seem to be at the start of a new generation of virus scanners (at last!, some would say). In some ways it parallels the days when very simple string scanners were made, with libraries of virus strings not produced as carefully as today. I feel the answer is not to avoid heuristic scanners, but to improve their hit rate before being released by some organisation establishing a huge library of good and infected files, and providing a certification of anti-virus products for free, inthe interests of everybody. I must say that I ran this particular program on what I think is a large number of files, and (apart from compressed files, and ones obviously odd to me, at least) the number of false alarms was small. But I doubt it could ever be zero. Mark Aitchison, Physics, University of Canterbury, New Zealand. ------------------------------ Date: 19 Sep 91 09:26:10 +0000 >From: tommyp@ida.liu.se (Tommy Pedersen) Subject: Re: SunOS virus checker needed (UNIX) (PC) jhk@ssds.com (Vienna) writes: >Looking for SUN/OS compatible Virus checker program >Like many LANs , Ours Files servers are UNIX based but also support >the MS-DOS community. I am looking for a SUN/OS binary or coding which >can be ran by the CRONTAB automaticly at set times. >It will only need to scan the MS-DOS file sectio sections or sections >requested. >Anybody have any ideas? >Anybody working on such a program? >jhk@ssds.com >Yasha "John" Kida >[Ed. The COPS package, among other things, does perform CRC integrity >checks on selected binaries. It is available for free by anonymous >FTP on cert.sei.cmu.edu in pub/cops, and runs on most any UNIX >system. Could be a good place to start.] Well using a regular CRC integrity check does help, but it is not a general solution. A virus can easily fool the checksumming program by simply adding a pattern which makes the checksum correct. This approach would therefore only work if the checksumming algorithm is kept secret, but that is of course not a good solution. A better and general solution is to use cryptographic checksums. It is then free to distribute the algorithm used since the secret relies upon a small key which can be changed very often and individually for the users. A virus can not add a pattern which makess the checksum correct since it not knows which key that has been used. The only way would be to break the crypto, and that is much more involved than just adding a pattern. If you would like to get some info on a commercial packet for unix machines, calculating cryptographic checksums, send me an email to "tommyp@isy.liu.se". Running a checksumming program (cryptographic or not) on a unix host obviously has the advantage of beeing immune against stealth viruses, since it is not the same machine that does the checksumming that may be infected. A check- summing program on the PC must be started after booting from a "clean" discette. - -- /Tommy Pedersen ______________________________________________________________________ |E-mail: tommyp@isy.liu.se /\ | |S-mail: Tommy Pedersen / / Telephone: +46 13 235200 | | SECTRA-Secure Transmission AB | | FAX: +46 13 212185 | | Teknikringen 2 |.> | | S-583 30 Linkoping |/ | |_______ SWEDEN ______________________________________________________| ------------------------------ Date: 19 Sep 91 09:06:23 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Heuristic analysis PEPRBV@CFAAMP.BITNET (Bob Babcock) writes: > I've written some code which does none of these things, yet it still > triggers a false alarm. This is code which I sell, so I'm not going > to be happy if customers start complaining that a heuristic scanner > claims that it may be virus infected. Worse, I have no clue as to > what the scanner is finding, so there's no way I can change the code > to quiet the scanner. If the algorithm used by the scanner is > released, or if the scanner is more specific about what code it found > which indicates possible infection, then virus writers can use this > information to write viruses which the scanner can't see. I raise I suggest that you send an example of your program that triggers the alarm to Frisk. This may help him to modify and improve his algorithm, and also he will probably suggest you what modifications to make in order to avoid the alarm. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: Thu, 19 Sep 91 09:52:00 -0400 >From: CRK5@pittvms.BITNET Subject: The "Azusa" virus (PC) Hi, I just came accross the AZUSA virus the other day. It appeared at boot up along with a STONED related virus. I was not able to clean it because it did not appear at the next boot up. Does anybody know what this virus does? What programs will clean it? Thank you for any information. Chris Kunselman ------------------------------ Date: 19 Sep 91 08:17:41 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: FAT Infection (PC) moore@iastate.edu (Brian J Moore) writes: > >If it overwrites only the first FAT copy, you won't lose anything... > >and you probably won't even notice that something nasty has happened. > Running CHKDSK will tell you if the FATs don't match... It won't, if the virus modifies the DPB to indicate that there is only one FAT copy... Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 19 Sep 91 09:15:59 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Virus Simulator available (PC) ender2@husc9.harvard.edu (Matt Ender) writes: > Last note of interest: I don't notice too many new viruses derived > from old viruses (example, the 'strains' of a particular virus.) > Thus, I must deduce that the authors either have stopped writing > viruses or don't bother watching the scanners and re-writing their > viruses. To my knowledge, more than 30 % of the known viruses are Vienna, Jerusalem, Cascade, or Amstrad strains. The question, however, is how many strains have been created just to fool a particular scanner. Does anybody have any information on this? Regards, Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 166] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253