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 AA25982; Tue, 12 Jun 90 07:10:26 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA13085; Tue, 12 Jun 90 07:10:23 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA04462; Tue, 12 Jun 90 07:10:15 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa10411; 12 Jun 90 11:28 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Tue, 12 Jun 90 11:10:12 BST Message-Id: <$TGVTCZHTCBWG at UMPA> Subject: Virus-L vol 0 issue #0822 Virus-L Digest Mon, 22 Aug 88, Volume 0 : Issue #0822 Today's Topics Re: Hiding a virus between disk sectors Virus insurance distribution Re: distribution Viruses Between Sectors Mail Order computer functionality b/w timed virus attacks REFERENCE TO PUBKEY MAILING LIST ------------------------------ Date: Mon, 22 Aug 88 07:35:47 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ken van Wyk Subject: Re: Hiding a virus between disk sectors In-Reply-To: Your message of Fri, 19 Aug 88 19:38:00 EST > What would the theory be > behind putting a virus in between sectors? If there's physical space there, then I'm sure that it can be done. You have to remember a couple things though. First, the virus would need some "bootstrap" code that would have to reside in a program(s) which is accessible to DOS, or else the space in between sectors would be ignored. Also, the virus would become very hardware specific. Certainly floppy disks and hard disks (yet alone different models of hard disk controllers, etc.) have different physical characteristics in this regard. Imho, the bottom line is that writing such a virus would not be feasible, or at least cost (of time) efficient. Ken Kenneth R. van Wyk Calvin: Dad, can I have a flame thrower? User Services Senior Consultant Dad: Of course not! Lehigh University Computing Center Calvin: Even if I don't use it in the Internet: house?!!! BITNET: -------------------- Date: Mon, 22 Aug 88 11:09:25 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ken van Wyk Subject: Virus insurance Recently, on the RISKS forum (I believe), there's been some discussion about virus insurance. Specifically, about how corporations are seeking virus clauses in their computer security insurance policies. The posting said that at least one (insurance) underwriter has started specifically rejecting any virus coverage at all. The insurance companies seem to feel that they need to learn more about viruses before being able to insure against them. Apparently it could cause security policies to specify much higher deductibles, etc. I thought that it could be an interesting topic for discussion... Any thoughts? If *you* were representing an insurance company, would *you* want to recommend insuring against viruses? Of course, this would not be limited to PCs and/or mainframes. Ken Kenneth R. van Wyk Calvin: Dad, can I have a flame thrower? User Services Senior Consultant Dad: Of course not! Lehigh University Computing Center Calvin: Even if I don't use it in the Internet: house?!!! BITNET: -------------------- Date: Mon, 22 Aug 88 07:54:16 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: distribution By the way, the distribution of this list has been really weird at my end lately; I've been getting postings WAY out of order, like days. My node seems to be served by some other site now; I don't know if that's the problem. Maybe it's just the size of the postings. Anyone else having major weirdness lately? - Jeff Ogata -------------------- Date: Mon, 22 Aug 88 13:54:53 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ken van Wyk Subject: Re: distribution In-Reply-To: Your message of Mon, 22 Aug 88 07:54:16 EDT > By the way, the distribution of this list has been really weird at my end > ... > major weirdness lately? BITNET, being store-and-forward, gives smaller messages priority over larger ones. That could possibly explain the ordering problems. The list should still be served by LISTSERV@LEHIIBM1.BITNET unless you're on a local redistribution list. We are, however, slowly looking to pick up a peer LISTSERV or two sometime in the future. Ken Kenneth R. van Wyk Calvin: Dad, can I have a flame thrower? User Services Senior Consultant Dad: Of course not! Lehigh University Computing Center Calvin: Even if I don't use it in the Internet: house?!!! BITNET: -------------------- Date: Mon, 22 Aug 88 15:25:06 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Loren K Keim -- Lehigh University Subject: Viruses Between Sectors A few weeks back, Joe, Chris Bracy and I were all called out to California to test a new anti-viral package of a company which none of us have anything to do with (That company will remain nameless). They asked us to put their package through the ringer and see if we could figure out a way to get a virus through all their defenses. We found several. One of the ideas we kicked around, which had been conceived by some of Fred Cohen's students a few years ago, was hiding a large part of the viral code in between sectors. We wouldn't have to specify that sectors were bad, or change file sizes or anything that a program might catch. A program can't really check between sectors because its unsure of what would be there. The virus would still have to be a boot sector virus or hide in an executable or so on. We felt the best combination was to have the virus attack the boot sector. This would be a difficult virus to work with and a difficult one to write, but not impossible by any means. The real problem is that we are very limited in space, although we can point to each of the between-sector areas. Remember that viruses can hide anywhere. On old Apple II's, we've heard of viruses being able to be hidden in memory other than the main memory, little pieces hidden around the system. There is no easy way to check for code in these sectors other than mapping them and CRCing whatever junk might be written there, and checking it periodically, but this is unreliable. Its far easier to watch for the main program in the boot sector, executables, memory, BIOS and so on. Loren -------------------- Date: Mon, 22 Aug 88 16:10:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: NEWTON@NBSENH Subject: Mail Order Yes. I had a dry spell for a few days, then came in this (Monday) and had *82* mail messages waiting--mostly from virus-l. -------------------- Date: Mon, 22 Aug 88 03:38:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: computer functionality b/w timed virus attacks The idea of a box that computes only one function certainly falls within the definition of a computer. Every computer I ever met satisfies that one. Any computer with finite memory is only capable of computing one function: executing its machine code with finite input and environment. Each program is merely a point in the domain of the function of the computer. After all, to a computer, programs are the real input. Data is just junk for the programs to munch on. When viewed from this perspective, the problem of computer infection becomes: how can a program alter the computer's actual input (programs)? In general, computer programs map some language expressed in the form of data into the domain of the computer's execution function. As such, most data can be viewed as a program running on a virtual machine being emulated by the program actually running on the computer. In the case of interpreters and compilers, the language of the data may be suffic- iently rich for data infection to propagate. But usually the data does not have sufficient semantics to alter other programs or data. Punching the keys on a calculator or microwave are types of data that fall into the latter class. Generalizing the idea a bit, we can see that any computer program is a simulator for some virtual machine. Almost every one of these virtual machines is a more limited machine than the actual computer it is being simulated by. (Possible exceptions: compilers, interpreters, assemblers.) So the idea of exploiting limited functionality for virus prevention is inherent in the use of computer programs. Virus infection from the data angle is never likely to be a problem because it is too difficult compared to good ol' code infection. How do you devise data that makes your accounting package crash your hard disk? And if you CAN, how can it propagate? The virtual machines provided by most computer programs are too limited to be infected. My theory is that virus attacks will almost invariably come from code- altering techniques. If so, calculators, microwaves, and security doors will always be safe because their actual data (code) is permanent and unwriteable. Also: Somebody put forth this scenario earlier: Timed virus crashes a system; Staff loads last dump; Dump crashes system too; Staff loads older dump, etc. until successful. By this time system has lost months of work. Not so; the appropriate response to such a virus attack is to perform the previous actions until a working system is found, then to reset the system clock to sometime in the past and reload your last dump. The recent work can then be salvaged (mostly, hopefully). Even if the virus is counting executions of itself for timing, tape archive formats usually allow selective retrieval of data; once a successful system is found, the latest data can be undumped and cleaned up. - Jeff Ogata -------------------- Date: Mon, 22 Aug 88 21:00:00 SST Reply-To: Virus Discussion List Sender: Virus Discussion List From: ANYONE@ISS.NUS.AC.SG Subject: REFERENCE TO PUBKEY MAILING LIST A RECENT VIRUS-L MSG MENTIONED A PUBLIC KEY CRYPTO MAILING LIST. I TRIED TO MSG THE NAME THAT WAS QUOTED AND GOT MY MSG BOUNCED. ANYBODY HAVE ANY FURTHER INFO ON PUBKEY??? /JC ON JIM@ISS.NUS.AC.SG -------------------- *** end of Virus-L issue ***