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 AA14028; Fri, 1 Jun 90 12:00:41 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA20830; Fri, 1 Jun 90 12:00:38 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA02640; Fri, 1 Jun 90 12:00:13 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa24082; 1 Jun 90 16:14 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Fri, 01 Jun 90 16:07:16 BST Message-Id: <$TGTWCZCFFBRG at UMPA> Subject: Virus-L vol 0 issue #0513 Virus-L Digest Fri, 13 May 88, Volume 0 : Issue #0513 Today's Topics The neverending chain.... RE: checksum signatures Preventing Public Domain Software contamination Re: Preventing Public Domain Software contamination Something funny about CheckUp ? Flushot+'s bugs RE: DES checksum signatures verification of authorship of computer programs detecting data alterations via CRC Signature lengths Checkup Signature lengths Signature lengths More FLUSHOT+ bugs All Things Considered Question about CRC protection XMAS EXEC add'l comments ------------------------------ Date: Fri, 13 May 88 01:55:53 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joseph Sieczkowski Subject: The neverending chain.... Ok guys...let's face some facts: NO software implemented virus protection scheme can ever be 100% effective against stopping viruses because there always can be a counter virus that attackes the protection program. (ie. Virus "A" attacks system, Vaccine "A" protects system, Virus "B" could attack Vaccine "A", etc...) It is also very important to consider the system on which we're implementing a protection package. A PC by definition is unsecure... Why? (1) You can address real memory, and (2) you can access the I/O ports directly. This compounds the problem. This is not to say we should not write protection programs to try and protect ourselves. There is probably much merit in the idea that if a protection scheme is "hard" to break, people might not bother trying. (Let's face it, the "fun" does wear off after days of trying to break protection schemes.) However, we must realize that no scheme is perfectly safe. What we are creating is a "fishnet" to catch most of the viruses around. And, of course, we always have the option of making the net a little finer. Presently, it is of key importance to be aware of these little beasties. (As all of you are as evidenced by being on this list.) In the future, "hardware" protection is probably going to be a neccessity. Hopefully, it won't inhibit system "friendliness" and utility too much. (Remember, the most secure and protected system to date is one which is totally isolated and restricted...and who wants one of those? Yeeek) Joes -------------------- Date: Fri, 13 May 88 02:36:00 CST Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: Warning -- RSCS tag indicates an origin of SMTPUSER@SASK From: Derek Andrew Subject: RE: checksum signatures It is true that simple checksums are easy to defeat. I suggest considering using the DES algorithm in the following manner. First, consider the file as a sequence of 8 byte blocks (64 bits). Encrypt each block using a public and known password, and add the result to a running total, 64 bits wide. At the end, you have a 64 bit checksum. I doubt anyone reading this is cabable of modifying the original file so as to calculate this checksum. I missed the original posting. I am assuming that the checksum does not reside with the file, but is kept in a seperate location where the virus could not get to it. derek andrew, u of saskatchewan, andrew@sask.USask.ca -------------------- Date: Fri, 13 May 88 10:00:53 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Atul Butte Subject: Preventing Public Domain Software contamination With all the problems with virus infected public domain and shareware software, I propose the following solution (for the Macintosh): There exists a shareware program called StuffIt 1.4 which was designed to group multiple files into one file which can then be uploaded. StuffIt 1.4 is for the Macintosh, and is turning into a sort of standard for packing. StuffIt 1.4, in addition to grouping files can compress them and can encrypt them. The proposal: How about adding a new feature to StuffIt that encrypts files, but in such a way that they can only be decrypted and not encrypted again? This can be done with the following method. StuffIt could prompt the uploading user to enter an encrypting code which is used to encrypt the files. Along with the files, another code is included. This code is the decrypting code, which downloading users can use to decrypt the file. The decrypting code could be hashed by some secret function into the original encrypting code. This method is similar to the "trapdoor" functions used for Public-Key Cryptosystems with one-way functions. The advantage of this is that the original author of a program can encrypt his or her software and place it in the public domain without the fear of others downloading the file, contaminating it with a virus, and then uploading the file as the original. Atul Butte /----------\ /----------\ Brown University ! OK ! ! CANCEL ! ST602397@BROWNVM.BITNET \----------/ \----------/ -------------------- Date: Fri, 13 May 88 10:51:35 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Preventing Public Domain Software contamination In-Reply-To: Message of Fri, 13 May 88 10:00:53 EDT from >How about adding a new feature to StuffIt that encrypts files, but in >such a way that they can only be decrypted and not encrypted again? This >can be done with the following method. StuffIt could prompt the >uploading user to enter an encrypting code which is used to encrypt the >files. Along with the files, another code is included. This code is the >decrypting code, which downloading users can use to decrypt the file. >The decrypting code could be hashed by some secret function into the >original encrypting code. This method is similar to the "trapdoor" >functions used for Public-Key Cryptosystems with one-way functions. Sounds like a fair idea, but what's to prevent a person from un-stuffing all the files, and then re-stuffing them into a brand new stuff file with his/her own encryption code? Sure, only the author could verify the authenticity of the encryption pw, but in the meantime, this new version could be floating all around on different bbs's. Ken - ---------------------------------------------------------------------- = Kenneth R. van Wyk = = = User Services Senior Consultant = Badgers! We don't need = = Lehigh University Computing Center = no stinkin badgers! = = Internet: = = = BITNET: = = - ---------------------------------------------------------------------- -------------------- Date: Fri, 13 May 88 11:39:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: GILL@QUCDNAST Subject: Something funny about CheckUp ? I had the same problem with CheckUp occurring that was mentioned earlier. However, I have had a lot of little bugs, system crashes, etc occurring in the last two weeks. My machine is getting a full physical next week, but I think the problem is software oriented. My impression is that FLUSHOT+ is actually buggy. I know for a fact that FLUSHOT+ will crash PCWRITE 2.71 (one can't run PR.EXE from within ED.EXE), and I've had other similar difficulties. I guess that comes from intercepting so many different DOS interupts. Right now, I'm in the middle of a total system backup and reorganization, without FLUSHOT+ to protect/mess me. (However, I may be wrong :-) ) Anyone else had similar, unexplained difficulties? Arnold Gill Queen's University at Kingston gill @ qucdnast.bitnet -------------------- Date: Fri, 13 May 88 12:00:04 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David A. Bader" Subject: Flushot+'s bugs I, too, had a problem with Flushot+ in that it changed the CMOS memory containing my AT clone's setup information (such as floppy and hard drives connected, time and date, video configuration, system memory, etc.) Also, I recently read that someone had a problem with PCWrite 2.71. To interject a paragraph from Eric Newhouse's Dirty Dozen List Issue #8, revision "A" dated February 21, 1988: PCW271xx.ARC (Suspected Trojan) A modified version of the popular PC-WRITE word processor (v. 2.71) has now scrambled at least 10 FAT tables that I know of. If you want to download version 2.71 of PC-WRITE be very careful! The bogus version can be identified by its size; it uses 98,274 bytes wheras [sic] the good version uses 98,644. For reference, version 2.7 of PC-WRITE occupies 98,242 bytes. David A. Bader Lehigh University -------------------- Date: Fri, 13 May 88 08:36:00 LCL Reply-To: Virus Discussion List Sender: Virus Discussion List From: Communication is the root of insecurity Subject: RE: DES checksum signatures >It is true that simple checksums are easy to defeat. I suggest considering >using the DES algorithm in the following manner. First, consider the file as a >sequence of 8 byte blocks (64 bits). Encrypt each block using a public and >known password, and add the result to a running total, 64 bits wide. At the >end, you have a 64 bit checksum. I doubt anyone reading this is cabable >of modifying the original file so as to calculate this checksum. Cryptography (and especially cryptographic checksums) is a complicated field, and is it difficult for a novice to determine how difficult a scheme is to defeat. The checksum you mentioned is trivial to defeat. Here is the method to defeat that checksum: Since the key is known, the intruder trying to modify the file can calculate the original checksum. The intruder modifies the file, but saves one 8-byte block that is never referenced and can have an arbitrary value. The checksum for the modified file is calculated (ignoring the spare block), and the difference between the original checksum and the new checksum is determined by subtraction. This difference is decrypted with the known key and placed in the spare 8-byte block in the file. This modified file now has the same checksum as the original file. Even if the key is not known, there is an additional attack against this checksum: individual 8-byte blocks of the file can be transposed and the checksum remains the same. This is not likely to be useful to someone who wants to create a virus, but is a concern if general file integrity is important. DES has a defined chaining mode (CBC--Cipher block chaining) where a series of blocks is encrypted with the result from each encryption step feeding into the next step. CBC mode has nice properties for encryption, but, again, an integrity check using CBC mode with a known key can easily be circumvented. [However, changing the order of blocks can be detected if the key is not publicly known.] A simple way to use DES and a known key to build a good (cryptographically secure) checksum scheme would be very useful, but I don't know of any that have been demonstrated to be secure. [One step further: It would be nice if the developer of the software could generate the cryptographic checksum and distribute it with the software. This results in another problem to solve: How the correct checksum can be securely distributed.] B.J. -------------------- Date: Fri, 13 May 88 12:50:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Dr. Woody" Subject: verification of authorship of computer programs One problem we have been dealing with is verification of authorship of computer works, whether executables or source code. (People feel better if they have the source - but I don't know about you guys, but if I'm presented with a 100K source file, I might not be able to detect a trojan...) This is a standard problem in cryptography. Probably the simplest solution applicable to the BBS system is to do the following: the author should choose his favorite two very very large primes, and publish and use their product in all his works. He can then encrypt his executable (or source code) so that a public key system can decrypt it. The author should, of course, put the public key with the cleartext documentation. The advantage is simply that a responsible BBS owner need only verify the existence of the author once, and can do it in a relatively compact fashion: he doesn't have to do a diff on files recieved, but only on the key. Moreover, the trojans we see today are typically revisions of already existing files (like the archive 1A => archive 1B) and so the BBS owner would know if a malicious user contaminated the file and resubmitted it: the key would change from the original author to one devised by the malicious user. One disadvantage of course is that decoding the file is made more computer resource intensive. What price security? I would not mind running an extra layer to verify that the author is who he says it is. A submission of a program not by the author would decrypt to gibberish. (With some authors, even the real program decrypts to gibberish... ;-) ) Of course, what will probably happen is that unsophisticated users will distribute already decrypted images. However, at least the BBS owners have the ability to store only author-encrypted files and preserve the BBS's integrity for trojan-free files. woody weaver wweaver@drew -------------------- Date: Fri, 13 May 88 12:49:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Dr. Woody" Subject: detecting data alterations via CRC One of the thoughts for detecting differences in files has been to write down a checksum signature with the file. The problem, of course, is that if the virus author realizes that his creation is subject to, say, CRC detection, then he will have the virus upon infection compute the CRC of the file, and then alter sufficient bytes to preserve the CRC. It has been pointed out that typical programs are measured in the kilo- byte, while signatures are measured in bytes; since the map is from a larger set to a smaller set, the map can not be 1-1. One solution to this was, as someone observed, is that there is more than one cyclic polynomial that can be used: after all, fields have lots of primitive elements. If the CRC polynomial can be chosen from one of m (where m is in the thousands), and there is only a probability of 1 in 2~n of the virus accidentally preserving the CRC checksum then the probability of correctly preserving all of the CRC polynomials is 1 in 2~mn. Of course, that means that the checking program would have to compute all m CRC polynomials. More likely, the program would sample 2 or 3 CRC values; most people can live with a likelyhood of 1 in 2~3n of the virus accidentally preserving the checksum. One problem is that the virus need not accidentally preserve checksums. The virus could concievably satisfy *ALL* of the CRC polynomials, provided it knew how large the signature n was. (This assumes that the input set is larger than 2~mn.) The chief advantage is that in order to be able to have self replicating code with an infection scheme this complex, the virus would have to be large and the infection process would be slow, consuming a (hopefully) visible fraction of computing resources. Fat and slow viruses can be detected, and after detection hopefully cured. An alternative, for the people who are especially concerned about security and are willing to devote a larger fraction of their resources can use a CRC scheme with site dependent signature size. In this fashion, the virus can not know in advance the detection scheme the site will use, and so the infection passing the signature-preservation test will be back to random, and a probability most people can live with. woody weaver wweaver@drew -------------------- Date: Fri, 13 May 88 08:28:10 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Craig Pepmiller Subject: Signature lengths It is not strictly true that a signature must be as large as the file checked to avoid many-to-one mapping. An easy way to prove this is data compression. It is easy to construct a file that uniquely identifies a larger file if the source has repeating patterns or other features that are compressible. Another thought for budding compu-epidemiologists; There is a set of unique machine instructions that a virus must use to work. If you compress all the bytes that are not part of that set then you can have a signature that is much much smaller than the original and still identify the vital parts of the file. This would not work on programs that are meant to unpack and execute other files (ie BASICA) or where a change in an argument can bring in unchecked code. Maybe you would have to check disks in their entirety. Any comments? What set of instructions would need to be part of the set? Should this be a thesis project for somebody (maybe me)? Think about it, Craig Pepmiller Comp. Prog./Anal. II University of MO-Columbia Bitnet: CCCRAIG@UMCVMB -------------------- Date: Fri, 13 May 88 13:59:24 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Checkup I just downloaded Checkup 1.4 from the author's own bbs (215-969-8379). Rich Levin, the author, tells me that version 1.5 should be out within a week or so. I'll post it as soon as it's available. I was unable to find any differences between the file that I downloaded and the one which I had previously posted. I think that Flu_Shot+ was displaying incorrect error messages - but I could be wrong... I did have some other problems with Flu_Shot+ interfering with a couple other programs, for what that's worth. Anyway, you can all rest assured that the Checkup file on VIRUS-L is as the author intended for it to be. The filename is still CHKUP14 UUE on this LISTSERV. Ken - ---------------------------------------------------------------------- = Kenneth R. van Wyk = = = User Services Senior Consultant = Badgers! We don't need = = Lehigh University Computing Center = no stinkin badgers! = = Internet: = = = BITNET: = = - ---------------------------------------------------------------------- -------------------- Date: Fri, 13 May 88 14:45:08 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: Signature lengths > From: Craig Pepmiller > It is not strictly true that a signature must be as large as the file checked > to avoid many-to-one mapping. An easy way to prove this is data compression. That's a point; the true statement is more like that the signature of a *random* file must be, on average, as large as the file to be checked (if you run a data-compression program on a file of truly random bits, the file usually gets larger...). If I had any faith in my understanding of the concept of information, I'd say that a one-to-one mapping is only possible if the elements of both sets contain the same amount of information... > Another thought for budding compu-epidemiologists; There is a set of unique > machine instructions that a virus must use to work. Could you elaborate on that? The instructions that a virus needs to work are generally the same instructions that any other program needs to do anything else (adds, moves, operating-system calls). You could probably identify a set of bytes and say "any virus must contain at least one of these", but it's not clear to me how that would aid in compression and signature-making. Sounds interesting, though; could you give more details? (Unless you think I'm the only one who doesn't understand, in which case write me a note and scold me!) DC -------------------- Date: Fri, 13 May 88 20:35:22 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List Comments: In-Reply-To: 13 May 88 08:28:10 CDT from Craig Pepmiller From: Otto Stolz +49 7531 88 2645 Subject: Signature lengths > There is a set of unique machine instructions that a virus must use to > work. True. > If you compress all the bytes that are not part of that set then you > can ... still identify the vital parts of the file. False!! Using specific instructions doesn't imply having these very instructions in the executable program file. The virus could well compose those vital (and revealing) instructions on the fly from totally unsuspicious material. E.g. it could subtract some register's contents from itself to fabricate zero, increment and shift it several times to produce an arbitrary OP-code, store it to memory and eventually jump to this very memory location. Hence, all OP-codes belong somehow to the vital set. Think about it. Best regards Otto -------------------- Date: Fri, 13 May 88 12:26:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: GILL@QUCDNAST Subject: More FLUSHOT+ bugs Now that someone mentioned it, I had the CMOS problem as well, but on an IBM-PC clone (no XT or AT!) - my machine is a Zenith 151. From the FLUSHOT+ documentation, I didn't even realize that my CMOS could even be changed - it implies this is a purely AT possibility. Arnold Gill Queen's University at Kingston gill @ qucdnast.bitnet -------------------- Date: Fri, 13 May 88 17:01:23 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Russell Nelson Subject: All Things Considered There will be a report on the Israel University virus tonight on NPR. Catch it on your local public radio station. This report might be repeated on next morning's Morning Edition. -russ -------------------- Date: Fri, 13 May 88 12:20:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: GILL@QUCDNAST Subject: Question about CRC protection As I understand CRCs, the CRC is a particular polynomial function of the bytes within a file. If that is the case, would it not be possible to devise two (or three) orthonormal CRC polynomials, such that any illegal change in the programs constant would necessitate a change in one or more of the CRCs? A virus could make one of the CRCs come out all right, but several orthonormal ones? If such an idea is possible, then virus protection becomes simply a matter of saving and safely protecting ones CRC list. Of course, I may be wrong. Being in physics means I'm not overly concerned with uniqueness proofs. :-) Arnold Gill Queen's University at Kingston gill @ qucdnast.bitnet -------------------- Date: Fri, 13 May 88 12:33:29 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Neil Duffee Subject: XMAS EXEC add'l comments some additional comments on the CHRISTMA EXEC: The above virus (which arrived here with the name XMAS EXEC) more likely relied on our trust because it was, after all, sent to us from a friend at another node, was it not? Since we trust our friends, why not just run it? (besides, at that time, virii were limited to micros and not mainframes) Locally, the operators (and prob. the system manager) did a periodic check of the spool files and purged about 200+ files manually. (we are a rather peripheral node) Neil Duffee Computer Operator University of Ottawa Ottawa, Ontario, Canada NJD2F@UOTTAWA.BITNET (soon to become NJD2D@UOTTAWA.BITNET)