Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/1.5) id AA25977; Wed, 24 Feb 1993 18:59:52 +0100 Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA10614 (5.67a/IDA-1.5 for ); Wed, 24 Feb 1993 11:42:29 -0500 Date: Wed, 24 Feb 1993 11:42:29 -0500 Message-Id: <9302241456.AA04775@first.org> Comment: Virus Discussion List Originator: virus-l@lehigh.edu Errors-To: krvw@first.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 #33 Status: R VIRUS-L Digest Wednesday, 24 Feb 1993 Volume 6 : Issue 33 Today's Topics: Viruses, Greeks, and Trojan Horses Re: Scanners getting bigger and slower Re: Virus education In-Re: "Re: Sale of Viri" [sic] Re: Virus detection by code inspection Re: Censorship Question about Patricia Hoffman and John McAfee Re: os2-stuff (OS/2) Re: Suggestion to the developers of resident scanners (PC) Central Point Antivirus and Stacker (PC) file name virus? (PC) Re: Minimal virus scan? (PC) EXE/COM switch (PC) Re: Scanning memory (PC) Re: standardization (PC) Re: Uruguay on PS/2 Ref disk (PC) re: logic bomb in PKZIP (PC) How can you recover a hrad drive from joshi? (PC) Re: my idea for detecting file infectors (PC) An undetectable virus I have been infected with. (PC) CP Antivirus with Stacker (PC) Re: standardization (PC) SIMTEL20 subdirectory name changes (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.org 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, krvw@first.org ---------------------------------------------------------------------- Date: Mon, 22 Feb 93 15:26:57 -0500 From: Brian Seborg Subject: Viruses, Greeks, and Trojan Horses I have been watching the attempts to define a virus here with some degree of nausea and boredom and thought it only appropriate to punish those responsible by forcing them to read my own thoughts on the subject. Let's go back to the beginning. It all started with the Trojan Horse. You see, the Greeks were fighting the Trojans, and the Trojans were basically pouring hot oil on the Greeks, shooting them with arrows, and generally making the battle a bit of a downer for the Greeks. The Greeks came up with an idea to take advantage of the Trojan's love of horses, and to turn the tide of the battle to their advantage. To do this they built a large horse made out of wood, and loaded the entire Greek army inside. The Trojans woke up the next day and saw that the Greek army had disappeared and in their place stood this large wooden horse. Thinking that the Greeks had given up and had left the horse as a token of their admiration of the Trojan's war prowess, the Trojans pulled the horse inside and had a big party. That night as the Trojans slept the Greeks crawled out and wiped them out. This story has different flavors, but it will suffice for the rest of my discussion. Now, we leap forward to the time of computers, and some joker figures that he can mess up your system by fooling you into running some program which promises great speed increases, or a neat game, and this type of program with hidden functionality becomes christened a "Trojan Horse." Your computer is the Trojan Fort, you are the Trojan, the program is the Trojan Horse, and the code inside it becomes the Greeks. Seems appropriate. Next we progress to program code which not only houses malicious code, but code which can spread to other programs turning them into Trojan Horses. We called these viruses since we assume the original program is similar to a cell, and the virus code is similar to a biological virus which attaches to the cell making it function like the virus. We also saw the development of worms which much like a biological tape worm are self-contained and can consist of one or several segments, and essentially exist to tap or sap the resources of systems attached to networks. But, we have seen viruses which attach to programs in different ways other than direct attachment. Companion viruses come to mind, where the viruses actually create a seperate and distinct file which has the same name as a legitimate program, but which is lower in the hierarchy of execution (i.e. creating program.com to ensure that it runs before program.exe). We have also seen viruses which change the pointers in the directory to point to the virus first (such as DIR II) and the virus maintains its own pointers to the original programs. There is also the "fragmentation attack" (I believe this was coined by Vesselin Bontchev) in which a virus takes advantage of the fact that certain system files are assumed to be located in fixed positions on the disk relative to the beginning of the DOS boot partition, and the virus simply places itself in these locations after moving the original code elseware (similar in concept to MBR and Boot infectors). So, we have to try to come up with a definition which embraces all of these developments, and still excludes programs such as Xcopy, and Diskcopy as well other legitimate programs which are not viruses. The old definition attributed to Fred Cohen's 1987 paper "Computer Viruses: Theory and Experiments," Computers & Security, Vol. 6, No. 1, February 1987, pp. 22-25 is: "We define a computer 'virus' as a program that can 'infect' other programs by modifying them to include a possibly evolved copy of itself." Fred further points out in his article the following: "The key property of a virus is its ability to infect other programs..." He also states: "It should be pointed out that a virus need not be used for evil purposes or be a Trojan Horse." The definitions put forth in this paper were groundbreaking, but Fred never anticipated some of the new ways viruses currently use to "infect" program code. However, I believe we can modify Fred's basic definition and arrive at a new working definition which will include the different types of viruses such as companion viruses and still exclude other non-virus programs. Modified definition: We define a computer 'virus' as a program that can 'infect' other programs by modifying them or their environment such that execution of the infected program implies a call to a possibly evolved copy of the 'virus.' Granted, the definition is recursive, and may need some work, but it seems to cover the current state of the art, while still distinguishing viruses from worms, or Xcopy. As for Fred's comment about viruses not necessarily being Trojan Horses, this is true since if one knows that a program contains a virus, then there is no unknown functionality implied. Also, perhaps when we find that our programs have a virus inside we should be historically correct and state, " My program was attacked by a damn Greek" (my apologies to any one of Greek decent :-)) since the Trojan Horse would have been nothing but a nice statue of a horse if it were not for the fact that it concealed the Greek Army inside. Also, an 'infected' program only becomes a Trojan Horse if we don't know that it is infected. Brian Seborg VDS Advanced Research Group :-) ------------------------------ Date: 22 Feb 93 19:43:09 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Scanners getting bigger and slower Gal_Hammer@f111.n9721.z9.virnet.bad.se (Gal Hammer) writes: > I was thinking (Not happen a lot, but...) if every virus have his own sig. and > every week few or some viruses appers, So don't all the AnitViruses program > will start to get bigger and slower ?! Bigger - yes. Slower - not necessarily. First, not everybody's scanner has a different signature for any different virus. There are a lot of scanners around that report "Jerusalem variant" for a couple of hundreds of different viruses, the only common thing being that they are indeed derived from the old Jerusalem virus. In most cases, all those variants are detected with 1-2 signatures. But, as more and more viruses appear, scanners must necessarily get bigger and use more memory. The speed, however, is not necessarily reduced. What all scanners do is essentially to find a substring (the virus signature) in a string (the file). But this is a well known problem in computer science, and there are well developed and fast algorithms to handle it. Space does not permit me to describe them here, so you should check the special literature - usually Donald Knuth's "bible", "The Art of Computer Programming", probably the first volume. Such algorithms allow to your program to tell very quickly that the substring is NOT contained in the string. In most cases, this can be achieved with a single comparison. And, remember, most files are not infected most of the time, and if they become infected, the users are not very much concerned about the speed of the scanner - they just want all infected objects properly detected. So, a scanner can permit itself to be fast on a clean system, with the price to be slow on an infected system. These algorithms are commonly referred to as "hashing" and use a special array, called a "hash table". There are only two problems with it - the array is usually big (e.g., 64 Kb) and if it gets almost filled, the access becomes very slow. But this is not likely to happen soon - currently there are about 2,000 viruses and handling 30,000 this way is perfectly possible. 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, 22 Feb 93 22:15:37 +0000 From: mechalas@expert.cc.purdue.edu (John Mechalas) Subject: Re: Virus education frisk@complex.is (Fridrik Skulason) writes: >mechalas@expert.cc.purdue.edu (John Mechalas) writes: > >> I could write a program, for example, that interrupts all I/O >>access to the hard drive. > >Technically no - you could not....well, maybe on a +386+, using protected >mode, debug registers and such...in general you would need hardware to >intercept all I/O. Software can be bypassed. True...in my enthusiasm I overspoke. :) But the idea is still valid...such a device would be a pretty silly "virus" detector, using a poor definition. As such, it does address the original posters issue of why it is necessary to have a clear, concise definition of a virus. - -- John Mechalas \ If you think my opinions are Purdue's, then mechalas@expert.cc.purdue.edu \ you vastly overestimate my importance. Purdue University Computing Center \ Stamp out and abolish redundancy. General Consulting \ #include disclaimer.h ------------------------------ Date: Mon, 22 Feb 93 18:11:00 -0500 From: Tom Zmudzinski Subject: In-Re: "Re: Sale of Viri" [sic] In V-L #29, tedwards@eng.umd.edu (Thomas Grant Edwards) writes: > I am just wondering if you got a virus, and passed it on accidently, > could you be held civilly at fault for thousands of dollars of > damage say if it got into a business? First, let me say that I am NOT a lawyer (my parents are married), but the answer is an otherwise unqualified (and rather loud) *Y*E*S* !!! Before any other pseudo-legal beagles jump me, the operant word is "could". I do not know if anyone has been sued over this YET [anybody got any CASE LAW they want to share?], but given our overly litigious society, it's an absolute lead-pipe cinch that it's going to happen. Now, if you want me to gaze deeper into my crystal ball, I'd say that it's unlikely that any individual will be zapped all by their lonesome - -- he/she usually doesn't have enough money to make the suit worthwhile. It's MUCH more likely that the employer (who usually has deeper pockets) will be tagged with partial liability. ("Partial liability" is a real trip through fantasyland -- in theory, if one has one-percent liability, one pays one-percent of the award; in reality, once the resources of the schmoe with ninety-nine-percent liability are exhausted, the one-percent liable entity is stuck paying the remainder.) Tom Zmudzinski ZmudzinT@CC.IMS.DISA.MIL "In ten years there's gonna be one million lawyers! ONE MILLION LAWYERS! One million lawyers! How much can the poor nation stand?" -- Tom Paxton, about a decade ago. ------------------------------ Date: 22 Feb 93 21:00:55 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Virus detection by code inspection jimo@sun.computing.manchester-metropolitan-university.ac.u (Jim O'Shea) writes: > Could you recognise that a file had been infected by a virus purely by > inspecting a disassembled listing? I do mean any virus, including one > you might not have met before. I accept it might not be possible to be > specific but answers like "Yes, given unlimited time." or " Seventy > percent probability of a correct answer after spending 6 hours on > inspection" will be useful. I am interested in applying AI to virus In general, when the file is infected, this is pretty obvious. (Just don't ask me to figure out how I am doing it...) What is NOT obvious is when the file contains a dropper, or an overwriting virus written in a high-level language and compressed, or when it is a buggy virus that always crashes when run. In those cases, the virus expert who is examining the file is likely to make a mistake and he usually needs to "try it out". Unfortunately, some viruses replicate only in very special conditions (one of the silly Violator viruses can infect properly on 17-byte files, I think - not larger and not smaller). For such viruses we say that they "need to be fed with a spoon". 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, 23 Feb 93 06:27:25 +0000 From: Albert-Lunde@nwu.edu (Albert Lunde) Subject: Re: Censorship Peters@DOCKMASTER.NCSC.MIL (Donald G Peters) writes: >All I really want to know is whether there should be >guidelines for this matter. It seems to me that if we could >develop guidelines (and who would be all that much better >than us?) we could provide something of use to the computer >community as a whole. > >I have NO objection to people keeping information private on >the basis of 'trade secrets'. That is, privacy because they >want to make money from their ideas. THat's fine. But very >often I see people saying (or implying) "I can't talk about >that here because that might give ideas to the bad guys." >[...] >Please feel free to propose things that we should NOT post >on this forum. I would agree to censor raw virus code but >would like to consider the value of censoring ANYTHING else. I think people who know the details of how viruses work have plenty of reasons to be cautious -- anti-virus "experts" with no commercial interests to protect, who have no "trade secrets" seem equally circumspect. Anyone who maintains anti-virus software has to respond to new viruses; anything that encourages the development of new viruses is more work for them. History shows that a lot of viruses are copies and variations of others. One reason to be wave hands at the details is to force virus creators to do some work. This does *not* interfer with defending against viruses -- unless I am writing an anti-virus package from scratch (actually more difficult than writing a virus), I don't need to know more than the general characteristics and symptoms of a virus to protect against it. It is true that lots of programmers could write a virus; however the higher we keep the skill level required, the more likely they will have better things to do. Virus source code is one thing I absolutely don't want made public, but I can see value in being relatively careful about what one says on other topics. - -- Albert Lunde Albert-Lunde@nwu.edu ------------------------------ Date: Tue, 23 Feb 93 07:22:36 +0000 From: mcafee@netcom.com (McAfee Associates) Subject: Question about Patricia Hoffman and John McAfee Hello Mr. 007, sbonds@jarthur.Claremont.EDU (007) writes: >mcafee@netcom.com (McAfee Associates) writes: >>>As far as I know, there is a close link between the authors of SCAN and >>>VSUM, and i wouldn't trust the test as a purely independent test. >>There is no close link between McAfee Associates and Ms. Hoffman, at >>least, none different from that between her and any other anti-viral >>vendor. >Really? I wonder why Ms. Hoffman states in her "A word from Patricia..." >section: > > A special thanks goes to John McAfee for the countless hours he > has spent reviewing VSUM prior to its release. > >Seems she has a bit more of a connection with SCAN than "any other >anti-viral vendor." Simply because John McAfee would spend hours on the phone telling her about what viruses were new, where they came from, how common they were, etc. If you think you have any such information that may be of use to Ms. Hoffman, I'd suggest that you contact her. Perhaps you too can get your name mentioned in her virus summary. Regards, Aryeh Goretsky Technical Support - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - McAfee Associates, Inc. | Voice (408) 988-3832 | INTERNET: 3350 Scott Blvd, Bldg 14 | FAX (408) 970-9727 | mcafee@netcom.COM Santa Clara, California | BBS (408) 988-4004 | CompuServe ID: 76702,1714 95054-3107 USA | USR HST Courier DS | or GO MCAFEE Support for SENTRY/SCAN/NETSCAN/VSHIELD/CLEAN/WSCAN/NETSHIELD/TARGET/CONFIG MGR ------------------------------ Date: 22 Feb 93 19:27:39 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: os2-stuff (OS/2) Malte.Eppert@f6050.n491.z9.virnet.bad.se (Malte Eppert) writes: > Two years ago I had a strange case of Cascade infection on a 386. An > APP-File of Ventura Publisher had been mistakenly hit by 1704-B and > was damaged - but not infected, since the virus in the file was no > longer capable of replicating - Ventura always crashed at startup. > Nevertheless SCAN (dunno which version it was those days :-) ) flagged > it as infected when using the /A switch; and there were other, > regularly Cascade-infected COM files on the drive which were simple to > clean. The APP-File had to be reinstalled. That can happen, because the APP files are Exec'ed - i.e., they are passed to INT 21h/AX=4B00h (or to INT 21h/AH=4Bh) and Cascade just happens to infect anything that is executed this way (in the second one, more exactly) and does not contain 'MZ' in its first two bytes. > I don't know the conditions under which that happened, but I think similar > things should also be possible with DLLs and other viruses. We were talking about the DLLs in OS/2 and they are NOT executed in the way mentioned above. Thus, Cascade cannot infect them. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Mon, 22 Feb 93 12:14:39 +0000 From: v922340@hildebrand.si.hhs.nl (Ivar Snaaijer) Subject: Re: Suggestion to the developers of resident scanners (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: >Ah, yes, I forgot about that. Yes, the file should be scanned when >executed from a network drive too. BTW, one thing that Frisk really >*MUST* implement soon is an option to re-activate VirStop after the >network shell has been loaded... you might try tbscanx the driver for the memory resistend TB* programs makes networks possible. Ivar. - ----------------------------------------------------------------------------- Rule one in program optimization : Don't do it. Rule two in program optimization (for experts only) : Don't do it yet. Rule three in program optimization (for athlets only) : Just do it. - -- - ----------------------------------------------------------------------------- E-mail : v922340@si.hhs.nl ... i can't help it, i'm born this way ... - ----------------------------------------------------------------------------- ------------------------------ Date: Mon, 22 Feb 93 12:32:52 -0500 From: D_GILL@twu.edu Subject: Central Point Antivirus and Stacker (PC) I use stacker, and recently have begun Internet, etc. I have Central Point Antivirus, but haven't installed it yet. Stacker manual warns against using some antivirus packages, but doesn't cite which not to use. Are Central Point Antivirus and Stacker compatible? Thanks Jack Gill D_GILL@TWU.EDU ------------------------------ Date: Mon, 22 Feb 93 18:51:54 +0000 From: cnews@umr.edu (UMR Usenet News Post) Subject: file name virus? (PC) I'm not sure if I have a virus or not. A user came to me today and the program he was using could no longer create files, the error message displays the names of the files it attemps to create. This used to create files fine every time. This user experienced this problem after allowing another user to copy files to his hard drive so that another machine with this problem could have the hard disk reformatted. Now both machines display this problem. The file names used to be a rather normal MYFILE.DAT type name, now when it attempts to create a file it says "ERROR, CAN'T CREATE bMYFILE.BAT" where the "b" is a beta (ASCII 225 in the English version of the extended character set). Are there any viruses that change or create files with a "beta" character (ASCII 225) prepended to the file name? Thanks, Scott Hayes shayes@usgs.gov Please e-mail me copies of answers since I am not a regular reader here. - -- Scott Hayes scotth@cs.umr.edu shayes@usgs.gov "This page intentionally blank." ------------------------------ Date: 22 Feb 93 19:09:22 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Minimal virus scan? (PC) swesterback@tne01.tele.nokia.fi writes: > My question now is if these assumptions are correct: > - - viruses only infects: > *.EXE and *.COM -files that has been used when a virus is in memory > the boot sector > command.com You forgot the SYS files and the master boot sector. And COMMAND.COM is not really different from the other *.COM files. > - - it is enough to scan only memory, the boot sector and for example the > following files: > command.com smartdrv.exe emm386.exe keyb.com > win.com win386.exe lat.exe redir.exe No. If the virus is not resident, you won't detect it at all. If the virus infects SYS files, you won't detect you there. If the virus infects MBRs, you won't detect you there. > Is that correct? If not please tell me why not! I can also think about > varying the scanned directories from day to day. Better install a resident scanner - a scanner that scans only those files that are executed. Also, install an integrity checker. > Also is there really any need to scan DLL, DRV, OVL and SYS-files? The SYS files - yes. There are already several viruses that can infect them. There are even SYS-only infectors (i.e., you won't find them in any other files), but for obvious reasons they don't spread well.It The other files should be scanned only if you find an infection - a virus could infect them by mistake, but a virus that infects -only- them cannot survive. 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, 22 Feb 93 15:17:38 -0500 From: Donald G Peters Subject: EXE/COM switch (PC) Here is an idea I have cooked up to defend against some types of viruses. It has not (to my knowledge) been in print before. Viruses which infect files often *look* for the extensions EXE and COM. If no such files exist, the virus will not replicate. Some people have propagated the idea that you should rename your EXE files as XXX so that a virus will not find it and it will remain safe from infection. >From what I have read, many viruses are *either* EXE or COM infectors, but not both. And even for viruses that infect both types, the following defense may work against them. The trouble with the XXX idea above is that the programs cannot be found and cannot be run with such a name. My idea is to rename all your EXE files as COM and rename all your COM files as EXE. Believe it or not, DOS is still able to run your programs after you make this switch. DOS does not rely on the extension to determine if the program is relocatable (a la EXE) or not (a la COM), rather it looks for the file signature ("MZ", the initials of the early Microsoft employee who developed this scheme) and takes action upon that. Now any virus which is tailored to work specifically on one type of program is not very likely to work when you pull this trick on it. I will leave it to the experts on this forum to determine the details of that. I will also leave it to an enterprising individual to determine wither COMMAND.COM will run if it is renamed to COMMAND.EXE (with the appropriate change to the COMSPEC variable in CONFIG.SYS). Personally, I doubt it, but perhaps a simple modification to the boot sector may make this possible. I think a utility in this regard would be very nice! A handful of programs may not run with the EXE/COM switch, and some programs may require "reconfiguration" especially if they are looking for programs of a given name, although some of them allow you to change the name to search for. In the future, viruses WILL be able to defeat this approach, but for now I think it is a valuable tool for those who are vulnerable to viruses. I would appreciate comments from the experts on this forum who know *exactly* how various viruses work (or who can simply test this idea with viruses that they contain in safe keeping.) Remember where you heard this from! (because I always wanted to be famous as a kid...) Don Peters ------------------------------ Date: 22 Feb 93 20:18:05 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Scanning memory (PC) peprbv@cfa0.harvard.edu (Bob Babcock) writes: > Isn't it better to be conservative and look everywhere in memory for active > viruses? No. There are some parts of memory where some viruses just cannot be active. Like Stoned in the DOS buffers. > I'd much rather see a false alarm than have something be missed > because a scanner was wrong about where viruses could lurk. Also, this sort I also used to think like you some time ago, but now I am convinced that this is not the case. A false positive can be very costly to a company - as much as a real virus. Because they have to figure out that this is a false positive. And sometimes this is more difficult than to clean up a virus, especially if it is a ghost positive that sometimes appears and sometimes not. > of false alarm can only arise if you have scanned an infected floppy. If a > user has an infected floppy, and doesn't know enough about viruses to > understand the ghosting problem, they should consider getting expert help. First, expert help is not running the streets, so why not push the producers of anti-virus program to make smarter software? Second, the in one of the cases it was a false positive that actually PREVENTED the user to quickly remove the virus from all floppies - because he had to reboot after each one... 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 Feb 93 20:24:44 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: standardization (PC) bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) writes: > I feel that the authors of scanners need to get together, and agree on a > naming system. That's a very good idea, but it is damn difficult to implement... First, somebody has to come up with a good naming scheme. But what is a "good" naming scheme? For instance, for me, a good naming scheme is a scheme that allows two people to understand each other that they are talking about a particular virus variant. That is, when I'm saying Jerusalem.AntiCAD.4096.Mozart, Frisk knows what I mean. But the producer of product XYZ does not like it, because it takes too much memory in its resident scanner to keep such long names. Anyway, we (CARO) have come up with such a naming scheme and now we are waiting the other anti-virus producers to use it. The latest status of the proposal is available for anonymous ftp from our site: ftp.informatik.uni-hamburg.de:/pub/virus/texts/tests/naming.zip The second problem is that different producers of virus scanners use different approaches to scan for viruses. For instance, it seems to me that the classification of viruses into families and subfamilies is important for Frisk's scanner, because he has become very skilled at that and does it regularly. Thus, any naming scheme used by him is likely to group the viruses into families. This, however, might not be helpful at all (or even annoying) to the producer of the scanner ZYX, who calls all the 200 Jerusalem subvariants "Jerusalem-B". So, obviously, he is not likely to adopt this naming scheme. Third, even if two producers of scanners agree to use one and the same names, it is very difficult to keep their products synchronized. For instance, both F-Prot and FindVirus are using the CARO naming scheme (although they use a different notation), and they -tend- to use the same names for the viruses, and both Frisk and Dr. Solomon are getting the new viruses practically at one and the same time, yet if you look at that "naming" file mentioned above, you'll see how different the names used by their programs still are... The anti-virus researchers are really overloaded with new viruses popping up literally every day, and they have more important things to do than to sit and ponder whether to call the yet another silly overwriting Burger variant Burger.V or Burger.Y. (Yet, they are doing this too...) The problem increases in difficulty in an exponential rate, if more than two scanners have to be synchronized... So, your idea is good. The only problem is to get an easy implementation of it... Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 22 Feb 93 20:56:35 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Uruguay on PS/2 Ref disk (PC) pinman@magnus.acs.ohio-state.edu (Patricia C Inman) writes: > Fprot 2.06 reports: command.com "Infection: Uruguay" on all PS/2 > Model 70/80 Reference Disks Version 1.06. Version 1.03 of the Ref > Disk reports clean. CPAV is current and reports nothing. > I recently went through a scare and collected all disks in the > facility. This is all I have left to cleanup. Is this "normal"? No, it is not normal. It is a false positive in F-Prot 2.06. The problem has been fixed in version 2.07, but now it does not detect the Uruguay viruses reliably... :-( The only good news are that (a) you are not infected and (b) the Uruguay viruses are not in the wild. 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, 22 Feb 93 16:34:14 -0500 From: peprbv@cfa0.harvard.edu (Bob Babcock) Subject: re: logic bomb in PKZIP (PC) >Well, the new PKZIP 2.04g (and possibly the older 2.04 versions too) >make use of this possibility. On execution, they check for the >identifier mentioned above, and, if it is not found, they destroy >themselves by overwriting argv[0] with 64 Kb of junk. .. >The logic bomb is obviously put there by PKWare, and does NOT have any >other destructive effects. I couldn't figure out any way in which it >could destroy anything that it shouldn't. What happens under DOS 2.x where argv[0] does not contain the program name? What happens if the disk has less than 64Kb of free space (counting the overwritten file as free space)? Suppose you are writing a task switcher, and it has a bug which causes it to not properly switch the PSP? Suppose a program you are debugging branches to a random location, and happens to run into the file trashing code still in memory from a previous PKZIP execution? I'm postulating some low-probability events, but I find the existence of the file trashing code disturbing. Remember that other parts of the code did not perform as expected on some machines when released into the real world. ------------------------------ Date: 22 Feb 93 21:40:24 +0000 From: murray@andromeda.rutgers.edu (Murray Karstadt) Subject: How can you recover a hrad drive from joshi? (PC) Can a hard drive once its been attacked by joshi be recovered? The story in brief is that a program was run that contained joshi( the bad news is that the program was an old antivirus program). The women in question ran the program found joshi, got rid of it and now cannot see her harddrive. We booted the system from a protected floppy but cannot find c:. Any suggestions as what to do next. One last thing, there are no backyps of anything. thanks in advance for any help murray murray@andromeda.rutgers.edu - -- not a test ------------------------------ Date: 23 Feb 93 00:48:41 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: my idea for detecting file infectors (PC) bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) writes: > I have an idea to detect new and unknown viruses. > Let me tell you up front, my idea is only for detecting file infectors, > and should be used in conjunction with other virus detection software. > It's only another tool for the virus detection toolkit. This will not give > the users the name of the virus or tell how to remove it. Simply a Yes or > No if the user has a file infector on the loose. Actually, it is worse than that - it -might- tell you that there is a file infector. But it also might fail to do so. The idea is not new, it is sometimes called "decoy launching". > 1575, and Frodo will attach to two byte .COM files. But 8 Tunes will not > attach to any file smaller than 9216 bytes. And DataLock does not infect a COM file smaller than 23,000 bytes. And some viruses infect only some special files (Lehigh infects only COMMAND.COM, ZeroHunter infects only files with large areas of zeroes in them, some viruses do not infect files with some particular names, etc. > I recommend PKzip or LHA, but not ARJ because the files size fluctuates. Uh, what do you mean by "file size fluctuates"? > As long as FC or COMP do not report any differences in the two archives, > you can be reasonably sure that you don't have a file infector. No, the only thing you can be sure about is that THOSE FILES (the ones you put in the archive) are not infected by a non-stealth virus. You cannot tell for sure that there is no virus in the system or that it is not a stealth one. > If you want this to detect stealth viruses, copy, this .BAT file, the > archive software, and FC.COM or COMP.COM to a known clean bootable > diskette. Once ever week or two; cold boot from this known clean diskette > (preferably write protected) and run this test. OK, that will do it for the stealth viruses, except that it's considered a bit inconvenient by most people... > In my tests, I archive six files. > > COMMAND.COM > FORMAT.COM > PKZIP.* > WINLOAD.* > DRWATSON.EXE > NOTEPAD.EXE And what if the virus refuses to infect files with such names? There are other holes in your idea - you are assuming that the virus will infect those files, because you are using them often. And what if it is a non-resident virus, that infects only in the current directory, or if has a weird infection pattern, like Anthrax? In general, the idea is equivalent to checking the integrity of a small subset of your executables. > I am releasing this idea to the public domain, so authors of virus > detection software can incorporate this idea into their software if they > care to. I have already seen this idea implemented in some products - VDS comes into my mind. However, there are some improvements: 1) The names of the generated decoys are rather random, so it is not easy for a virus to avoid to infect them. 2) The decoys are both copied and executed. 3) Some anti-stealth tunnelling tricks are used. They are able to bypass most stealth viruses, but unfortunately they also bypass very successfully any user-installable volumes, like Stacker. 4) They don't claim to be able to detect any file virus - they are just using that idea as a tool to help detecting the virus. Sometimes it works, sometimes it doesn't. 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, 22 Feb 93 21:07:30 -0500 From: Max Maser Subject: An undetectable virus I have been infected with. (PC) I hope that this is being sent to the correct recipient. I do not receive the 'comp.virus' group at my location. On the 6th of Feb. at 7:10:56 pm, (est.) my computer crowed like a rooster. At precisly the same time every day it 'crows' 21 times. McAfee's scanv100 detected stoned active in memory and in the partition table. I formatted several discs and then used clean100. It reported that there were no virus's detected, and 1 hour and 15 minutes later, the crowing repeated. I would like to know if you have had any other reports of this virus, plus any other information that you may have available re this. Since I am unable to get the newsgroup at this time, I would greatly appreciate direct mail replies. Other scan programs I have tried are F-PROT, IBM's latest virus scanner, Central Points latest CPAV, and McAfees V100. Thanks for your time and I look forward to a reply soon. Max Maser [215] 494-5813 148 Bethel Rd. Aston, Pa. 19014 My internet address is maxm4@pacs.pha.pa.us ------------------------------ Date: Mon, 22 Feb 93 22:50:19 -0500 From: D_GILL@twu.edu Subject: CP Antivirus with Stacker (PC) I have stacker on my hard drive. Can I use CP Antivirus on the same drive without disturbing Stacker? Has anyone reported adverse effects of the two on the same drive? JACK GILL BITNET: D_GILL@TWU TEXAS WOMAN'S UNIVERSITY INTERNET: D_GILL@TWU.EDU DENTON, TEXAS 76204 ------------------------------ Date: Tue, 23 Feb 93 07:41:06 +0700 From: micke@qainfo.se (Micke Larsson) Subject: Re: standardization (PC) sbonds@jarthur.Claremont.EDU (007) writes: > bill.lambdin%acc1bbs@ssr.com (Bill Lambdin) writes: > > >I feel that the authors of scanners need to get together, and agree on a > >naming system. > > A (very) few already have. The naming system is called the CARO > standard, and the scanner that adheres most closely with it (that is [stuff deleted] > (Hey frisk, how about "f-prot /CARO" as a command line switch?? ;-) Solomon's FindVirus have a /EICAR switch which outputs the Eicar code for viruses found. These codes are a part of the CARO naming standard. Micke Larsson QA Informatik AB, PO Box 596 S-175 26 Jarfalla Sweden Tel +46-8-7602600 Fax +46-8-7602605 BBS +46-8-7602615 2:201/370@FidoNet e-mail micke.l@qainfo.se Compuserve Id 100135,1742 TeleGuide 81006329 QA Informatik distributes Dr Solomon's Anti-Virus Toolkit in Sweden ------------------------------ Date: Mon, 22 Feb 93 14:37:33 -0500 From: w8sdz@TACOM-EMH1.Army.Mil (Keith Petersen - MACA WSMR) Subject: SIMTEL20 subdirectory name changes (PC) Effective immediately the following WSMR-SIMTEL20.Army.Mil subdirectories have been renamed: Old Name New Name PD1: PD1: PD1: PD1: This corresponds to the following on OAK.Oakland.Edu: Old Name New Name /pub/msdos/arc-lbr /pub/msdos/archivers /pub/msdos/trojan-pro /pub/msdos/virus Keith - -- Keith Petersen Maintainer of the MS-DOS archive at WSMR-SIMTEL20.Army.Mil [192.88.110.20] Internet: w8sdz@TACOM-EMH1.Army.Mil or w8sdz@Vela.ACS.Oakland.Edu Uucp: uunet!umich!vela!w8sdz BITNET: w8sdz@OAKLAND ------------------------------ End of VIRUS-L Digest [Volume 6 Issue 33] *****************************************