From virus-l@lehigh.edu Wed Jan 6 10:42:28 1993 Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/2.0) id AA12611; Wed, 6 Jan 1993 21:45:51 +0100 Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA13502 (5.67a/IDA-1.5 for ); Wed, 6 Jan 1993 15:42:28 -0500 Date: Wed, 6 Jan 1993 15:42:28 -0500 Message-Id: <9301062041.AA14693@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 #4 VIRUS-L Digest Wednesday, 6 Jan 1993 Volume 6 : Issue 4 Today's Topics: Re: os2-stuff (OS/2) Re: Viruses in OS/2 HPFS (OS/2) Info on Music Bug virus (PC) Re: Vshield vs Virstop (PC) Jerusalem (Israeli) Virus (PC) Re: Brain Viruses (PC) Info on 1575 Virus Needed (PC) Is this VIRSTOP version current? (PC) Yet another undocumented MS-DOS 5.00 FDISK "Feature" (PC) Re: NEW MPC On the way (PC) Re: SUMMARY: FORM virus infection in Germany (PC) Re: Virus Simulator MtE Suppliment (PC) Clash between FDISK/MBR and scanners (PC) Re: MS-DOS CHKDSK & VER /R (PC) Re: Is this a new virus? (PC) McAfee libel suit (From Risks-l Digest...) Interesting Book Re: Viral Based Distribution System Changes at ASP On the definition of viruses Call for Papers - National Computer Security Conference 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: 05 Jan 93 22:25:57 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: os2-stuff (OS/2) KARGRA@GBA930.ZAMG.AC.AT writes: > as pointed out in point 10 at least *.dll and *.drv files contain code which > cannot be executed by the user, but is loaded and executed as any other *.ov? > As there are viruses which infect overlays, they can be infected in a similar > way. Could somebody check how exactly the DLL and DRV files are loaded in OS/2? The only reason that "some viruses can infect overlays" is that they infect on INT 21h/AH=4Bh, instead of INT 21h/AX=4B00h. Since some overlays are loaded with INT 21h/AX=4B03h, a sloppy written virus could infect them by mistake. How are the DLL and DRV files loaded in OS/2? If they are not loaded using any INT 21h/AX=4Bxxh function, then it is rather unlikely that any of the currently known viruses will infect them... 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: 05 Jan 93 22:50:52 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Viruses in OS/2 HPFS (OS/2) buhr@umanitoba.ca (Kevin Andrew Buhr) writes: > For one thing, if a boot sector virus infects your system on start up, > it won't survive the OS/2 startup process. You may get the "Your > computer is stoned!" message, since this is displayed (randomly > approximately one out of every eight times in many cases) before the > operating system is loaded. HOWEVER, OS/2's own floppy disk device A minor nit picking - Stoned displays the message only when you are booting from a floppy. It is unlikely that OS/2 will be often booted from a floppy... > In summary, the worst you can expect is your system simply not > working. An infected OS/2 system generally won't infect new floppy > disks unless you use the special "DOS from Drive A" sessions with an > infected boot floppy. There is one more danger. If the virus is Michelangelo (which -is- a Stoned-like virus; it is even a Stoned variant) and the current date is March 6 - bye, bye hard disk, regardless of the operating system installed on it... :-) 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: 29 Dec 92 00:40:00 +0000 From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) Subject: Info on Music Bug virus (PC) Quoting from Scott Jeffrey B to All About Info on Music Bug virus ( on 12-09-92 SJ> My 286 clone was recently infected with the 'Music Bug' virus. SJ> Every time something was read from the hard disk, it played SJ> a random tune. Didn't seem to be harmful - just annoying as hell. The Music Bug virus isn't generally destructive, but the FAT table structure on hard drives gives some weird effects occasionally. SJ> I'm just curious. Does anyone know exactly what this virus does? SJ> Is it harmful? Might I still have problems in the future as a result SJ> of this virus? Like all boot sector viruses. if you didn't scan every diskette in the building, the virus will probably come back sooner or later. I have heard that Music Bug waits four months before the musical effects start. The tune is usually 36 notes long. Bill - --- * WinQwk 2.0 a#383 * Thunder Byte USA BBS (615) 442-2833 ------------------------------ Date: 29 Dec 92 00:28:00 +0000 From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) Subject: Re: Vshield vs Virstop (PC) Quoting from Vesselin Bontchev to All About Re: Vshield vs Virstop (P on 12-09-92 VB> BTW, I think that there is a way to tell Vshield to use the EMS if yo VB> have some. This is a feature that Virstop doesn't have yet. Vshield Vesselin: Vshield doesn;t go into EMS. It can be loaded high in upper memory blocks. However. this is done with the /LH parameter. Vshiels will not work if users use LOADHIGH from DOS 5.0 or LOADHI in QEMM or some other memory manager. VB> has also some other features, like an attempt to do on-line integrity VB> checking, but this is not implemented well enough. There are several problems with the integrity checking by Scan, and Vshield. 1. Some programs will not run after the CRC is added to the file. So it is necessary to remove the CRC. Scan filename /RV will remove the CRC. 2. These CRCs will not detect stealth infectors because stealth viruses disinfects infected files when an infected file is opened for any reason. 3. These CRCs will not detect the presence of companion infectors because these companion infectors do not attach to files. Bill - --- * WinQwk 2.0 a#383 * JULY 13TH activates Jul 13th ------------------------------ Date: 29 Dec 92 06:33:00 +0000 From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) Subject: Jerusalem (Israeli) Virus (PC) Quoting from Samid Hoda to All About Jerusalem (Israeli) Virus on 12-20-92 SH> I need some information on the Jerusalem B virus as it has SH> infected almost every single file on my system. Does anyone know how SH> it spreads and how it spreads so fast? Any advice in getting rid of SH> the virus would be appreciated( except for a low level format as that SH> is an obvious option.) Jerusalem B is a file infector. It runs as a TSR, and will infect every executable file you run except for .COM files larger than 62K. I believe the virus is around 1800 bytes long. 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] after Clean gets finished, turn your computer off for a few seconds, then back on. The reason for this is that since Jerusalem-B runs as TSR. After the computer is clean, make a bootable diskette, then place a write protect tab on the notch. Then the next time you have another virus, you will be ready. I hope this has been of help to you. Bill - --- * WinQwk 2.0 a#383 * CASPER activates Apr 1st ------------------------------ Date: 28 Dec 92 23:53:00 +0000 From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) Subject: Re: Brain Viruses (PC) Quoting from Kevin Marcus to All About Re: Brain Viruses (PC) on 12-07-92 KM> brain, whatever you wanna call it). It is a VERY old boot sector KM> infector (some of the newer varients can infect the MBR). This means KM> they infect disks, and not files. It uses some steath techniques, so KM> that it hides the it's infection by redirecting calls to read in the I'f I not mistaken. I believe "Pakistani Brain" was the first virus that used stealth routines. No-Int (sometimes called Stoned three) is also a stealth boot sector virus. However; the stealth routines are quite sophisticated. Bill - --- * WinQwk 2.0 a#383 * SATURDAY THE 14TH activates Saturday 14th ------------------------------ Date: Thu, 31 Dec 92 23:31:28 +0000 From: Mark Kovarski Subject: Info on 1575 Virus Needed (PC) Since I do not have FTP access intil early 1993, can someone provide me information on the 1575 Virus. I remember seeing a Database which is maintained by a german University that had great technical information about every Virus. Could someone copy the portion about the 1575 Virus and post it here. Also, what anti-virus programs can detect it and remove it? I would *GREATLY* appreciate it. Sincerely, Mark K. Happy New Year to All. E-Mail: kovarski@zooid.guild.org ------------------------------ Date: Tue, 05 Jan 93 11:15:39 -0500 From: sgr4211@ggr.co.uk Subject: Is this VIRSTOP version current? (PC) Just noticed that the version of VIRSTOP that came with F-Prot 2.06a announces itself as v2.05 on loading. Only noticed this after 1st Jan when it complained about being old. Is there a newer version? Steve Richards. ------------------------------ Date: Tue, 05 Jan 93 13:01:14 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Yet another undocumented MS-DOS 5.00 FDISK "Feature" (PC) FDISK /STATUS (but UNFORMAT/PARTN/TEST/L is better 8*) Warmly, Padgett ------------------------------ Date: 05 Jan 93 18:22:37 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: NEW MPC On the way (PC) ncoast!arnold@usenet.INS.CWRU.Edu writes: > again about a week after the anouncement. I have also been told that > McAFEE can already detect all the virus created with the MPC. Note: At least version 99 of SCAN cannot. > There is a new Mutation Engine out called TPE, it E It is from Italy > or Somewhere near in, and supposedly it is better an MTE. I don't TPE seems to be from the Netherlands, according to my information... There is already at least one virus that uses it; we are calling it Girafe. TPE is smaller than MtE - about 1.6 Kb, compared to the 2.5 Kb of MtE. At first look it seems indeed more polymorphic, because there are no fixed things like JNZ backwards as in the decryptors generated by the MtE. However, if you take a closer look, you'll see that it is actually less polymorphic and if you ignore the noise instructions in the decryptor, the total number of possible decryptors seems to be less than in MtE... Of course, further analysis is needed in order to confirm that. 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: 05 Jan 93 18:30:02 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: SUMMARY: FORM virus infection in Germany (PC) cfsc-hga-gc-mis@augsburg-emh1.army.mil (David Hanson) writes: > Thanks to all who wrote to tell me to use SYS.COM. However, I don't > think that I would recommend SYS without the caveat that you may lose > some FAT information. Areyah alludes to it in his response, and in > reality, there can be quite a bit of destruction. Could you please elaborate -how- could SYS.COM cause destruction of some FAT information? Assuming that you are using the same DOS version your DOS partition is formatted with, of course. But even if you don't, all damage I can think about is that your DOS partition could become non-bootable or SYS could just refuse to work (i.e., "no room...")... 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: 05 Jan 93 18:39:30 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Virus Simulator MtE Suppliment (PC) as194@cleveland.Freenet.Edu (Doren Rosenthal) writes: > Thank you for your comments on my Virus Simulator MtE Supplement. I'll be > mailing the first copies january 1, so I hope your opinion is mistakenly > based on my original Virus Simulator and not your technical review of a > program you could not possibly have examined yet. Readers of this forum may > recall the considerable controversy and strong opinion you expressed > beginning two weeks before my release of that program as well. Well, Frisk's comments about your Virus Simulator turned out to be right even after it appeared, so I would guess that he understands the principles behind such "test" tools even better than you do... > pattern to avoid recognition. A few examples of viruses that employ this > same MtE engine are: > > Pogue, Dame, MtE, Gotcha, 7S, Mut, Dedicated, Fear, Groove, Coffee Shop, > MtE-Spawn, Questo, Crypto Lab, Encroach. Corrections: By "7S" you probably mean "Seventh_Son" ("7S" is how SCAN calls it) and it is NOT based on MtE. "Dame" is not a virus, it is just how SCAN call -all- MtE-based viruses. Gotcha is NOT an MtE-based virus. Dunno what you are calling "Mut" but I know about no such MtE-based virus. The CARO name for "MtE-Spawn" is "Insufficient". The correct spelling of the last two names is "CryptLab" and "Encroacher". "MtE" is not a virus; it is a tool for building polymorphic viruses. When looking at the names you quoted, I am getting the impression that you knowledge about the names of the existing MtE-based viruses is based on the reports generated by SCAN, since it sometimes reports the unencrypted variants of Pogue as "Gotcha" (which is correct - Pogue is actually a Gotcha variant with MtE polymorphism added), and one of the older versions of SCAN reported "7S" in some unencrypted variants of one of the other MtE-based viruses (not certain about that; have to check). > Although the MtE simulations produced by my program are safe and > controlled, they are real viruses, capable of infecting their special dummy > host programs. So, you are not only distributing malicious software (MtE) but also real viruses, hmm? Anyway, Frisk's comment is still valid. The ability of a scanner to detect "your" viruses may or may not be related to its ability to detect -real- MtE-based viruses. > Vigilant anti-virus programs that are capable of reliably > detecting the MtE mutation engine should report these simulations as being > infected. Usually, yes, but not necessarily. It depends on how your viruses infect their victims, how often they are generating unencrypted replicants, how exactly the particular scanner works, and so on. As I said, it may or it may not be connected with the actual ability of the scanner to detect the existing MtE-based viruses... But if a scanner - -doesn't- detect some of "your" viruses, this is a serious reason for further investigation. It does not necessarily mean that that particular scanner will also miss a real MtE-based virus, but it is worth checking why it misses your virus... 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: Tue, 05 Jan 93 15:31:08 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Clash between FDISK/MBR and scanners (PC) >From: "Roger Riordan" >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. Cannot speak for all versions but the FDISK.EXE in MS-DOS 5.00 dated 3-22-91 is identical to that of 11-11-91 and both zero out all the unused bytes between the end of the messages at absolute offset 0D9h and the beginning of the partition table at offset 1BEh. Of course FDISK/MBR will not have *any* effect with any DOS before 5.00 so this may be the cause. It is possible that PC-DOS or some other proprietary version or even that there may be an "export" MS-DOS that might have the effect Roger reports. (can only speak for what I have seen). Please reply directly & I will summarize any verifiable exceptions. Warmly, Padgett ps anyone know what the FORMAT switches /SELECT, /BACKUP, & /AUTOTEST do (MS-DOS 5.0) ? ------------------------------ Date: Tue, 05 Jan 93 15:50:52 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Re: MS-DOS CHKDSK & VER /R (PC) From: bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) >Quoting from A. Padgett Peterson to All About MS-DOS CHKDSK & why VER / on >12-20-92 AP> Further, COMP finds no difference between this COMMAND.COM and the on AP> just expanded from a new set of distribution disks that is dated 11-1 >Just for your information, FC (File Compare) does a better job at >comparing files than COMP. Agree that FC produces a nicer (and unlimited length) output than COMP but it was designed to compare text files and you have to remember to use the /B switch on binaries or the check may terminate on the first marker. COMP, on the other hand, uses no intelligence, is much faster, and has worked the same way in all DOS versions. I prefer COMP when all that matters is "are the files identical?". To each his/her/its own. Warmly, Padgett ------------------------------ Date: 05 Jan 93 22:18:57 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Is this a new virus? (PC) tck@bend.ucsd.edu (Kevin Marcus) writes: > >0,0,8. This is irrelevant. What is rellevant is that the problem with > >Michelangelo occurs exactly because the "standard" Stoned variant put > >the original MBR at 0,0,7 - at the same place as Michelangelo, and > >because the two viruses do not recognize each other. > Oh, come on, it is relevant. The original problem: Disinfection of a > Stoned and MIchelangelo infection. Where they move the orig. MBR is > quite important, because in one case, it is possible to remove the > viruses by pulling the original MBR up, and in the other, it is not. That's exactly what I am trying to tell you, but maybe I am not expressing myself clearly enough. The Stoned+Michelangelo problem occurs exactly because both viruses store the original MBR at ONE AND THE SAME PLACE, therefore the original MBR gets lost. Such system cannot be disinfected, because there is no original MBR. The only solution is to put a new MBR, which the anti-virus program must carry with itself. Of course, some care should be taken not to destroy any PARTITION TABLE information. 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: Thu, 31 Dec 92 16:43:39 -0500 From: HAYES@urvax.urich.edu Subject: McAfee libel suit (From Risks-l Digest...) Hi. Following is a cross-post from risks-l digest. Does anyone know more about what exactly happened? And are they (if any) any legal problems for the end users? BTW, found nothing in the local paper ... In any cases.... Happy New Year to all! Claude. - ------ begin forwarded message --- RISKS-LIST: RISKS-FORUM Digest Thurs 31 December 1992 Volume 14 : Issue 20 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Date: Thu, 31 Dec 92 11:31:38 PST From: Peter G. Neumann Subject: Antiviral technology target of legal action The Washington Post has an article by John Burgess (at least some of which appears in today's San Francisco Chronicle) discussing a federal judge's order to McAfee Associates of Santa Clara CA, to stop distributing their Pro-Scan Version 2.31 and ViruCide Version 2.33 and derivative products. Imageline Inc. of Richmond VA (maker of PicturePak and ValuePak) has sued McAfee Associates for libel, fraud, and other misdeeds, because those antiviral products mistakenly identify Imageline products as containing viruses. Stay tuned for further details. - ----- end forwarded message --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Claude Bersano-Hayes HAYES @ URVAX (Vanilla BITNET) University of Richmond hayes@urvax.urich.edu (Bitnet or Internet) Richmond, VA 23173 ------------------------------ Date: Tue, 05 Jan 93 10:54:00 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Interesting Book Over the holidays took a much-needed rest (family went to visit cousins in Scotland & I was permitted to stay home 8*) & caught up on some reading. One of the more interesting ones was *War in 2020* by Ralph Peters. Published in March of 1991 it missed the breakup of the Soviet Union though the afterward makes it clear that the author was not surprised. An interesting sub-plot developed late in the book was that high-tech weaponry takes humans out of the tactical loop and relegates them to strategic decisions. Further, if you can remove trust in the weapons (virus etc.) you can destroy an adversary's capability to defend himself. Somewhere in the last few years we seem to have lost Heinlein's "tell me three times" concept for trust and IMHO much of our difficulties today stem from this. Philosophically, Padgett ps In a modern PC disk information is stored in the CMOS, Partition Table and the DOS Boot Record. The code is trivial and given any two, the third can be easily reconstructed. ------------------------------ Date: 05 Jan 93 22:40:49 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Viral Based Distribution System ygoland@edison.SEAS.UCLA.EDU (The Jester) writes: > Yes.. I understand. And may I say I STRONGLY disagree with Dr. > Cohen's definition. Any human-language definition will be inexact. For an exact definition you should check his mathematical definition that involves Turing machines... I think it is explained in his paper "Computational Aspects of Computer Viruses", published in "Computers & Security". It is also explained in his Ph.D. thesis (although the paper is better) and is mentioned (without any explanation, which is rather confusing) in his booklet "A Short Course on Computer Viruses". > A program in the login script that checks if you > have been updated and then updates you is NOT a virus. The program in > the loader does NOT reproduce itself it reproduces another program > which is itself NOT a virus. No, you still do not understand. The "virus" is not just the login script - it is the whole package. The login script is just the active segment that seeks for "infectable" machines and transfers the rest of the "virus code". It is actually a worm, but Cohen's definition does not seem to make a difference between a virus and a worm. > loader installs an infected program =) For me the acid test of a virus > is:Can it reproduce itself? Correct. So, the copy of the anti-virus package on the server reproduces itself on each workstation when this workstation tries to log in. Automatic update. Reproduction. Virus-like behavior. > Is the login script programming trying to > run around and find other login scripts or executable files to infect? Another misunderstanding comes from the fact that most people distinguish between a "virus" (i.e., something that modifies executable files) and a "worm" (i.e., something that copies itself as a whole). While it is useful to make such a distinguishment for practical reasons, there is no real theoretical difference (e.g., what "files" do the boot sector viruses infect? How about the companion viruses? They do not modify anything...). > No. It doesn't infect anyone! 'Damnit Jim, its not alive!' Yup, it does. It "infects" the workstation with a copy of the "virus/worm" - the anti-virus package. 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: Mon, 04 Jan 93 22:09:50 -0500 From: fc@turing.duq.edu (Fred Cohen) Subject: Changes at ASP As of Jan. 1, 1993, ASP has decided to transfer all maintenance, marketing, and other responsibility for all information protection products currently made and marketed by ASP to outside companies in which we have no financial interest. We are therefore no longer involved in the commercial aspects of protection software, except for the licensing of basic technology developed at ASP. This transfer is being done in order to eliminate any appearance of conflicts of interest with a new venture just started as a joint project between Information Integrity and ASP - called: (tm) "Protection Experts " (tm) Protection Experts provides immediate and unbiased answers to your most pressing questions about computer security policies and practices, electronic eavesdropping and countermeasures, malicious software, network protection, and protection products and services. We rapidly identify, retrieve, and distribute relevant documents and information from our extensive collection of books, conference proceedings, government publications, on-line information services, journals, popular media, and product literature. (tm) For further details on Protection Experts, please contact us at: 8:30AM-2PM Eastern 2PM-8PM Eastern TEL:US 412-422-4134 TEL:US 907-344-5164 FAX:US 412-422-4135 FAX:US 907-344-3069 Dr. Frederick B. Cohen President ASP ------------------------------ Date: Tue, 05 Jan 93 22:30:03 -0500 From: fc@turing.duq.edu (Fred Cohen) Subject: On the definition of viruses Computer viruses do not have to be malicious, they do not have to be Trojan horses, and they do not have to enter without the knowledge or consent of the user. Any definition that depends on these properties depends on peoples' opinions, skills, and knowledge, and are thus not "testable" in the scientific sense of the word. (See Popper and others for more details). For example: The "stoned" virus is not apparently malicious - perhaps others do not agree - perhaps this is why we should not make our definition depend on that property (i.e. peoples' opinions). Is it a virus for you but not for me? The "Brain" virus notifies you of its presence with a copyright message displayed whenever you do a directory of an infected disk. It doesn't fit the Trojan horse definition by my understanding if it announces itself. Is it not a virus? If I know I am placing a Jerusalem virus in my computer, is it not a virus? It entered with my knowledge and consent, thus it is not a virus by the third criterion above. Is it a virus for you and not for me? The mathematical definition first published in 1985 is testable, and appears to properly differentiate viruses from non-viruses. Perhaps someone else wishes to do a better job, but let's not make definitions that are senseless. So what is a computer virus? In simple terms, it is a sequence of instructions that, when interpreted in an appropriate environment, "replicates" in that at least one relica also "replicates", etc., ad infinitum. Want an example? A backup program replicates by making an exact copy of itself (if it does a good job) on the backup media. In many environemnts, you can run a program from the backup media (e.g. a remote file system backup). If you run the backup program from the backup media, and it again replicates, etc., ad-infinitum, then it is a virus! Suppose we put the backup program for DOS in an IBM mainframe? in that environment, it would probably not be a virus, because it wouldn't probably operate in the mainframe operating environment. Thus we see the intimate link between a virus and its environment. I don't want to waste more space here, but there is a good deal more to know and think about in applying this definition. On benevolent viruses: If a virus doesn't have to be malicious, perhaps the same technology can be beneficial! When I published this idea in 1984 (in the paper that first described viruses to the scientific community), nobody commented on it, but when I published the results of 7 years of research with benevolent viruses in The Sciences, I was very publicly called a heretic. The loudest complaints came from the academic community! It seems they are not as open minded as they claim to be. They were closely followed by the anti-virus industry, which has been using the press to make money by claiming that all viruses are bad. At least they have well understood motives. I don't so much mind that these people have their opinions, everyone is entitled to that. I do mind when they force their opinions on others - for example, when they tell people to write letters to The Sciences telling them that it is wrong to publish the concept that viruses can be used for good, and when they claim that I am telling people about the possibility of benevolent viruses only to sell a product. If that were true, I wouldn't publish my results, I would only use them for my financial advantage. It is certainly true that the anti-virus vendors (which I am no longer one of) stand to make money by convincing people that all viruses are bad and that they are a major threat. Another upsetting example is the censure at the DPMA, ACM, IEEE Annual Computer Virus and Security Conference held in New York each March. In this conference, they blank out portions of papers and provide full text only to conference attendees. So if I publish details of benevolent virus techniques and how to make them safe, only the attendees will see the details, and the paper will look like swiss cheese. Does the fairness doctrine apply to electronic media? Do the DPMA, IEEE, and ACM have such a lock on research in the computer field in the US that we allow their censorship to prevent us from hearing about ideas that aren't popular? Do the universities support this censorship of ideas? Do they do it for grant money in computer security? (They must be pretty hard up if the grant money in this field is enough to sway them into anything.) Maybe this posting is about a little bit more than just viruses. It seems to me that censorship in all its forms leads to ignorance and all of it's evils. To quote Maxwell Smart: "If only they could have used their power for goodness instead of evil." I am glad that other people who read virus-l don't rule out the possibility of benevolent viruses. I'm sad that so many virus-l readers have been misled about the true meaning of viruses. I'm even sadder that our university people in the US don't think that new and different ideas are good and decide to try to censure them. I'm really glad that I no longer sell virus defenses, because I think it's a pretty shady business (except for a few good companies that tell the truth about viruses and their products). ------------------------------ Date: Fri, 01 Jan 93 20:53:36 -0500 From: Jack Holleran Subject: Call for Papers - National Computer Security Conference CALL FOR PAPERS 16th NATIONAL COMPUTER SECURITY CONFERENCE Sponsored by the National Computer Security Center and the National Institute of Standards and Technology SEPTEMBER 20-23, 1993 BALTIMORE, MD The National Computer Security Conference audience represents a broad range of interests drawn from government, industry, and academic communities. Their interests include technical research topics, security applications, and management issues. Papers may be addressed toward the entry level or skilled practitioner. Special emphasis will be placed on papers addressing the special needs of users and creating better security for user information technology resources. We are pleased to invite academic Professors to recommend Student papers in the application of Computer Security methodology. Three student submissions will be selected by the Technical Committee for publication in the Conference Proceedings. To be considered, the submission must be authored by an individual student with the assistance of their academic Professor and be recommended by their academic Professor. Only one copy for student submission is required. BY FEBRUARY 8, 1993: Send eight copies of your draft paper* or panel suggestions to the following address. See author instructions for your submission format. * Government employees or those under Government sponsorship must so identify their papers. Mailing Information National Computer Security Conference ATTN: NCS Conference Secretary, AS 11 National Computer Security Center Fort George G. Meade, MD 20755-6000 BY MAY 15, 1993: Speakers selected to participate in the conference will be notified when their camera-ready paper is due to the Conference Committee. All referee comments will be forwarded to the primary author at this time. For additional information on submissions, please call (410) 850-0272. Preparation Instructions for the Authors To assist the Technical Review Committee, the following is required for all submissions: Page 1: Type of submission (paper, panel, tutorial) Title of submission Keywords Abstract (not to exceed 250 words) Author(s) Organization(s) Phone number(s) Net address(es), if available Point of Contact Submissions having U.S. Government sponsorship must also provide the following information: U.S. Government Program Sponsor or Procuring Element Contract number (if applicable) U.S. Government Publication Release Authority Note: Responsibility for U.S. Government pre-publication review lies with the author(s). The submission (pages 2-9, these are the 8 pages of your submission): Title of submission - do not include author(s), address(es) or organization(s) Abstract (with keywords) The paper (Suggested Length: 8 pages, including figures and diagrams; pitch: no smaller than 8 point; 1 inch margins on top, bottom and sides.) A Technical Review Committee, composed of Government and Industry Computer Security experts, will referee submissions only for technical merit for publication and presentation at the National Computer Security (NCS) Conference. No classified submissions will be accepted for review. The Conference Committee provides for a double "blind" refereeing. Please place your names and organizations ONLY on page 1 of your submission, as defined above. Failure to COMPLY with the above instructions may result in non-selection BEFORE the referee process. Papers in excess of 8 pages may also result in non-selection BEFORE the referee process. Papers drafted as part of the author's official U.S. Government duties may not be subject to copyright. Papers submitted that are subject to copyright must be accompanied by a written assignment to the NCS Conference Committee or written authorization to publish and release the paper at the Committee's discretion. Papers selected for presentation at the NCS Conference requiring U.S. Government pre-publication review must include, with the submission of the final paper to the committee, a written release from the U.S. Government Department or Agency responsible for pre-publication review. The release is required no later than July 1, 1992. Failure to comply may result in rescinding selection for publication and for presentation at the 16th NCS Conference. Technical questions can be addressed to the NCS Conference Committee by mail (see Mailing Information) or by phone, (410) 850-0CSC [0272]. For other information about the conference, please call (301) 975-2775. ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 4] ****************************************