VIRUS-L Digest Friday, 6 Apr 1990 Volume 3 : Issue 71 Today's Topics: HACKER.THESIS, HACKTHES.ZIP (text) Brunnstein's lists Re: Virus in Text Files Validating Virus Software ftp of disinfectant problem (Mac) Universal Virus Detector Re: Virus cure (PC) The ZUC virus and SAM 2.0 (Mac) 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: Thu, 05 Apr 90 09:14:51 -0500 From: James Ford Subject: HACKER.THESIS, HACKTHES.ZIP (text) A bad copy of these files were loaded onto MIBSRV....approximately half the thesis was missing. This has been corrected now. HACKER.THESIS is 152596 bytes (instead of 62504 bytes) HACKTHES.ZIP is 47137 bytes (instead of 19483 bytes) Thanks to Jim Weinhold for pointing this out.....sorry for any inconvience. - ---------- James Ford - JFORD1@UA1VM.BITNET, JFORD@MIBSRV.MIB.ENG.UA.EDU Acknowledge-To: ------------------------------ Date: 05 Apr 90 16:35:14 +0000 From: dweissman@amarna.gsfc.nasa.gov (Dave Weissman) Subject: Brunnstein's lists Does K. Brunnstein put out a list of MAC viruses similar to the DOS virus list (i.e. *VIR.A89). If so, where would I find it (preferably by anonymous FTP). Dave Weissman GSFCMail/X.400 Systems Goddard Space Flight Center NASA ------------------------------ Date: 05 Apr 90 18:29:00 +0000 From: len@csd4.csd.uwm.edu (Leonard P Levine) Subject: Re: Virus in Text Files RKARRAS@PENNSAS.UPENN.EDU (Dr. Ruth Mazo Karras) writes: > I have heard of a concern that text files (consisting of plain ASCII text) > may contain viruses. I had thought that only executable files such as > *.com or *.exe files were subject to viruses. Which view is right? Is there > risk in moving a text file from a mainframe to a PC? There is NO evidence that anything other than an .exe, .com, .ovl, or .sys file can infect. There has been talk about .pgm files (for dBase) and lotus spreadsheets being carriers but I have no evidence of any known. The following file: XPHPD[0GG0G,0G51G31GB'(G+(G:u'0g?(G>(GE1G@arwIV_F*=US@<1|_,5wXNg-7muTu(4 1m2?352t0osr2e3K1q2s0s3e0W1_F0:sss1@2G0t1k0s3p0@3T1m3>52f3>1k0t3<2C0@3T2 K1g2?0@3T1Fm3U51g3<1q0s3:0@3T1g3r1l0ts1>0I@3T1m3i52e0O2;h0L1_Eg352s0m3S2 j0W1g3of0<1;2?0r1m0s3:1>0m@3T2e0R1FH2E1m0s3:1>0B3^0=2g3=1g3s0@3T2e0@3^1t 2e0<1>0m1m0s361>0e1l0s371g3r1:0P@3T1:0P2e1hDk0s3q0V1F2M1_3_c2o3Z1=0Y1=0c 2s0o2Ag3H0CSCS1:0=F[1:0=2s0]352k0t1]2s0U390^3<1KL2D1Dc0sf1]2L0UE^1T2HfTZ X3mS2@F5C6G3S2Y\_X3a25BB3W2HacTV^\aZ3S2gb3S2Y\_X3mSW28eebe3S2Whe\aZ3S2Y\ _X3S2<3b2B3W2Abg3S2XabhZ[3S2`X`bel3W4 is a text file that unpacks a kermit .boo format. This is an ASCII string that WHEN NAMED AS A .COM FILE executes. Gives one pause doesn't it? + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@cs.uwm.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. FAX (414) 229-6958 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ------------------------------ Date: Wed, 04 Apr 90 23:14:00 -0400 From: David Ward -- Computer Support/Special Needs Subject: Validating Virus Software Periodically we hear concerns about the validity of SCANVxx and other antiviral programs. I think these concerns are valid since a virmentor creating a virus would likely take great joy in attaching the virus software to a product designed to fight viruses. I do not have complete confidence in our local sources of SCANVxx -- the distribution path of the software I use is as follows: - a local bulletin board downloads the SCANVxx software directly from homebase - our college microlab person downloads to his PC - he repacks it - he uploads to our VAX - I download it from VAX to my PC - I copy to disks to distribute it in my department. There is potential for infection along the way. It would seem logical that the most reliable source for SCANVxx is the homebase bulletin board operated by McAfee himself. However, it is a long distance call and when a new version is released, the line is quite busy. The VALIDATE program is designed to allow us to determine whether or not these programs are intact. But what if someone modified SCANVxx, revalidated the program, updated the check sums in the docs, and then repacked the programs? We would not be able to detect the changes since the check sums would appear to be correct. Clearly, the validation check sums must come from a source that is different from the source of the program. That is, if we get SCANVxx from a local bulletin board, then to validate it, we must compare the validation strings we generate to those published by McAfee on his bulletin board. A simple solution to this problem is that when new versions of scan are announced on this digest, the announcement should include the validation strings given by McAfee. Then we can download from any local source and compare the strings published in Virus-L to those we generate with the validate program. - ------------------------------------------------------------------- David Ward Phone: 416-491-5050 Special Needs Dept Seneca College Netnorth/Bitnet: WARD@SENECA Toronto - ------------------------------------------------------------------- ------------------------------ Date: Thu, 05 Apr 90 09:31:06 -1100 From: Michael Perrone Subject: ftp of disinfectant problem (Mac) I am having trouble getting disinfectant to my Mac via ftp/kermit-white knight. I can get the .sit file over to my IBM 4381 account, and to a unix account okay but I can't get white knight to kermit or zmodem the file properly. When I kermit from the ibm, White Knight recognizes it as Macbinary but the file type and creator don't come up as SIT!, and then it bombs id 4 (divide by 0 error!) and I have to reboot. WK kermit has worked for me before with macbinary to and from the IBM with .sit files. On my unix accounts, I can't get WK to even recognize as Macbinary. Yes, when I ftp I am first setting it to binary. Does anyone else have similar problems or a solution? Michael Perrone, Portland State University (Oregon) Macintosh support A2MP@PSUORVM.BITNET ------------------------------ Date: Thu, 05 Apr 90 14:17:00 -0700 From: jmolini@nasamail.nasa.gov (JAMES E. MOLINI) Subject: Universal Virus Detector 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. 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. A Universal Virus Detection Model **** EXTENDED ABSTRACT **** by Chris Ruhl and James Molini Computer Sciences Corp. Email: jmolini@nasamail.arc.nasa.gov [Ed. Thanks for the paper! Those interested in reading the remainder of this paper can get it by anonymous FTP from cert.sei.cmu.edu in file: pub/virus-l/docs/universal.detector.molini In addition, I'm sending a copy of the paper to the U.K. comp.virus archive site.] This paper attempts to define an abstract model which will support the construction of a Universal Virus Detector. DEFINITIONS VIRUS - A self-replicating program that must attach itself in some way to an existing executable on the target computer system in order to propagate. In doing so, no overt user action is required to further the replication process. TROJAN HORSE - A non-replicating malicious program that misleads the user in order to cause him/her to execute it's malicious code. This type of program does not necessarily modify any existing executable files on the system. MASKING - The act of preventing discovery by intervening at some point in the scanning process. Typically this effects an indication of a clean system, when, in fact, the environment under review has been modified. A Virus Propagation Model In order to develop this model the following assumptions are made: a.) The user will begin the detection process (we have proposed a CRC type routine) prior to infection. By doing so, the user has provided an uninfected baseline from which to judge future states. b.) The user will avoid the introduction of self modifying code into the system. By doing so, he/she ensures that the target system maintains a given state of integrity. Given the assumptions above, we may now define the circumstances necessary to support a virus infection. Without the adherence to the following rules, it is impossible to define a circumstance in which a virus can propagate. Rule #1: A Virus infection, or propagation occurs when an executable file is altered. Rule #2: Assuming that the detection mechanism is sufficiently robust, the only possible way to avoid detection is to mask the infection prior to having the detection results presented to the user. UVD CONSTRUCTION. >From the above discussion, we can begin defining a UVD with some degree of assurance that it will do the job. If a virus must modify the original state of the system in order to be successful, we can define a process that can detect that modification. (Insert your favorite Checksum/CRC/Cryptographic routine here.) Any program which circumvents the modification of existing code is not a virus. Then, to defeat the detection process, the virus must mask the infection in some way so that this verifiable change detection mechanism cannot present accurate results to the user. Any program which circumvents the detection mechanism must do so by modifying the data delivery process into, or out of the detector. Once again we are talking about code modification. 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] b. Validate the integrity of the read process by checking the interrupt table and low memory for changes. c. Validate the correctness of the output process by checking screen write interrupt vectors and device paths. It could be done also by generating a direct write procedure to hardware addresses during the installation process. d. Validate the Boot sector of the disk and hidden R/O system files via direct sector reads. Knowing that the read process is unchanged, we can also be sure that the data coming into the CRC routine is correct. e. Once both ends of the pipe and the pipe itself are validated, we can begin checking all executables on the system for modifications. 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. By doing this we have checked the entire data path and found it to be correct. We have also checked the correctness of the change detection procedure. This assumes that no other process has taken over the CPU during the scan, but this is no problem as long as we mask all external interrupts. Then only an actual hardware interrupt can cause the program to pause. User involvement in the procedure can be coached by the detector. [Not included in abstract.] ------------------------------ Date: 5 Apr 90 23:15:40 GMT From: Subject: Re: Virus cure (PC) nguyen@presto.ig.com writes: > One IBM PC at my office gets infected by virus. I used Virscan(tm) > from IBM and it detected some executable files *.EXE and *.COM are > infected by 1813 or Jerusalem virus. Anybody knows any kind of > software which can fix the don't have to reformat hard drive. Any > public domain or commercial software can do the job? Any information > is highly appreciated. I have run into Jerusalem virus myself.And as far as I can tell, there is one program that I think will help you out. The program is called m-jruslm. I tried it quite a few times and it seemed to work fine except on a few occasion. There is another program called "clean", which doesn't seem to disinfect the Jerusalem virus when I tried them. I think you can find them in SIMTEL, and best of all they are shareware. You can try for a couple of days before purchasing them. Hope this helps. Roslan MdZaki. ------------------------------ Date: Thu, 05 Apr 90 20:09:47 -0300 From: Peter J Gergely Subject: The ZUC virus and SAM 2.0 (Mac) >From comp.sys.mac: Date: 3 Apr 90 14:37:37-GMT From: Joel B Levin Subject: The ZUC virus and SAM 2.0 Sender: news@bbn.COM Reply-To: levin@BBN.COM (Joel B Levin) Organization: BBN Communications Corporation SAM Intercept can also prevent infection by the ZUC virus (at least version 2.0 with "standard" or higher protection turned on). The information below was provided by the author of SAM to the Virus-L list and comp.virus. - - - - - - For SAM 2.0 users: A new virus has recently been discovered (now named ZUC). If you happen to run across the ZUC with SAM 2.0, you can expect to see the following. 1) If you are running in standard, advanced, or custom levels, SAM will alert you to ZUC's attempt to change CODE resources within applications when ZUC is trying to spread itself. Denying this attempt with SAM keeps the infection from spreading. 2) If you have previously inoculated your applications with Virus Clinic 2.0, then if ZUC has infected any files since inoculation (if, for instance, you had SAM Intercept turned off or set to basic level), then SAM will alert you to an inoculation discrepancy when you try to launch the infected file. 3) SAM Virus Clinic will also alert you to a checksum change to any infected files if you have turned on checksumming in the Virus Clinic scans. 4) You can configure SAM (both Virus Clinic and Intercept) to find ZUC during scans and application launches with the new virus definition feature. Using the Add Virus Definition option in Virus Clinic, create a new one with these fields: Virus Name: ZUC Resource Type: CODE Resource ID: 1 Resource Size: Any Search String: 4E56FF74A03641FA04D25290 (hexadecimal) String Offset: Any You can then add this definition to both Virus Clinic and SAM Intercept. One other note: SAM 2.0 also repairs files infected with multiple viruses. Paul Cozza SAM Author - - - - - - - Nets: levin@bbn.com | "There were sweetheart roses on Yancey Wilmerding's or {...}!bbn!levin | bureau that morning. Wide-eyed and distraught, she POTS: (617)873-3463 | stood with all her faculties rooted to the floor." ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253