VIRUS-L Digest Friday, 17 Nov 1989 Volume 2 : Issue 242 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., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's LEHIIBM1.BITNET for BITNET folks). Information on accessing anti-virus, document, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@SEI.CMU.EDU. - Ken van Wyk Today's Topics: BITFTP confusion of yesterday Virus or just hardware/software problem? (Mac) Write protect tabs (was Re: CRC's) Help needed on Mac virus attack (Mac) possible bug in scanres46 (PC) STONED Virus (PC) Re: Signature Programs --------------------------------------------------------------------------- Date: Fri, 17 Nov 89 07:27:08 -0500 From: Kenneth R. van Wyk Subject: BITFTP confusion of yesterday Hi folks, Yes, I accidentally replied to a message yesterday, directly to the entire list. Again, I apologize for that. I did learn that one of the quickest ways to get help on something is to make a glaring mistake like this. :-) Thanks to all those who sent in the HELP information for BITFTP. Allow me to explain... FTP (File Transfer Protocol) is an Internet facility which, as the name implies, allows users to transfer files between Internet hosts. This facility is used frequently for making archives, programs, etc., available to the general public - the VIRUS-L/comp.virus archives are available via anonymous FTP. Traditionally, FTP was only available to Internet subscribers since it relies directly on the TCP/IP network protocol used on the Internet. Enter BITFTP... BITFTP is an email facility provided at PUCC (Princeton University Computing Center) - perhaps other IBM VM/CMS sites as well? - which allows users to invoke Internet FTP sessions via email requests to BITFTP@PUCC.BITNET. This gives BITNET and other email networks (Usenet, etc.) access to much of the FTP facilities of the Internet. I say "much of" because the facility, in all its usefulness, cannot currently transfer binary files, though real FTP can. Rather than include the lengthy HELP information for BITFTP here, I refer readers who would like this information to obtain it on-line by sending email to BITFTP@PUCC.BITNET - in the email message, just enter a line containing "HELP". You will then receive the actual HELP file provided by the service. I hope this clears up the confusion. BITFTP can provide a very useful service to non-Internet sites. As a disclaimer - BITFTP is not provided by VIRUS-L/comp.virus, CERT, or any group that I'm associated with; I know little more about it than what I've presented here, and I'm merely pointing its availability out to users who might find it useful. Regards, Ken ------------------------------ Date: 16 Nov 89 13:50:17 +0000 From: mmccann@hubcap.clemson.edu (Mike McCann) Subject: Virus or just hardware/software problem? (Mac) I encountered a problem with a Mac Plus (Everex 20Mb HD, 6.0.3, 2.5Mb RAM, QuickMail, Netway1000, SAM). The system and finder were not visible but the machine was still bootable (some software failed to run or crashed). When I used ResEdit from a locked disk I found two DeskTops but no system or finder anywhere. The person in charge of Macintoshs for that area said he reinstalled all the software but the problem reoccurs. I immediately thought of a virus and scanned all the disks and the Mac Plus with Disinfectant1.2 but found nothing (I did find two file with damaged resource forks on the Mac Plus but these were documents). If anyone can offer any suggestions, I would greatly appreciate it. (PS- I personally used Everex's HD formatter to erase the drive and then installed new, known-clean system software on the Mac Plus with his software (he didn't have known-clean copies of the software) and I'm now waiting to see if strange things happen again). Thanks - -- Mike McCann (803) 656-3714 Internet = mmccann@hubcap.clemson.edu Poole Computer Center (Box P-21) UUCP = gatech!hubcap!mmccann Clemson University Bitnet = mmccann@clemson.bitnet Clemson, S.C. 29634-2803 DISCLAIMER = I speak only for myself. ------------------------------ Date: 15 Nov 89 01:14:28 +0000 From: munnari!stcns3.stc.oz.AU!dave@uunet.UU.NET (Dave Horsfall) Subject: Write protect tabs (was Re: CRC's) In article <0007.8911071214.AA17820@ge.sei.cmu.edu>, kichler@harris.cis.ksu.edu (Charles Kichler) writes: | The advantage is hardware is difficult to modify via software. As of yet, | I haven't seen a program that can beat a write protect tab. I have heard a story, perhaps apocryphal, of a disk controller whose "write protect" mechanism merely set a bit in a register, which the software was supposed to check. Do you _know_ your write-protect tab really works? [Ed. This question was discussed a few times on VIRUS-L/comp.virus; the consensus was (after reviewing schematic diagrams) that the write protect mechanism on PCs (and clones thereof) and Macs is implemented in hardware and is thus not circumventable without hardware modifications. Unless someone can produce a definitive, reproducable piece of code that can prove otherwise, lets all please consider this to be the case.] Dave Horsfall (VK2KFU), Alcatel STC Australia, dave@stcns3.stc.oz.AU dave%stcns3.stc.oz.AU@uunet.UU.NET, ...munnari!stcns3.stc.oz.AU!dave ------------------------------ Date: Thu, 16 Nov 89 09:19:27 -0500 From: Tom Southall Subject: Help needed on Mac virus attack (Mac) Hello, We are being hit by a Mac virus that is not recognized by our vaccine programs (Disinfectant, etc.). The symptoms we see, in order of severity (age?) of the virus are: 1. System file date changes to current date 2. All printing services are degraded 3. File can not be opened - but is visible 4. Open files can not be saved 5. Machine freezes in the middle of doing work 6. Names of infected files are changed to *'s The virus appears to be passed through data files and/or through our Appletalk network. We have reformatted all disks and fixed the server, but the virus re-appears very quickly. Any ideas as to what this might be, and how to get rid of it would be greatly appreciated. Thank you, Tom Southall Manager, User Services The American University Washington, DC 20016 (202) 885-2277 ------------------------------ Date: Thu, 16 Nov 89 15:55:20 -0600 From: mitch cottrell Subject: possible bug in scanres46 (PC) To whom it may concern... I do not wish to spread rumors....but?? Concerning the McAffee scanres and SCAN program, I am experiencing unusual hardware problems at undetermined time lengths after execution of these two programs (version 38 and 46) This problem affects floppy disk drives only on base PC and XT systems. The faults appear to affect the disk drive motor and do not allow it to run. This problem does not appear in systems unless the programs a re executed. This problem is also cleared by a reboot or power cycle. If anyone else has experienced similar problems please let me know... PS. I would hate to discover a new virus...... [Ed. Has anyone else had similar problems. I'd suggest being *real* hesitant to draw a conclusion on this without more similar occurances.] Reply C2852@UMRVMB.UMR.EDU Acknowledge-To: ------------------------------ Date: Thu, 16 Nov 89 17:31:32 -0500 From: Mark Powers Subject: STONED Virus (PC) Two of our PC labs have been infected with the STONED virus. Is there anything out there that will fix these machines or are we looking at rebuilding the infected disks? Thanks for any assistance Mark Powers Academic Computer Service Miami University 513-529-2020 ------------------------------ Date: Fri, 17 Nov 89 00:17:27 -0500 From: Steve Woronick Subject: Re: Signature Programs Bob Bosen <71435.1777@CompuServe.COM> brings up some interesting points, asking why programmers writing authentification programs are utilizing CRC and checksum algorithms rather than more sophisticated algorithms like ANSI X9.9, ISO 8731-2, or DES. I think it depends on what you are trying to do. If your plan is to encrypt your program and rely on difficulties in decryption for protection against infection, then it probably makes sense to use something very sophisticated, because you want to make certain that no one but yourself can do the decryption. If you are leaving the encrypted form on your disk (where it might be compared with the unencrypted form which is surely to appear either on your disk or in memory at some future date if you use it), you don't want to be using something so simple that it might give your algorithm away. On the other hand, if you are not encrypting your program but are simply trying to generate a number (or maybe several numbers) for authentification purposes, I don't see that it is necessary to use anything more sophisticated than a polynomial. If the virus doesn't know your polynomial, then it's chances of guessing a sequence of characters with which to "pad" your program file in order to generate the same CRC value as the original unaltered program is quite small. Of course, everyone ought to be using a slightly different algorithm (i.e. different polynomials) and ought to be hiding the authentification algorithm. Correct me if I'm wrong: If the algorithm is sophisticated enough that it is very hard for anyone to guess CRC values, then there probably is no need to hide the values it calculates for each of your program files; in principle, one might be able to deduce the algorithm by comparing program files with the CRC values generated by the algorithm, but this will work only if there is enough information available for analysis (which will not be the case for sufficiently high order polynomials). The information in a CRC is small compared to the information in an encrypted file, so CRC programs need not be terribly sophisticated to foil discovery. It has been pointed out that doing a cold boot from a clean floppy assures you that your system is running clean (i.e. there are no viruses in memory --- there may be some on your hard disk, but these are dormant until you run an infected program). If you then run your authentification program from the clean floppy disk on your clean system to check your hard disk (or other), you can rest fully assured that no virus etc. has had the opportunity to intercept your checking program and fool you into thinking that an infected program is uninfected (unless you were dumb and previously exposed the clean disk, though write- protected, to the inquiring eyes of a virus). And since there are no viruses in memory, none can steal your checking algorithm or any of the CRC values (which you probably are keeping on the clean disk; for that matter you can keep your own personal polynomial coefficients on the disk also). You probably will wisely want to keep your clean disk write-locked to prevent accidents, but infection is not the only threat (so write protection does not fully protect one from accidents). If one runs the authentification program (or even accesses the disk it's on), without first doing the cold clean boot, then one risks having the authentification algorithm stolen by a virus. And as has been stated before, one cannot be certain of the authentification results if the cold boot from the clean disk was not done. Finally, you obviously have to write to the clean disk once in a while to update the CRC-values list for new programs/ whatever, but this is no problem because you're not going access it without first doing the cold clean boot. One of course also assumes that your clean disk was really clean to start with. Any comments? Here's a question: What's a good reference for finding out about ANSI X9.9 and ISO 8731-2? I can give you one for DES (Data Encryption Standard): Numerical Recipes, The Art of Scientific Computing, by W.H. Press, B.P. Flannery, S.A. Teukolsky, and W.T. Vetterling, published by Cambridge University Press, (c)1986, p. 214-220. Two and one half pages of highly-inefficiently coded FORTRAN is given which implements the DES algorithm (except that the standard itself explicitly states that any implementation in software is not secure and therefore not DES). - ----------------------------------------------------------------------- Steven C. Woronick | Disclaimer: These are my own opinions. Physics Dept. | Always check it out for yourself... SUNY at Stony Brook | Stony Brook, NY 11794 | Acknowledge-To: ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253