VIRUS-L Digest Tuesday, 10 Apr 1990 Volume 3 : Issue 73 Today's Topics: Gatekeeper 1.1.1 & Scores (Mac) Disinfectant 1.7 and GateKeeper (Mac) Re: Universal Virus Detector Validate program corrupted?? (PC) Low Level Format (PC) Re: Validating Virus Software Re: FTP from SIMTEL20 to VM/CMS (Internet) What do I buy? (PC) re: Universal Virus Detector FTP and .hqx (Mac) Re: Virus in Text Files (Mac) Oops- wrong thing sent Virus info request (PC) Archive service at Heriot-Watt Re: Virus in Text Files 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. Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to LEHIIBM1.BITNET for BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU. Ken van Wyk --------------------------------------------------------------------------- Date: Mon, 09 Apr 90 10:30:00 -0400 From: Thank you matchline Subject: Gatekeeper 1.1.1 & Scores (Mac) The following is an excerpt of a letter sent to John Norstadt, Author of disinfectant and may be of interest to anyone who uses gatekeeper ____________________________________________________________________ SMU, 9-APR-1990 John, I'm sending this to you because I think it may be of interest. I just downloaded gatekeeper 1.1.1 off the rice archives and was in the process of evaluating its performance against scores, nVir and WDEF. Immediately I found a problem. When starting up an application already infected with scores (on a floppy) gatekeeper announced 3 times that the virus was attempting to infect the application and its attempt was 'vetoed' Great so far. However, after that initial warnining I waited about 10 minutes and then checked on the process of the attempted infection. By that time, pyro had come on and nothing was any different BUT when I checked the system folder the notepad file and scrapbook files had the 'dogeared page' icon. I ran disinfectant 1.6 and guess what the system was infected as well as the desktop, clipboard and scrapbook. It seems that gatekeeper only partly protects from scores attacks. And worse yet disinfectant had to be run twice to completely remove all bits and pieces of scores. - Zav ------------------------------ Date: Mon, 09 Apr 90 12:24:33 -0400 From: jln@acns.nwu.edu Subject: Disinfectant 1.7 and GateKeeper (Mac) Disinfectant 1.7 requires GateKeeper privileges even when just scanning. Earlier versions only required privileges when repairing. I wasn't aware of this until after I had released 1.7, or I would have mentioned it in the document. The solution to this problem is to simply grant Disinfectant all six GateKeeper privileges. John Norstad Academic Computing and Network Services Northwestern University ------------------------------ Date: 09 Apr 90 13:45:20 +0000 From: rwallace@vax1.tcd.ie Subject: Re: Universal Virus Detector jmolini@nasamail.nasa.gov (JAMES E. MOLINI) writes: > I am working with a colleague on defining a robust virus detection > utility. The following is an extended abstract of a paper which > discusses an approach we are investigating. The work was undertaken as > part of a research project sponsored by the National Aeronautics & > Space Administration at the Johnson Space Center. Please look it over > and tell us (or Virus-L) what you think. This is I think the fourth serious attempt on this newsgroup to propose a universal virus detector. Unfortunately like all the rest it won't work. (theoretical UVD discussion) > So to put our theoretical UVD into practice, on, for example, an IBM > PC, we would do the following: > > a. Begin by validating the integrity of the detector code. This has > been discussed above. [not included in abstract] How? I haven't copied your entire posting in this followup because it was too long but I couldn't see any proposed method for validating the detector code. And an obvious way to defeat your mechanism is to overwrite the detector program with code that always says "OK". ... > f. In order to prevent a virus from attacking the CRC table, we will > add a set of dynamic "State Vectors" for the machine, which define > the run time environment for the detector. This creates an > unforgeable "fingerprint" of the detector as it exists in memory > and can be prepended to each file prior to computing the CRC. What do you mean? Another obvious way to defeat the detector is to recalculate CRCs for infected programs and put the new CRC value into the table. I don't see any way to prevent this other than storing the table offline (which would create what most users would consider unacceptable hassle). Also your detector would detect most resident programs as well as multiuser systems and upgraded versions of the operating system as viruses because it checks the system call vectors. "To summarize the summary of the summary: people are a problem" Russell Wallace, Trinity College, Dublin rwallace@vax1.tcd.ie ------------------------------ Date: Mon, 09 Apr 90 15:13:00 -1100 From: Subject: Validate program corrupted?? (PC) I just received this message. It was posted on the RED-UG list as you can see. If you have any questions about the message please send them to the author of the original message. Nino ******************************************************************************* *JANET: n.margetic@uk.ac.ucl.euclid | Nino Margetic * *EARN/BITNET: n.margetic%euclid.ucl.ac.uk@UKACRL | University College * *INTERNET: n.margetic%euclid.ucl.ac.uk@cunyvm.cuny.edu| Dept. of Med. Physics * *UUCP: n.margetic%euclid.ucl.ac.uk@ukc.uucp | 11-20 Capper Street * *Phone: [+44 - 1 | 01 ] 380-9846 | London WC1E 6AJ * *FAX: [+44 - 1 | 01 ] 380-9577 | Great Britain * ******************************************************************************* - --------------- Original message follows ------------------------------- Via: UK.AC.RUTHERFORD.MAIL ; Mon, 9 Apr 90 14:51 GMT (V41 at UK.AC.UCL.EUCLID) Received:from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 7403; Mon, 09 Apr 90 14:50:10 BS Received:by UKACRL (Mailer X1.25) id 7680; Mon, 09 Apr 90 14:49:57 BST Date: Mon, 9 Apr 90 15:17 Reply-To:Gunnar Radons Sender: Red File Server Users Group From: Gunnar Radons Subject: virus alert To: BSMTP Hello netlanders, Another topic on viruses. The german computer-journal "DOS-Shareware" reported the following in it's No. 3 issue : There is an infected version of SCANV58.zip. Actually the VALIIDATE program seems to be changed. The original VALIDATE should be a .COM file, while the corrupt is a .EXE with 46167 bytes (instead of 6485) The original SCAN.EXE should have the values: Size: 42977 bytes, Date: 2-15-1990, File Authentication: Check Method 1: 2F16, Method 2: 1C57. This message is to be found on page 77 of the above journal. Also there are to files "NORTSTOP.ZIP" and "NORTSHOT.ZIP" which claim to be written by peter norton. Both contain a trojan which erases some files between christmas and new year. To identify those look in the .ZIP file for NORTSHOT.EXE and in the .EXE for the string "Norton Public". If you find those trojan please inform Tony McNamara from Norton computing (phone: US: 213/319-2076). The length of NORTSHOT is 38907 bytes and it's date is 02.01.89 (European format I suppose). This message is from page s6 of the above journal. This message will be sent to RED-UG and games-l (Apr. 8. 1990). Bye, Gunnar :----------------------------------------------------------------------: : :: : : Gunnar Radons :: Gunnar Radons : : Astronomisches Recheninstitut Heidelberg :: s46@dhdurz1 : : Moenchhofstr. 12-14 :: : : D-6900 Heidelberg :: (+49) 6221 405147 : : :: : :------------------------------------------::--------------------------: : Do you have the solution or are you the problem? : :----------------------------------------------------------------------: ------------------------------ Date: Mon, 09 Apr 90 15:59:02 -0000 From: LBA002@PRIME-A.TEES-POLY.AC.UK Subject: Low Level Format (PC) Many thanks to all those who sent me messages about low-level formatting. I now have a very clear idea of what it does and when to use it. Great help (as usual) from the -LIST Rgds, Iain Noble Teesside Polytechnic Library (UK) - ----------------------------------------------------------------------------- Iain Noble | LBA002@pa.tp.ac.uk | Post: Main Site Library, JANET: LBA002@uk.ac.tp.pa | Teesside Polytechnic, EARN/BITNET: LBA002%pa.tp.ac.uk@UKACRL | Middlesbrough, INTERNET: LBA002%pa.tp.ac.uk@cunyvm.cuny.edu | Cleveland, UK, TS1 3BA UUCP: LBA002%tp-pa.ac.uk@ukc.uucp | Phone: +44 642 218121 x 4371 - ----------------------------------------------------------------------------- ------------------------------ Date: Mon, 09 Apr 90 09:52:07 -1000 From: Jim Wright Subject: Re: Validating Virus Software I am willing to start a new mothly posting, which includes validation information for various popular anti-viral software packages. It need not be limited to ibmpc software. Each author is free to choose their own favorite validation method. Due to the nature of this, I will only accept information from the author, or from an authorized individual. (Authorized by sending me a post card.) I will not be able to keep up with this on my own. Out here, ftp and modems are a bit expensive. So I will rely on the authors to keep this up to date. Anyone interested, just drop me a line. Jim ------------------------------ Date: 09 Apr 90 19:20:10 +0000 From: werner@cs.utexas.edu (Werner Uhrig) Subject: Re: FTP from SIMTEL20 to VM/CMS (Internet) > In spite of several months of trying, I have still never successfully > obtained Disinfectant over the Internet. I believe the problem > has something to do with 7 databit vs. 8 databit binary as was already exlained by the moderator, there is indeed a differenc \ce when trying to retrieve a binary file from SIMTEL20. given that folks tend to have other (local) problems downloading binaries also, I make both binaries *AND* hexed (7-bit ASCII) version \cs of all the latest Macintosh anti-virals available for ANON-FTP on RASCAL.ICS.UTEXAS.EDU in directory "mac/virus-tools" ------------------------------ Date: Mon, 09 Apr 90 16:14:49 -0600 From: David Perales Subject: What do I buy? (PC) We are in the market for a good solid product for dealing with the virus situation in the IBM world. Hopefully something that will give us a good basis for cures, detection and possibly prevention - a good all-in-one package. Any suggestions? Thanx, David =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ David Perales, M.B.A., C.S.P. BitNet: DPERALES@TRINITY Micro Programmer Analyst telephony :(512)736-7401 Trinity University Computing Center 715 Stadium Drive, Box 50 San Antonio, Texas 78212 ------------------------------ Date: 09 Apr 90 00:00:00 -0500 From: "David.M..Chess" Subject: re: Universal Virus Detector jmolini@nasamail.nasa.gov (JAMES E. MOLINI) writes: > If you have questions, or see a flaw in the process, please let us > know. We are building a virus detector, which could be placed into the > public domain, that uses the techniques below to detect virus > infections. Our initial tests have shown encouraging results. ... These comments are based on the abstract only, not the paper (I'll eventually figure out how to FTP from here...). Modification detectors seem like a promising way of detecting at least some "new" (not seen before) viruses. The usual problems faced by a modification detector include: 1) A virus that knows about the detector (or about a class of them to which it belongs) might make changes that the detector won't detect. 2) A similarly detector-aware virus might update the detector's database to reflect the changes it makes when it infects. 3) A virus might (by luck or design) modify files in such a way that the user, presented with a list of files that have changed, will not notice anything wrong. 4) If the virus is active in the system when the detector runs, it could lie to the detector about the state of the system. A simple CRC approach runs into point (1): if lots of people start using your detector, and it always uses the same CRC polynomial, it's not all that hard for the virus to include code that patches infected objects so that the CRC is the same as it was before infection; a CRC isn't hard to invert. My favorite solution to this is to allow the user to specify his own polynomial (through the use of a "key phrase" or whatever); other solutions also exist (crypto-based MDC's and such). I gather from the abstract that the exact scheme used isn't fixed by the proposal; that's a reasonable approach. I gather that your point (f) > f. In order to prevent a virus from attacking the CRC table, we will > add a set of dynamic "State Vectors" for the machine, which define > the run time environment for the detector. This creates an > unforgeable "fingerprint" of the detector as it exists in memory > and can be prepended to each file prior to computing the CRC. is supposed to deal with my point (2), but I don't really understand it. If it's possible for the detector to update the database (and it must be, when the user gets new pieces of software and so on), then it's possible for a virus to as well, if the database is ever r/w to the system while the virus is active. (3) is one of the harder problems, I think; in some of the environments that are most important to protect (program development environments, for instance), many executables will be expected to change. Helping the user figure out which changes are OK and which are not is something that needs considerable thinking about, I think. Doing it perfectly is probably impossible (a good reason to avoid calling anything a "universal" virus detector...). Most of the abstract seems to be devoted to (4); making sure the virus isn't lurking anywhere when the detector runs. This is the general computer-security problem of getting the system into a trusted state; I tend to think that the problem needs to be solved at the system level rather than the application level (that is, there should be a good wired-in procedure for getting the system into a trusted state, rather than making every security application program do it itself). I doubt that any piece of software in DOS can really determine that the system is trustworthy; checking interrupt vectors doesn't tell you anything about the code they're pointing to, for instance. Painful as it is, the only method I know of that I trust is booting cold from a trusted floppydisk. Sounds like an interesting project, though, and I -will- try to get the full paper... DC ------------------------------ Date: Mon, 09 Apr 90 18:09:12 -0400 From: Joe McMahon Subject: FTP and .hqx (Mac) Since I run through vast amounts of sw on various servers about the net, and it always seems to work for me, try this: 1) ftp to whereever. 2) GET the file. No binary, no translate, zilch. 3) Transfer it up with Kermit. My feeling is that you may be trashing the file by insisting on transferring it as binary when it isn't. HQX format (as is used on the FTP servers I know of) is ASCII only, designed not to get trashed by character translations (e.g., EBCDIC to ASCII). Try not doing anything but the transfer, and I think you'll find this will work. --- Joe M. ------------------------------ Date: 10 Apr 90 00:19:57 +0000 From: woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) Subject: Re: Virus in Text Files (Mac) Macintosh datafiles, as I understand them, have 2 parts, a resource fork and a data fork. Anything in resource fork (so I've been told) can execute. Does this imply that one could bury a virus in the resource fork of a data file? I'm sure that this has been hashed over before. Cheers Woody ------------------------------ Date: 10 Apr 90 01:35:25 +0000 From: rwillis@hubcap.clemson.edu (Richard "Crash" Willis) Subject: Oops- wrong thing sent OOPS! Sorry guys, I sent the wrong file to a few people. Please ask again and I'll send the right information. BTW- the paper itself is not yet avalible (although that wil change in a few days) however, the infomation I do have avalable consist of a description of Internet, Virus De-infection, a theory on a new type of virus prevention and several other papers. Sorry again for the mess up. >* Sigh *< I'd better dig out my flame-proof underware for a few days - -Richard rwillis@hubcap.clemson.edu "No matter how subtle the wizard, a dagger between the shoulderblades seriously cramps his style" -Stephen Burst ------------------------------ Date: 10 Apr 90 01:58:32 +0000 From: malv_ss@uhura.cc.rochester.edu (Max Avarez) Subject: Virus info request (PC) Does anyone know of a virus that changes the size of PC files (usually .exe files) to 2048K? Also, what is the best virus detection program for the PC? Thanks, Max Alvarez (malv_ss@uhura.cc.rochester.edu) University of Rochester ------------------------------ Date: Tue, 10 Apr 90 10:29:19 -0000 From: David.J.Ferbrache Subject: Archive service at Heriot-Watt Just a quick note to apologise for disruption to the archive service at Heriot-Watt over the last month. The network core is due to change to a Sun system from an ageing Vax, in the meantime a re-organisation of archive service will take place. Normal service for immediate processing of email will be restored by end May. The archive contents will be extended to include the following: 1. General document archives (viruses) 2. PC, Mac, Amiga, Atari and Apple 2 anti-viral software 3. Archives of CERT, DDN SC and other advisories 4. Patches for BSD Unix releases 5. Risks digest backissues 6. Virus-l digest backissues In addition I am considering a protocol for access to more sensitive materials including backissues of the Zardoz security digest, Phage mailing list (historical material from the Internet worm period), and other lists. These will probably be available by restricted NIFTP. Again apologies for the disruption. - ----------------------------------------------------------------------------- \c- Dave Ferbrache Internet Dept of computer science Janet Heriot-Watt University UUCP ..!mcvax!hwcs!davidf 79 Grassmarket Telephone +44 31-225-6465 ext 553 Edinburgh, United Kingdom Facsimile +44 31-220-4277 EH1 2HJ BIX/CIX dferbrache - ----------------------------------------------------------------------------- \c- ------------------------------ Date: Tue, 10 Apr 90 09:27:29 -0400 From: flaps@dgp.toronto.edu (Alan J Rosenthal) Subject: Re: Virus in Text Files cdss!culliton@uunet.UU.NET (Tom Culliton) writes: >How many times has this question been answered? If you can't execute the file >or run it via an interpreter it can't carry a virus. A counterexample to this assertion is the wdef viruses on the macs. They are carried in the Desktop file which is a data file describing the layout of the windows. >If it's source code for a compiler or interpreter the danger is present that >it contains malicious instructions but visual inspection can quickly settle >that. You're saying that you can quickly read the source code to an entire compiler and understand everything it does? I find this extremely hard to believe. ajr ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253