Return-Path: Received: from barnabas.cert.org by abacus.HGS.SE (SunOS 4.1/SMI-4.1-01) with sendmail 4.1/SMI-4.1-01 id AA02108; Thu, 9 Jul 92 14:07:26 +0200 Received: from localhost.cert.org by barnabas.cert.org (4.1/2.3) id AA29459; Thu, 9 Jul 92 08:10:39 EDT Message-Id: <9207091210.AA29459@barnabas.cert.org> To: Mikael Larsson (MiL) Subject: VL5-128 In-Reply-To: Your message of "Wed, 08 Jul 92 22:51:54 +0200." <9207082051.AA28670@abacus.HGS.SE> Date: Thu, 09 Jul 92 08:10:38 EDT From: Kenneth R. van Wyk Status: RO VIRUS-L Digest Wednesday, 8 Jul 1992 Volume 5 : Issue 128 Today's Topics: Re: 696/Scr2/Enemy (was Re: Scream II virus help?) (PC) Re: 696/Scr2/Enemy (was Re: Scream II virus help?) (PC) A Trojan in Sydney, Australia (PC) Check archives for Virus... (PC) Re: MtE analysis & report (PC) Re: Imprecise scanners (PC) Getting a Copy of Cohen's Paper Re: The "Lehigh" virus (CVP) Checksumming and false positives Re: virus-l stuff of late questionnaire 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: Mon, 06 Jul 92 22:40:58 +0000 From: mjbrown@magnus.acs.ohio-state.edu (Mike J. Brown) Subject: Re: 696/Scr2/Enemy (was Re: Scream II virus help?) (PC) Repeat after me: LESSON LEARNED THE HARD WAY. You know what I honestly thought? "Viruses aren't that common" and "it's too much trouble to buy all those disks and take all that time to back up." Yeah, I know I was playing with fire, and I don't deserve anybody's help, but both Frisk and "the McAfee people" seem willing to investigate it since the virus is destructive and is in the wild. I'm going to leave my other hard drive infected and untouched for now, and I'm running VirStop on bootup and F-Prot at least twice a session to be sure nothing's happening. I ran Norton Utilities which repaired some "lost clusters" and in the process ended up repairing some of the not-completely-disinfected files back to their infected state. What a mess! - -- Mike Brown mjbrown@magnus.acs.ohio-state.edu "The Universe is a spheroid region 705 meters in diameter." ------------------------------ Date: 06 Jul 92 22:54:47 +0000 From: frisk@complex.is (Fridrik Skulason) Subject: Re: 696/Scr2/Enemy (was Re: Scream II virus help?) (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: >:-) The "F-Prot people" are just Fridrik Skulason. Well...I have a few people working for me... :-) > I hope that he'll >include disinfection for this virus soon, I have... version 2.04B (to be released tomorrow or the day after) includes disinfection of this virus. > since the virus is >definitively in the wild. The discrepancy is only in the naming and >probably F-Prot will match the CARO standard. It does now... - -frisk ------------------------------ Date: Mon, 06 Jul 92 22:02:56 +0000 From: Jim.Baltaxe@vuw.ac.nz (Jim Baltaxe) Subject: A Trojan in Sydney, Australia (PC) I just returned from a two week holiday to find a request from a local radio station for information concerning a trojan program which was discovered in Sydney, Australia. Unfortunately the original wire service story was slightly garbled (it identified the program as a "virus" called "trojan" then said that it did not replicate itself) and did not include the name of the carrying files/programs to watch out for. It did say that the program displayed a message that it was a virus simulation, but it then seemed to distroy FAT & directory information making the hard disk unusable. Does anybody have any further details concerning this trojan, like what it actually does, how common it might be, where it has come from, spread to etc.? Please e-mail replies directly since there is some urgency if the information is to be incorporated into the news story that is being written (It'd be nice for a change to have an _accurate_ account of one of these things). My apologies if this is asking for old news, as I said, I was away on holiday. Thanks again. - -- Jim Baltaxe - jim.baltaxe@vuw.ac.nz Computing Services Centre - Victoria University of Wellington - New Zealand - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Time is such a valuable commodity because they're not making it any more. ------------------------------ Date: Tue, 07 Jul 92 14:37:30 +0000 From: billr@orl.mmc.com (Bill Richmond) Subject: Check archives for Virus... (PC) My appologies if this subject has been beaten to death but I need to know if most virus scanners (ie SCAN) look through all files in a zipped file? Is there a switch to make it do this? All email would be greatly appreciated... I can't give you brains, |\ but I can give you a O __________|_\______ diploma. \_.______________________| * * * * * * * * */ -- The Wizard of Oz __\____ |=================/ billr@orl.mmc.com ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ------------------------------ Date: Wed, 08 Jul 92 05:55:15 +0000 From: hps@sdf.lonestar.org (Holt Sorenson) Subject: Re: MtE analysis & report (PC) frisk@complex.is (Fridrik Skulason) writes: >TYETISER@ssw02.ab.umd.edu (Tarkan Yetiser) writes: > >fraction of the (rare) Method-3 encrypted files, which I hope I will >be able to fix as soon as I have succeeded in creating a single sample >that I don't detect. What exactly is Method-3 encryption ? What makes it different from the usual XOR schemes ? Holt Sorenson ------------------------------ Date: Wed, 08 Jul 92 05:59:58 +0000 From: hps@sdf.lonestar.org (Holt Sorenson) Subject: Re: Imprecise scanners (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: > >Version 91 of Scan is MUCH worse in identification than any previous >version. I have to agree with this. After disassembling and comparing the virus that I posted here a couple weeks ago about, it turned out that it was Datarape v1.1 not 1530. Oh, well. Guess we have to rely on down and dirty disassembling for real identification. Holt Sorenson ------------------------------ Date: Mon, 06 Jul 92 17:43:22 +0000 From: calvin@leland.stanford.edu (The Weasel) Subject: Getting a Copy of Cohen's Paper Hi There, Many of the general discussions on this group mention Fred Cohen's paper, his thesis I think. I was wondering if there is an ftp site where I can get this paper, or if someone out there could mail it to me. Thanks in advance. Peter - --- Peter Chang | "Would it save you a lot of time E-Mail: calvin@leland.stanford.edu | if I just gave up and went mad now?" Snail Mail: PO Box 9603 | Arthur Dent, The HHG Stanford, CA 94309 | ------------------------------ Date: 07 Jul 92 07:08:39 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: The "Lehigh" virus (CVP) rslade@sfu.ca (Robert Slade) writes: > computer literate. Student consultants at universities and colleges > are presented with a steady stream of disks from which files have > "mysteriously" disappeared. In November of 1987, however, it > appeared that certain of the failed disks were due to something > other than user carelessness. Well, the disks returned had a more serious problem than just a few files disappeared. They were unreadable. Of course, this happens every now and then, but what surprised the consultants at Lehigh was the quantity of returned unreadable diskettes. > The Lehigh virus overwrote the stack space at the end of the > COMMAND.COM file. (Early reports stated there was no increase in > file size: later research showed an increase of 555 bytes in the > size of infected files.) When an infected COMMAND.COM was run Then the "later research" is wrong. The virus indeed is 555 bytes long, but it does NOT increase the size of the file. It just overwrites the last 555 bytes of any file named COMMAND.COM. > uninfected COMMAND.COM files would be infected. A counter was kept > of infections: after four infections the virus would overwrite the > boot and FAT areas of disks with contents from the BIOS. The counter was kept in memory on computers without a hard disk and on the hard disk on computers which had one. According to some reports, a new version of the virus appeared in February the next year. It had the counter limit increased to 10. Unfortunately, Ken didn't save a copy of it, so now this variant is "lost". Regards, Vesselin P.S. I am taking my holidays the next week. This will have the side effect to reduce the traffic on Virus-L/comp.virus... :-) No e-mail sent to me will be lost, but don't expect a reply before the end of August. For several reasons I cannot install an e-mail answering machine. - -- 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: Tue, 07 Jul 92 20:24:59 +0000 From: duck@frcs.Alt.ZA (Paul Ducklin) Subject: Checksumming and false positives As someone said: > I am somewhat taken aback by the claims that integrity >checkers get substantial numbers of false positives or that they >require users to make decisions when they don't know how. Modifying executable files on disc is, alas, fair game under DOS. There are many programs which, when executing, record information about their last run (or what have you) back into their binary on disc. There are also plenty of software systems in which the installation utilities write configuration information back into binary files on disc. Program pairs like TURBO--TINST and TC--TCINST come to mind at once. Binaries modified in this way trip up integrity checkers as surely as unauthorised tampering or virus infection. Somewhere in the checking loop, users need to decide whether a modification was legitimate or not...a sometimes onerous burden. And, of course, if you have a slow virus (one which infects only when binaries change or are created), this burden becomes more problematic. In other words, nothing's easy :-) Paul Ducklin Somewhere near the middle of the City of Pretoria South Africa ------------------------------ Date: Wed, 08 Jul 92 15:12:00 +1200 From: "Mark Aitchison, U of Canty; Physics" Subject: Re: virus-l stuff of late bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: > ccmail.norton.com!cjkuo@norton.norton.com (Jimmy Kuo) writes: >> People seem to forget, 99.99999999% IS 100%. It is not, however, (sigh) The whole point of the "as close to 100% as can be reasonably tested" discussion is that a few mutations might get past (although the generation after them might not all escape detection, spoiling the analogy with biological viruses). The testing processes can only say a product probably detects ninety nine-point-so-many-nines percent of the mutations. Knowledge of the software that creates the mutations and the software detecting them, plus some assumptions about other software not changing things (e.g. the effects of a second virus!) might lead to a theoretical hundred percent. But what good is saying you have 100% detection of a subset of what one mutation engine can do at one point in time? Users really want 100% detection of 100% of the viruses that are known or unknown. What we get is advertising hype, in which the "numbers game" looks to now include the magic number "100%" in places it simply shouldn't be. >> 1) a standard location on a network drive could provide information to the >> integrity checker of updates conducted or available through the network. >>... > This is a nice idea and certainly has to be researched... However, > consider this: such tool will be something standard. What prevents the > virus from using it to register the infected files as properly > updated? But the important use of this is where there are areas that network nodes cannot write, so the updating can only be made on the server. In that case, you might ask, why worry about the programs in such read-only areas? Well, there could be programs of the same name (or .COM extension) that get executed first, created by viruses in data areas. Or there could be machines with a mixture of local programs and some network drives, meaning it is worth running change checkers - but they would keep choking on changes made by system adminstrators. So the idea is a good one, I'd say, so long as that "standard" area is safe. In fact, the more that change detectors can be told about the environment, the better. Not only should some areas be read-only (here we might not be talking only about networks), but rules like (there must not be a program with the same name (or even any programs!) in particular areas. I have a feeling that networks have so far mainly been thought of as a hassle for anti-viral programs, but they are - if used properly - a way of getting very good security for organisations where PC's and Mac's with diskette drives (and all that implies). They can provide the same level of security as good hardware protection schemes, without all the problems (well, with a different set of problems, perhaps!). Mark Aitchison ------------------------------ Date: Wed, 08 Jul 92 07:44:43 -0400 From: celustka@sun.felk.cvut.cs (Celustkova-k336-doktorand(Richta)) Subject: questionnaire Hello, I am postgraduate student on Department of Computers of Faculty of Electrical Engineering in Prague, working on my thesis "Software Reliability with regar- ding to computer viruses". Thesis is planned to be composed of three parts. First part should present computer virus problem today. The presentation should include introduction to computer virus problem in general with short history, description of typical computer virus behaviour and list of computer virus types today. Second part should give a mathematical description of computer virus infection process and reliability function of software attacked by computer virus. This part should include: - - description and results of experiments performed with several computer viruses, - - mathematical definition of infection process based on results of the experiments, - - mathematical description of reliability of software endangered with computer virus based on mathematical form of infection process which actually represents failure rate process (a term from reliability theory), - - verification of some of today's present antivirus programs regarding to software reliability maintenance. Third part of thesis should give a prediction of environment for computer viruses spread in future, a model of future computer virus and suggestion of the most effective antivirus protection. For the purpose of this part I prepared the questionnaire which results should give a prediction of environment for computer virus spread and evolution in future. I would like to have a sample of at least 100 filled in questionnaires. I hope that it is possible to obtain via VIRUS-L. The questionnaire is rather long ( about 25 K ) and detailed one. It has eight question groups : 1.Electronic data processing and electronic data interchange, 2.Information systems, 3.Hardware, 4.Operating systems and software, 5.Software reliability,security and security management, 6.Computer viruses, 7.Antivirus protection, 8.Standardization. I hope you will help me. Every answer, further suggestion, comment or advice regarding questionnaire as well as suggestions to my thesis topics will be appreciated. Thank you in advance. Best regards, Suzana Stojakovic-Celustka [Moderator's note: Anyone wishing to take part in Suzana's project may get the questionnaire by anonymous FTP from cert.org in pub/virus-l/docs/celustka.questionnaire. I would appreciate it if an e-mail based archive site would pick up this file and make it available by e-mail, and then announce it here.] - ------------------------------------------------------------------------- Address: Suzana Stojakovic-Celustka e-mail address: Department of Computers celustka@sun.felk.cvut.cs Faculty of Electrical Engineering Karlovo namesti 13 12135 Prague 2 Czechoslovakia fax : (+42 2) 290159 ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 128] ******************************************