Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA13880; Fri, 1 Jun 90 11:33:24 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA20612; Fri, 1 Jun 90 11:33:17 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA01145; Fri, 1 Jun 90 11:32:57 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa23914; 1 Jun 90 16:11 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Fri, 01 Jun 90 16:08:04 BST Message-Id: <$TGTWCZCFFBTB at UMPA> Subject: Virus-L vol 0 issue #0517 Virus-L Digest Tue, 17 May 88, Volume 0 : Issue #0517 Today's Topics Detecting damaged data CRC Signatures not reliable at all ? re: Detecting damaged data Special Warning on 3 infected MacIntosh programs Special Warning on 3 infected MacIntosh programs Re: checksum signatures Re: Detecting damaged data re: CRC signatures not reliable at all ? Re: hunting up infected files ------------------------------ Date: Tue, 17 May 88 04:19:54 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Amanda B Rosen Subject: Detecting damaged data Shortly after I posted some thoughts concerning the usefulness of keeping several (random) signatures for every file, Woody(WWEAVER%DREW.BITNET) posted a long, well-written article declaring that this is exactly the right thing to do. He still mentions only CRC's, though. Why are they considered the best signatures? Is there a particularly easy way to defeat byte-counters (or nibble counters, if you can't store a 256 word signature)? It seems to me that in order to check files sufficiently often, the CPU overhead must be *very* light. Disk storage, however, is at much less of a premium. Even a 256 word signature would be a tiny percent of the actual file's size, and the byte-counting algorithm is very cheap. /a -------------------- Date: Tue, 17 May 88 12:52:00 CET Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Karl-L. Noell" Subject: CRC Signatures not reliable at all ? Several discussion remarks have objected, that CRC signatures wouldn't be able to protect against intentional file tamperings. This holds true only under the following assumptions: 1. A CRC based protection scheme is utilized. 2. The certain G(x)=... is the current (and public known) denominator polynomial to calculate the signature, and 3. the original (untampered) file yields to the very remainder R(x)=... considered as the signature of the clean file. To succeed in his impious attempts, an evil-doer must exactly know really *everything* stated above (1.,2.,3.). Then it's indeed possible to 'adjust' the CRC signature to get the expected value even after files have been altered. For this reason, CRC signatures can't provide sufficient security if one intends to protect the public *distribution* of files showing, that they are coming from trustworthy sources. Nevertheless CRC signatures can be fairly reliable to protect files from getting tampered *subsequently* during running for applications. If you chose an arbitrary G(x) and *not* the polynomials standardized by CCITT, and if you alter *your* G(x) from time to time, how should another person be able to know about this scheme ? Keeping and com- paring weekly logs reporting file sizes, time date stamps *and* CRCs (computed with home made and sometimes changed polynomials) will give a fair chance to detect suspicious events. I believe such imperfect methode is still better than taking no care at all whilst waiting for the 'great and entirely secure' solution. Karl Noell -------------------- Date: Tue, 17 May 88 07:22:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Woody Subject: re: Detecting damaged data Amanda B Rosen asks >Why are they [CRC checks] considered the best >signatures? Is there a particularly easy way to defeat byte-counters (or >nibble counters, if you can't store a 256 word signature)? Actually, I don't think there is a "best" scheme. To defeat a particular CRC check, you have to make sure that your virus maps the binary polynomial of the corrupted file (mod the CRC polynomial) to the binary polynomial representing the true file (mod the CRC polynomial). To defeat a byte counter, you have to make sure the corrupted file has the same bytes as the true file (though presumably in a new order). The thing is, though, if you devote that 256 word signature to a CRC check, we have 2~256*(wordsize) different possible states that can arise as residues. Moreover, there are good mathematical reasons to believe that these different states occur with equal frequency. If you devote that 256 word signature to a byte counter then not all 2~256*(wordsize) bit patterns arise: moreover, I would suspect that the counts for most executable files have about the same percentages of each operation. The lack of randomness makes the test less effective. However, most people want to check the size of the file as part of the corruption check -- the idea of a byte counter is simply a generalizaton of that examination. She continues >It seems to me that in order to check files sufficiently often, the CPU >overhead must be *very* light. Disk storage, however, is at much less of a >premium. Even a 256 word signature would be a tiny percent of the actual >file's size, and the byte-counting algorithm is very cheap. Absolutely. If we want to add this check to a segment loader as part of the operating system, it needs be fast indeed. As I recall, the CRC check is done by fairly simple shifting and mod 2 addition: in both the byte counting algorithm and the CRC check algorithm, the actual check is a small fraction of the time required to retrieve the file from storage. Is a CRC check before launch being done anywhere? Even a simple parity check (i.e. CRC with polynomial x + 1)? Why not? -------------------- Date: Tue, 17 May 88 08:37:26 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Otto Stolz +49 7531 88 2645 Subject: Special Warning on 3 infected MacIntosh programs Hello, A couple of minutes ago, I run into a letter dated 21th March 1988, that was circulated by a Software Distributing House in southern Germany to their customers. I will not post their name or address to this list; if somebody really needs it, please drop my a note, privately. As I don't have access to a MacIntosh, I can't assess the importance the message might bear to MacIntosh users; so I deemed it best posting it in this list for anybody who might be concerned. As none of the programs below is mentioned in the DIRTY DOZEN, somebody (Ken Van Wyk?) should forward this note to Eric Newhouse whose BITNET address is unknown to me. Following is the main part of this letter (translated into English): > Subject: MacIntosh Virus!!! > > Regrettably, also MacIntosh has been befallen by some virus, meanwhile. > Please do *not* use any of the following programs: > Pre-Release PageMaker 3.0 > Pre-Release HyperCard German > Pre-Release Multifinder German > > *Beware:* Virus spreads through networks (e.g. AppleTalk)!!! > > Symptoms: Difficulties when using the Hard Disk, even to the amount > of completely loosing the Hard Disk. Best regards Otto Stolz -------------------- Date: Tue, 17 May 88 10:08:20 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Resent-Date: 17 May 1988, 15:49:32 +0200 (MESZ) Comments: Resent-From: Otto Stolz +49 7531 88 2645 RZOTTO at DKNKURZ1 From: Otto Stolz +49 7531 88 2645 Subject: Special Warning on 3 infected MacIntosh programs The following contribution came back to me from somewhere down the line for a reason I couldn't figure out from the accompanying message. As I'm not sure wether it has already reached the relvant LISTSERV, I'm going to post it again. Hello, A couple of minutes ago, I run into a letter dated 21th March 1988, that was circulated by a Software Distributing House in southern Germany to their customers. I will not post their name or address to this list; if somebody really needs it, please drop my a note, privately. As I don't have access to a MacIntosh, I can't assess the importance the message might bear to MacIntosh users; so I deemed it best posting it in this list for anybody who might be concerned. As none of the programs below is mentioned in the DIRTY DOZEN, somebody (Ken Van Wyk?) should forward this note to Eric Newhouse whose BITNET address is unknown to me. Following is the main part of this letter (translated into English): > Subject: MacIntosh Virus!!! > > Regrettably, also MacIntosh has been befallen by some virus, meanwhile. > Please do *not* use any of the following programs: > Pre-Release PageMaker 3.0 > Pre-Release HyperCard German > Pre-Release Multifinder German > > *Beware:* Virus spreads through networks (e.g. AppleTalk)!!! > > Symptoms: Difficulties when using the Hard Disk, even to the amount > of completely loosing the Hard Disk. Best regards Otto Stolz -------------------- Date: Tue, 17 May 88 08:40:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Joseph M. Beckman" Subject: Re: checksum signatures In-Reply-To: Message of 12 May 88 09:15 EDT from "Kenneth R. van Wyk" 1. It is patently false that a checksum algorithm can (with an accuracy of 100%) detect changes to a file. I am assuming that "checksum" here means some "encoding" of the file that *is less lengthy* of the file itself. Consider this: let's let xx represent files, y represent the checksum. If we only use digits for this example, there are 100 different files that can exist, 10 different checksums. Clearly, one checksum "covers" 10 files. Although you can do certain other things (in addition to "pure" checksums), you would (?) have to *be able to recreate the original file* from the "checksum" (and whatever else you looked at) in order to claim 100% detection. Anything less says that there is a possibility of "collision." If you make a backup of a file & then do a compare, that would give you 100% (with certain assumptions); or even if you could compress the file & back that up. It may be that you can achieve 100% detection with less if you make certain assumptions about what the file will or will not contain; but if you are talking about arbitrary strings, such an assumption is not valid. Joseph -------------------- Date: Tue, 17 May 88 17:18:00 LCL Reply-To: Virus Discussion List Sender: Virus Discussion List From: Michael Wagner new! +49 228 8199645 Subject: Re: Detecting damaged data > From: Woody > > Is a CRC check before launch being done anywhere? Even a simple > parity check (i.e. CRC with polynomial x + 1)? Why not? I believe OS-9 has always done this. Even on slow 1MHz 6809s, the delay was never objectionable. The point was not to detect viruses, but rather to provide some minimal protection against calling programs that had suffered damage on disk and had passed the rather simplistic old disk data validation checks. This was especially important on a cpu that had no memory protect and no supervisory/user mode capabilities. I don't recall the details of the algorithm any more, but I can find out if anyone is interested (private mail, please - don't tell the whole list). It was so simple at thing to do, and offered considerable protection. I never understood why no other micro-os manufacturer did it. Michael -------------------- Date: Tue, 17 May 88 12:59:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Woody Subject: re: CRC signatures not reliable at all ? Karl Noell (Germany! Isn't BITNET a great communication network?) writes >Several discussion remarks have objected, that CRC signatures wouldn't >be able to protect against intentional file tamperings. >This holds true only under the following assumptions: > 1. A CRC based protection scheme is utilized. > 2. The certain G(x)=... is the current (and public known) > denominator polynomial to calculate the signature, and > 3. the original (untampered) file yields to the very remainder > R(x)=... considered as the signature of the clean file. >To succeed in his impious attempts, an evil-doer must exactly know >really *everything* stated above (1.,2.,3.). Then it's indeed possible >to 'adjust' the CRC signature to get the expected value even after >files have been altered. [...] I'd like to point out he needn't really *know* all that. Let us suppose that the virus writer knows that 1 is true. Also, suppose that the virus writer does not *know* the G(x) of 2, but suspects it is one of g1(x), g2(x), ... gk(x). Write G(x) = g1(x) * g2(x) * ... * gk(x), and set ti(x) = G(x) / gi(x) (for i = 1 .. k ). For a fixed remainder gi(x) he precomputes mi(x) so that mi(x) * ti(x) = 1 mod gi(x). (Such exist from the chinese remainder theorem, because the CRC polynomials are relatively prime.) Set p(x) to be the clean file, interpreted as a binary polynomial. Compute r1(x), r2(x), ... , rk(x) the remainders mod g1(x), g2(x), ... , gk(x) respectively. Form r(x) = sum { ri(x) * mi(x) * ti(x) } mod G(x). The virus need only do the following: (1) analyze the executable image, and find a routine that is rarely executed. Carefully jump around that routine, and use the space for his viral code. Alter p to form an infected, virally communicating file p'(x). Save a bit more space that we will use as free variables. (2) Alter p'(x) to p*(x) by manipulating that free space so that p*(x) = r(x) mod G(x). Now, no matter which CRC check g1(x) to gk(x) is run, p*(x) has the same residue as the 'clean' file p(x). There is no way to defend against that, provided the invading virus does know that you are using a CRC check and has a (short) list of CRC polynomials to protect itself against. There is considerable hope, however. The computation involved in obtaining r(x) is nontrivial. Moreover, the 'save a bit more space' may also be nontrivial: to match the residue mod G(x) it could be necessary to use up to degree(G(x)) bits and this is the degree of the CRC check times the number of potential checking polynomials: with a sufficiently large CRC check signature and sufficiently many candidates for check polynomials, our virus writer can't write an undetectible virus. Anyway, Karl Noell goes on to observe >If you chose an arbitrary G(x) and *not* the polynomials standardized >by CCITT, and if you alter *your* G(x) from time to time, how should >another person be able to know about this scheme ? Keeping and com- >paring weekly logs reporting file sizes, time date stamps *and* CRCs >(computed with home made and sometimes changed polynomials) will give >a fair chance to detect suspicious events. I believe such imperfect >methode is still better than taking no care at all whilst waiting >for the 'great and entirely secure' solution. A person could know your CRC check polynomial because you aren't clever enough in concealing it. Suppose you have a file called MY_CRC_CHECK_POLYNOMIAL.DAT... I could have my virus look for such a file and use it. But seriously, this is the whole point. If we are able to assume that the virus does not know which of the CRC polynomials you are using (nor its size) then he can not protect completely against it. As long as we are dilligent and random, this is not an "imperfect methode" but safe protection against a random virus. A more serious problem however would be a program designed to specifically live inside a specific site or system. For a specific site, the randomness of the CRC is no protection. But then, this is virus-L, not ICE-L... woody -------------------- Date: Tue, 17 May 88 08:42:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Resent-From: "Joseph M. Beckman" Comments: Originally-From: "Joseph M. Beckman" From: "Joseph M. Beckman" Subject: Re: hunting up infected files In-Reply-To: Message of 9 May 1988 11:05 edt from Karl-L. Noell As an employee of the National Computer Security Center, I must point out that we do *NOT* attempt to track perpetrators for prosecution or for *ANY* other reason! We are not a law enforcement Agency, and are prohibited by law to take any such action. We are interested in tracking the viruses (or ordinary Trojan Horses) as they infect different sites. As a matter of professional interest, I would be curious as to the motivations of perpetrators of malicious code, or whether they are members of "Hacker Clubs;" but that is information that may be conveyed without identifying the people/organizations involved. Joseph