VIRUS-L Digest Thursday, 11 Apr 1991 Volume 4 : Issue 60 Today's Topics: Administrivia - DIGEST FORMAT CHANGE Infection by insertion (Mac) Interpol reacts to computer viruses re: Non-obvious viruses (was: Unix and viruses (UNIX)) Re: AF/91 - John Gantz joke in Infoworld Infoworld article Classification of the Malicious Software An Analysis of McAfee's Authentication Methods (longish) (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. 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. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU. Ken van Wyk --------------------------------------------------------------------------- Date: Thu, 11 Apr 91 09:16:30 -0400 >From: Kenneth R. van Wyk Subject: Administrivia - DIGEST FORMAT CHANGE Hi Folks, (NOTE: this does not affect comp.virus, only VIRUS-L.) Recently, an Internet RFC (Request For Comments - these are the generally accepted standards within the Internet community) on digest formats has been brought to my attention. RFC 1153, dated April 1990, states (among other things): The Preamble must be separated from the remainder of the message by a line of 70 hyphens followed by a blank line. ... Each enclosed message must be separated from the the remainder of the digest message by a blank line before and after a line of 30 hyphens. VIRUS-L digests currently use 75 hyphens to separate the preamble from the remainder of the digest. However, each message is separated by the correct (30) number of hyphens. So, in an effort to conform to RFC 1153, I will be changing the format slightly. Effective Volume 4 Issue 61, the digests will contain 70 hyphens between the preamble and the remainder of the digest. Anyone out there who is using a digest exploder should make the necessary changes to be able to read the new format. I hope that this does not cause difficulties for anyone. If anyone would like to see RFC 1153, it is available by anonymous FTP on NIC.DDN.MIL. Or, email me and I'll send you a copy. Cheers, Ken Kenneth R. van Wyk Moderator VIRUS-L/comp.virus Technical Coordinator, Computer Emergency Response Team Software Engineering Institute Carnegie Mellon University krvw@CERT.SEI.CMU.EDU (work) ken@OLDALE.PGH.PA.US (home) (412) 268-7090 (CERT 24 hour hotline) "Be it ever so humble, there's no place like $HOME" ------------------------------ Date: Thu, 11 Apr 91 08:58:00 -0500 >From: "Mark Nutter, Apple Support" Subject: Infection by insertion (Mac) Thomas DiBlasi asks: >Is it possible for a virus, trojan, worm, etc. to infect a hard disk >or RAM simply by inserting an infected floppy into a drive without >execution?? There are a couple of Mac viruses that take advantage of a loophole in the Mac OS to produce precisely that effect. Basically, the Mac OS allows you to define code resources for such common items as windows and menus, so that you can implement custom windows and unusual menus. The WDEF and MDEF viruses exploit this by putting modified (viral) code resources where the operating system will find them when it goes to draw a window or pull down a menu. Thus, if you put an infected disk in your disk drive, and then open a window (or pull down a menu), the infected code resource gets executed, even though you never ran a program. Naturally, the freeware program GateKeeper (actually GateKeeper Aid), and a number of other anti-viral products, now check this loophole, so a protected Mac should be safe from this particular avenue of infection. I run GateKeeper all the time, and it has caught a number of WDEF-infected disks before they could do anything. (It automatically removes the virus upon detection). - ----------------------------------------------------------------------------- Mark Nutter MANUTTER@IUP Apple Support Manager Indiana University of Pennsylvania G-4 Stright Hall, IUP Indiana, PA 15705 "You can lead a horse to water, but you can't look in his mouth." - Archie B. ============================================================================= ------------------------------ Date: 11 Apr 91 13:21:55 +0000 >From: Pete Jinks Subject: Interpol reacts to computer viruses An article in The Daily Telegraph, Saturday April 6th p.2 col.1 about computer crime: " ... [at] the 20th Interpol European conference in London [yesterday] ... Det. Insp. John Austen, who runs the computer crime unit of the Metropolitan Police Fraud Squad ... [and is] chairman of Interpols's European computer crime working party ... [said that] `... By the end of the year, Interpol will have set up a computer virus library in Holland, to provide a central information point for European police forces, and a database from which to send out warnings of any major virus attack. ... An index of 400 computer viruses had been compiled, with cures for most of them.'" ------------------------------ Date: 11 Apr 91 10:31:11 -0400 >From: "David.M.Chess" Subject: re: Non-obvious viruses (was: Unix and viruses (UNIX)) In an otherwise quite solid article, William Hugh Murray <0003158580@mcimail.com> writes: >>d. That the individual is sufficiently sophisticated to avoid leaving >>obvious clues (file sizes, dates, etc.). > >Well, that excludes all viruses. It is possible to conceive of a >virus that was so subtle that it left no evidence; on the other hand, >if you never notice that you have been damaged, then you have not been >damaged. > >No such virus has ever been detected, for obvious reasons. All the >reported viruses have done something noticeable. Since the intent of >a virus is to spread, and since if it has no symptoms, the author >cannot know if it is successful, few people would write such a virus. This is much too strong. There are certainly viruses that go to great lengths to avoid leaving *obvious* clues, and there are quite a number of viruses that have no intentional payload (don't ever erase files, damage data, print a message, or anything else). Presumably the authors of these viruses had a somewhat different set of intents; any statements of the form "the intent of a virus is X" are backed up by little or no evidence, and should be avoided by the fastidious! *8) Of course, all viruses have *some* symptoms (they change existing objects, or create new objects, or whatever). But that doesn't mean that there aren't viruses that do their best to have as few symptoms as technically feasible. Even a virus that did have a destructive "payload" could be written to have no obvious symptoms until the payload was delivered. DC ------------------------------ Date: Thu, 11 Apr 91 09:52:08 >From: johnboyd@logdis1.oc.aflc.af.mil (John Boyd;CRENP) Subject: Re: AF/91 - John Gantz joke in Infoworld I guess that, from now on, anyone who writes 'joke' articles, even if they *do* appear in a 1 Apr cover date pub should begin and end their articles with the banner: _________________________________________________________________ *JOKE* *JOKE* *JOKE* *JOKE* *JOKE* *JOKE* *JOKE* _________________________________________________________________ so that those of you who neither have a sense of humor, *or* read to the *end* of the article will know that it's a joke. I passed the aforementioned article to all the members of my end-user support team; and while the article 'had them going' in the beginning, when one got to the bottom, it became *obvious* that it was tongue-in-cheek humor. You have seen that style of humor, haven't you? I have been reading computer related pubs written to various user levels for about 10 years, and it has been my experience that you almost *always* see some article which, at first glance appears to be real, only to 'remove its tongue from its cheek in the end'. Geez!, lighten up! Laugh once in a while; and get some sun! ------------------------------ Date: Thu, 11 Apr 91 12:16:46 -0400 >From: padgett%tccslr.dnet@uvs1.orl.mmc.com (A. Padgett Peterson) Subject: Infoworld article >From: sharp@mizar.usc.edu (Malcolm Sharp) >In the April 1, 1991 issue of Infoworld, John Gantz in his column >"Tech Street" warned of a virus called "AF/91"... >In the same issue, columnist Robert Cringely discussed Windows 3.0 >vulnerability to viruses saying it "has lots of holes for custom >viruses to slip through." Of the two, I consider the Cringely article far more dangerous. Mr. Gantz clearly stated at the end that "AF" meant "April Fool" and the concepts were plainly ludicrous. Mr. Cringely, however, is echoing out of context some mythconceptions concerning Windows. Windows is a colletion of programs. It makes use of certain "undocumented" constructs and capabilities in MS-DOS just as NetWare DOS. The error cones in the implication that there is no way to protect against malicious software that exploits these "holes". This is completely erroneous ! The "holes" are simply alternate paths used for disk and OS access that will bypass a conventional Int 13 or Int 21 "trap" that is layered on after DOS has loaded. These are easily plugged by a system that places its "traps" before DOS has loaded for hardware access, and understands the special hardware where networks are involved. (ROM pointers are still present, the protection software just must know how to find them. To me, this comes under the same heading as last year's reports of the "invisible stealth" viruses that could not be detected. BALDERDASH. For example, many people are surprised to find that their machine has become infected in the partition table from an "accidental" floppy boot. If the partition table (MBR) code just checked three things such infections (like BRAIN & STONED) would have never spread: 1) Can I trust myself 2) Can I trust the disk access 3) Can I trust the MBR on the disk Such checking can be done in about 20 additional bytes. What is needed is a comprehensive integrity management scheme that is invisible to the user but encapsulates the OS. The sooner a vendor comes up with a good mechanism (and it would be easiest for MicroSoft), the sooner the public will quit worrying about hundreds of "unkillable" viruses in PCs. Oh well, the incredible diversity of virus checking programs out there makes it difficult for malicious software to be able to defeat everything. Maybe that is a good. Warmly, Padgett ps I left a similar message on Mr. Cringely's voice mail system. It has not been returned. app ------------------------------ Date: Thu, 11 Apr 91 17:57:05 +0300 >From: eldar@lomi.spb.su (Eldar A. Musaev) Subject: Classification of the Malicious Software Writing a book about malicious software I need in classification. I ask to discuss the next classification. That is not my classification, I've only formulated common implications and made some attempt to make it complete. Another basis of this classification are the recommendations of (American) National Institute of Standards and Technology (John Wack Suggested Reading List for Computer Viruses and Related Problems, September 22, 1989 - Basic Terms). Till now there is some unstability in some terms so it would be very good to find the best fits. Please, send replies to me, I'll summarize results. Common name: Malicious Software Short informal synonym: Badware Interlanguage synonym: Trojans Reasons: Any malicious software can be considered as a programs with Trojan side effects. The first level classification criterion: a)Duplicating/non-duplicating - i.e. does the program duplicate itself or not ? b)Parasitic/non-parasitic - i.e. does the program attaches itself to another program to duplicate itself ? So there are three classes of malicious software: I.Trojans - non-duplicating, non-parasitic II.Worms or Bacteriums (this term I've read in French-language papers) - duplicating, non-parasitic III.Viruses - duplicating, parasitic I.Trojans - the suggested classification criterion is the origin of the Trojan effect: I.1.Accidental Trojans or Infirm Programs - the programs which have not been sufficiently tested and so contain many errors. Example: PCShell word-processor which sometimes looses the file if the disk is full I.2.Side Trojan or Programs with bugs (or implanted bugs) - the programs with unspecified back entries or other opportunities to deactivize software or make any harm. Example: Software for the French weapon systems sold to Iraq. I.3.Direct Trojans or Trojan Horses - the programs which are specially designed to harm something and which are designed to hide these side effects. II.Worms or Bacteriums - the suggested classification criterion is the area and media of duplication. II.1.Network worms - the programs which duplicates themselves from node to node in networks. Example: Christmas Tree II.2.Local worms - the programs which copy themselves *INSTEAD OF* another program. The original program is destroyed in part or as a whole. Another names: Overwriting viruses - Patricia Hoffman; Worms - some French-language papers; Bacteriums - the same place. Suggested short terms: absorbers, destroyers, spoilers ... What is better ? III.Viruses - the suggested classification criterion for viruses is the kind of the link between the virus and a victim and the fact of modification of the victim content. III.1.Static viruses - most numerous class of viruses and malicious software. These viruses join to the victims and modify them to get a control first. Exaples: Vienna, Dark Avenger etc. III.2.Dynamic viruses - the viruses which do not change the contents of the victim and place themselves in separate files, which are logically and dynamically connected with the victim. Example: Spawning viruses (in terms of Patricia Hoffman) which make a COM-twins for EXE-victims, so when calling a victim, the virus gets a control first (as a COM-file with the same name) and later dynamically loads and executes the victim. "Spawn" is the C/Unix term for the dynamic call with return of a program, so it is a comparatively new term. The older generation of programmers use "attach", "link" or "[dynamically] call" terms. ===== Please, reply to me, I'll summarize the results ================== | Eldar A. Musaev, Ph.D., Researcher | eldar@lomi.spb.su or | | Mathematical Institute, Acad.of Sci. | lomi.spb.su!eldar@fuug.fi | | USSR 191 011 Leningrad Fontanka 27 LOMI AN USSR | ======================================================================== ------------------------------ Date: Tue, 02 Apr 91 14:06:00 +0300 >From: "Y. Radai" Subject: An Analysis of McAfee's Authentication Methods (longish) (PC) [The following is a draft of an article I'm submitting elsewhere (except that for this version I've added a few references to this forum). Your comments and constructive criticisms are welcome.] The anti-viral programs released by McAfee Associates are well known in this forum. It is presumably because of their popularity that they have been the victims of a number of "Trojanizations" or bogus ver- sions. I would therefore like to discuss them not from the usual point of view of their ability to recognize and remove known viruses, but rather with respect to the measures which McAfee has taken to ensure that his programs have not been tampered with. These are as follows: 1. The first measure he introduced was insertion of a self-test into each of his programs when it begins execution. If one of them has been modified, a warning "The file xxxxxx has been damaged!" is displayed, but the program is allowed to continue execution. If there has been no modification, no message is displayed. 2. Starting from Ver. 46 (in the case of SCAN and SCANRES), his pro- grams have been packaged with an external file authentication utility VALIDATE. According to the most recent version of the documentation file for VALIDATE, it uses "two discrete methods" to generate CRCs. (In my opinion, it would be more accurate to say that it uses a *single* method (the CRC algorithm) to compute a pair of 16-bit check- sums based on each of two generator polynomials.) The utility displays these, as well as the file size and date of creation, for the user to compare against the "known" data for the program, i.e. that "published by the author of the program or obtained from a trusted information database". (This includes the CVIA, but it's not clear what other databases are trustworthy.) But the correct data for each of McAfee's programs is also included in the doc file for the current version of that program. The documentation for SCAN says that if your copy of SCAN.EXE differs (i.e. if you get different validation results), the program "may" have been modified. On the other hand, until recently the VALIDATE.DOC file claimed that "If they match, you can be assured that the program has not been tampered with." In recent versions, the wording is slightly more modest: "If they match, than it is highly improbable (less than one in sixty-four quadrilion) that the program has been modified." 3. Starting with Ver. 72, all of McAfee's programs which are made available for downloading are archived using the Authenticity Verifi- cation option of the PKZIP utility. At the time they are extracted or tested the user should see the message > Authentic Files Verified! # NWN405 Zip Source: McAFEE ASSOCIATES If one or more files in the archive have been replaced by someone else, all files will be extracted as usual, but PKUNZIP will display the following message instead: > Authenticity Verification Failed! > One or more of these files has most likely been tampered with. The idea of introducing authenticity checks is a good one in prin- ciple, and one might suppose that with so many methods, McAfee's pro- grams must be secure against forgery. Unfortunately, the particular techniques chosen all seem to me inadequate for the following reasons: Self-Test: This is the simplest check to circumvent. A self-test makes sense as protection against most viruses, since a virus is ordinarily de- signed to preserve the functionality of the program which it infects, which would include the self-test in this case. However, a self-test is useless if the program is replaced by a Trojan, since in this case the hacker is not constrained to preserve functionality; in particular, there's no reason why his Trojan should retain the self-test. (Actual- ly, a self-test is ineffective against some types of viruses too, since overwriting viruses do not preserve functionality, and a virus could be designed to neutralize the self-test routine itself. Most important, the test would fail when certain types of stealth viruses are active.) VALIDATE: The great majority of users are not going to bother contacting the author or the CVIA in order to validate their programs. If they do it at all, they're going to use the values given in the documentation files. Hence when the hacker modifies one of McAfee's programs, he can simply compute the CRCs (i.e. the checksums produced by the CRC algo- rithm) of the modified program and substitute these values for the au- thentic ones in the doc file, and similarly for the file size and date. But suppose one contacts a "trusted information database" and that the CRCs, dates and file sizes all check out. Can we be so confident that the file has not been modified, as the documentation claims? Unfortunately no. It is true (as I have emphasized several times in VIRUS-L) that the CRC algorithm is perfectly secure against forgery when it is used to detect modification of a file *on a given computer* (the typical anti-viral application of checksum programs), provided that (1) each user's generator is unknown to others and (2) the CRC corresponding to a given file is inaccessible to a virus or other program planted by a hacker. However, in the present situation (detection of modifications which take place during transmission of a file from one computer to *other* computers) these conditions cannot be satisfied. In particular, the generators which VALIDATE uses must be the same for all users, and so it suffices to determine them once in order to be able to modify any file in such a way as to preserve its CRCs. Now it so happens that the two generators which VALIDATE uses can be very easily determined by downloading the PVALIDAT package and examin- ing the source code. But even if the source were not available, one could find them by disassembling VALIDATE.COM or by computing them from a few file-CRC pairs. Once this has been done, the next step is to "forge the CRCs", i.e. to modify the bits in some small area of the file so that the CRCs of the resulting file are the same as those of the original one. Now trying to forge with respect to two generators simultaneously may seem impossible to some people, but actually, it's equivalent to forging with respect to the single generator which is the least common multiple of both of them (which is of degree at most 32 in the present case). And once the generator has been determined, the extra modification required to forge the CRC of a given file can be computed directly, without need for trial and error. Thus the CRC algorithm, even with two or more generators, is not sufficiently secure in the present situation. Concerning the above-quoted claim that the probability of an undetected modification is 1 in 64 quadrillion, I confess that it's a mystery to me where that number came from. From the above it follows that the probability is 1 in (at most) 2^32, which is about 4.3 billion. But actually, such probabilities are meaningful only when the file modification is a *random* one, not when it is deliberately directed against the algorithm. When that is done by someone who knows the method, the probability is not 1 in quadrillions or even 1 in billions, but simply 1! The hacker also has to preserve the date and size of the file. Preserving the date is trivial. In the case of viruses, preserving file size (actually, and not just apparently) is impossible in the majority of cases since a (generic, non-overwriting) virus must preserve functionality of the program while adding propagation code and damage code. But it's simple in the case of a Trojan, since there are no functionality constraints and no propagation code. PKZIP authentication: This has the advantage over the other two features of authenticating the sender as well as the files. Still, it is essentially a self-test and it can be easily circumvented. One way would be for the hacker, after unzipping McAfee's archive and modifying one or more of the files, to simply rezip them without using the authenticity verification option; the user will not get any message that a file has been modified. And if the hacker also removes the warning not to use the programs if one does not get the authentication message, the user will not even *know* he's supposed to look for such a message. Another way would be to distribute a hacked version of PKUNZIP which always displays the decrypted name and code, even in the case of an authentication mismatch. These are my reasons for concluding that all three of McAfee's authentication methods are inadequate. I hope it will not be thought that my purpose has been to single out McAfee for criticism. Obvious- ly, if his software is insecure in this sense, then so is all the other software which uses only a subset of these methods or none at all, and that's nearly all software. His simply constituted an ideal "case study" since it has more authentication features than any other that I know of and since it's so well known in this forum. Fortunately, there's a better solution (one which gets suggested every now and then in VIRUS-L): Replace the CRC algorithm in VALIDATE by a cryptographic hash function (such as MD4) to get a "message digest" about 128 bits long, and then apply the private-key procedure of a two-key cryptosystem to this. This solution has a number of advantages over the above methods: Unlike VALIDATE, which authenticates only the file, this method also authenticates the sender; the signatures can be safely supplied along with the files; and it requires only a one-time public announcement of the author's public key instead of having to re-announce all the checksums each time new versions of the programs are released. As for PKZIP's authentication system, it's true that this also authenticates the sender. However, unlike PKZIP, with the above solution the user's authentication utility (based on the public key) can be supplied independently of any program which it is designed to protect, and there is no circumvention process analogous to rezipping of the archive without the authentication option. Finally, it seems to be computationally infeasible to forge the signatures of most two-key systems. In the case of RSA, 13 years of unsuccessful attempts to break it suggest that it is as infeasible to forge as it is to factor its modulus. In the case of some other sys- tems, such as those of Rabin and Williams, it has even been *proved* that this is so, though these systems are more difficult to implement. On the other hand, there is no evidence, as far as I know, that it's infeasible to forge PKZIP authentication. And it's certainly possi- ble, as mentioned above, to forge CRCs in the current environment. While this solution seems better than any of the above methods, I don't claim that it's perfect. In particular, the commonly suggested protocol at the recipient's end seems to me problematic. I have a suggestion for improving it, but that will have to wait for a future posting. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 60] ***************************************** Downloaded From P-80 International Information Systems 304-744-2253