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 AA21806; Thu, 7 Jun 90 18:24:50 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA16571; Thu, 7 Jun 90 18:24:51 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA15180; Thu, 7 Jun 90 18:24:44 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa28838; 7 Jun 90 20:30 BST From: Anthony Appleyard To: DAVIDF@cs.heriot-watt.ac.uk Date: Thu, 07 Jun 90 15:35:36 BST Message-Id: <$TGVGDBVHFKVW at UMPA> Subject: Virus-L vol 0 issue #0722 Virus-L Digest Fri, 22 Jul 88, Volume 0 : Issue #0722 Today's Topics Presentation by F. Cohen HDSENTRY Re: Password Snatchers. Re: VM/CMS viruses ------------------------------ Date: Fri, 22 Jul 88 07:37:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Presentation by F. Cohen On Wednesday, July 20, 1988 at the IBM Watson Research Laboratory at Hawthorne, New York, Fred Cohen gave a lecture titled "Models of Practical Defenses Against Viruses." The lecture drew well from both within the lab and from among the members of this forum. I enjoyed both the content and style of the lecture. I was disappointed, but not surprised, that he had no magic to offer. I am sure that others will want to report on what Fred said. I can only report on what I heard. He began by repeating his definition of a virus from an earlier presentation in the same forum. He also gave his general purpose virus program which contains the line "IF "trigger-pulled" THEN DO "damage." He suggested that most defenses for viruses are combinations of the following: * detect by appearance * detect by behavior * detect by change He asserts that detection by appearance is undecidable. Detection by behavior involves too many false positives and false negatives; it is disruptive. He asserts that detection of change may be costly, untimely, easy to forge, and at any rate, fails to deal with all attacks. He suggested that ultimately we deal with viruses by a combination of limiting sharing, limiting transivity, and by limiting functionality and generality. He suggests a world comprised, mostly, of application machines. In such a world we can enjoy most of the benefits of computers while limiting the inherent risk. Specifically, he recommends that we limit methods of interpretation. [Comment: Your reporter has long promoted such a strategy [ Computers & Security 2 (1983) 16-23, "Computer Security: Observations on the State of the Technology," ] To put it another way, Von Neumann was wrong; that is, programs are not like other data, should not be modifiable, and should not share storage with modifiable data objects. For example, in the IBM System/38 programs are strongly typed data objects. The type, program, cannot be changed. Modifiable data types cannot be executed. A program may be replaced in toto, but that results in a change in its fully qualified name. This tends to make surreptitious changes to the program difficult indeed. This is not an assertion that S/38 is not vulnerable to viruses, but rather an example of how restricting generality can reduce the vulnerability or increase the attackers work factor and increase his requirement for special knowledge. A counter example might be the inclusion of BASIC or REXX language interpreters in a system, not restricitng access to them, while not treating their input as executables.] Cohen proposes a strategy which he calls "Complexity Based Integrity Maintenance." He asserts that programs must check things upon which they rely, and which are subject to change. This includes their data, their own content, the operating system, micro-code, hardware and physics [in order of increasing stability]. The check function must be hard to identify, locate, and forge. The check function must verify everything, most things, relevant things, or "however well we can do." Of course, the check function computes a short, but difficult to reverse, function of the object to be checked . He demonstrated a checker called ASP (Automatic Software Protection). It checks the boot block, OS files, and dependencies. It detects and reports all changes. [My inderstanding is that it works in a manner similar to that of Vaccine by FoundationWare (not to be confused with other programs of the same name.)] Questions focused on the windows of vulnerability in the demonstration system. Of course, Cohen only promised defenses, not perfect security. There was some suggestion that "trusted" systems would improve the effectiveness of Cohen's defense, ease its implementation, and reduce its cost. Of course this assumes that "trusted" systems are easier to achieve and cheaper than Cohen's strategy; undecidable. Fred Cohen demonstrated both comprehension and wit. I am satisfied that his description of the problem and the solution is both informed and useful. We will find that whatever strategy we adopt to deal with viruses, if deal we must, will have been anticipated by his work. William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 -------------------- Date: Fri, 22 Jul 88 09:54:27 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: HDSENTRY Not knowing much about actual MS-DOS specifics, I can present some conjecture on the operation of the "hardware write-protect tab" you mentioned. In many operating systems, disk allocation tables and directory information are kept in RAM. After a disk write, the updated directory info is written to the disk. If some program disables all write access to a disk without informing the OS, the OS is likely to be unaware that its disk writes are failing. The practical upshot is that while a directory listing from the OS indicates some files have been changed or erased, the actual contents of the disk have not been altered. The OS's dir is based on its belief of what is on the disk. When the machine is rebooted, it will reload the directory info from the disk, which will still contain the old data. I imagine that MS-DOS keeps the hard drive directory info in RAM with periodic updates. Note that floppy dirs get checked all the time in case you switched disks while the machine wasn't looking. I still prefer the CP/M method of dealing with floppies: if you switched the disk, it's R/O until you type a ctrl-C. The niceness about this is that the OS doesn't have to look at the disk every time you ask for a directory, it just spouts off what was there the last time. - Jeff -------------------- Date: Fri, 22 Jul 88 13:32:39 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: Password Snatchers. In-Reply-To: Message from "VIRUS-L@LEHIIBM1.BitNet" of Jul 21, 88 at 6:09 pm >>The basic idea behind our snatcher.com was to have a terminal appear >>to be unused and let the Victim "log in" there. We simulated the system >>password request mechanism and When the person typed in his/her username and >This attack belongs to the class called spoofs. It is well known and >documented. Along with eavesdropping, it is one of the reasons that >re-useable passwords should be limited to systems in which the terminal >and link are dedicated to the application and in which there is no user >programming (yes, Virginia, there really are such systems.) In other >systems serious consideration should be given to the use of one-time >passwords. (While there are other defenses against such attacks, they >all rely upon knowledgeable and diligent users. These are known to be >expensive.) >William Hugh Murray, Fellow, Information System Security, Ernst & Whinney >2000 National City Center Cleveland, Ohio 44114 >21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 On the other hand, there are systems that detect a loss of DTR (pin 24) and can log out a user who tries this spoof. We have used such systems for some time now. When a user tries to set up a trap like this, the new user can only be nailed if he or she does not turn off the terminal before logging in. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + -------------------- Date: Fri, 22 Jul 88 08:22:18 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe Simpson Subject: Re: VM/CMS viruses In-Reply-To: Message of Wed, 20 Jul 88 12:57:17 SET from >I fear that there is a "good" chance that (almost) all PCs get infested from >the public ones - not necessary by deliberate action. It could come from a >user who caught a virus by accident and uses the public PC to copy some >diskettes. At Miami we found that PC's serving software on LAN's were resistant to infection. Frequently LAN software offers access features like execute only. It would appear to be a bit more difficult to spread a virus accross a LAN set up to serve software with no write access. Perhaps your LAN propagation could ammelorate your other concerns. -------------------- *** end of Virus-L issue *** 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 AA25836; Tue, 12 Jun 90 06:36:16 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA12940; Tue, 12 Jun 90 06:36:13 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA04148; Tue, 12 Jun 90 06:36:00 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa09424; 12 Jun 90 11:06 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Tue, 12 Jun 90 11:03:44 BST Message-Id: <$TGVTCZHTCBQJ at UMPA> Subject: Virus-L vol 0 issue #0722 Virus-L Digest Fri, 22 Jul 88, Volume 0 : Issue #0722 Today's Topics Presentation by F. Cohen HDSENTRY Re: Password Snatchers. Re: VM/CMS viruses ------------------------------ Date: Fri, 22 Jul 88 07:37:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA Subject: Presentation by F. Cohen On Wednesday, July 20, 1988 at the IBM Watson Research Laboratory at Hawthorne, New York, Fred Cohen gave a lecture titled "Models of Practical Defenses Against Viruses." The lecture drew well from both within the lab and from among the members of this forum. I enjoyed both the content and style of the lecture. I was disappointed, but not surprised, that he had no magic to offer. I am sure that others will want to report on what Fred said. I can only report on what I heard. He began by repeating his definition of a virus from an earlier presentation in the same forum. He also gave his general purpose virus program which contains the line "IF "trigger-pulled" THEN DO "damage." He suggested that most defenses for viruses are combinations of the following: * detect by appearance * detect by behavior * detect by change He asserts that detection by appearance is undecidable. Detection by behavior involves too many false positives and false negatives; it is disruptive. He asserts that detection of change may be costly, untimely, easy to forge, and at any rate, fails to deal with all attacks. He suggested that ultimately we deal with viruses by a combination of limiting sharing, limiting transivity, and by limiting functionality and generality. He suggests a world comprised, mostly, of application machines. In such a world we can enjoy most of the benefits of computers while limiting the inherent risk. Specifically, he recommends that we limit methods of interpretation. [Comment: Your reporter has long promoted such a strategy [ Computers & Security 2 (1983) 16-23, "Computer Security: Observations on the State of the Technology," ] To put it another way, Von Neumann was wrong; that is, programs are not like other data, should not be modifiable, and should not share storage with modifiable data objects. For example, in the IBM System/38 programs are strongly typed data objects. The type, program, cannot be changed. Modifiable data types cannot be executed. A program may be replaced in toto, but that results in a change in its fully qualified name. This tends to make surreptitious changes to the program difficult indeed. This is not an assertion that S/38 is not vulnerable to viruses, but rather an example of how restricting generality can reduce the vulnerability or increase the attackers work factor and increase his requirement for special knowledge. A counter example might be the inclusion of BASIC or REXX language interpreters in a system, not restricitng access to them, while not treating their input as executables.] Cohen proposes a strategy which he calls "Complexity Based Integrity Maintenance." He asserts that programs must check things upon which they rely, and which are subject to change. This includes their data, their own content, the operating system, micro-code, hardware and physics [in order of increasing stability]. The check function must be hard to identify, locate, and forge. The check function must verify everything, most things, relevant things, or "however well we can do." Of course, the check function computes a short, but difficult to reverse, function of the object to be checked . He demonstrated a checker called ASP (Automatic Software Protection). It checks the boot block, OS files, and dependencies. It detects and reports all changes. [My inderstanding is that it works in a manner similar to that of Vaccine by FoundationWare (not to be confused with other programs of the same name.)] Questions focused on the windows of vulnerability in the demonstration system. Of course, Cohen only promised defenses, not perfect security. There was some suggestion that "trusted" systems would improve the effectiveness of Cohen's defense, ease its implementation, and reduce its cost. Of course this assumes that "trusted" systems are easier to achieve and cheaper than Cohen's strategy; undecidable. Fred Cohen demonstrated both comprehension and wit. I am satisfied that his description of the problem and the solution is both informed and useful. We will find that whatever strategy we adopt to deal with viruses, if deal we must, will have been anticipated by his work. William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 -------------------- Date: Fri, 22 Jul 88 09:54:27 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: me! Jefferson Ogata Subject: HDSENTRY Not knowing much about actual MS-DOS specifics, I can present some conjecture on the operation of the "hardware write-protect tab" you mentioned. In many operating systems, disk allocation tables and directory information are kept in RAM. After a disk write, the updated directory info is written to the disk. If some program disables all write access to a disk without informing the OS, the OS is likely to be unaware that its disk writes are failing. The practical upshot is that while a directory listing from the OS indicates some files have been changed or erased, the actual contents of the disk have not been altered. The OS's dir is based on its belief of what is on the disk. When the machine is rebooted, it will reload the directory info from the disk, which will still contain the old data. I imagine that MS-DOS keeps the hard drive directory info in RAM with periodic updates. Note that floppy dirs get checked all the time in case you switched disks while the machine wasn't looking. I still prefer the CP/M method of dealing with floppies: if you switched the disk, it's R/O until you type a ctrl-C. The niceness about this is that the OS doesn't have to look at the disk every time you ask for a directory, it just spouts off what was there the last time. - Jeff -------------------- Date: Fri, 22 Jul 88 13:32:39 CDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Len Levine Subject: Re: Password Snatchers. In-Reply-To: Message from "VIRUS-L@LEHIIBM1.BitNet" of Jul 21, 88 at 6:09 pm >>The basic idea behind our snatcher.com was to have a terminal appear >>to be unused and let the Victim "log in" there. We simulated the system >>password request mechanism and When the person typed in his/her username and >This attack belongs to the class called spoofs. It is well known and >documented. Along with eavesdropping, it is one of the reasons that >re-useable passwords should be limited to systems in which the terminal >and link are dedicated to the application and in which there is no user >programming (yes, Virginia, there really are such systems.) In other >systems serious consideration should be given to the use of one-time >passwords. (While there are other defenses against such attacks, they >all rely upon knowledgeable and diligent users. These are known to be >expensive.) >William Hugh Murray, Fellow, Information System Security, Ernst & Whinney >2000 National City Center Cleveland, Ohio 44114 >21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 On the other hand, there are systems that detect a loss of DTR (pin 24) and can log out a user who tries this spoof. We have used such systems for some time now. When a user tries to set up a trap like this, the new user can only be nailed if he or she does not turn off the terminal before logging in. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U. S. A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + -------------------- Date: Fri, 22 Jul 88 08:22:18 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe Simpson Subject: Re: VM/CMS viruses In-Reply-To: Message of Wed, 20 Jul 88 12:57:17 SET from >I fear that there is a "good" chance that (almost) all PCs get infested from >the public ones - not necessary by deliberate action. It could come from a >user who caught a virus by accident and uses the public PC to copy some >diskettes. At Miami we found that PC's serving software on LAN's were resistant to infection. Frequently LAN software offers access features like execute only. It would appear to be a bit more difficult to spread a virus accross a LAN set up to serve software with no write access. Perhaps your LAN propagation could ammelorate your other concerns. -------------------- *** end of Virus-L issue ***