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 AA14055; Fri, 1 Jun 90 12:05:32 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA20875; Fri, 1 Jun 90 12:05:27 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA02772; Fri, 1 Jun 90 12:05:07 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa25037; 1 Jun 90 16:29 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Fri, 01 Jun 90 16:07:04 BST Message-Id: <$TGTWCZCFFBRD at UMPA> Subject: Virus-L vol 0 issue #0512 Virus-L Digest Thu, 12 May 88, Volume 0 : Issue #0512 Today's Topics checksum signatures checksum signatures Re: hunting up infected files ** no subject, date = Thu, 12 May 88 12:02:24 EDT Signatures and Checksums Is there something funny in the posted CHECKUP? Re: Is there something funny in the posted CHECKUP? re: the "database" scheme.... re:re: is there something funny in .... The "database" scheme RE: checksum signatures RE: checksum signatures ------------------------------ Date: Thu, 12 May 88 09:15:22 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: checksum signatures In looking at the documentation for the Checkup program, I see that they're using a form of a checksum to validate whether or not a file has been altered. Now, a smart virus author can easily circumvent a checksum algorithm by adding dummy characters to the file so that the checksum comes out to the same value. The Checkup program, however, maintains that its scheme is impossible to get around by using padding characters since it calculates the checksum of the entire file as well as that of randomly sized blocks within the file. It then stores this data in (I assume) an encrypted format. This raises an interesting question - is it truly possible to write a checksum/crc/whatever algorithm that will be able to figure out whether or not a file has been changed 100% of the time? Let's assume that the signature data has *not* been tampered with in any way. It is no secret that both checksums and crcs can be circumvented rather easily. But, an algorithm which could validate a file with 100% effectiveness could be very worthwhile looking into. Once again, the validity of the signature data itself would have to be insured via encryption and/or read-only isolation. Comments? Can anyone prove or disprove the claims that the author of Checkup makes? Ken - ---------------------------------------------------------------------- = Kenneth R. van Wyk = = = User Services Senior Consultant = Badgers! We don't need = = Lehigh University Computing Center = no stinkin badgers! = = Internet: = = = BITNET: = = - ---------------------------------------------------------------------- -------------------- Date: Thu, 12 May 88 09:36:19 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: checksum signatures Well, there's a very simple argument that suggests that no short (or even medium-sized) checksum or other signature can be 100% effective in detecting changes to files. Consider: files are large objects, thousands of bytes long. Signatures are smaller than that; at most hundreds of bytes long. When you map a large set into a smaller set, there must be cases in which two or more things in the larger set are mapped onto the same thing in the smaller set (that is, the mapping must be many-to-one); this is just the PigeonHole principle. For instance, if you're assigning all files 10,000 bytes or less a 4-byte checksum, there are 256-to-the-9,996 as many different files as there are different checksums. So the "average" checksum will correspond to a very large number of different files. Whenever two different files have the same signature, that signature will not be 100% effective in detecting changes (since it won't detect one of those two files changing into the other). But we've just seen that whenever the signature is smaller than the maximum filesize, at least two different files will have the same signature. So (assuming this rather rough argument holds!) no small signature can be 100% effective. Fortunately, signatures don't *have* to be 100% effective to be helpful against viruses. Viruses operate under certain constraints, and as long as we can make it sufficiently *hard* to "spoof" the signature, in a sufficiently large number of cases, a signature-based scheme will detect a useful fraction of nerfarious file-changes. Something like that. DC Watson Research Center * Disclaimer: I gave up the idea of majoring in Math sometime * around Complex Analysis. None of the above is an * Official Statement of anybody around here. -------------------- Date: Thu, 12 May 88 09:18: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 -------------------- Date: Thu, 12 May 88 12:02:24 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" I was shooting off my mouth back in January on an internal conference, about how it should be relatively easy to write a program that would detect most simple viruses, and someone said "OK, let's see it". Being lazy, I responded with pseudo-code. I attach (a slightly updated version of) that pseudo-code for the benefit of the community, for comments, etc. The idea is that the system keeps a big "database" file containing various facts about executable objects (their time/date/length, and any other signature-like things one wants to code), and periodically checks the executables against the database, to see what's changed. Of course a change doesn't mean an infection (could be a patch, an update, etc), but it can be a Clue... The following assumes a PC-DOS base, but could be trivially changed for CMS, etc. Build a list of files to be checked (all EXE files, COM files, BAT files, SYS files, or whatever, on whatever disks). Attempt to open "old database" file If open succeeds, read the records describing the files found last time into the OldRecords structure, and mark each item in that structure as "Not Seen Yet". If open fails, alert user that there is no old database, and ask for permission to continue. Continue only if permission is given. Set NoOldDatabase to True. Attempt to open "list of current files to be checked" file If open succeeds, continue. If open fails, abort with error message. For each file listed in "list of current files to be checked" file (begin Ask DOS about the file (int21H, subfn 4Eh). If the file is "special" (COMMAND.COM, IBMBIO.COM, IBMDOS.COM, whatever else seems reasonable), compute a CRC or other signature for the file (patient users with fast machines can treat every file as special, of course). Look the file up in OldRecords. If the file was not listed there, add it, marked as "Seen". Tell the user that it is a new file (unless NoOldDatabase is true). if the file -was- listed there, and the information is not the same as the information we just got from DOS, or if the file is special and the CRC or signature has changed, tell the user that the file has changed (and how), mark the item as "Seen", update the item to reflect the current information (from DOS and the new CRC calculation) and continue. If the file was listed there, and the information there -is- the same as the information we just got, simply mark that item as "Seen", and continue to the next file. end) For each item in the OldRecords structure If the item is marked "Seen", write it out to the "new database" file. If the item is marked "Not Seen Yet", tell the user it is Gone, and do not write it to the "new database" file. So at the end the user has a report of new files, old files that have vanished, and files that the program could tell had been changed. If there are unexpected new files, or unexpected changed files, the user can try to figure out why, which may lead to discovering a virus. This is designed with a hard-disk system in mind (for floppies, you'd have to store something like the diskette label as well, and prompt the user to swap diskettes alot), and could obviously be improved in various ways. It can also be used in various ways; if you're very worried, you can always boot the system from a write-protected "trusted" disk before using it, and keep the checking program and the "datbase" on a diskette that resides in a locked file cabinet except when checking is going on. There is also lots of room for invention in the "CRC or signature" part of the description. The development of hard-to-spoof signatures is an active research area. Now of course (more of courses) there are many possible viruses that this sort of scheme won't catch. But it will catch (in the sense that you'll be told about file modifications that you probably didn't expect) the spread of all the executable-file-based PC-DOS viruses that I know of. DC Watson Research Center -------------------- Date: Thu, 12 May 88 09:47:07 PDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: pozzo@CS.UCLA.EDU Subject: Signatures and Checksums Yes it is true that you can not find a checksum that is 100% unique as long as the size of the checksum is smaller than the executable. It is a many-to-one mapping. The trick is to find one that has a small possibility that two different executables will generate the same checksum. How "small" depends on you, your system, your needs, etc. The idea of signing executables for protection from modification is not a new one. Most recently, I invite you to read "An Approach to Containing Computer Viruses" published in a 1987 volume of the IFIPs Computers and Security Journal. -Maria -------------------- Date: Thu, 12 May 88 11:49:25 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jeff Balvanz Subject: Is there something funny in the posted CHECKUP? Just got the CHKUP14 UUE from the VIRUS-L LISTSERV, but I have a question: when I run the program with CHECKUP CHECKUP.EXE Flushot+ comes back with the message "Write access being attempted on C:\VACCINES\CHECKUP.EXE." Is CHECKUP supposed to try to write on the executable file that you're reading checksums on? Doesn't make sense to me. . .but I'm not a good programmer. Is there something legitimate or illegitimate in CHECKUP, or has my computer been sitting out in a cold draft too long (i.e., has caught something)? -------------------- Date: Thu, 12 May 88 13:48:02 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: Re: Is there something funny in the posted CHECKUP? In-Reply-To: Message of Thu, 12 May 88 11:49:25 CDT from >Just got the CHKUP14 UUE from the VIRUS-L LISTSERV, but I have a >question: >Flushot+ comes back with the message "Write access being attempted >on C:\VACCINES\CHECKUP.EXE." Is CHECKUP supposed to try to write on >the executable file that you're reading checksums on? When I try the same thing here, I don't get anything. I also tried it on a write-protected floppy and couldn't duplicate it. It appeared to work fine for me - anyone else have any problems with it? If so, I'll remove it from the archives until I can get a copy directly from the author. Ken - ---------------------------------------------------------------------- = Kenneth R. van Wyk = = = User Services Senior Consultant = Badgers! We don't need = = Lehigh University Computing Center = no stinkin badgers! = = Internet: = = = BITNET: = = - ---------------------------------------------------------------------- -------------------- Date: Thu, 12 May 88 14:12:00 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: GREENY Subject: re: the "database" scheme.... this idea is good, providing of course that a virus writer doesn't find out about your database and infect it as well.... I still believe that the best way to validate the length of the files as being unaltered is to have a good hard copy on a piece of paper locked in a safe that only you have the combination to.....(probably in a secret room in your basement...:-) ), then once a month (or however long it takes you to feel paranoid....) you can check the current length against the lengths on the hardcopy. This may or may not be feasible on systems with a huge amount of files (simtel20....), but it would seem to be such for a small-time user.... bye for now but not for long... Greeny Bitnet: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU -------------------- Date: Thu, 12 May 88 14:20:00 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: GREENY Subject: re:re: is there something funny in .... > ...did anyone else have any problems with it? If so, I'll get a copy of > it directly from the author... Seeing as how we have been discussing for some weeks now the topic of viruses and how easy it is to infect programs (especially those that cross thru net-land...) I would think that *NO* programs designed to detect viruses and/or eradicate them should be allowed into the Virus-l archives unless they /it have been obtained from the author of such a program directly... Even if it is a "trusted" friend that you are getting the program from, do you trust his/her/it's friends as well? Remember that trust is transitive and that if you trust me, you inherently have to trust everyone that I trust. Therefore, getting it directly from the author seems to be the best possible route of action. That way, if the program does go haywire, you know exactly who to blame... bye for now but not for long... Greeny Bitnet: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU Disclaimer: I'm just visiting this planet, and everything I do on my planet is absolutely legal, so it must be so here! -------------------- Date: Thu, 12 May 88 15:25:18 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess 862-2245" Subject: The "database" scheme There are lots more "provided"s than that! This is intended just to catch viruses of the kind that I know are actually out there. There are probably dozens of ways around it (some involving altering the database and some not), and it doesn't even try to catch boot-record-altering viruses like the "Brain" (although that would be a small mod...). I just thought it might give some budding anti-virus-programmers a concrete jumping off point. Maria commented that it wasn't a new idea: that's very true, and I don't claim to have invented anything new in the least. This kind of modification-detection scheme seems to be the first thing that good programmers think of when they first hear about viruses. More references to previous work along these lines (or any other lines!) would probably be valuable additions to this list. DC -------------------- Date: Thu, 12 May 88 09:50:00 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: LOWEY@SASK Subject: RE: checksum signatures > This raises an interesting question - is it truly possible to write > a checksum/crc/whatever algorithm that will be able to figure out > whether or not a file has been changed 100% of the time? Of course, one thing you can do is keep copies of sensitive files on other disks, like a floppy disk. You can then use the MS-DOS "comp" or "fc" command (or the unix DIFF or whatever) to see if the files are identical or not. As long as the copy of the file is in a "sterile" environment, where the virus can't get it, this approach should work better than any CRC checks. This doesn't help in my original problem of getting a program to check its self for an infection. Kevin Lowey -- University of Saskatchewan Computing Services -------------------- Date: Thu, 12 May 88 09:44:00 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: LOWEY@SASK Subject: RE: checksum signatures > Consider: files are large objects, thousands of bytes long. > Signatures are smaller than that; at most hundreds of bytes > long. When you map a large set into a smaller set, there > must be cases in which two or more things in the larger set > are mapped onto the same thing in the smaller set (that is, > the mapping must be many-to-one); this is just the PigeonHole > principle. Your argument is valid if you just want to corrupt the file. However, as you pointed out, a virus has to work under certain constraints. A virus has to modify a program so it does some damage AND perpetuates its self. Usually the program has to operate correctly for a while to give it time to infect other programs. If we have a CRC checker that not only calculates a CRC, but also saves the original file size, date, and time, then the virus maker would have a tough time. The virus would have to put the damaging code in a specific place in the file (like into the DIR command in COMMAND.COM), with the instructions in a specific order. The virus would have to add code to save the date and time on the file, then reset it back after infecting the file. The virus would have to add more code to make the CRC pass, after determining what CRC was used. Some viruses would need code to see if it is on a hard disk or a floppy disk. A count of how many "infections" would have to be kept to delay the action of the virus. The program would still have to operate "correctly" so the user doesn't know he is infected. All this would have to be done without changing the size or date of the file. So with an appropriate virus checker, it isn't as simple as changing a few bytes to make the CRC work out, assuming you know which CRC was used in the first place. Kevin Lowey -- University of Saskatchewan Computing Services