From lehigh.edu!virus-l Thu Jan 7 07:06:32 1993 Date: Tue, 5 Jan 1993 10:09:29 -0500 Message-Id: <9301051402.AA11929@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 #2 Status: R VIRUS-L Digest Tuesday, 5 Jan 1993 Volume 6 : Issue 2 Today's Topics: Re: A user's view of IBM's antivirus/2 (OS/2) Re: A user's view of IBM's antivirus/2 (OS/2) Re: Bugs in Mcafee OS/2 Clean (OS/2) Re: Questions about OS2SCAN and OS/2-based AV software in general (OS/2) Re: Viruses in OS/2 HPFS (OS/2) Re: NEW MPC On the way (PC) Virus Simulator MtE Suppliment (PC) TBAV 5.01 (PC) SUMMARY: FORM virus infection in Germany (PC) Re: Virus Simulator MtE Available (PC) Re: VSHIELD, VIRSTOP, ... comparison ? (PC) Solution to using %VARIABLE% with scan (PC) Re: Integrity Management (PC) Re: SVC 6.0 not rem. by F-PROT206a (PC) Re: Virus Simulator MtE Available (PC) Chkdsk / undelete fix from Microsoft. (PC) Clearing out old signatures (PC) "Beneficial" viruses Checksums, signatures, and "good enough" algorithms. (Generic) Definition of computer virus (was FC on virus creation) 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: 22 Dec 92 12:17:35 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: A user's view of IBM's antivirus/2 (OS/2) tyetiser@umbc5.umbc.edu (Mr. Tarkan Yetiser) writes: > DC>> or that their boot record had changed (because they > DC>> changed a volume serial number). ^^^^^^^^^^^^^ > >Hey, they should be really power users, if they know how to do that! > >For instance, I don't know how it can be done, without reformatting > >the disk, or using a sector editor... And anybody who is competent > >enough to mess with a sector editor in the boot sector, should not be > >surprised by a message that the said sector has been modified afterwards... > No, it is not really necessary to be a power user. If you use the > LABEL command with DOS 4.0 or above, it will update the BPB in the > boot sector. DOS 4.0+ records the volume label at offset 2Bh in the > boot sector. I know that. That's why a boot sector integrity checker should exclude this area. But David mentioned the volume SERIAL NUMBER, not the volume label... I didn't know that the serial number can be changed with the LABEL command... Can't verify it now - I am running DR-DOS - but I am pretty much convinced that it cannot... 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: 22 Dec 92 12:21:38 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: A user's view of IBM's antivirus/2 (OS/2) tck@fold.ucsd.edu (Kevin Marcus) writes: > >Hey, they should be really power users, if they know how to do that! > >For instance, I don't know how it can be done, without reformatting > >the disk, or using a sector editor... And anybody who is competent > >enough to mess with a sector editor in the boot sector, should not be > >surprised by a message that the said sector has been modified > >afterwards... > Well, I don't have the entirety of the original sentence, so I might > be missing something, but, int 25h will let you read in the boot > sector, you modify it however, and rewrite it with int 26h. Yes, of course, but as I said, anybody who is competent enough to do that (especially if s/he knows the difference between using INT 25h/26h under DOS 4.x+ and the DOS versions below) is a power user and shouldn't be surprised by a message the the boot sector has been changed... Besides, it is trivial to make the integrity checker exclude this area of the DOS boot sector from the integrity check... > Additionally, I have just recently seen some 486-50s with AMI BIOS's > (copyright 1992, I dont' know the exact date, though), that allow for > a "bootsector virus protection". Which is somewhat funny. Since I do > a lot of fdisking and formatting of drives on new systems, they scream > these messages, "Boot sector write - continue? (Y/n)" type of thing. Sounds like a very nice feature, unless it is not possible to turn it off, of course... :-) > THe funniest thing, however, is that it didn't do that when I ran sys > on a hard drive. In fact, they mean bootsector of floppy, or MBR on > hard drive. No, they probably mean track 0, side 0, sector 1 of ANY drive... This the boot sector on diskettes and the MBR on hard disks. 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, 22 Dec 92 09:57:19 -0500 From: Otto Stolz Subject: Re: Bugs in Mcafee OS/2 Clean (OS/2) Hello, on Fri, 18 Dec 92 18:13:10 +0000 Brett J.L. Landry said: > OScan discovered that there was stoned in two partitions on 120 meg > drive Obviously a canard! On hard-disks, Stoned is a MBR infector, hence it is *never* in a partition. (There is only one MBR on any one HD, which is outside of all partitions; rather, it defines the partitions.) > The problem came into play when I cleaned using OSclean. It > removed stoned but also removed the second partition loosing the 80 > meg section. I do not know OSclean. But if it indeed tried to clean Stoned off partitions (i.e. OS boot records), anything seems possible... > Any thoughts on this would be appreciated. Just my 2 Pennies' worth of thoughts... Merry Xmas to those who celebrate it, and best wishes to all, Otto Stolz PS. I've sent detailed Stoned info to J.L.Landry, privately. ------------------------------ Date: 22 Dec 92 18:40:09 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Questions about OS2SCAN and OS/2-based AV software in general (OS/ 2) aryeh@mcafee.com (McAfee Associates) writes: > >Do you know any way in which a known DOS virus can infect an extended > >filename on an HPFS partition? > Nope. But I myself create directories under OS/2 HPFS with names like > "MS-DOS 3.3 Files" and "Today's Downloads" in which I keep normal DOS > files. I'm sure other people do as well :-) Yup, you are right. And there is one more possibility, which I figured out myself after posting my message. A virus could infect a file with a short filename and the user could rename it later to an extended filename. If the scanner does not scan those files, then there is a danger for reinfection. 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: 22 Dec 92 18:53:08 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Viruses in OS/2 HPFS (OS/2) bjl1@Ra.MsState.Edu (Brett J.L. Landry) writes: > There has been aa lot of talk about OS/2 not being able to be infected > from regular old DOS boot sector viruses using the HPFS. This is false > since regular old STONED can infect both logical and physical parttions > on OS/2 using HPFS. Why wait for true OS/2 viruses when you can suffer > from regular DOS viruses. I don't know what do you call logical and physical partitions on OS/2 using HPFS, but Stoned can infect only one thing - the Master Boot Record of the hard disk. That is, the sector at track 0, side 0, sector 1. It can be infected on any IBM PC compatible machine, regardless whether it runs MS-DOS, OS/2, Unix, or whatever. Some systems (Unix) may become non-bootable after the infection. On other systems (OS/2) the virus will be unable to spread further, i.e. to infect diskettes. 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, 21 Dec 92 19:48:00 -0500 From: ncoast!arnold@usenet.INS.CWRU.Edu Subject: Re: NEW MPC On the way (PC) JDG111@PSUVM.PSU.EDU writes: >Rumor has it that a newer verion of the Phalcon/Skism MPC (Mass >Produced Code Generator) is going to be released sometime soon. My >source didn't say when, but "soon". Also, a new edition of the 40-Hex >magazine is suposedly coming out around New Years. Happy New Year >everyone. Yes there is a new 40-hex comming out, I am in-contact with a member and he said issue 9 would be out. The group for to everyone's releif disbanded after their big Bust, but unfortunately they banded together 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: 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 know I will have to test it but I will post my results.. Arnold ------------------------------ Date: 22 Dec 92 02:24:13 +0000 From: as194@cleveland.Freenet.Edu (Doren Rosenthal) Subject: Virus Simulator MtE Suppliment (PC) Doren Rosenthal Rosenthal Engineering 3737 Sequoia San Luis Obispo, CA USA 93401 November 21, 1992 >From: frisk@complex.is (Fridrik Skulason) >Subject: Re: Virus Simulator MtE Available (PC) >Date: Fri Dec 18 05:15:10 1992 >as194@cleveland.Freenet.Edu (Doren Rosenthal) writes: >> are using their MtE virus detecting programs correctly, >> additionally affording an opportunity for a practice >> training drill under safe and controlled conditions. >I just hope that everybody realizes that the ability of a program to >detect the files generated by the "Virus Simulator" does not at all >indicate if it will detect the actual viruses or vice versa, which >makes this effort quite pointless, IMHO. >- -frisk Frisk, 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. Because of the security nature of the Virus Simulator MtE Supplement, it is only available directly from Rosenthal Engineering and you should not trust it to be harmless unless you can directly trace its source to Rosenthal Engineering without compromise. The Virus Simulator MtE Supplement is only available to registered users of Virus Simulator, it is not shareware. Registered users of Virus Simulator should be receiving the Virus Simulator MtE Supplement shortly, without additional charge. The Virus Simulator MtE Supplement compiles a test suite of highly controlled, safe test viruses and special dummy programs they will infect (only). The test viruses will only infect the special dummy test programs generated by the Virus Simulator MtE Supplement. Provisions have been taken to discourage modification and tampering. Both .EXE and .COM viruses and dummies are provided. With the exception of their special safety and security provisions, the MtE test simulations are real polymorphic viruses. At the hart of these MtE virus simulations is an actual Dark Avenger MtE mutation engine. The MtE engine provides virus writers with the ability to turn their relatively simple programs into very sophisticated polymorphic viruses which are extremely difficult to detect by virus scanners. Each time the virus infects a host program it mutates, changes its signature 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. Although the MtE simulations produced by my program are safe and controlled, they are real viruses, capable of infecting their special dummy host programs. Vigilant anti-virus programs that are capable of reliably detecting the MtE mutation engine should report these simulations as being infected. Because these are real polymorphic viruses several samples are required to validate a virus detector, as each time the virus mutates in attempt to avoid detection, its signature changes. Doren Rosenthal ------------------------------ Date: Mon, 21 Dec 92 02:47:00 +0000 From: Malte_Eppert@f6002.n491.z9.virnet.bad.se (Malte Eppert) Subject: TBAV 5.01 (PC) Hello Vesselin, you wrote about TBCHECK: > It doesn't know about PATH companions. Well, it won't let them through. If you have a validated file called HELLO.EXE, and a path companion virus creates some HELLO.COM in a directory listed in the DOS path, and you issue "HELLO" in a path different from that one where HELLO. EXE resides in, then TBCHECK would give a warning like "HELLO.COM is not listed in the ANTIVIR.DAT-File. Stop execution?". So it takes care of it. Of course you're right with the other weaknesses (DOS file fragmentation, fixed polynomial). The product is unfortunately not designed to stand a directed attack, but it's a nice approach for a multilayer concept, I think. BTW: what do you think about the tunneling-stopping features of TBAV? Do the utilities effectively stop tunneling? They e.g. prevented TBSCAN from tracing to the BIOS entry point :-)) in version 5.01, and when I executed the Tequila virus, TBAV said: TEQUILA.EXE tries to trace to the BIOS entry point and advised me to reboot. >> BTW: I managed to have Armageddon infect a file after I allowed the >> virus to go TSR, though I've activated the whole product palette. >> What's that - a special way to put its code into a file, which TB >> doesn't recognize? > I'm afraid that I do not understand the question... There's nothing > special with Armagedon - it just prepends itself to the COM files - > like the Jerusalem virus does... That's what I thought, too... Well, how does it manage to successfully infect a file via 'standard methods' when TBAV is active, then? Any other link virus I tested was stopped (I just have a few ones). For example, the Cascade triggers the same warning ("This program tries to remain resident in memory and is not confirmed to be allowed to do this") as Armageddon, and when I allow it to go TSR, it tries to infect COM files on execution - but is caught by TBAV. Armageddon is not, it happily infects any COM file without any interception - why? cu! eppi - --- Via SCANTOSS V 1.37 * Origin: No Point for viruses - The EpiCentre! (9:491/6002) ------------------------------ Date: Tue, 22 Dec 92 04:39:41 -0500 From: David Hanson Subject: SUMMARY: FORM virus infection in Germany (PC) I wrote: >On 18 November 1992, we discovered the FORM virus on the boot >sector of 12 of our PC hard disks. >Question: Outside of using a commercial anti-virus package, > is there any way of eliminating this virus "manually" > (ie. editing sectors on the disk)? mcafee@netcom.com (McAfee Associates) writes: >> The DOS SYS command can be used to overwrite the boot sector off >> infected disks to remove the virus. Afterwards, run the DOS CHKDSK /F >> command to recover any clusters marked as bad by the virus (if using >> DOS 5.00, make sure your disk can have CHKDSK /F run safely on it, or >> upgrade to MS-DOS 5.00a). >>Oops, my mistake, CHKDSK recovers lost clusters, not bad >>ones. 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. CHKDSK can be pretty heavy-handed in doing FAT repair, so I would suggest to anyone attempting to use SYS to remove a FORM infection: Have your Disk Doctor (or whatever) handy 'cause you're going to need it! Again, thanks to all who responded... David Hanson cfsc-hga-gc-mis@augsburg-emh1.army.mil ------------------------------ Date: Tue, 22 Dec 92 11:11:40 +0000 From: icking@gmd.de (Werner Icking) Subject: Re: Virus Simulator MtE Available (PC) as194@cleveland.Freenet.Edu (Doren Rosenthal) writes: > Virus Simulator MtE Supplement Available > ------------------------------------------------ > > An MtE virus simulation test suite generator is available > suitable for use by general end users, system > administrators and educators. [...] Where? How to get it? Free/share/beg/charity/.../ware? - -- Werner Icking Werner.Icking@gmd.de (+49 2241) 14-2443 __o GMD - Gesellschaft fuer Mathematik und Datenverarbeitung mbH _`\<,_ Schloss Birlinghoven, P.O.Box 1316, D-5205 Sankt Augustin, Germany (_)/ (_) "Der Dativ ist dem Genitiv sein Tod." ~~~~~~~~~~~ ------------------------------ Date: Tue, 22 Dec 92 07:20:53 -0500 From: David_Conrad@MTS.cc.Wayne.edu Subject: Re: VSHIELD, VIRSTOP, ... comparison ? (PC) In VIRUS-L v5i203 (Vesselin Bontchev) writes: >mramey@u.washington.edu (Mike Ramey) writes: >> [requesting] a point-by-point comparison of VSHIELD and >> VIRSTOP? >> One of my questions is this: VSHIELD intercepts a keyboard reboot and >> checks for the presence of an infected diskette in the boot diskette >> drive; > >No, VIRSTOP doesn't have such feature (yet). > >2) VShield can scan a file while it is being copied. VirStop does not >have such a feature yet, although Frisk is promising it since a long >time. > >From recent comments Frisk has made here it sounds as though scanning while copying and scanning diskette boot sectors on access will be in the next version. For preventing boots from diskettes (to the extent it can be done) Padgett's NoFboot and SumFboot programs are excellent and have served me well. >3) VShield uses much more memory than VirStop. > >4) VShield can be swapped out to the disk, in order to reduce the >amount of memory used. This slows down the loading of the programs. >VirStop does not have such an option (although Frisk intends to >implement it), but then the memory requirements for VirStop are much >more modest. This isn't really correct. The /DISK option to VirStop causes it to read the signatures from disk instead of loading them into memory, and reduces the memory requirements from 12K to 2K. It is true that there is no way to swap out the 2K kernel, but that would almost be silly. Otherwise a fine comparison. Regards, David R. Conrad David_Conrad@mts.cc.wayne.edu, dave@michigan.com ------------------------------ Date: Tue, 22 Dec 92 07:20:55 -0500 From: David_Conrad@MTS.cc.Wayne.edu Subject: Solution to using %VARIABLE% with scan (PC) In VIRUS-L v5i203 (Vesselin Bontchev) writes: >craig@cadzook.columbiasc.NCR.COM (Craig.Williamson) writes: >> OK here is what I am trying to do: > >> SET NETDRV=x: >> scan c: d: e: /date/report %NETDRV%\vir_rep > >> The %NETDRV% is not getting replaced with x: like it should. > >Hmm... Very strange... It -should- work... What does %NETDRV% get >replaced with? What DOS version are you using? What command >interpreter (COMMAND.COM/4DOS)? In any case, it is not a problem of >SCAN; it is a problem of the operating environment you are using... > >[Moderator's note: I agree that this appears to be a problem with the >operating environment, and I'd like to request that follow-ups get >handled via e-mail, with the exception of a follow-up summary of the >solution (if anyone cares to post one).] There's nothing wrong with his operating environment; chalk this one up to user error. He's typing those lines at the command prompt -- DOS only replaces environment variables when interpreting lines of batch files. Put those lines in SCANIT.BAT and it would work. (Try typing "echo %COMSPEC%" at the command prompt and see what you get.) I'm cc'ing this solution to Craig. Regards, David R. Conrad David_Conrad@mts.cc.wayne.edu, dave@michigan.com ------------------------------ Date: 22 Dec 92 12:51:18 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Integrity Management (PC) RADAI@vms.huji.ac.il (Y. Radai) writes: > ing"). First, you write as if all algorithms have a seed. Well, in My initial thought was that the database of checksums is kept on-line. If it isn't (i.e., if it is stored on a write-protected diskette), then you don't need any cryptographic checksum, of course. But if it is, you cannot just use plain MDx or any other known keyless algorithm, because a virus could use the same algorithm to compute the new checksum of the infected file and update the database of checksums, so that everything will look OK... In these cases, you -must- have some kind of key that is kept unknown to the virus. > the case of the MDx algorithms, I suppose you could say that the > initial contents of the buffers constitute a seed; also that DES has a > seed when used for authentication purposes (ANSI X9.9), namely the > initial block. But what do you mean by "using a different seed for > the checksum" in the case of CRC? Well, a CRC is usually computer like this: crc = INITIAL_VALUE; while ((c = getc (file)) != EOF) crc = crc_table [(crc & 0x00FF) ^ c] ^ (crc >> 8); Usually INITIAL_VALUE is 0, but you could set it to anything you would like... > More important, in the case of MDx and X9.9, how do you know that > varying the seed is enough? You *may* be right, but to the best of my > knowledge, neither the buffer contents of MDx nor the initial block of > X9.9 were designed for that purpose. You are right, I don't know whether it is secure enough. But you have to do something with the keyless algorithms, if you want to achieve different checksums for each user and not allow the virus to guess the correct checksum of the modified object... 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: 22 Dec 92 13:26:30 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: SVC 6.0 not rem. by F-PROT206a (PC) kratz%orville@uunet.UU.NET (Thomas Kratz) writes: > A week ago I had two guys with their pc's in our office who had > cought the SVC virus in version 6.0. Gosh, how did you manage to get infected by this relatively not widespread Russian virus?! > SCAN V99 reported [SVC] and(!) [SVC 5.0] in the boot sector and on > various .com & .exe files, an information I decided not > to trust, because of the multiple report of infection. Right, SCAN 99 incorrectly reports two infections for this virus. If there is enough interest, I could post a full list of viruses that SCAN 99 detects as more than one. > F-PROT found (correctly) SVC 6.0 (4644 bytes), but only on the .com & .exe > files. The virus also infects SYS files. If F-Prot does not say this or if it does not detect this, then it is a bug. > After removing the virus (which f-prot claims to do correctly) > all infected files were absolutely identical with the originals, that were > present on security-disks, but knowing that SVC 6.0 does infect the boot- > sector i ran scan again; with the result, that it reports [SVC] and [SVC5.0] > still present in the boot sector. Sounds indeed like a bug in F-Prot to me... The virus is indeed multipartite and infects boot sectors, COM, EXE, and SYS files. It also does funny things to the source of the program AIDSTEST (AIDSTEST.C), if it finds it... This is a Russian anti-virus program, written by Lozinsky. 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: 22 Dec 92 13:35:04 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Virus Simulator MtE Available (PC) frisk@complex.is (Fridrik Skulason) writes: > I just hope that everybody realizes that the ability of a program to > detect the files generated by the "Virus Simulator" does not at all > indicate if it will detect the actual viruses or vice versa, which > makes this effort quite pointless, IMHO. Well, I tend to agree with you, just maybe "not at all" is a too strong expression. Depending on how exactly his dummy files are generated, their detection might, or might not be connected with the ability of a scanner to detect the MtE-based viruses. I suspect that he's using the MtE itself to generate them. In this case, not detection of one of them by a scanner does not necessarily mean that the scanner will not detect the real virus, but in any case should prompt further investigation... 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, 22 Dec 92 09:57:21 -0500 From: Jon Freivald Subject: Chkdsk / undelete fix from Microsoft. (PC) In line with our discussion of the CHKDSK bug in DOS 5.0, I received an upload on my BBS from a user who has a relative who works for Microsoft. It contains a text file, as well as a new chkdsk.exe and undelete.exe. For any who wish to obtain this, you can download it by calling (516) 483-5841, n-8-1, 300-9600. Sorry, due to feed troubles my mail-server is off-line. The file is /public/dos/chkupdt.zip. Jon ============================================================================= Jon Freivald ( jaf%jaflrn@uunet.UU.NET ) Nothing is impossible for the man who doesn't have to do it. ============================================================================= - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiqxd1UAAAEEAMFukk0cHx1XUSNdnwuDC9+paXaH5DAQfRQaADxoTQddbh/P UJ9GAfFvpmnTYNvNjZYZ6GtMS8E/VlNyPnpqNuqbFVkDJhhBTYq5FeKBZVHItSNW ------------------------------ Date: Tue, 22 Dec 92 14:37:55 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Clearing out old signatures (PC) 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, extract the portion of this message between the (cut here) lines and name it CLEAR.DEB (the portion beginning with "a100" and ending with the blank line after the "q" - NOTE: that last blank line must be there as must the blank line following "JMP 102". Next run "DEBUG Subject: "Beneficial" viruses I believe that Fred Cohen, who is flogging his "beneficial" viruses again, is being very mischievous, and doing the industry a great deal of harm. I gather that in fact these are not viruses at all, in the sense that we use the term. They may fit Fred's original definition, but the modern definition makes much more sense, and it is impossible for Fred to turn the clock back single handed, any more than I can resurrect the original meaning of the word "gay". Fred is well aware of this, but he persists in using the term "virus" for his product, as he knows it will get him far more publicity, but when you attack him he says 'Are you going to ban FORMAT?', which, by his definition, is apparently a virus. The trouble with this talk of 'good' viruses is that it provides all the would be virus writers in our schools with the perfect justification for their activities. After all, if Dr. Fred Cohen is selling 'good' viruses, why shouldn't they see if they can do the same? He makes the situation even worse when he announces that he has made 1500 viruses in an afternoon, and that this shows scanners are dead. In the first place it shows nothing at all, as no one is interested in viruses until they enter circulation, and in the second place it provides evidence for the skeptics who believe that we amuse ouselves in our spare time writing viruses to keep ourselves in business. Unfortunately there are already so many kids trying to emulate Fred, that none of us have the time, let alone the need, to write viruses. Seasons Greetings to everyone. 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: Tue, 22 Dec 92 10:04:27 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Checksums, signatures, and "good enough" algorithms. (Generic) From: Y. Radai > Padgett Petersen wrote: >>> I agree but take it one step further, again the algorithm should be >>> tailored to the specific machine and use a different seed on each - this >>> in no way weakens the algorithm but gives each PC a different signature >>> for a particular file. Break one machine and "malware" must start all over >>> again on the next. > Vesselin Bontchev replies: >> In fact, it depends on the algorithm used. If you are using a CRC, >> just using a different seed for the checksum does not make it secure - >> you must change the polynomial each time. If you are using something >> cryptographically strong as DES, MD4, MD5, MD2, or some such, then >> just changing the seed is enough. >I agree with part of this. Yes, it depends on the algorithm, and >using a different seed does not necessarily make an algorithm secure. Ok, I did not explain fully. This is a expansion of a discussion that Ross Greenberg, Yisreal Radai, & I had in Virus-L about two years ago. The complete concept did not use a single algorithm, rather it was selected from a 3x3 matrix at the time of installation. Combine a 1 of nine algorithm with a unique seed and you have a signature that is difficult for software to forge - at least forging the signature would be more difficult than breaking the mechanism. First a sample matrix: Row: ROL ROR NOP Column: XOR ADD SUB In practise the code might select two to make things more difficult & would look something like this for .COM files (stages would be needed for .EXEs over 64k). CX contains the file size. DS points to the file in memory. Row: ROL ROR NOP Column: XOR BX ADD DX SUB XOR SI,SI MOV BX, sig1 MOV DX, sig2 L1: LODSB XOR BL,AL ROL BX,1 ADD DL,AL ROR DX,1 LOOP L1 (please, no jibes at the algorithm - this is just an example) Appending BX to DX would produce a 32 bit signature. A final confusion might be whether the order is BX-DX or DX-BX. Since we have three unknowns (initial seed, algorithm, final order) that are selected at installation, it becomes very difficult for malware to determine which is acually in use. The easiest way is to compare a known program with its signature but even there there are many crossing points & if the wrong branch is taken, the forgery will fail. Further the process will have to start from scratch on the next PC. Now, it becomes easier for the malware to try to break the program than to forge a signature so armoring is the next step. The basic point is that the above code is very tight so performance would not suffer (in tests I have been able to process nearly 64k/second on a 4.77 Mhz 8088 PC). The selection process can take a little longer since it is only done once. The above is an example of quantum economics: the strenght of the algorithm is matched to the speed of the process and the strength of the process itself. IMHO there is no point in making the signature any stronger since, unlike DES, it is never transmitted outside the PC it is used on (and, in fact the user never needs to know what it is). I trust this is sufficient explination. * | abc defgh And a Merry Christmas to All, ijklmno pqrstuvwx Padgett yzabcdefghi jklmnopqrstuv wxyz __||__ ------------------------------ Date: Tue, 22 Dec 92 14:29:28 -0500 From: celustka@sun.felk.cvut.cs (Celustkova-k336-doktorand(Richta)) Subject: Definition of computer virus (was FC on virus creation) Hello everybody, I was following for some time discussion about ethical correctness of Fred Cohen's virus creation. It seems to me that most of dilemmas arises from different understanding of term computer virus. I am relatively new on this list, so don't know if the definition of computer virus was properly discus- sed earlier and if some general definition was accepted. If was I would like to know which one. I saw different definitions in literature (I looked in the VIRUS-L FAQ too :-))and would like to sublime what I've read till now in following statement : Computer virus is set of instruction written with intention to cause some unwanted function in system in which is currently situated. Virus has ability of reproduction, it can propagate through different media, may evolve over time and can mutate. Is that correct definition ? I would really like to know one which wouldn't lead to misunderstandings. Cheers, ______________ | | Suzana /| Who am I ? | /~~~~~~\~\ / |______________| ( * * )/ /( ___ ) ~ \______/ @/ \@ - --------------------------------------------------------------------------- Address: Suzana Stojakovic-Celustka e-mail addresses: Department of Computers celustka@sun.felk.cvut.cs Faculty of Electrical Engineering celustkova@cs.felk.cvut.cs Karlovo namesti 13 12135 Prague 2 phone : (+42 2) 293485 Czechoslovakia fax : (+42 2) 290159 ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 2] ****************************************