From virus-l@lehigh.edu Thu Jan 7 06:52:32 1993 Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/2.0) id AA10431; Thu, 7 Jan 1993 17:56:32 +0100 Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA20246 (5.67a/IDA-1.5 for ); Thu, 7 Jan 1993 11:52:32 -0500 Date: Thu, 7 Jan 1993 11:52:32 -0500 Message-Id: <9301071651.AA16031@barnabas.cert.org> Comment: Virus Discussion List Originator: virus-l@lehigh.edu Errors-To: krvw@cert.org Reply-To: Sender: virus-l@lehigh.edu Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: "Kenneth R. van Wyk" To: Multiple recipients of list Subject: VIRUS-L Digest V6 #5 VIRUS-L Digest Thursday, 7 Jan 1993 Volume 6 : Issue 5 Today's Topics: Re: Untouchable (PC) Re: Untouchable (PC) noint - what is it? (PC) Re: Untouchable (PC) Re: Invalid Boot Sectors (PC) Known virus that tweaks PC date function? (PC) Re: Clash between FDISK/MBR and scanners (PC) Re: Invalid Boot Sectors (PC) Joshi Question (PC) PKZIP V2.04C (PC) False positive in the new PKZIP (PC) Info on Music Bug virus (PC) New Virus (PC) Re: Vshield vs Virstop (PC) Re: Jerusalem (Israeli) Virus (PC) Clearing out old signatures (PC) DOS Serial Numbers (PC) Viral Code Access Re: The Internet Worm (CVP) Re: Good use of (possible bad) viruses Export restrictions of anti-virus software? How to measure polymorphism? 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@LEHIGH.EDU. Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. A FAQ (Frequently Asked Questions) document and all of the back-issues are available by anonymous FTP on cert.org (192.88.209.5). Administrative mail (comments, suggestions, and so forth) should be sent to me at: . Ken van Wyk ---------------------------------------------------------------------- Date: 28 Dec 92 23:48:00 +0000 From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) Subject: Re: Untouchable (PC) Quoting from Vesselin Bontchev to All About Re: Untouchable (PC) on 12-07-92 VB> One important thing to have in mind is that the product is very good, VB> but not as good as the advertisements are trying to suggest you. Some VB> advertisements (in France) say that it is "the absolute weapon agains VB> computer viruses" and that no virus, even an unknown one, is able to I agree 100%. Untouchable is capable, but I wouldn't do much farther. I have Untouchable 1.13. UTScan Detection is fair removal leaves a lot to be desired. I would place F-Prot, VIRx, and Scan in front of it. UTRes Detection is fair. UTPeriodic This is one of the best integrity checkers that I have seen. I would put it in the same league with Victor Charlie's Bit Checking, or Integrity Master. The advertising for Untouchable is doing them a dis-service. Untouchable is good, but not THAT good. Bill - --- * WinQwk 2.0 a#383 * Hacked version of Math Master MATHMSTR.* ------------------------------ Date: 29 Dec 92 00:05:00 +0000 From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) Subject: Re: Untouchable (PC) Quoting from Y. Radai to All About Re: Untouchable (PC) on 12-08-92 YR> UTSCAN has the ability to examine archives and compressed executa- YR> bles (recursively), includes one of the better MtE detectors (its Untouchable does well at scanning archives, abd files compressed with PKlite, LZEXE, Diet, and maybe others. However; I performed some tests with PKlite 1.15 recently. McAfee's Scan was able to detect the virus inside the file compressed with PKlite 1.15. Untouchable wasn't able to scan inside the file. I hope that UTScan can be updated to work with compressed files created with PKlite 1.15 and above. Bill - --- * WinQwk 2.0 a#383 * SURIV 3.0 activates Friday the 13th ------------------------------ Date: 29 Dec 92 07:40:00 +0000 From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) Subject: noint - what is it? (PC) Quoting from Gang Wu to All About noint - what is it? (PC) on 12-23-92 GW> anyone has any idea what noint virus is? we discovered several of the GW> here in barnard college and it seemed that the virus can physically GW> destroy the floppy disk (all the disks we found infected by this viru GW> has numerous bad sectors after the infection.) No-Int is a stealth boot sector virus. Sometimes called Stoned 3. This is the virus that was accidentaly distributed by Novel about a year ago. Bill - --- * WinQwk 2.0 a#383 * MICHELANGELO activates Mar 6th ------------------------------ Date: 29 Dec 92 01:37:00 +0000 From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) Subject: Re: Untouchable (PC) Quoting from Y. Radai to All About Re: Untouchable (PC) on 12-12-92 YR> I was referring to Ver. 26 of UTScan. I am using version 25.10 of UTScan. When was 26 released? Bill - --- * WinQwk 2.0 a#383 * CASINO activates Jan 15th ------------------------------ Date: Tue, 05 Jan 93 17:58:25 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Re: Invalid Boot Sectors (PC) >From: "Roger Riordan" >I recently wrote >>In a recent comment on a query by MOPURC01@ULKYVM.LOUISVILLE.EDU >>(Michael Purcell) about a virus which allegedly made disks >>unreadable I wrote. >>> If you put the wrong byte in the wrong place you can get the >>> symptoms described. ... >It appears the original message got lost, but the gist was that, >IN THEORY, it is possible to write a BS virus which is invisible >on an infected PC, but impossible to detect on an uninfected PC >with any existing scanner because DOS will crash if any attempt is >made to access an infected disk. This is something that experimentation has been done on. What I have found is that: a) If the Partition table is missing certain DOS signature bytes, DOS will refuse to recognise the disk (but a floppy boot will still work). b) If certain bytes in an otherwise good P-Table have certain wrong values a floppy boot may hang (which bytes and what values are DOS version dependant). c) Even given (a) or (b), BIOS software can restore bootability (I have a version of FIXMBR that loads and runs from the BIOS just like the early Microsoft Flight Simulator). d) *Every* MBR infection that I have seen is detectable if you look in the right places. "Stealth" can always be bypassed with a direct BIOS call. In other words, every infection I have seen is recoverable with the right tools (usually DEBUG, FDISK, & SYS). Sometimes it is not worth the bother since repair via E-Mail is somewhat more difficult, but whatever is not corrupted can be retrieved and that which has been corrupted can usually be restored. In general I have found that the stupider the program, the more likely it will work. I am glad that the above said "IN THEORY" since an undetectable, invisible virus that can make a system completely unbootable except from the hard disk just cannot exist. (Note, I am not including access control programs that encrypt the whole disk and rely on input of the key by the user for decryption - this could be made "strong enough" - but a self-contained program cannot. Period. 82 today - what Floridians put up with summer for, Padgett ------------------------------ Date: Tue, 05 Jan 93 22:57:57 +0000 From: vpcsc11@sfsuvax1.sfsu.edu (student) Subject: Known virus that tweaks PC date function? (PC) In the office where I work, we recently purchased a 286 clone.. Over the past few weeks, the computer's internal clock has been losing days. The first time, it stuck on Thanksgiving. A week later, it hung on December 7th (Pearl Harbor Day). A few weeks later, it stuck on Christmas Eve. Has anyone heard of a virus that would produce these symptoms? If not, does anyone have any other ideas about how to fix the problem? Please respond via e-mail to: vpcsc11@sfsuvax1.sfsu.edu Thanks! ------------------------------ Date: 06 Jan 93 09:05:10 +0000 From: tck@bend.ucsd.edu (Kevin Marcus) Subject: Re: Clash between FDISK/MBR and scanners (PC) riordan@tmxmelb.mhs.oz.au (Roger Riordan) writes: >The command FDISK /MBR is often recommended for removing MBR >infectors (Stoned, etc) from hard disks. However in some >circumstances this can cause problems with some scanners. It >appears that some versions of FDISK/MBR rewrite the Master Boot >Record only as far as the end of the error messages, leaving the all >important partition information unchanged, but also leaving any >viral code between the messages and the partition information. I recently installed Linux, a version of unix for the PC, in addition to my regular dos partition. This comes with a small program called "wini" which is a program, which occupies the MBR to allow me to choose which OS I would like to boot into. It's my understanding OS/half does somethign like this, also, or can do something like this. If FDISK/MBR REWRITES the MBR with the basic, boring code that normally is there with DOS, then if I use this method, I will destroy the wini program, and restrict myself from booting into my Linux partition. This is another drawback to fdisk/mbr. - -- || Kevin Marcus, Computer Virologist. (619)/457-1836; RE-xxx, TSCAN || || INET: tck@bend.ucsd.edu []-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[] || tck@fold.ucsd.edu || All I wanted was a Pepsi... || || datadec@watserv.ucr.edu || And she wouldn't give it to me...|| ------------------------------ Date: 06 Jan 93 09:06:21 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Invalid Boot Sectors (PC) riordan@tmxmelb.mhs.oz.au (Roger Riordan) writes: >It appears the original message got lost, but the gist was that, >IN THEORY, it is possible to write a BS virus which is invisible >on an infected PC, but impossible to detect on an uninfected PC >with any existing scanner because DOS will crash if any attempt is >made to access an infected disk. well, only if the scanner uses int 21H/25H/26H to access the disk. If it uses int 13H to access the disk the disk can be read no matter what data is in the boot sector. - -frisk - -- - -- Fridrik Skulason Frisk Software International phone: +354-1-694749 Author of F-PROT E-mail: frisk@complex.is fax: +354-1-28801 ------------------------------ Date: 06 Jan 93 16:38:22 +0000 From: rind@enterprise.bih (David Rind) Subject: Joshi Question (PC) I have a question about the Joshi virus (yes, yesterday was January 5th). Does Joshi trap attempts at warm reboots? There was an intermittent problem with a new program on a computer that turned out to be infected with Joshi. The problem was sporadic enough that I can't be certain that getting rid of Joshi eliminated it, but if Joshi was trapping Alt-Ctrl-Del, then that would explain the "bug". I checked the info in F-Prot, and it wasn't that specific, and I'm not sure where else to check (my impression from reading this group is that there aren't many reliable sources for descriptions of specific viruses). Thanks. - -- David Rind rind@binoc.bih.harvard.edu ------------------------------ Date: Thu, 07 Jan 93 11:44:21 +0000 From: pd@nwavbbs.demon.co.uk (Peter Duffield) Subject: PKZIP V2.04C (PC) I picked the following post up in comp.archives.msdos.announce and thought it may be of interest to this group... - --------------------------------- cut here ----------------------------- From: PKWare.Inc@mixcom.mixcom.com (PKWare.Inc) Subject: PKZIP 2.04c RELEASED (NO VIRUS) Reply-To: PKWare.Inc@mixcom.com Date: Thu, 7 Jan 1993 09:38:18 GMT PKZIP 2.04c is now released and on the PKWARE BBS (414-354-8670) Some reports have come in the certain version of Norton Anti-Virus are reporting PKZIP 2.04 to have the Maltese Amoeba virus. THESE REPORTS ARE FALSE! If the version of Norton is upgraded to a newer version the false reports cease. The correct files size,date and time should be: PKZ204C.EXE 188818 12-28-92 2:04 SIZE DATE TIME If you have any further questions, please feel free to contact me here at pkware.inc@mixcom.com Mark Gresbach PKWARE, Inc. - -- PKWARE.Inc@mixcom.com Voice (414)354-8699 Authors of PKZIP, PKLITE 9025 N. Deerwood Dr. BBS (414)354-8670 PKZFIND, PKZOOM, and the Brown Deer, WI 53223 USA FAX (414)354-8559 Data Compression Library - --------------------------------- cut here ----------------------------- Peter - -- Peter Duffield pd@nwavbbs.demon.co.uk (Internet) Voice: +44 244 545669 BBS: +44 244 550332 8,N,1 North Wales Anti-Virus Support BBS, FidoNet: 2:250/201, VirNet: 9:441/110 === PGP 2.0 == public key available on request == Key ID 991AB1 === ------------------------------ Date: 06 Jan 93 21:03:27 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: False positive in the new PKZIP (PC) Hello, everybody! As most MS-DOS users probably know, the very popular archiver PKZIP from PKWare Inc. has not been updated from version 1.10 since about two years. The new version was in "about to be released final beta-test" during more than a year. This, of course, caused a lot of bogus, hacked, or trojanized versions to be released by malicious people to fool the legitimate users. The number of hacks is probably above 10. A few days ago, PKWare finally decided to release a new version of their archiver, called 2.04c. Regardless of the long developpment period, the program turned out to contain a few minor bugs and even errors in the documentation. But this is not so interesting from the computer virus point of view... :-) What is interesting is that somebody used an out-of-date version of Symantec's Norton Anti-Virus to scan the new archiver. It seems that this version causes a false positive - the program is flagged as infected by Maltese Amoeba. The confusion is increased by the fact that all executables in the package are self-compressed with PKLite 1.20. This caused the heuristic scanner of F-Prot to report that those files are suspicious, because they contain a program that modifies itself in memory (of course - the decompressor unpacks the compressed code) - something often used by viruses. As a result, a major hoax was started; the archiver was several times uploaded and deleted at wuarchive.wustl.edu; and the number of messages about that in comp.compression is reaching the record caused by the famous posting that informed about the claims of a company to produce an archiver which is able to achive compression rate of 16:1 for any file... :-) I obtained a copy of the new version of PKZIP, examined it manually with a debugger, and scanned it with about a dozen scanners. The result is that NONE OF THE EXECUTABLE FILES IS INFECTED. Even a recent version of NAV (2.1 with signature updates of December) does not report the false positive any more. PKWare has confirmed that this is a "real" version. So, please done's pay attention to the rumors, if they reach you. The VALIDATE codes of the self-unpacking archive containing the new version of PKZIP is: File Name: PKZ204C.EXE Size: 188,818 Date: 1-5-1993 File Authentication: Check Method 1 - 0DC8 Check Method 2 - 045E The actual Date: field may be different; it was destroyed while I was downloading the file. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Wed, 06 Jan 93 17:04:01 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Info on Music Bug virus (PC) >From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) >The Music Bug virus isn't generally destructive, but the FAT table >structure on hard drives gives some weird effects occasionally. Not quite. The MUSIC-BUG is not *intentionally* destructive however mistakes do cause damage since this virus makes assumptions about disk structure that works only on some floppies and on no hard disks. The virus tries to create a "haven" for its code by searching for unused sectors and allocating them (six or seven as I recall). Unfortunately, while the chosen clusters are "safe", in computing the register values for a cluster/sector translation the M-B makes mistakes that cause the virus to write to a different set of sectors which may be in use. The virus also makes a single byte change to the Boot Parameter Block which renders removal via SYS C: unusable since the disk becomes unbootable. For some time this led to the opinion that recovery was impossible but most vendors now use a equally simple recovery method that works (think it took less than 30 bytes). The most common vector was via a graphics driver disk furnished with certain computer systems and though the manufacturer was notified, I have never seen any indication that the disks were withdrawn/replaced. Unseasonably warm & humid, Padgett ------------------------------ Date: Wed, 06 Jan 93 23:52:02 +0000 From: s3176997@techst02.technion.ac.il (Daphne Rosenhouse) Subject: New Virus (PC) hi all Id like to report a new virus/mutation i found It looks like a variant of te WHALE, but larger, and harder to remove im researching it and will soon post the results and send a sample to all anti-viral softs programmers... i just wanted to inform all users on comp.virus and VIRNET. p.s. do VIRNET users get messages from here too ? bye ------------------------------ Date: Thu, 07 Jan 93 01:22:10 +0000 From: aryeh@mcafee.com (McAfee Associates) Subject: Re: Vshield vs Virstop (PC) Hello Bill Lambdin, You write: [regarding VSHIELD's ability to check validation (CRC) data created by SCAN] >2. These CRCs will not detect stealth infectors because stealth viruses > disinfects infected files when an infected file is opened for any > reason. VSHIELD (or SCAN) will detect the change in a CRC made by a stealth virus provided the stealth virus is not resident in memory to interfere with checking. Regards, Aryeh Goretsky Technical Support - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - McAfee Associates, Inc. | Voice (408) 988-3832 | INTERNET: aryeh@mcafee.COM 3350 Scott Blvd, Bldg 14 | FAX (408) 970-9727 | IP# 192.187.128.1 Santa Clara, California | BBS (408) 988-4004 | CompuServe ID: 76702,1714 ------------------------------ Date: Thu, 07 Jan 93 01:26:20 +0000 From: aryeh@mcafee.com (McAfee Associates) Subject: Re: Jerusalem (Israeli) Virus (PC) Hello Bill Lambdin, You write: >Quoting from Samid Hoda to All About Jerusalem (Israeli) Virus on 12-20-92 [asking about how to remove the Jersualem virus] >McAfee's Clean can remove this virus fairly easy to remove. It would be a >very good idea to re-boot the computer from a known clean bootable >diskette. If you don't have a clean bootable diskette, go ahead and type >the following on the command line. > >CLEAN C: [JERU] > [...deleted...] Since the Jerusalem virus also infects overlay files. I would recommend the use of the the /A and /NOPAUSE switches, which tell CLEAN-UP to check all files on the disk for the virus and remove it if found regardless of their extension, and not to pause when it has filled up the screen with messages, respectively. Regards, Aryeh Goretsky Technical Support - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - McAfee Associates, Inc. | Voice (408) 988-3832 | INTERNET: aryeh@mcafee.COM 3350 Scott Blvd, Bldg 14 | FAX (408) 970-9727 | IP# 192.187.128.1 Santa Clara, California | BBS (408) 988-4004 | CompuServe ID: 76702,1714 ------------------------------ Date: Wed, 06 Jan 93 20:34:25 -0500 From: "Roger Riordan" Subject: Clearing out old signatures (PC) padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) wrote recently > Enclosed is a DEBUG script that will create a 68 byte .COM file > (CLEAR.COM) that will zero out memory between the current load > position and the TOM. To use, ... The only trouble with this is there is a surprising amount of software which leaves active code in memory, but does not bother to tell DOS. To guard against possible unknown viruses like to Chinese Fish, which install themselves in high memory, but do not set the top of memory down, we recently added a feature to VET to fill unused memory with a diagnostic procedure which gives a warning message, and locks the PC, if anything attempts to execute unused memory. So if you run VET, and an unknown virus of this type is already in memory, you get the warning as soon as VET calls an interrupt the virus has trapped. Ahh! Another loophole closed! Unfortunately a big customer immediately complained some users could no longer log in. We investigated, & found that they were using Microsoft Lan Manager. When PROTMAN was run from CONFIG.SYS a block of code was installed at 7000:7800, but top of memory (as recorded at offset 2 in the PSP) remained 9FFF:0000. If this code was overwritten by running VET (or anything else) before the user logged in, the system would crash when the program NBP.EXE was run as part of the log in procedure. We sent details of this to MicroSoft Support, but, naturally, never received any reply. We added an option to VET to disable this feature. A significant no. of users have encountered similar problems. Most have been using Lan Manager, but other programs may also have been involved. Roger Riordan riordan.cybec@tmxmelb.mhs.oz.au CYBEC Pty Ltd. Tel: +613 521 0655 PO Box 205, Hampton Vic 3188 AUSTRALIA Fax: +613 521 0727 ------------------------------ Date: Wed, 06 Jan 93 23:44:33 -0500 From: Jack Davis Subject: DOS Serial Numbers (PC) Regarding the question of changing the SERIAL NUMBER of a DOS disk. An undocumented DOS function 69h which will GET or SET the serial number of a disk is discussed in PC Magazine, July 1992, V11N13, Page 496. A PASCAL program listing is included with the article and the program itself is avaiable from PC Magazine. Regards, Jack Davis jack@csn.org ------------------------------ Date: 06 Jan 93 08:44:34 +0000 From: ygoland@edison.SEAS.UCLA.EDU (The Jester) Subject: Viral Code Access I REALLY don't mean to start this debate again but my personal experience have left me with little choice: The Situation:I am trying to get ahold of a certain virus because it implements certain features which are of central importance to a paper I'm writing. (Note:I am trying VERY hard to leave out all details because I want this to be a discussion of topic and not a hidden request, something the moderator has made clear he will not stand for and a request I intend to respect.) The problem is that for all intents and purposes I am a 'nobody'. I am a Junior at U.C.L.A.'s school of engineering and getting my degree in computer science and engineering. In addition just about everybody has a dead on prohibition against giving anyone their viral code, even though they got it from someone. So I have been totaly unable to get a copy of this virus. Solution:One researcher who shall rename nameless suggested that I call a virus exchange board in order to get a copy of the virus. In other words that I go skulk around with the miscreants who keep many of you employed so I can get the material I need for my paper. However its not just a matter of dealing with the lowest of the low. Many viral exchange bbses require you to upload a new virus in order to access their collection. Should I go out and write some hyper deadly virus so I can get into their collection in order to look at the virus that every researcher and his brother already has but is to scared to give out? Maybe I should just write a moderatly deadly virus? A dude? What? Is this how the anti-viral community wants to run itself? Is this 'open and free exchange of information'? [Moderator's note: This is obviously a touchy subject. I stand by my policy of keeping requests for live viruses off of the group. At the same time, I certainly recognize the need to get virus samples to the appropriate people for analysis purposes. I welcome thoughts and discussions on this issue.] Yaron (The Jester) Goland - -- "Only the blind see in color." "Any union based upon pigment is foolish ignorance designed to give power to those few who enjoy power's taste above the common welfare." ------------------------------ Date: Wed, 06 Jan 93 10:44:43 -0500 From: Olivier "M.J." Crepin-Leblond Subject: Re: The Internet Worm (CVP) >From rslade@sfu.ca Fri Dec 25 08:15:00 1992 >Date: Fri, 25 Dec 92 00:15:35 -0800 >From: rslade@sfu.ca >Subject: The Internet Worm (CVP) > >HISVIRO.CVP 921215 > > The Internet Worm > >By the fall of 1988, VIRUS-L had been established (let's hear it for >Ken!) and was very active. Issues were, in fact, coming out on a >daily basis, so I was quite surprised when I didn't receive one on >November 3rd. I didn't get one on November 4th, either. It wasn't >until November 5th, actually, that I found out why. This is incorrect. The first digest of VIRUS-L appeared on 9th Nov 88. I suspect that this was triggered by the FLOOD of undigested messages that had to be sent all around the place during the week 1 Nov to 8th Nov 88. (am I right, Ken ?) [Moderator's note: For the e-record, VIRUS-L Volume 1 Issue 1 was posted Wednesday, 9 Nov 1988, just a few days after the Internet worm incident. The primary input behind going digest+moderation at that time was a storm of ASCII "pictures" that were posted to the group. That, plus the added discussions due to the worm prompted several people (including myself) to want the list to go to digest format. In any event, VIRUS-L was distributed unmoderated and undigested from Fri, 22 Apr 88 07:48:39 EDT (when I sent the first announcement to the newly formed group) until 9 November. The distribution was from LEHIIBM1.BITNET aka IBM1.CC.Lehigh.Edu - the same IBM 4381 mainframe that served the group until July 1992, when we switched over - not without pain - to an RS6000 running AIX and IDA's sendmail.] VIRUS-L was a BITNET listserv list (LEHIIBM1.BITNET) and was just an email exploder, forwarding messages on BITNET and traffic went-on throughout the internet worm. I recall receiving messages here in UK via EARN-RELAY (known as UKACRL.BITNET). It was interesting to read messages as they came in. I remember spending most of the 4th of November 1988 on my terminal, reading message after message. (or was it 5th ?) Receiving so many messages per day was quite exciting, since I had only started to subscribe to VIRUS-L a week earlier. An amazing coincidence. Judging from the nonsense that was often written, the amount of confusion amongst those affected by the worm was at a peak. Rumours spread so quickly. - -- Olivier M.J. Crepin-Leblond, Digital Comms. Section, Elec. Eng. Department Imperial College of Science, Technology and Medicine, London SW7 2BT, UK Internet/Bitnet: - Janet: ------------------------------ Date: Wed, 06 Jan 93 16:50:11 +0000 From: grweiss@phoenix.princeton.edu (Gregory Robert Weiss) Subject: Re: Good use of (possible bad) viruses celustka@sun.felk.cvut.cs (Celustkova-k336-doktorand(Richta)) writes: >Hi boys and girls, (a day of inspiration,huh ?) > >Just one of those days...Two examples of good use of (possible bad) >viruses come to my mind : > >1. Viruses written to improve an A-V product > >The logic is simple. It is better that I write virus which can do this >or that and have prepared solution to implement in my A-V product than >wait that such virus arises in wild and then react. That means if I >know that today exist viruses which could be stealthy, tunneling or >polymorfic why shouldn't I write virus which is all that and design my >A-V product to recognize such virus before it really appears in wild. >(Well, maybe it is not commercial, I don't know). Developing solutions for anticipated problems is quite reasonable; however, the following statement isn't: >If such virus *by >accident* escape from my lab I already have a response and there is no >ethical problem at all. No problems if it "accidently escapes"... - unless of course you developed the virus and it "escaped by accident" before you had your A-V program properly detecting it. - unless you think about the fact that most people will not use *your* A-V program, they'll use someone else's, or maybe even no protection at all. - unless you consider that and you will create a lot of work for other A-V writers, and damage to others in the meantime. These problems are both technical and ethical problems that you must confront before doing this kind of work, IMHO. >2. Viruses built in an A-V product (it's just an idea, don't blame me if it >is not applicable in reality) > >Suppose that we have an A-V product which in regular intervals or >randomly send a virus in system. Virus (fast infector) infects only >programs which checksum doesn't correspond to previously calculated >values. If no such program is found virus deletes itself or removes >from memory. If changed program found virus activates scanner to check >if there is any known virus. If known virus is found message is sent >to the user. If program is changed and no known virus is found the >message is sent to the user to make decision. This sounds fine and good for a strictly contained system owned by an A-V writer (note the dangers mentioned in my previous comment above), but will be *absolutely, fundamentally worthless* in an A-V product as you describe, because you are describing a system in which the virus is discovered (and hopefully removed) only *after* files have been damaged. The point of having A-V products is to prevent the damage in the first place. So now my financial records which I hadn't backed up for a month or two (or more...) are damaged: my A-V virus says the checksum has changed. Well, I'm glad that I caught that virus, even though it destroyed the data file I was trying to protect! :-) The reason why many A-V products are TSRs is to catch viruses *as* they enter the system, not *after* they enter the system. Your A-V virus seems to fall short in this regard. > If decision is to leave >program as is, virus cuts itself from the program. The whole process >(except messages) takes place in background. There is no need for all >A-V program (which is combination of I-checker and scanner) to be TSR, >only virus is occasionally TSR. There is slight similarity in this >idea with reaction of human immunity system. Anyone has ethical >problem with her/his own immunity system ? I understand your comparison is tongue-in-cheek, but you really are comparing apples and oranges here. In the immune system, a few cells can die, but your body can still function properly. Computer data files and programs are much less forgiving of a few errors. >Cheeeers, > >Suzana Happy New Year everyone! --Greg grweiss@phoenix.princeton.edu ------------------------------ Date: 06 Jan 93 20:57:29 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Export restrictions of anti-virus software? The following was provided by Robert Heuman from Canada in one of the newsgroups (sci.crypt, I think). It seems to imply that some kinds of anti-virus programs are restricted from export in Canada. I would be very interested whether similar export restrictions exist for the USA. Please note that I am interested -only- in export restrictions of anti-virus software, not in export restrictions of cryptographic software. Could somebody in the USA who has access to the full text of ITAR verify that? Please, if you find something, post the exact reference and quote, if possible. Thanks. Regards, Vesselin Date Entered: 12-22-92 10:34 I was asked to supply information re export control over anti-virus software, since I stated it was restricted in some cases. The exact information follows: Source: A Guide to Canada's Export Controls, January 1, 1992 Page 25, item 1150.Information Security NOTE: The embargo status of "information security" equipment, "software", systems, application specific "assemblies", modules, integrated circuits, components or functions is defined in this Category even if they are components or "assemblies" or other equipment. Page 25, item 1154. Software 1154.a.c.3. "Software" designed or modified to protect against malicious computer damage, e.g., viruses. Page 1, General "Software: Note This List does not embargo "software" which is either: 1. Generally available to the public by being: a. sold from stock at retail selling points, without restriction, by means of: 1. Over the counter transactions 2. Mail order transactions 3. Telephone call transactions _AND_ b. Designed for installation by the user without further substantial support by the supplier, _OR_ 2. "In the public domain". A check with Ottawa resulted in the statement that F-PROT was export restricted (controlled) as shareware did not meet the criteria of this general "software" note... Therefore SCAN by McAfee also would not meet the requirements. I believe a similar restriction will be found in the US regs, as Canada's are based in good measure on the US regs, and this specific restriction was added at the request of the US gov't. Bob - --- RoseReader 1.70 P001886: Twice as human as anyone else my opinions are my ow n RM 2.00 : RoseNet<=>Usenet Gateway : Rose Media 416-733-2285 - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 06 Jan 93 21:21:12 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: How to measure polymorphism? Hello, everybody! There are already two polymorphic engines available (MtE and TPE) and we are going to see more and more polymorphic viruses in the future. An interesting question arises - how to determine how polymorphic a virus is? How to determine which of two viruses is "more polymorphic"? In other words - how to measure polymorphism in an objective way? There are several ways one could think about: 1) Determining the total number of different instance that a particular virus can take. Obviously, a virus that can take 6 different appearances (V-Sign) is less polymorphic than a virus that can take 65,536 (Cascade). Unfortunately, this does not work. First, for some viruses it is almost impossible (well, at least too difficult) to count the total number of appearances. Nobody has succeeded yet to determine the exact number of different decryptors that MtE can generate. Second, a variably encrypted virus with the following decryptor mov si,code_end mov cx,code_length mov ax,key decode: xor word ptr [si],ax jmp short skip garbage db ? skip: dec si dec si loop decode where the byte 'garbage' can take any value is not very polymorphic, regardless that the number of possible decryptors is 256. If we change garbage db ? to garbage dw ? this will mean that the number of possible decryptors is 65,536, but the virus is not more polymorphic... 2) The second idea is to divide the polymorphisms is classes. Class 0 means no polymorphism, class 1 means variable encryption with constant decryptor, class 2 means variable encryption with a decryptor that can be detected by a wildcard scan string, class 3 is a virus that cannot be detected even with a wildcard string. E.g., Vienna (class 0) is less polymorphic than Cascade (class 1), which is less polymorphic than Suomi (class 2), which is less polymorphic than V2P2 (class 3). Unfortunately, this is not good enough. First, what to do with viruses that use a limited set of decryptors, one of which is selected randomly (Whale). Such viruses are obviously more polymorphic than Cascade. But are they more or less polymorphic than Suomi? They can be detected by a set of non-wildcard strings... Second, what about Bad Boy? It consists of 9 segments of code, 8 of which can appear in any order. This gives 8! = 40,320 variants. But the virus is even not encrypted, so it can be detected with a simple (non-wildcard) scan string... Third, what is a "wildcard string"? A string allowing "don't care" bytes? A string allowing "don't know how many don't care bytes"? A string allowing "don't care" bits? For instance, Maltese Amoeba cannot be detected by the user-defined scan strings of SCAN or F-Prot, but can be with the wildcard scan strings of HTScan/TbScan... So, is Maltese Amoeba class 2 or class 3 polymorph? Fourth, what about V2P2 and V2P6Z? None of them can be detected by a scan string (even a wildcard one), but most experts agree that V2P6Z is "more polymorphic" than V2P2 - because the decryptor can be of different length, the virus too, and many other things... 3) The third idea was proposed by Dr. Solomon. He proposes to use the length of the longest byte sequence that is present in the decryptor. As an addition, one could use the sum of the length of all constant byte sequences in the decryptor - if there are several short ones that can appear in any order (like it is in V2P2). This is already better, but still not good enough. According to this criterium, the MtE-based viruses have polymorphism 1 - because all decryptors contain only a single constant byte (the JNZ instruction), which does not appear at a constant place. (Obviously, by this criterium, the higher the number, the less polymorphic the virus is.) Unfortunately, as I said, this is still not good enough. There are other viruses with only a single constant byte in the decryptor, which are much less polymorphic than the MtE-based ones. On the other side, the TPE-based viruses can have 0 constant bytes in the decryptor, but this does not imply that they are more polymorphic than the MtE-based ones... In fact, if one looks at them very carefully, it is possible to see that the different decryptors are pretty similar, if you remove the garbage ("do-nothing") instructions... It seems that what each anti-virus researcher considers as "level of polymorphism" is dependent somehow on the technique he uses in his anti-virus product to detect polymorphic viruses. For instance, V2P6Z might look "more difficult" (i.e., more polymorphic) than the MtE-based viruses to those people whose scanners depend on the number of addressing modes used by the instruction that performs the actual decoding... This article is not meant to provide a solution of the problem. I am trying just to explain the problem and am asking for solutions. Any ideas are welcome - we really need an objective way to measure the level of polymorphism... Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 5] ****************************************