From VIRUS-L@ibm1.cc.lehigh.edu Fri Jun 5 07:39:29 1992 Return-Path: Received: from csmes.ncsl.nist.gov (MACBETH.NCSL.NIST.GOV) by csrc.ncsl.nist.gov (4.1/NIST) id AA11030; Fri, 5 Jun 92 07:39:26 EDT Posted-Date: Fri, 5 Jun 1992 07:26:20 EDT Received-Date: Fri, 5 Jun 92 07:39:26 EDT Received: from IBM1.CC.Lehigh.EDU by csmes.ncsl.nist.gov (4.1/NIST(rbj/dougm)) id AA04109; Fri, 5 Jun 92 07:34:27 EDT Message-Id: <9206051134.AA04109@csmes.ncsl.nist.gov> Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 1965; Fri, 05 Jun 92 07:27:38 EDT Received: from LEHIIBM1.BITNET by LEHIIBM1.BITNET (Mailer R2.08) with BSMTP id 6264; Fri, 05 Jun 92 07:27:13 EDT Date: Fri, 5 Jun 1992 07:26:20 EDT Reply-To: VIRUS-L@ibm1.cc.lehigh.edu Sender: Virus Discussion List From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V5 #114 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L Status: R VIRUS-L Digest Friday, 5 Jun 1992 Volume 5 : Issue 114 Today's Topics: Re: Zipped Viruses (PC) information needed on v4 [f4] (PC) Re: (Primative ?) Question (PC) Re: McAfee VIRUSCAN V91 uploaded to SIMTEL20 (PC) Re: ISPNews and why 100% is the only good enough solution (PC) Re: How effective can TSR scanners be vs new viruses? (PC) Famous Last Words (re Scan91 for Windows (PC) Re: VIRx version 2.3 released (PC) re: OS2 Viruses (OS/2) Re: OS2 Viruses (OS/2) MVS Virii (IBM MVS) Re: Taxonomy of viruses re: Virus informational databases Re: how to evolve Contents of a talk on viruses Reply to Jim Bates' article in Virus Bulletin re: re:Clarifications -2 Related historical programs (CVP) NETSC9191B.ZIP from McAfee at garbo, SIMTEL20, etc (PC) VIRUS-L is a moderated, digested mail forum for discussing computer virus issues; comp.virus is a non-digested Usenet counterpart. Discussions are not limited to any one hardware/software platform - diversity is welcomed. Contributions should be relevant, concise, polite, etc. (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@IBM1.CC.LEHIGH.EDU (that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. 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: 01 Jun 92 17:07:36 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Zipped Viruses (PC) magnus@thep.lu.se (Magnus Olsson) writes: > At least McAfee's scanner doesn't only check files on the disk and > make a self-check, but also scans memory for viruses before doing > anything else. Doesn't this cure the above problem, as the > memory-resident stealth virus would be detected in memory? It does - for the known viruses. If it is a new virus (unknown to SCAN), it will not be found by the memory check; SCAN's self-check will not detect it either; and if it is a fast infector (it almost has to be, if it is a stealth virus), it will infect all the files that you are scanning... Now suppose that it has a damaging payload that says something like "IF Number_of_infections >= 100 THEN Do_Random_Damage"... No, when dealing with viruses it is always better to make sure that no virus is present in memory. The only 100 % foolproof method for doing this is to cold boot from a non-infected write-protected system diskette. 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 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, 02 Jun 92 05:12:17 -0500 >From: Anthony Di Nardo Subject: information needed on v4 [f4] (PC) Can someone please supply with information on the virus V4. SCANV91 recently reported finding this virus. I checked in the virus list file supplied with scan and also vsum but could not find any information. ------------------------------ Date: Mon, 01 Jun 92 20:48:29 +0000 >From: duck@frcs.Alt.ZA (Paul Ducklin) Subject: Re: (Primative ?) Question (PC) Thus spake bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev): >> Well, for DOS PCs, one can create a "fairly secure channel" by the >> tried-and-tested expedient of a clean boot. One of the delights of >Don't forget that we are speaking about self-checking programs. If >such program gets infected, the clean boot doesn't help a lot, since >you must execute it in order to activate the self-checking code. And >once you execute it, the virus will get control -before- the >self-checking code. From that point on it can do just -anything- with >the self-checking code - disable it, remove it, circumvent it, etc. OK. But if one can arrange a "clean boot", one can (hopefully) arrange a clean copy of one's favourite AV stuff too -- on the same write- protected disc as the kernel, COMMAND.COM and so forth. We're talking about a "fairly" secure channel, of course. But you're right to point a paranoid finger at the proverbial clean boot. I've dealt with many support calls (amongst colleagues who ought to know better) which go along the line of "I found the XYZ virus in memory. So I booted clean and scanned again: it survived the boot!". They had indeed clean booted, then run IPX and NETx off their local drives to connect to the network to run the AV stuff! So much, indeed, for secure channels.. Paul Ducklin Lounging in the City of Pretoria, South Africa ------------------------------ Date: Tue, 02 Jun 92 14:13:00 +0200 >From: "Jean-Pierre Engel (CMU Geneva)" Subject: Re: McAfee VIRUSCAN V91 uploaded to SIMTEL20 (PC) mcafee@netcom.com (McAfee Associates) writes: > I have uploaded to WSMR-SIMTEL20.Army.Mil: >... > VALIDATE VALUES FOR VERSION 91: > CLEAN-UP V91 (CLEAN.EXE) S:96,570 D:05-27-92 M1: D0F7 M2: 1AA1 > NETSCAN V91 (NETSCAN.EXE) S:75,050 D:05-27-92 M1: 33DA M2: 1AD1 > VIRUSCAN SCANV91 (SCAN.EXE) S:75,801 D:05-27-92 M1: 18FA M2: 127D > VSHIELD VSHLD91 (VSHIELD.EXE) S:41,005 D:05-27-92 M1: 194F M2: 11CF >... I have Uploaded from SIMTEL20: NETSC91B, CLEAN91, SCANV91, VSHLD91. I have found the following value with the validation prog.: netsc91b.zip S: 116,543 D: 6-2-1992 M1: 16DC M2: 12FC clean91.zip S: 141,577 D: 6-2-1992 M1: FD45 M2: 0101 scanv91.zip S: 129,268 D: 6-2-1992 M1: F2C3 M2: 0AC7 vshld91.zip S: 107,574 D: 6-2-1992 M1: 71B7 M2: 190B Where is the probleme? Thak you for your reply and best regards. Jean-Pierre +----------------------+------------------------------------+ | Jean-Pierre ENGEL | | | Univ. Med. Center | Bitnet: engel@cgecmu51.bitnet | | University of Geneva | Internet: engel@cmu.unige.ch | | 1, Michel-Servet | Phone: +4122 229340 | | CH-1211 Geneva 4 | FAX: +4122 473334 | | Switzerland | Tx: 421330 cmu ch | | ~~~~~~~~~~~ | | +----------------------+------------------------------------+ ------------------------------ Date: 02 Jun 92 11:40:57 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: ISPNews and why 100% is the only good enough solution (PC) FBCohen@DOCKMASTER.NCSC.MIL (fc) writes: > If you read ISPNews this month, the article with my name on it is not > even close to the article I submitted - so if you are following my > writings, throw that one out. Hmm... I don't read ISPNews, but I sent an article there - I'm wondering what will come out... :-) > I have 500 EXE files, MtE gets 500, scanner catches+cleans 495. Next The currently existing MtE-based viruses are able to infect only COM files, but this is not essential, since the MtE itself can be used for any kind of virus - including EXE infectors, boot/master boot sector infectors, viruses written in a high level language... > morning, I have 5 old MtE viruses and 495 new ones, scanner catches > 490... After a few weeks, every file is infected, and scanner detects > no infections!!! Yes, this is exactly why I said in my posting that all the tested scanners failed the test - even SCAN which missed only 4 mutations of 9,867... Meanwhile we got three more "100 % MtE detectors", so we are going to test them. One of them says it is based on the complete analysis of what MtE is able to produce (an analysis of the code, no heuristics). BTW, recently it was announced that the new version of VirX (2.3) is able to detect the MtE-based viruses. BEWARE! In my -very- preliminary tests, it missed 7 out of 27 Fear mutations! Don't use this scanner for detecting MtE-based viruses! It is unreliable!!! > I can just hear it now - "The infection was pretty bad - At > first all of the files were infected, but after a few weeks of cleaning > the systems every day, we completely eliminated the virus. Gee, what's > that ping pong ball on the screen?" BTW, we discussed the problem with David Chess and agreed that - -disinfection- of MtE-based viruses is even more difficult than - -detecting- them! So, if a system is found to be infected by such a virus, the recomended solution is to remove all executable files and to replace them with clean copies. 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 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: 02 Jun 92 10:57:12 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: How effective can TSR scanners be vs new viruses? (PC) pain.uucp!curtiss@markv.com, writes: > I've seen several TSR programs lately that claim that they will detect > and viruses on your system even if they are new viruses. Now I > understand that many viruses use the same methods but how reliable is > this claim? Most new viruses that aren't just reworks of an old virus > won't be caught will they? It depends. If the programs that you refer to are really nothing more than scanners, then you are correct - they will not detect new viruses, regardless what their authors claim. However, nowdays products that claim to "detect all viruses - including the unknown ones" are usually not scanners but integrity checkers. A resident integrity checker is perfectly possible - it is in fact sometimes called "integrity shell". There are already several such products: ASP Integrity Toolkit, VDS, and others. All of them are able to catch unknown viruses. Whether they are able to catch all possible viruses - no they are not, regardless what their authors are claiming. But they offer a very good protection - much, much better than the simple scanners. 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 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, 02 Jun 92 08:48:16 -0400 >From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Famous Last Words (re <100% MTE detection) (PC) >From: fc >Subject: ISPNews and why 100% is the only good enough solution >I can just hear it now - "The infection was pretty bad - At >first all of the files were infected, but after a few weeks of cleaning >the systems every day, we completely eliminated the virus. Gee, what's >that ping pong ball on the screen?" Heard much the same thing some time ago - received a call from another company with a massive Jerusalem infection on their network (at 9 pm and they needed help *now* 100 miles away natch). Once there overheard a conference call between the local manager and the "Head Office". H.O. did not understand why I was there, they had their own experts, after all their people had already cleaned the Jeru-B off the H.O. network three times in the last quarter ! 8*) Not all bad, that evening paid for my laptop and was the start of "active network defenses using login scripting" (see lots of previous postings). Of course today with most anti-virus programs permitting login validation (the .DOCs for McAfee v91 even includes a sample Novell login script) things are much easier and all major corporations now use active techniques, right ? Oh well, I could use a 486... Warmly, Padgett Obviously my own opinions and not necessarily my employer's (working on it). ------------------------------ Date: Tue, 02 Jun 92 15:46:38 -0400 >From: Alfredo Pinheiro Subject: Scan91 for Windows (PC) Greetings, Please, could anyone upload Scan91 for Windows? Thanks in advance, Alfredo Pinheiro - CPDSBD04@FGVRJ Database Administrator Fundacao Getulio Vargas - Rio ------------------------------ Date: 01 Jun 92 16:56:10 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: VIRx version 2.3 released (PC) trent@rock.concert.net (C. Glenn Jordan -- Virex-PC Development Team) writes: > 2. VIRx now detects all files encrypted with the "Mutating Engine" > attributed to the Dark Avenger that are not already destroyed by the > Engine's attempts to encrypt them (and most of those, as well). This requires a bit of clarification. No files are "destroyed by the Engine's attempts to encrypt them". However, the MtE sometimes (a bit too often, IMHO) generates something that I call a "zero-key decryptor". It does not encrypt the body of the virus and generates a decryptor which essentially does nothing else than juggling a few constants around some registers. No attempt to perform decryption is present in these cases. The files are not destroyed - they work perfectly and are able to spread the virus. However, since the decryptor is almost non-existent, it is very difficult to detect it... :-) Therefore, the scanners include a scan string for the non-encrypted virus in order to cover these cases. This is true for SCAN (it calls these cases "Mutating", instead of "DAME"), F-Prot (it calls them "Dedicated", instead of "MtE"), and obviously for VirX. However, if somebody writes a new virus using the MtE, these special cases will not be detected by the scanners - since the non-encrypted virus will not contain the old scan strings (unless they are taken from the body of the MtE itself - not from the virus). However, all encrypted variants of this new virus will still be detected by the scanners... Well, with a reliability that I reported. > If you find executable programs with MtE encryption that we miss, > please advise us at Microcom. As always, the BBS number is: :-) Yet another scanner that performs 100 % detection of the MtE... OK, I'll get it and perform some tests. 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 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: 02 Jun 92 08:39:18 -0400 >From: "David.M.Chess" Subject: re: OS2 Viruses (OS/2) A few comments and clarifications on Fred Cohen's OS/2 posting: > From: fc > Unfortunately for the scanner people, OS2 will not run DOS >type scanners on OS2 files with long filenames... That's OK; OS/2 will also not allow DOS type viruses to see those files, so they won't get infected anyway! Assuming that by "DOS type" you mean "runs in DOS sessions, not in OS/2 itself". Also, if your scanner is in C (say), it's reasonably easy to port to OS/2; IBM's Virus Scanning Program works in OS/2 itself as well as in DOS and DOS sessions, and when run in OS/2 it can see files with long filenames. (Despite my comforting words above, it's possible to have an infected file with a long filename, if it had a short filename when infected and someone has renamed it in the meantime; so a scanner that can see long filenames is a nice thing to have.) >(i.e. virus writers tend not to be rich) I will once again have to say that we don't know this, or have anything but intuition and very sparse anecdotal evidence to support it. Virus writers have access to computers, which right away puts them in the top 1% or so of the world's population. I would guess a good number of them could afford a simple OS/2 system with enough memory and disk to write a virus. It certainly doesn't require 120M! >Partition table infectors work, but if they use memory, they get >mangled by OS2 pretty fast. Also, the existing ones never spread, since they rely on hooking INT13 to get control, and OS/2 never calls INT13 for diskette I/O. >Boot block infectors and DIR viruses only work on FAT file systems. That's not entirely true; the FORM virus, for instance, can infect an HPFS-formatted partition. But the infected file system may no longer be reliable, and data loss is likely. >File infectors work As you point out later, you mean "some file-infectors work". In particular, "well-behaved" ones that use only documented DOS calls (and some of the more popular undocumented ones) work. >Low level viruses have to be OS2 customized to survive the OS2 memory >mangement process. And, for that matter, to be able to do -anything-. Low level viruses currently do INTs of various kinds (13, 21) to change files and disk areas; INTs don't work under OS/2 itself (although they do work in DOS sessions). >Evolutionary file infectors will continue to be a problem except for >those with integrity shells. At the moment, "evolutionary file infectors" are a problem only for anti-virus developers. From the end user's point of view, they're no more of a pain than any other virus, since all the good anti-virus products detect them just as well as non-"evolutionary" viruses. So I wouldn't have used the word "continue"! *8) Integrity shells and similar things are certainly a good idea, since we may reach a point where simpler methods no longer work; but we aren't there yet ("Death of Scanners Predicted; Film at 11"). >higher level viruses, such as spreadsheet viruses will operate >unchanged. Good point; OS/2 tries to be quite source-compatible with DOS, so viruses at the source or interpreter level that worked under DOS will likely work under OS/2 with little or no change. Note, though, that no such viruses are currently a problem for real users. >Conclusions - OS2 helps, but we're not out of the woods yet. Definitely true, and a good summary. Thanks, Fred! DC ------------------------------ Date: 02 Jun 92 12:06:38 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: OS2 Viruses (OS/2) FBCohen@DOCKMASTER.NCSC.MIL (fc) writes: > which is a version of the Integrity Toolkit for OS2. OS2 hase some > very nice advantages over DOS protection, in that the operating system > actually protects itself from arbitrary modification by user > processes!!! The access control package from IT will work far better > under OS2, and the protection from modifying executables will no > longer be bypassed by direct IO to the disk. In short, OS2 makes > sound techniques far more effective and removes all of the painful > restrictions of DOS (e.g. fitting the resident protection intto under Unfortunately, OS/2 also provides some excellent possibilities to the virus writer... Just to list a few: stealth technologies using the installable file systems feature, more executable objects to infect, a richer batch language (REXX) which makes batch viruses perfectly possible, ability to spawn even a non-resident virus to infect files in the background, viruses which install themselves as device monitors, the ability to directly execute files on another OS/2 machine connected via an Ethernet link (makes worms easy)... Have you taken into account all those possible attacks? I have to agree, however, than protection is much more easier added to OS/2 than to MS-DOS... > 3K, etc.) Unfortunately for the scanner people, OS2 will not run DOS > type scanners on OS2 files with long filenames, but on the good side, Ah, but this is not true. Some of them will run, if the files (even the ones on the HPFS partitions) comply to the 8.3 convention. And there are at least two scanners (IBM's VIRSCAN and Dr. Solomon's Anti-Virus ToolKit) which run perfectly under OS/2... > Partition table infectors work, but if they use memory, they get > mangled by OS2 pretty fast. The currently existing ones - yes. But it seems pretty easy to me to make an MBR infector OS/2-aware... > Boot block infectors and DIR viruses only work on FAT file systems. Correct, although most boot sector infectors might have problems and the DIR II virus itself might not work (I have not tested this). However, Dir II-type viruses will work perfectly in the FAT files systems. > File infectors work Only if they don't use too much tricks... In general, a virus which is able to spread under Novell (with loosy set protection rights) will be able to spread on the FAT partitions too... > Viruses that require more than 8086 CPUs don't work. Hmm, some of these require more than 8086 just because they use PUSHA or PUSH immediate... Don't all these instructions work under OS/2? > Stealth viruses aren't very stealthy, since OS2 is not bypassed, only > DOS IO is forged. Yeah, OS/2 is wonderful for examinig live stealth viruses. I mean - viruses that are using the current stealth technology... However, it should be possible to achieve wonders using the IFS technology - you can make the disk look almost in any way you want to... 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 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: 02 Jun 92 10:46:58 +0000 >From: "Tim Hare" Subject: MVS Virii (IBM MVS) While I have been following this group for only three or four months, I have seen no mention of virii, bombs, trojans or the like which have targeted large mainframe systems like MVS (which I work on as a systems programmer), or VM. I would like to know if such programs exist, if anyone out there knows. Because of the many security safeguards in MVS, I know it would be difficult for a bomb or trojan to operate, but I don't believe it to be impossible. I've read the logic manuals some, and I don't see ways to prevent the equivalent of a "boot sector infection" on a 370 platform (i.e. something infecting either the IPL bootstrap program, or the IPL program itself) - however I might be overlooking something. Anyone out there want to discuss this with me? I know there will be less interest (after all there are far fewer mainframes than PC's), but the issue is still important, since one mainframe bomb could conceivably affect many people. If you need to limit your discussion to private mail, because of the way I reach BITNET, you will need to send a message to register yourself into a Soft-Switch mail re-router before you can successfully reach me. You do this by sending a message containing FN= LN= to REGISTER@UFDIR.MAIL.UFL.EDU Regards, Tim Hare ------------------------------ Date: 01 Jun 92 16:38:45 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Taxonomy of viruses mkkuhner@phylo.genetics.washington.edu (Mary K. Kuhner) writes: > 1. Distance methods. One can find some measure of bit-by-bit distance > between two viruses, and use any one of several algorithms to combine > these into a tree. > Advantages: This can be completely automated--there is no judgement > involved in assessing the similarity of two viruses. It is also similar It is not so simple. A virus is not just a bit stream. It contains code areas, constant data fields, variable data fileds... The binary image of the virus in two different files may be (and usually is) different is compared on a byte-by-byte basis - becase of the different contents of the variable data fields. What you propose is theoretically possible if you have a detailed analisys of the virus - its breakdown into code, constants, text, data, and junk fields. Even the code parts must be further broken down further into routines. Only then you can apply some kind of cluster analysis. However, this is too effort-expensive and cannot be automated, so it is of no signifficant practical interest. > 2. Parsimony methods. Viruses can be hand-scored for the presence or > absence of various features--file types infected, stealth, encoding, > polymorphism, file destruction, etc.--and this data can be used to draw > a phylogenetic tree via parsimony. The assumption is that these traits > are not often changed by virus writers, so that viruses which share many > of them are likely to be related. > Advantages: The tree produced is likely to reflect intuitive ideas of > virus relationships, since it's based on traits that are felt to be > important. It won't be misled by such things as different literals in > the payload. Well, this is essentially what we are doing now... Unfortunately, it cannot be automated or even formalized - as you said, it reflects our intuitive ideas about virus relationship. > It would be possible to classify a virus based on a report of its > behavior, given enough detail, without having to examine an actual copy > of the virus. Indeed. Very often, if you describe detally a new virus to an expert, he would be able to tell you 'Aha, yet another Jerusalem/Stoned/Vienna variant'... 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 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, 02 Jun 92 00:56:00 +0100 >From: Anthony Naggs Subject: re: Virus informational databases Julian Leong (cert!jules@soda.berkeley.edu) brings up an interesting subject: > During the last 6-8 months that I've been reading the VIRUS-L > group I've noticed that no one has given a favorable review to any of > the virus databases -- particularly Patricia Hoffman's VSUM. Has any > effort been made to make any of the databases better? ... I haven't seen VSUM in a while, the phone connect time for download is l..o..n..g, but I was underwhelmed by the accuracy last time I looked. The virus catalogues from Hamburg are accurate, but rather terse and not really a database in the cross-referenced - easy to use sense. I don't know of anything better, the ideal author of such a database must have a number of skills or resources: * accurate technical information about each virus, preferably first hand so that (s)he can vouch for the quality of research. * communication skills so that the content is relevant & helpful. * understanding of Human Computer Interfaces so that presentation is of greatest help to users, (without the messy, rainbow coloured, confusion of some 'friendly' interfaces). * sensible judgement as to which features of viruses should be given most emphasis. * an appreciation of the different situations when the database is used so that an appropriate selection of operations can be provided. (I can think of one person with most of these, :-), but how do I pay my bills while writing/compiling the database? Constructive criticisms of my abilities in any of these areas are always welcome (see below), otherwise please complain to /dev/null). > ... To me such a > database would be an invaluable tool for the average computer user > that believes a virus has his computer under siege. ... [stuff deleted] > ... I am aware > that the FAQ mentions several sources of information but they also > exercise a hefty toll on one's pocketbook. I realize that many may be > hard-pressed for spare to devote to such a project, but doesn't it > seem worthwhile? Definitely, although pricing may be difficult: ideally it would be cheap and readily available for home users, students, etc..., but for large businesses such a database would be equivalent to a $1000 business directory - ie something that it is necessary to help assure the continued smooth running of the business. A high price would be necessary to meet the original development costs, and maintenance overheads, eg examining all new viruses submitted, possibly cataloging A-V products for effective detection, ... Regards, Anthony Naggs Internet: amn@vms.brighton.ac.uk or Janet: amn@uk.ac.brighton.vms Interesting offers? Phone: +44 273 589701 or write: P O Box 1080, Peacehaven, East Sussex BN10 8PZ, Great Britain ++ Profound message #182: What happened to my .sig? ------------------------------ Date: 02 Jun 92 11:16:24 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: how to evolve FBCohen@DOCKMASTER.NCSC.MIL (fc) writes: > In the addendum to my short course book, several types of evolution are > shown. It turns out pretty ueasy to make detection of evolved programs > NP-complete (or even exponential in same cases). Here's a simple > example: > a, b, ...., x, y, z Original program ja,r,js,f,jg,a,jb,...,j,jk Evolved > program, where j* is a jump to the location of instruction *. Ah, this is an old idea which we expected that will appear in some virus, but it actually didn't... Using it it is possible to write a polymorphic virus which is not encrypted. However, it is much more difficult than just to use variable encryption and modify the decryptor. Why do you think that detecting such viruses will be a NP-complete problem? One can easily follow the JMPs and record ("trace") the execution flow in order to obtain a good scan string. It can be done much easily than to detect V2P6, for instance... > How about another? > j=j+14 k=j+120-(58*2);j=k; This is essentially what the Mutation Engine does; only it uses more complex expressions. Can you show that detecting it is an NP-complete problem? > Another? > a; > b; > c; > d; is replaced by: > a; > call bb; > c; > call dd; dd: d > return bb: b > return Ah, this seems to be a new idea... 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 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, 26 May 92 17:23:31 +0000 >From: raphael@ms.uky.edu (Raphael Finkel) Subject: Contents of a talk on viruses I am a professor of computer science. Every so often, I am asked to talk about computer viruses. Much of my knowledge comes from reading this newsgroup on an irregular basis. I would like to share the notes for my talk with the newsgroup in the hopes that the members can improve the content and accuracy of the talk. Please send notes directly to me (raphael@ms.uky.edu or @ukma.bitnet); if the talk changes substantially and there is interest, I will repost later. Feel free to use this material yourself, if you want. I can send troff source to anyone who is interested; it looks better formatted for overhead slides. - ---- talk follows [Moderator's note: Thank you, Raphael. The complete text of the talk has been placed in the VIRUS-L/comp.virus archives; it is available by anonymous FTP from cert.org (192.88.209.5) in pub/virus-l/docs/finkel.presentation] ------------------------------ Date: 01 Jun 92 17:18:56 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Reply to Jim Bates' article in Virus Bulletin Hello, everybody! In the May issue of Virus Bulletin there was an article about the Vacsina viruses. The article was by Jim Bates and is partially based on an information which I published on Virus-L about four years ago. Therefore, I considered that it will be fair to forward a copy of my reply to this article here. Sorry for the wasted bandwidth. Regards, Vesselin To: Mr. Edward Wilding Editor-in-chief of Virus Bulletin Virus Bulletin Ltd. 21 The Quadrant Abingdon Science Park Abingdon OX14 3YS England CC: Virus News International, Virus News and Reviews, Virus Telex, Virus-L/comp.virus >From: Vesselin Bontchev Virus Test Center University of Hamburg Fachbereich Informatik - AGN Vogt-Koelln-Strasse 30, rm. 107C 2000 Hamburg 54 Germany 29 May 1992 To be published in full or not at all. Dear Mr. Wilding, I read with mixed feelings the article "The Vacsina Development Path" by Jim Bates, published in the May issue of Virus Bulletin. Mr. Bates is a person whose capabilities as a technical virus expert I estimate very much, so I was quite upset to notice what I understood as non-objective personal attacks against me in his article mentioned above. First, if you don't know it already, let me inform you that I am the "Storyteller" refered in the article. This is quite well known, since I have published what Mr. Bates calls "the Story" in the elctronic computer virus related forum Virus-L/comp.virus in December 1989. "The Story" is true and regardless of some technical mistakes which it contains, I am not ashamed to put my name under it. The technical mistakes are due to the fact that I was not an experienced virus expert at that time and some of the information which I presented was obtained from what the author of the viruses had told me, instead of from my own disassemblies of the viruses. Nevertheless, I admit the technical mistakes and would like just to notice that Mr. Bates' own articles are not totally free of them too - - even if we just consider his article about the GP1 virus... However, this does not give to Mr. Bates the right to refer to me as a suspicious "Storyteller", who is "a Bulgarian himself". Regardless of being a Bulgarian, I have devoted all my efforts to inform the people all over the world about the virus threat and to help them to combat it. But let me consider the different points in Mr. Bates' article and my objections against them. 1) Mr. Bates writes: "The Storyteller, a Bulgarian himself, claimed to know the author, whose initials he gave as TP." Yes, I claimed to know the author of these viruses personally and am still claiming this. We have been together for two years in the army, together for four years in the computer science department in one and the same university (the Technical University of Sofia), and even worked together for one year in one and the same laboratory in this same University after our graduation. His initials are indeed TP. Does Mr. Bates imply that I am lying? I am presenting enough facts which can be verified. Mr. Bates, who is a consultant of the Computer Crime Unit at Scotland Yard could arrange these "claims" to be verified, instead of putting my words publicly under suspicion. 2) Mr. Bates writes: "While engaged in this circular method of product development, TP took great care (the Storyteller tells us) to ensure that his viruses were not destructive." Yes, I am telling you this. The Vacsina/Yankee Doodle viruses were designed and created at the time when the only known viruses in our country were Vienna, Cascade, and Ping Pong. The sophisticated tricks used in the Dark Avenger's viruses were not invented yet. Still, TP indeed took great care to make his viruses not intentionally destructive. Has Mr. Bates found some intentionally destructive code in them? Why does not he mention that some viruses made in England (Fu Manchu, Superhacker) cause non-intentionally damage much more often than TP's ones? The interrupt tracing technique which is now used even in some anti-virus products was first implemented by these viruses. They used it to bypass the interrupt monitoring programs. Yet they bypass only programs that monitor INT 21h, not the ones that monitor INT 13h. Does Mr. Bates think that the reason for this is that the person who invented the technique didn't think about this possibility? Yes, he did think about bypassing INT 13h too, but refused to implement it, because it would bypass some disk cacheing programs too and could cause (in some rare occasions!) unintentional damage. None of the Vacsina/Yankee Doodle viruses tries to infect files with internal overlays - because they just cannot be properly infected without they functionality being destroyed. Does Mr. Bates know other viruses which take the same care? (I do know some, by the way, but they are very few.) Note that with the above arguments I am NOT trying to prove that these viruses are harmless. There is not such thing as a harmless virus. I do not try to condon TP's activities. I am just trying to justify my own words that he at least tried to make his viruses non-destructive. 3) Mr. Bates writes: "TP's later viruses (following this series) were described as 'much more clever' since they were able to 'hide' in all sorts of exotic places within the machine's memory - PC DOS I/O buffers, unused space of EXE headers and so on. They also became able to 'circumvent any memory-resident program that monitors INT 13h' and eventually became so clever and dangerous that even his close friend (the Storyteller) was forbidden access to the code." Again, Mr. Bates seems to imply that I am lying or telling stories. Yet he must know rather well that now other viruses exist, which implement similar ideas: the Number of the Beast viruses hide in the PC-DOS I/O buffers, The Rat virus installs itself in the unused space of the EXE headers and so on. Unforunately, the people who produced these viruses (who are Bulgarians, I have to admit) didn't take as even much care as TP did and freely released their viruses in wild... 4) Mr. Bates writes: "However, the Storyteller then proceeds to explain that the reason the viruses escaped to the outside world was not because TP spread them himself, but because they were left 'lurking' on his PC which was a shared machine. TP warned the other users of the presence of viruses on the machine but this was 'taken as a joke' and that is how the virus spread! At this point the story's credibility passes the breaking point - but true or not, this tale of foolishness did have a number of speciments of virus code accompanying it." Here Mr. Bates plainly says that he does not believe me. This is his right, but it is not his right to make the oppinion of the readers for themselves without refering to the full story. I would like to remind to Mr. Bates that at the time when the first TP viruses appeared, such a well-known computer specialist as Peter Norton claimed that computer viruses do not really exist and that they are just yet another urban myth. Was it so susprising then that most people in Bulgaria didn't take TP's warning seriously? Later I learned that one of the students did spread some of the variants intentionally, because he wanted to verify that they can really show a virus-like behaviour... This might look strange now and to the West, but yet another true story is that the father of the author of the Voronezh viruses was so proud of his son's creatures, that he went and spread them intentionally in his office... Now let me point some technical mistakes in Mr. Bates' article. 5) Mr. Bates writes: "The samples range in date from February 1989 to November 1990 and, somewhat strangely, they don't occur in order of development. The oldest is TP33 while the most recent is TP39." It has obviously not occured to Mr. Bates that I have not received those samples directly from the author and that the dates of the files reflect the dates when I have caught the respective variants in the wild. 6) Mr. Bates writes: "In appending this code, the 'MZ' in the header is destroyed but the program usually continues to function correctly." Can Mr. Bates provide some examples when the program DOES NOT continue to function properly (excluding the case of the self-checking programs)? The code appended to the files does essentially the same as DOS does when loading an EXE file. 7) Mr. Bates writes: "The next time the virus tests this file, it will appear to be a COM file and that is when infection occurs." Obviously Mr. Bates has failed to disassemble all the examples of the virus provided to him, otherwise he would have noticed that some of the later versions of the virus infect EXE files in "one pass", consecutively converting them into COM format and appending the virus code to them. 8) Mr. Bates writes: "With TP25, the author developped a musical penchant and included a routine to play the George M. Cohan tune 'Yankee Doodle' whenever the user pressed Ctrl-Alt-Del." For Mr. Bates' information: very few variants of the virus play the tune under those conditions. (Only variants 23-25, if I remember correctly.) The others play the tune at 17:00 (or more exactly, a few seconds before that). 9) Mr. Bates writes: "We are told that this was the first virus to introduce armoured code to deactivate debuggers." Obviously, Mr. Bates does not seem to believe what he has been told. Maybe in this case he is able to show us an earlier virus which has this capability? Or does he not believe in the exsistence of the capability at all? At least this is something which can be checked easily... 10) Mr. Bates writes: "This is a discrepancy in the Storyteller's narrative, since he insists that TP46 'is able to fight the 1701/Cascade virus'." Either Mr. Bates' disassembly of the virus is incomplete, or he is misunderstanding my words. Otherwise I cannot explain how he failed to notice that the virus (TP46) tests for the presence of Cascade during installation time, using Cascade's own "are you there?" call and then deactivates the virus if it is present. 11) Mr. Bates writes: (about TP46) "The musical trigger is still present but the virus has no other trigger routine other than code to deactivate the Italian virus." Again, Mr. Bates' technical tallents seem to fail him. The truth is that the virus DOES have a trigger to the musical routine and it is not triggered at "an indeterminate time after the virus goes resident" (as is written in the sidebar of Mr. Bates' article), but exactly at the same time as the previous variants - a few seconds before 17:00. Indeed, the routine is triggered with a probablity of 1/8 - obviously to prevent the virus from being noticed by some "experts" like Mr. Bates. 12) Mr. Bates writes: "This sequence of events is at variance with the Storyteller's description of the anti-Italian virus which he names as TP42. He insists that this changes it 'in such a way that after 255 reboots it will kill itself and the only thing which will rest on the disk will be the 'dead body' of the virus.'" Mr. Bates is correct this time and I admit my mistake. I would only like to point out that it was due to my unexperience at that time and to the fact that I just believed the virus author, instead of disassembling the virus myself... To err is human; everybody commits mistakes especially when speaking about viruses. Mr. Bates' own articles on this subject are far from error-free... 13) Mr. Bates writes: "The range of TP viruses has not grown since the original group of fourteen were sent to the West." Mr. Bates probably means that no LATER variants have been discovered. The reason is that TP has simply stopped writing viruses. However, onle EARLIER variant has been reported later - TP39 has been discovered signifficantly later than the other variants. In fact, I have discovered it myself in a Russian virus collection. 14) Mr. Bates writes: "Only TP04 and TP46 have been reported in the wild,..." This is a blatant mistake, which even disagrees with Scotland Yard's Computer Crime Unit's own reports - an organization of which Mr. Bates is a consultant. In fact, the first variant of the virus reported in the West was TP05. Probably the most widespread one is TP44, although variants 4, 6, 33, and 45 have also been reported. Maybe's Mr. Bates' routine to determine the particular virus variant is buggy... As a conclusion, I would like to emphasize that I continue to highly estimate Mr. Bates' technical talents as a computer virus expert. I would only like to suggest him to limit himself in his articles to technical matter, instead of using them for personal attacks against people like myself or Dr. Fred Cohen, who are at the same side of the virus fight as Mr. Bates... And while it is true that several computer viruses have been written in Bulgaria, it is definitively NOT true that all Bulgarians write viruses and none of their words should be trusted... Mr. Bates should trust (or at least verify) the words of at least some of them... Failing to do so he runs the risk to continue to make mistakes like in the case of the Dir II virus, which it declared as "curiosity", and "far from being dangerous" in Virus Bulletin's issue of November 1991. Obviously the virus has not read Mr. Bates' article, since it spreads happily in the UK - just as I have predicted... Sincerely yours, Vesselin "The Storyteller" Bontchev - -- 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: 30 May 92 20:44:04 -0400 >From: "Tarkan Yetiser" Subject: re: re:Clarifications -2 Hello, From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes > Subject: Re: Clarifications... part 2 (PC) >>> I certainly won't spend the time to test all the viruses we have on >>> your product. It doesn't worth the effort. Besides, even if it does >> Then you should adjust your claims on the capabilities of VDS. >> IMHO, you are making too many assumptions. > My claims are based on my knowledge about the internals of DOS and the > PC and on my knowledge of what some viruses can do, which I gained by > disassembling hundreds of viruses... I still claim that it is not > possible to stop all the possible stealth viruses, even if we restrict > ourselves to only the currently existing stealth/tunneling -techniques- I was not questioning your experience with viruses or your knowledge of the way DOS operates. Definition of "stopping all possible stealth viruses" is subjective. If a virus can do it, so can an anti-viral and vice versa. The odds are in favor of the anti-viral since it has nothing to hide :-)) >>> detect all the known viruses, this does not mean anything - most good >>> scanners do the same. In order to prove that it fails to protect >> Let's get serious. Scanners do the same? It takes a minor hack to >> outdate the niftiest one. We are concentrating on large scale/long term >> solutions. Remember Cohen's cost formulas? > Yes, I remember Cohen's cost formulas. I have studied most of his > publications very carefully. And you should read more carefully what I > am saying. I say that "detects all known viruses" is nothing more than > what the currently existing good scanner do. And "minor hack" means > that you are creating a new virus, which falls outside the above claim > (which is aimed only towards the -already- existing viruses). How can you constrain your argument like that? New viruses, hacked versions are an everyday reality. You cannot just stop the clock and say that a good scanner detects all known viruses. That's the same fallacy many people trying to come up with virus information banks are committing. By the time such an effort is completed, it will be obsolete. Back to square one again. IMHO, such virus-specific approaches are futile. More generic detection mechanisms should be considered. >>> construct a virus which uses them - something that I'll never do >>> anyway. What I might do in the future is a set of programs that >> Hope, you do not mean to create a virus just to break a certain scheme. > I think I was clear enough in saying that I won't construct a virus, > even for the purpose of demonstrating that a particular security > scheme is weak. I realize you are a serious researcher with good practices in dealing with such things. No innuendo was intended. Alas, the same cannot be said of others who try to prove a point by crafting viruses. >>> BTW, there's a kind of virus that will defeat -any- anti-virus system, >>> which is based on integrity checking -only-. This is the Darth Vader >>> virus. I know, you'll argue that it spreads so slowly that it's >>> unlikely to be successful in the wild... >> In the bigger scheme of things, it is trivial as far as the threat it >> might pose is concerned. Exceptions again. > I fail to understand your objection. I just plainly said that a virus > which uses Darth Vader's idea for infection strategy will evade the > integrity checkers. Do you object to that? Or shall I explain you how > to write a much better spreading virus than Darth Vader, using the > same idea and still evading the integrity checkers? I already > explained this privately to Yisrael Radai, I hope that he can confirm > what I am claiming... What I meant is that no one technique can be so successful that the viral spread cannot be contained. I still would like to hear what kind of an improvement to Darth Vader you had in mind. >> Good. You read Cohen's paper :-) > As I already said, I am following his publications very carefully. My > own experience shows me that he's usually right in what he says and > that ignoring what he says might have bad consequences. Well, yes, he has the kind of focus that many of us lack :-)) >> No, Vesselin, no. We operate quite differently. I'll describe it in >> private if you are interested. > Please, do so. I hope to be able to show you what a virus can do in > order to bypass your program and this is not for public discussion. I will shortly. >>> isn't mainly because it tries to bypass stealth viruses - something >>> which is a priori impossible without memory protection. Therefore why >> This is not correct. > Isn't is correct that the stealth bypassing feature is what prevents > your program from working on compressed disks and other disks that are > controlled by installable device drivers? For the most part, yes. What I meant is that, even without memory protection it is not impossible. The virus does not have the benefit of memory protection either. Both viruses and anti-viruses are subject to the limitations of the target system. Odds are in favor of anti-viruses. >> Memory protection is a different issue, and it >> would allow us to accomplish many other things, but the implementation >> overhead is too much. > The implementation is trivial, since this is already supported by the > '286 and '386 hardware. Implementation is not the problem. The problem > is that implementing it will break a lot of currently existing > applications and this is not acceptable for most people. No implementation exists in a vacuum. You just defined "overhead" :-) >> More compatible? Yes, this is needed. VDS 2.10 is a lot more flexible. > Good! Is is available? Hopefully, next week. Our acid testers discovered a few glitches that had to be fixed. Better logging facility was demanded too. Decoys are smarter (I should thank you as well). >>> As to UT, it -will- detect any stealth virus, if installed on a clean >>> system and used according to the manual. Something that cannot be said >>> about VDS... >> Any stealth virus? Well, you are contradicting yourself in principle. > And you fail to read carefully what I'm saying. I said that it is able > to do so IF installed on a clean system AND used according to the > manual. Indeed? Doesn't this put it in the same category as a home-made CRC checker? Even if a good integrity checker is not installed on a clean system, it should be able to detect new modifications to existing code. It will miss the ones that were there before installation, assuming a virus that was not recognized by the scanner component. How do you explain failure to notice new modifications? >> what is that magic quality that makes UT catch all stealth viruses? I > Ensuring that no such virus is in memory. I.e., booting from a clean > floppy. At least from time to time. I rest my case :-)) I could provide source code to a home-made CRC checker if it would be used only in the manner you prescribe for UT. Otherwise, all bets are off. But we know such home-made solutions are doomed since they do not get used as intended: boot from a clean DOS diskette and then look for modifications while a virus is not active. I shall let some magazines offer such solutions :-))) >> have reports from people who forgot to activate the memory resident >> component of UT and ended up infecting most of their programs as the > Had they used the safe check, it wouldn't happen. >> integrity checker component did its miracle. BTW, this was not a stealth >> virus, just a hacked version of Datalock. Of course, UT told her each > Yup, it will happen with any fast infector (like Dark Avenger), if the > virus is already active. The trick is to prevent it from being active. Fascinating! That very trick requires much user-awareness, something many people lack, and therefore the viruses continue to spread. Contributing to viral spread by a full-fledged anti-viral package is simply not acceptable. > Oh, BTW, the product is called UT only in the USA. To the rest of the > world it is known as V-Analyst III. I wonder if 6th Gen. made BRM people not to compete with them in the US. The developers probably would not sign their names under 6th Gen's docs. It is less than realistic, and more than just marketing hype. Very sad. Regards, Tarkan Yetiser VDS Advanced Research Group P.O. Box 9393 (410) 247-7117 Baltimore, MD 21228 e-mail: tyetiser@ssw02.ab.umd.edu ------------------------------ Date: Fri, 29 May 92 22:12:55 -0700 >From: rslade@sfu.ca (Robert Slade) Subject: Related historical programs (CVP) HISINT2.CVP 920529 Early viral related programs One of the factors involved in the success of viral programs is a study of the mindset of the user: a study of the psychology or sociology of the computer community. Since the spread of viral programs generally require some action, albeit unknowing, on the part of the operator, it is instructive to look at the security breaking aspects of other historical programs. "Password trojans" are extremely popular in the university and college environments (where most of the new security breaking ideas and pranks tend to come from anyway). These programs can be extremely simple. An easy "painting" of the screen with a facsimile of the normal login screen will generally get the user to enter their name and password. It is quite simple to have a program write this information to a file, or even mail it to a specific account. Most of these programs will then send back a message to the user that the login has been denied; most users will accept this as an indication that they have either a mistake in entering the login data or that there is some unknown fault in the system. Few question it even after repeated refusals. Some programs are sophisticated enough to pass the login information on to another spawned process: few users even know enough to check the level of nesting of processes. (A famous, if relatively harmless, prank in earlier computers was the "cookie" program which ran on PDP series computers. This program would halt the operation that the victim was working on and present a message requesting a cookie. There are consistent reports of viral programs following this pattern, including a very detailed report of a "Spanish Cookie" virus, however the author has never seen any such program. In the absence of such data I have, regretfully, come to the conclusion that this is another piece of computer folklore which has mutated into legend.) Another, lesser known, prank has a closer relationship to current viral programs. In the RISKS-FORUM Digest (6-42) in March of 1988 there was a detailed outline of the use of the "intelligent" features of Wyse 75 terminals. This was a specific instance of a general case of the use of intelligent peripherals for security cracking. In this case, the terminal had a feature which would allow keys to be remapped from the host system. Another feature allowed the keys to be called for from the host. This allowed email messages (actually only the subject line) to be composed which would remap a key to correspond to the "kill process and logout" command, and then have the command submitted by the terminal. With only a little thought, an email virus could be written taking advantage of this fact. copyright Robert M. Slade, 1992 HISINT2.CVP 920529 ============= Vancouver ROBERTS@decus.ca | Lotteries are a tax Institute for Robert_Slade@sfu.ca | on the arithmetically Research into rslade@cue.bc.ca | impaired. User CyberStore Dpac 85301030 | Security Canada V7K 2G6 | ------------------------------ Date: Tue, 02 Jun 92 05:57:05 +0000 >From: ts@uwasa.fi (Timo Salmi) Subject: NETSC9191B.ZIP from McAfee at garbo, SIMTEL20, etc (PC) - -From: hv@garbo.uwasa.fi (Harri Valkama) To: mcafee@netcom.com Date: Tue, 2 Jun 92 07:59:56 +0300 Date: Mon, 1 Jun 92 11:20:06 PDT From: mcafee@netcom.com (McAfee Associates) X-Mailer: Mail User's Shell (7.2.3 5/22/91) I have uploaded to SIMTEL20 PD1: I have uploaded to GARBO pc/incoming I have uploaded to CERT.ORG incoming I have uploaded to RISC pub/00uploads NETSC91B.ZIP NETSCAN 91-B network server virus scanner NETSCAN VERSION 91-B RELEASED Version 91-B of NETSCAN has been released. This release replaces This release replaces Version 91 which gave a false alarm of the V3 [F3] virus on the CHK123.EXE file from Lotus. VALIDATE VALUES FOR VERSION 91-B: NETSCAN 91B (NETSCAN.EXE) S:75,118 D:05-28-92 M1: CC02 M2: 17FD Aryeh Goretsky McAfee Associates Technical Support Thank you Aryeh. This is now available as: garbo.uwasa.fi:/pc/virus/netsc91b.zip - -harri- ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 114] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253