VIRUS-L Digest Monday, 23 Jan 1989 Volume 2 : Issue 21 Today's Topics: re: PDP virus Size-changing viruses Re: 1st and 2nd Main propositions of virus hunting Anti-virus programs RE: Otto's Rules --------------------------------------------------------------------------- Date: Fri, 20 Jan 89 16:46:52 EST From: shafferj@amethyst.bucknell.edu Subject: re: PDP virus I haven't seen any PDP viruses, but the Cookie Monster seems to be a classic program. I wouldn't call it a virus -- at least, I've never heard of any viral versions. It's probably something someone inserted when no-one else was looking. Unless the perpetrator manages to patch the operating system, you should be able to find the file somewhere and delete it. Also, you should be able to find the process (task? I'm not very familiar with PDP terminology, and you didn't mention which OS you were running on it anyway) and kill it. Unless this is an exotic version, it should be very easy to get rid of the problem. Jim ------------------------------ Date: Sun, 22 Jan 89 15:22:22 PST From: PJS%naif.JPL.NASA.GOV@Hamlet.Bitnet Subject: Size-changing viruses I gather that at least some of the virus-detection programs on the market recognise viruses by looking for files or file extensions of specific sizes. What happens when a virus comes out which changes its size with each infection according to a random number table? Peter Scott (pjs@naif.jpl.nasa.gov) ------------------------------ Date: Sat, 21 Jan 89 21:37:34 PST From: crocker@tis-w.arpa Subject: Re: 1st and 2nd Main propositions of virus hunting In vol 2, # 20, Otto Stolz gives two propositions of virus hunting, viz. (1) every program designed to catch viruses can be circumvented by virus-writers who know its principles of operation, and (2) every virus can be [caught] and prevented from further propagating if its principles of operation are known. These principles help characterize virus hunting as a game, in the theoretical sense, but they include an implicit assumption that is worth examining. A "virus-hunter" can be viewed as a filter. The user presents to the filter a set of programs and asks it to separate out the programs that have viruses from the ones that don't. This is the same paradigm as trying to sort out, say, bad ball bearings from a manufacturing process using some sort of test, and there four classical outcomes. 1. A truly good part will be seen to be good. [Translation, a virus-free program will be seen to be virus-free.] 2. A truly bad part will be seen to be bad. [Translation, a program which contains a virus will be detected.] 3. A truly bad program appears to be good. This is a "false acceptance," or in the lingo of statistics, a Type II error. [Translation, a program which contains a virus slips through the filter.] 4. A truly good program appears to be bad. This is a "false rejection," or a Type I error. [Translation, a program which is ok is rejected unfairly.] Only a perfect test will have no false acceptances and no false rejections. Less than perfect tests must necessarily have some combination of these errors. Now the critical contribution from the world of statistics is that it is almost always possible to trade off Type I for Type II errors. Looking at only the Type I or only the Type II error rate doesn't tell enough about the power of the test. When comparing two different tests, e.g. whether to use, say x-ray screening or a mechanical test on ball bearings, one test is superior to another only if it yields lower error rates for BOTH Type I and Type II errors. How does this apply to virus hunting programs? There are two ways a virus hunting program can fail. It can reject good programs or it can pass bad programs. So far as I can tell, virus hunting programs are generally written with the implicit assumption that it is unacceptable to reject a good program. That is, they strive to have a very low (ZERO?) false rejection rate. As these tests are also less than perfect, they necessarily have a significant false acceptance rate, i.e. they fail to detect some programs that have viruses. If the tolerance for false rejections were changed, i.e. if it became acceptable to reject some programs which are really ok, then it is entirely possible to build a virus hunter than cannot be circumvented. At the extreme, rejecting EVERY program surely catches every virus, but that throws the baby out with the bath water. The interesting question is how much better can we do? As long as we are faced with imperfect tests, we will necessarily have to live with non-zero error rates. Nothing forces us to have these errors be only false acceptances. We can choose to have only false rejections, if we wish. [We can also choose to have a combination, but let me ignore that in this note.] Only when we apply some sort of cost function can we choose appropriately. Now, it might seem to readers of this forum that having a fail-safe test would necessarily result in too many false rejections. This is indeed a relevant question, but I don't think any of us know what the answer is. It may well be possible to write a fail-safe virus hunter that examines the innards of a candidate program to decide if it's ok, and that most of the genuinely ok programs actually pass the test. In the current world, where there are no ground rules for writing programs to make them easy to examine, Stolz' principles indeed characterize the situation for virus hunting programs that are not permitted to reject good programs. There are two ways to change the game, however. 1. Permit virus hunting programs to declare a program "unsafe" if it cannot PROVE that there is no virus. 2. Set forth standards for programs to facilitate examination by this new class of virus hunters. The first proposal, taken alone, may or may not be practical. I do not know how hard it is to write an acceptably accurate virus filter that works on software prevalent today. Some of my colleagues think it is obviously too hard. My own view is that it may well be easier that it first seems to be. In either case, I don't think there's enough data, and I believe it would be worthwhile exploring the question. The latter proposal is much easier from a technical standpoint but involves creation and promulgation of standards. In the long run, this may be the way we ultimately develop the means to trust the software we depend on. These ideas are taken from a paper Maria Pozzo and I have written, "A Proposal for a Verification-Based Virus Filter," which is being presented at the 1989 IEEE Symposium on Research in Security and Privacy, Oakland, May 1-3. The ideas expressed here are mine, and do not necessarily -- and in some cases are known not to -- represent those of my colleagues, any of our clients or sponsors, or the official position of Trusted Information Systems. Steve Crocker Vice President Trusted Information Systems ------------------------------ Date: Sat, 21 Jan 89 16:18:08 +0200 From: "Yuval Tal (972)-8-474592" Subject: Anti-virus programs I have a few good PUBLIC DOMAIN programs that checks if you have a virus on a disk or in yuour memory. it is also possible to tell the program to check your disk every X time if your hard disk is infected by a virus. Some of you probly heard of them: IMMUNE, UNVIRUS, VIRALARM, RUNTIME, BB-VIRUS, CHKVIRUS etc... Who wants them can send me mail and i'll be happy to send them... Yuval Tal (NYYUVAL@WEIZMANN.BITNET) ------------------------------ Date: Fri, 20 Jan 89 23:03:14 EST From: Neil Goldman Subject: RE: Otto's Rules To put it another way, as Fred Cohen has said (i believe): In general, it is impossible to detect viruses, but any particular virus can be detected by a particular detection scheme. I believe it is the ignorance of not only the general public, but also computer professionals that compounds the perception that somewhere out there exists a cure-all. Everything WE CAN DO TO EDUCATE virus inquirers of Otto's rules, the LESS the hysteria will continue. - ---------------------------------------------------------------------- Neil A. Goldman NG44SPEL@MIAMIU.BITNET Replies, Concerns, Disagreements, and Flames expected. Mastercard, Visa, and American Express not accepted. Acknowledge-To: ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253