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 AA03505; Tue, 19 Jun 90 07:19:03 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA28584; Tue, 19 Jun 90 07:19:00 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA01592; Tue, 19 Jun 90 07:18:53 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa07577; 19 Jun 90 10:46 BST From: Anthony Appleyard To: DAVIDF@cs.heriot-watt.ac.uk Date: Tue, 19 Jun 90 09:44:00 BST Message-Id: <$TGWFCWKBBCVX at UMPA> Subject: Here is Virus-L vol 0 #0930 Virus-L Digest Fri, 30 Sep 88, Volume 0 : Issue #0930 Today's Topics Conference Book / Phone Number re: legislation on viri RE: Re: FSP_12 RE: Re: FSP_12 ** no subject, date = Fri, 30 Sep 88 18:48:17 +0200 program simulating a virus which can pass a CRC check twiddling rather than altering bytes paper "The Infection of PC Compatible Computers" Re: Conference Speeches Outlined Re: Conference Speeches Outlined ------------------------------ Date: Fri, 30 Sep 88 01:24:55 EDT From: Loren K Keim -- Lehigh University Subject: Conference Book / Phone Number I've had a number of people ask if the book would be available for sale after the conference. Yes, we'll send out copies to whoever might want one, including notes we'll take from each lecture and discussion we can. I can't quote a price yet, we'll need to know exact printing costs (although I can come close) and shipping. I'll get that to you probably a few days before the conference, but it is helpful for me if you send me a letter saying you want one. LKK0@LEHIGH Also, many people have been having problems getting hold of me. I will be at my father's house for till Oct. 31st (my house is being worked on at this very moment) which is (215) 865-3904. You'll have to ask for Jr because we have the same name. You can still leave a message on my machine at my place (215) 865-4253, and I will get it. During the day, its easier to leave a message at our main office (215) 395-0393. Loren -------------------- Date: Fri, 30 Sep 88 10:21:59 EDT From: Otto Stolz +49 7531 88 2645 Subject: re: legislation on viri There have been questions in this list concerning laws pertinent to virus writing and implanting, and related issues. This contribution tries to give an answer for the Federal republic of Germany. As I'm no lawyer, and English isn't my mother tongue, you'll probably need much imagination to understand my attempts for proper translation of the legal terms (this Cassel's Dictionary doesn't serve its purpose, either). Paragraph (%) 303 of our Penal Code deals with Damage to Property. After this paragraph, there have been inserted two more paragraphs, effective from 1 Aug 1986: % 303a Alteration of Data: (1) Who illegally deletes, suppresses, renders useless, or alters Data (cf. %202a, sect. 2), will be punished with up to two year's imprisonment or with a fine. (2) The attempt is punishable. % 303b Computer-Sabotage: (1) Who disturbs data processing that is of significant importance to some outside firm or some public authority by ways of 1. an act according to %303a sect. 1 or 2. destroying, damaging, rendering useless, removing, or altering some data processing unit or some data recording medium, will be punished with up to five year's imprisonment or a fine. (2) The attempt is punishable. Implanting a virus into a program on someboy else's computer or diskette means changing data, illegally, and hence clearly is subsumed under %303a sect. 1. Putting into circulation a Trojan Horse that is meant to implant some virus, clearly is subsumed under %303a sect. 2. In both cases, %303a is applicable even if no damage has been caused. %303b sect. 1 nr. 1 heightens the punishment for qualified cases of Alteration of Data, whilst %303b sect. 1 nr. 2 does the same for qualified cases of Damage to Property. The latter will seldom apply to viri -- only if a virus damages the screen (which can be done by faulty or malicious programming of the CGA or EGA cards, as I've been told) or other hardware. In any case, it'll be difficult -- if not impossible -- to hold somebody responsible for virus-issuing. E.g. we have evidence that the virus we've found, recently, has been dwelling in some of our computers for more than three months. We surely will not be able to trace this virus back to its originator! I do not know what the term "illegally" in %303a means to lawyers. Hopefully, a person spreading a virus unwittingly cannot be blamed for "illegally altering data". There is also a "Law on Protection from Improper Use of Person-Related Data during Data Processing" (do not blame my translation: this is also awful German :-), effective from 1 Jan 1978 (for data processing by private persons, corporations, firms, and federal authorities) and a couple of similar laws (for data processing by municipal, regional and other authorities). Here, I cannot discuss the whole law. It pertains only to particulars (no statistical aggregations) of individuals (no corporate bodies). It covers every form of data processing, even manually processed card-indizes. According to this law, processing of personal data is in principle forbidden (i.e. only allowed in special cases enumerated by this or other laws). One special case is consent of the person refferred to ( and I take it for granted, that posting a note to VIRUS-L implies everybody's consent to being refferred in every subscriber's NOTEBOOK and NAMES files -- otherwise I'd be liable for breaking this wonderful law :-) Now for the implication of this law to virus-defeating: according to %6 (far too long to be quoted verbatim) technical and organizational measures are to be taken to prevent unauthorized disemination or alteration of person-related data. Under this paragraph, a faculty member of our university had to give up processing his reserch-data (which included criminal records and similar data of real persons) on a personal computer. Even if this computer was kept in a locked room, it was considered too weak (subject to unautho- rized and unnoticed manipulations) to bear such delicate personal data. The research-project was delayed until a new and safe data processing procedure (on a host) had been established. So much for "security": word has spread even to lawyers in our country, that there is *no* such thing as "Security on a Personal Computer"! Best regards to everybody. I agree, that you store my name, phone number, and BITNET address on your computer with the object of communication :-) Otto Stolz -------------------- Date: Fri, 30 Sep 88 10:30:00 EDT From: Santanu Sircar Subject: RE: Re: FSP_12 To send any file(s) to anyone, type the following: -For a binary file SEND/FILE filename username@host /VMSDUMP -For a text file SEND/FILE filename username@host -Santanu -------------------- Date: Fri, 30 Sep 88 11:02:48 EDT From: Ken van Wyk Subject: RE: Re: FSP_12 In-Reply-To: Your message of Fri, 30 Sep 88 10:30:00 EDT > To send any file(s) to anyone, type the following: > -For a binary file > SEND/FILE filename username@host /VMSDUMP > -For a text file > SEND/FILE filename username@host That works great...if you're on a VAX on BITNET running JNET, and binary files can only be sent to another BITNET host using the above method. For the rest of us, however, that command will only generate an error message. To send a binary file via the networks, the (arguably) most universal method is to uuencode the file and mail it to the other user(s). The recipient(s) would then uudecode the file back into its original binary form. I've been meaning to get onto Ross Greenburg's bboard and pick up his latest version of FSP (I believe 1.4 or 1.5). When I get it, I'll make the file available via the LISTSERV here at Lehigh. (Please don't send me the file, I'll get it directly from Ross to assure that it's the latest version.) Ken Kenneth R. van Wyk Calvin: I'm gonna learn to ride this bike User Services Senior Consultant if it kills me! ... AAAAAUUUGGGHHH!!! Lehigh University Computing Center Hobbes: Did it kill you?! Internet: Calvin: No, it decided to maim me first. BITNET: -------------------- Date: Fri, 30 Sep 88 18:48:17 +0200 From: "Y. Radai" For various reasons (Bitnet problems, local holidays, even occasional work!) I'm only now catching up with the correspondence on VIRUS-L. So please forgive me if I refer to postings which are 2-3 weeks old. [This message has be split into the following separate messages, one per subject] -------------------- Date: Fri, 30 Sep 88 18:48:17 +0200 From: "Y. Radai" Subject: program simulating a virus which can pass a CRC check EAE114@URIMVS (ERISTIC) writes: > Has anybody seen or heard of any virus designed to pass a CRC > check? Or is this more work than the casual psychopath > is willing to incur? I haven't heard of an actual virus which does this, but not long ago I received an interesting program called PROVECRC, distributed by Chuck Gilmore of Gilmore Systems, CA, which is supposed to demonstrate what a virus *could* do in this respect. Given any input file (25 to 32000 bytes long), this program produces another file of the same size which, though different in content, is supposed to have the same CRC. The moral is supposed to be that "CRC checking alone is inadequate for file modification detection." Obviously, Gilmore's program could not possibly succeed against *arbitrary* generating polynomials; he would have to know the actual generator, or at least know that the generator was one of a certain small set of polynomials. The evidence shows that he assumes a specific 16-bit generator. In order to test his program, I ran PROVECRC on a small file. As promised, the modified file which was created had the same size, date and time as the original file. But when I computed the CRC of each of the two files using one of the CRC programs at my disposal, the CRCs were *different* happened when I tried another CRC program. Presumably, they don't use the same generator as Gilmore assumed. By comparing the files, I discovered that what PROVECRC does is as follows: Let n be the size of the file. Then it replaces the (n-19)th through (n-11)th bytes of the file by the string '*altered*' and twiddles the (n-10)th and (n-9)th bytes so as to yield the same CRC as the original file (relative to whatever generator he was assuming). I repeated the experiment with other program files, getting the same results with respect to CRCs. It is not surprising that in some cases the modified versions of the programs performed exactly as the original programs did, since for many executable files the actual program ends considerably before the nth byte, so that PROVECRC had enough room to modify bytes without affecting execution. Of course, actual viruses that perform destructive actions would generally take up more space than is available in such a "gap". But what most aroused my curiosity about PROVECRC was this: After an initial message giving the "actual" CRC of the file, one gets the message "NOTE: Up to 65,535 passes may take place!" The actual number of passes depends somehow on the particular file, though it's not a function of the size of the file. In any case, each pass takes about 1/65 of a second on the 4.77 MHz PC I was using. But what precisely was the program doing all this time and what constitutes a "pass"? Given that the program (thinks it) knows the generator and the corresponding CRC of the file, I don't think it should take that much time to figure out what 16 bits should replace the (n-10)th and (n-9)th bytes. (I considered the possibility that the mention of passes was merely a coverup for some time-consuming Trojan or viral activity, but I found no indication of it.) So does anyone out there have any idea whether there's a legitimate reason for such a program to take so much time, and what a "pass" might consist of? (If anyone's interested in taking this program apart, I'll be glad to e-mail it to him.) -------------------- Date: Fri, 30 Sep 88 18:48:17 +0200 From: "Y. Radai" Subject: twiddling rather than altering bytes me!Jeff Ogata writes: >The reason I discussed only adding bytes to the original file, rather >than modifying bytes in the file, is that as far as I know, virus >attacks are not effective if they crash the program they infect, >which is likely to happen if they twiddle bits in the original >program. As Jerry Leichter replied, modification with preservation of size can be performed without crashing the program if the virus writer concentrates his attack on specific files whose content is known to him in advance. But I wish to add another point: Any self-respecting program to compare checksums of files will also compare their *sizes*. (And there are some programs which notify you of size changes even though they don't compute any checksum.) Therefore a virus creator has a better chance of his modification going undetected if he avoids altering the file size. -------------------- Date: Fri, 30 Sep 88 18:48:17 +0200 From: "Y. Radai" Subject: paper "The Infection of PC Compatible Computers" Referring to the Kiel-Lee paper "The Infection of PC Compatible Computers", David Chess writes: > In a similar vein, I would advise being a little less confident > when stating things like "four versions of the Israeli virus > and seven versions of the Brain virus have been found." It > may be true in the most literal sense of "version" (anyone could > create a "new version" of one of these by changing a text or > no-op byte), but there doesn't seem to be any good evidence > that it's *really* true, in the sense of there being that many > versions that actually have some difference in their behavior. > (Authors, especially in the popular press, always seem to be > tempted to exaggerate, if only by implication, the number of > different viruses they know of; makes them sound wiser...) I suspect that when the authors spoke of "four versions of the Israeli virus", they meant to say "four Israeli viruses". And I can assure you, David, that there really are (at least) that many. I agree that using a binary editor to change a string of text, or even to change the date the bomb is set to go off, should not be considered as creating a new virus (although the latter could be considered as a new "version" of the same virus since it changes the *behavior* in an essential way). But the two viruses discovered in Israel whose target date is April Fools Day are sufficiently distinct from the Friday-the-13th virus and from each other that they deserve to be considered as separate viruses. (The fourth virus is admittedly very similar to the main Friday-the-13th virus and maybe should be considered as another version of the same virus, but if I'm not mistaken, even it differs by more than mere binary editing.) Y. Radai, Hebrew Univ. of Jerusalem -------------------- Date: Fri, 30 Sep 88 14:40:05 EDT From: MICHAEL LEE Subject: Re: Conference Speeches Outlined And where is Lehigh University? Mike Lee, Washington U., St. Louis, Mo -------------------- Date: Fri, 30 Sep 88 14:43:58 EDT From: MICHAEL LEE Subject: Re: Conference Speeches Outlined I received information about a conference being given about viruses and security concerns. Where will this lecture/conference be taking place? I am interested in attending. ----mike lee, Washington Univ -------------------- *** end of Virus-L issue ***