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 AA19534; Wed, 6 Jun 90 11:33:46 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA03731; Wed, 6 Jun 90 11:33:42 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA17755; Wed, 6 Jun 90 11:33:19 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa20228; 6 Jun 90 15:24 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Tue, 05 Jun 90 14:07:48 BST Message-Id: <$TGVGDBVHCNZW at UMPA> Subject: Virus-L vol 0 issue #0624 Virus-L Digest Fri, 24 Jun 88, Volume 0 : Issue #0624 Today's Topics VM/CMS viruses OS in ROM Viruses and COMMAND.COM VM/CMS viruses ** no subject, date = Fri, 24 Jun 88 08:18:13 EDT ROM BIOS and CHK4BOMB Re: VM/SP Release 5 doesn't RECEIVE hidden files; Re: constructive viruses Re: Don't trust CRC as a virus-indication ------------------------------ Date: Fri, 24 Jun 88 10:07:00 URZ Reply-To: Virus Discussion List Sender: Virus Discussion List From: BG0@DHDURZ2 Subject: VM/CMS viruses Hi folks, some of you may think that writing viruses for a IBM mainframe running VM/CMS requires access to the mainframe for testing the code. Failed!! A potential virus-writer has (at least) two possibilities to develop VM viruses at his PC at home: . Buy a XT/AT/370 computer (price approx. $5000). Throw away the VM/PC operating system IBM offers for this system. Get (means *steel*) a copy of VM/SP 4.0 (or even 5.0) and put it onto your own system (This really works: I *konw* a person who did exactly this!!). Copy the ASMH and all MACLIBs from the mainframe and develop you own VM virus. . Get the (ShareWare) package called PC370 (from PC-SIG disk#402) written by Don Higgins (a former IBM'er? He wrote a lot of macros for the IBM/370 system as I found out when I looked at the MACLIBs available at our mainframe). Expand the program to handle macro-expansion and adapt all macros you need for the virus to run under MS-DOS. Develop your virus. Of course the first option is the better one - all you need is to buy a XT/AT/370 and to steel a VM/CMS to develop a virus that can cause *MUCH MORE* harm than PC viruses. How can we face this problem ???? All the best, Bernd. -------------------- Date: Fri, 24 Jun 88 08:15:59 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: OS in ROM The idea of putting the operating system (and perhaps other important executables) in ROM is interesting, although not a new one. I saw a product a while back for IBM PC (or compats) that would allow the user to do exactly that - burn a ROM with whatever file(s) (s)he wishes, and use them as if they were coming from a floppy disk. I can't remember the name of the product, but I recall that it came in a couple of different capacity configurations of approx. 360k up to about 1/2 Meg. This idea would appear to be functionally equivalent to what Disk Defender does - recall that Disk Defender is a commercial product that allows the user to physically lock part or all of his/her hard disk from all write attempts. In all of these instances, there are a couple things that we must remember. First, a virus need not limit itself to infecting the operating system; it could easily infect any executable file. Second, if there is a way for the user to update the software in the write-protected storage, then there *is* a way for a virus to get there as well. With Disk Defender, for example, there is a switch which toggles the write protection. During the time that you're updating any software in the read-only portion of the disk, a virus could conceivably be copied as well. In the case of Tandy's ROM DOS (if this is the case), only Tandy, or a person with access to a ROM burner, would be able to alter the contents of the ROM. This could be seen as good and bad, for obvious reasons. I'd see a product like a ROM disk as being useful primarily for its speed and convenience because, unlike a RAM disk, the software is always there. It ought not be viewed as a sole virus protection scheme due to the fact that other files may be infected. It probably does, however, reduce the chance of becoming infected somewhat. The Brain virus would probably have a real tough time getting onto the ROM... :-) Ken Kenneth R. van Wyk Calvin: When I take a bath, I always User Services Senior Consultant put my rubber ducky in the Lehigh University Computing Center water first. Internet: Hobbes: For companionship? BITNET: Calvin: No, to test for sharks! -------------------- Date: Fri, 24 Jun 88 10:28:36 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: Viruses and COMMAND.COM Various contributors have talked about having the operating system in ROM, and how this might help deter viruses. Remember, though, that most viruses don't live in the operating system at all! The Lehigh virus (that started all this discussion) does, but none of the other PC-DOS/MS-DOS viruses that I know of do. They live either in the boot records of floppies, or in normal executable files (COM and EXE). DC -------------------- Date: Fri, 24 Jun 88 10:23:01 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "David M. Chess" Subject: VM/CMS viruses Bernd Fix asks > How can we face this problem ???? I think the answer is "about the same way we're facing the problem for microcomputers". That is, identify the executable objects in the VM/CMS environment, and write programs that do the best we can to detect unauthorized changes in them. Since the typical VM/CMS machine is a bit faster than the typical micro, a good CRC-check (preferably with a nice long user-chosen polynomial) of every vulnerable executable becomes a more attractive option. The outline of a virus-detector that I suggested above could easily be modified for VM/CMS. The main difficulty that I see is that there's no counterpart to keeping the checker, and the database, in a locked file cabinet between runs. Perhaps keep them DES encrypted instead? (And of course re-IPL and "ACC ( NOPROF" before using the detector.) Viruses on mainframes are not very different in kind from viruses on micros (somewhat oversimplified statement offered as a basis for discussion!). DC -------------------- Date: Fri, 24 Jun 88 08:18:13 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Stephen SSM Clark In response to Mr. Goldman's inquiry on definition of worm.... The National Computer Security Center, in its poster 86-3, defines worm as: "Worm" or "Virus" - A self propogating computer program which, in addition to performing a desired function, causes a malicious side effect. -------------------- Date: Fri, 24 Jun 88 15:30:19 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: David.Slonosky@QueensU.CA Subject: ROM BIOS and CHK4BOMB Message-Id: 153:David Slonosky/QueensU/CA,"",CA From: David Slonosky/QueensU/CA,"",CA To: Subject: ROM BIOS and CHK4BOMB This probably will demonstrate my lack of knowledge about DOS more than anything, but here goes...I used CHK4BOMB on a file I received from a friend which draws a picture of a naked female on the screen. It is called MISS-DV.COM. CHK4BOMB gave the message that the program uses ROM BIOS routines and should not be run until I consulted an expert. Is there any reason that a program which supposedly uses a digitized image (from 5 data files labelled SCR0...SCR4.SCR) would need to access ROM BIOS? The program also lists the BBSs from which you can supposedly get more. I know the Macintosh has a ROM toolbox which users can access to draw graphics, and I was just wondering whether DOS has the same sort of setup. (P.S. I am getting Peter Norton's books on MS/PC-DOS and Assembly language so I won't have to ask questions like this any more!) -------------------- Date: Fri, 24 Jun 88 16:43:00 LCL Reply-To: Virus Discussion List Sender: Virus Discussion List From: Michael Wagner +49 228 8199645 Subject: Re: VM/SP Release 5 doesn't RECEIVE hidden files; Rats. I ran out of time today and didn't get to send you this file. If it will still be helpful monday, send me a note and I'll do it then. Greetings Michael -------------------- Date: Fri, 24 Jun 88 14:20:44 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: constructive viruses In-Reply-To: Message from "me! Jefferson Ogata" of Jun 22, 88 at 2:47 pm > >Maybe you don't recall the details of the constructive virus sjb was >referring to. It contained self-replicating code and patches for the >... >boot disk. I, for one, hate updating software on all the disks it might >be living on, and I love the idea of software that updates itself. > >- Jeff Ogata > so would we all, until something failed and we would change our ideas with GREAT suddenness and gusto. - Len Levine -------------------- Date: Fri, 24 Jun 88 14:32:08 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: Don't trust CRC as a virus-indication In-Reply-To: Message from "Mark R. Williamson" of Jun 23, 88 at 4:15 pm > >>Subject: CRC as a virus-indicator. >> >>Don't trust CRC-calculation or parity-calculations as a virus-indicator! >>It is very easy to change a file or program in such a way that the CRC or >>parity of the changed file remains the same. > >True, if the changer knows what polynomial is being used for the CRC. >However, use of two or more independent polynomials should make it much >more difficult. The more independent virus checkers with different >polynomials there are, the harder it will be for the virus builders. > >Note: The above is an unverified assertion. > It truly works. The use of a user-chosen polynomial will make the defeat of the virus very likely. There is no way for the writer of the virus to know what polynomial the user is working with, and therefore no way to know just what to put in his code to compromise the calculation. As long as we agree to disagree, that is to all use arbitrary polynomials, there is good chance of catching this sort of virus. I recently (april?) posted a package called filetest that ran CRC on selected files. I can permit the user to enter his/her own CRC formula and can also check the boot block of the default disk. This does correctly find changes in any desired exec or com files, or the system files. It should be effective, but only reports after the fact. Any takers? len levine len@evax.milw.wisc.edu -------------------- *** end of Virus-L issue ***