RISKS-LIST: RISKS-FORUM Digest Monday 2 May 1988 Volume 6 : Issue 75 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: The effectiveness of write-protection (WHMurray) Brain virus remembered (Fred Cohen) To speak of the disease is to invoke it? (Viruses) (Fred Cohen) Fear of Fear of Viruses (John Chambers) New BITNET LISTSERV group for discussing viruses (Kenneth R. van Wyk) Re: KAL007 (Don Wegeng) "Human Error" and RISKS of being deceased (Jon Jacky) Pitfalls of simulation (economic models) (Jon Jacky) Re: bad checks (Brian Kantor) Re: NORMAL ACCIDENTS (Jon Jacky) Re: Stores and SSNs and Perrow (David Chase) W.H.J. Feijen on Formal Specification of Programs The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. For Vol i issue j, ftp kl.sri.com, get stripe:risks-i.j ... . Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85). ---------------------------------------------------------------------- Date: Mon, 2 May 88 10:38 EDT From: WHMurray@DOCKMASTER.ARPA Subject: The effectiveness of write-protection Phil Goetz quotes (without attribution to me, probably out of deference to my age) as follows: >To suggest that [write-protection] is 100% effective against a virus is to >overstate. Studies in biology suggest that a virus can thrive even in a >population in which a large percentage of the members are immune, if a there >is sufficient commerce among the non-immune members... >Depending upon design of the virus, the target system and population, and >the chosen distribution vector, the effectiveness of this mechanism against >the spread of the virus might vary from high to none at all. Those of you that read the original posting may remember that the reference in the original posting was not to "write-protection" in general but to a specific hard-disk write protection mechanism that could write protect up to 80% of the hard-disk. You may also recall that the ellipsis at the end of the first paragraph represents: >This is not an argument against vaccines but only a caution >about the limits of their effectiveness. Mr. Goetz asserts: >Conclusion: Write-protecting the hard drive can offer 100% protection. I concede the following: Write-protecting 100% of the hard drive 100% of the time can offer 100% protection against any contamination or infection of the hard drive. 100% protection of 100% of all hard drives (an absurd case) can provide 100% protection against any infection of those hard drives. However, even write protection of 100% of 100% of the hard drives will not be 100% effective against 100% of viruses. [I refer Mr. Goetz to Mr. Cohen for proof of that assertion.] The assertion in the second pargraph was also made in the narrow context of the particular implementation of write-protection which was the subject of the posting. However, upon inspection, I conclude that it stands by itself. I leave it to Mr. Goetz' peers to instruct him as to why. Mr. Goetz concedes: >Of course, if you are using your computer as a terminal, you might move a >virus between accounts on a mainframe, or between different computers you >dial up. But your computer is protected. The interesting characteristic of a virus is not how it behaves in the target machine but how it behaves in the community. The interesting characteristic is the ability of the virus to replicate rather than its ability to infect. The XMASCARD program did not infect; it only replicated. After it replicated a sufficient number of times, the number of copies overwhelmed the community. The issue here is not how or whether you can protect yourself. Rather it is how viruses will behave in a community of systems many of which are not protected. It is whether or not Mr. Goetz will have to write protect his hard disk. It is whether or not the community will be sufficiently orderly and well behaved that we can safely share programs and other data that we did not create ourselves. Forgotten, but not gone. Bill Murray 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: 1 May 88 20:51:23 EDT (Sun) From: fc@ucqais.uc.edu (Fred Cohen) Subject: Brain virus remembered Some info on the brain virus not previously mentioned by those who were trying to quell it - it modifies several .com files, maybe all of them eventually, without changing file sizes or dates - this was found by using a cryptographic checksum on a golden unit, infecting it, and looking at the results. Apparently, at Miami U of OHIO, they were accidentally reinfecting every time they cleaned a disk because they had NO GOLDEN UNITS! We found a 2 year old disk and are going to use this as a beginning from now on. We also got help from a programmer who wrote a little routine that checks for changes in the interrupt vectors and halts the machine as soon as they change. We are in the process of installing an improved self defending command interpreter, but are having a hard time because we cannot get sources for the system files we are trying to protect. Once again, protectionism causes more problems than benefits. Oh yeah, did I forget to mention, that since you cannot write protect lotus, etc because of copy protection, you cannot keep them from getting infected - I thought I should bring it up. Finally, even if you rewrite the boot sector, the brain we found remains active through the com files it modified. So much for the cures I've heard about. As always, suggestions are welcomed, but I think we will get it under control before the summer break (2 days away). If we don't it could be real trouble for the rest of you. - Fred ------------------------------ Date: 1 May 88 21:09:54 EDT (Sun) From: fc@ucqais.uc.edu (Fred Cohen) Subject: To speak of the disease is to invoke it? (Viruses) In WHMurray's recent article to this bboard, I hear the same sounds I have heard for years when attempting to discuss computer viruses in an open forum. To speak of the disease is to invoke it. Did anyone ever consider that the disease is inevitable, but the defense is not. Society does not progress by failing to recognize threats, by hiding its head in the sand, or by ignoring gaping holes in its integrity. It survives by identifying corruption and eliminating it. Those who would permit society to live in a situation so frail that a single attacker could bring it to its knees, and then try to cover up that knowledge by hiding it from those best prepared to put up a defense are begging for the destruction of that society. Imagine howbad the virus situation would be 20 years from now if we didn't find out about it now! We would have cars that could be infected, automated airliners waiting for an accident to happen, automated defense systems that could strike individuals deads directly from space, all existing in an environment without integrity. To hide the truth is not to make the world safe. Only the truth can set us free from the oppressive forces that lack integrity but live in a dearth of secrecy. I think we need to start to spend our efforts in computer security on protecting integrity, not secrecy, and I will say it in public forums, dispite the best efforts of some of our government agencies to keep me from doing it. Furthermore, I will continue to encourage others to do so. Don't get me wrong,. I don't think we should glorify attackers, I think we should start to talk about rational defenses that protect the individual. Don't forget that society is made up of individuals, and that by protecting those individuals, we protect the society as well. It is the attempt to protect the society by allowing individuals to come to harm that rationalizes needless wars, police actions, illegal arms deals, and the whole slew of other corrupt practices that are bringing our society down. It is the truth that will set us free, but only if we are brave enough to face it. Sorry for the flaming nature of this, but I feel strongly on this issue, and have had enough from those who would silence important work. Fred ------------------------------ Date: Mon, 2 May 88 01:23:22 PDT From: ames!necntc!adelie!minya!jc@ucbvax.Berkeley.EDU Subject: Fear of Fear of Viruses (Re: RISKS-6.73) You've described a general problem, of people refusing to document security problems out of fear that some unscrupulous readers (or children) will use the information. The result, of course, is that honest computer users are kept ignorant while the dishonest ones slowly learn the tricks. I've discovered one approach that is often successful at tricking people into telling me about the problems. I tell them that I don't believe them. Very often they will respond by trying to demonstrate my ignorance, and of course, the only way they can do this is to demonstrate the problem. You can vary the form of the insult quite a bit. For instance, if they have named a particular commercial product and claimed that it is infected, you can suggest that they have a financial interest in another product, and are using scare tactics to discredit a competitor. (This isn't hypothetical, of course; people have done this.) Recently, there was a debate in unix.wizards about a supposed security problem with the Bourne-shell's IFS feature. The same debate raged, with nobody willing to document the problem. I finally got fed up, and announced that I didn't believe there was a problem; that they were just shooting off their mouths, trying to sound like security wizards when they weren't. I got lots of flames that didn't document any problems, but among them was one letter containing a piece of code that used IFS to create a shell that was setuid to root. It's now part of my collection of security bugs. As for viruses, I have the feeling that most people talking on the subject are rather ignorant, and can't tell you or me anything. Perhaps if you challenge them, you can find a few who will try to show that they know more than you.... John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) ------------------------------ Date: Mon, 02 May 88 15:54:24 EDT From: "Kenneth R. van Wyk" Subject: New BITNET LISTSERV group for discussing viruses. For anyone who may be interested, I've started a LISTSERV discussion forum on BITNET, entitled VIRUS-L. It is dedicated to the discussion of computer viruses, including present viruses and their progress, and the prevention/detection of viruses. To subscribe to the list, as with any LISTSERV-run list, send a message to the appropriate LISTSERV; in the message, say: SUB listname your name. That is, send a mail message to LISTSERV@LEHIIBM1, stating SUB VIRUS-L your real name. To subsequently sign off of a LISTSERV group, send a message to the appropriate LISTSERV stating SIGNOFF listname. Please do not send these requests to the list itself, as they will be distributed to the entire list [and] do nothing other than annoy people... :-) Once subscribed, send list submissions to VIRUS-L@LEHIIBM1. VIRUS-L is currently open to the public. Regards, Ken van Wyk Kenneth R. van Wyk, User Services Senior Consultant, Lehigh University Computing Center, Internet: , BITNET: ------------------------------ Date: 2 May 88 09:01:09 EDT (Monday) From: Don Wegeng Subject: Re: KAL007 In regards to the continuing debate in RISKS about the KAL007 incident, it appears that one side of the argument is putting all of its faith in the version of the story reported in the book "Shootdown". It seems to me that you are always at RISK when you chose to put all of your faith in a single source, be it a pressure sensor in an engine, the phone company's billing system, an elected official, or a book about an aircraft that was shot down. [... and the OTHER side of the story is putting its faith on information that is all derived from one set of interrelated sources??? If you wish to speak in analogs with fault-tolerant computing, beware of the common-mode failures that can undermine supposedly redundant systems. By the way, one difficulty with trying to prove a conspiracy theory is that everyone on the inside will deny it (which may thus seem credible), whether or not the theory is true. So, you are ALWAYS AT RISK, period. PGN] ------------------------------ Date: Mon, 02 May 88 09:12:28 PDT From: jon@june.cs.washington.edu (Jon Jacky) Subject: "Human Error" and RISKS of being deceased In the Letters column of the 1 May 1988 NEW YORK TIMES MAGAZINE (p. 14), a Steven Goldberg writes concerning an earlier article (27 March) on civil aviation accidents. He observes, "In the 'all accidents' category, the pilot is found responsible for the accident in only 38.6 percent of the cases. However, in the 'fatal accidents' the pilot is found responsible 61.5 percent of the time. It may be that there is a benign explanation for the fact that a pilot who is dead is far more often blamed than one who can defend himself. But the prima facie conclusion, in the absence of such an explanation, is that considerations other than safety lead the authorities to blame the pilot, who can not speak for himself." - Jon Jacky, University of Washington ------------------------------ Date: Mon, 02 May 88 09:26:51 PDT From: jon@june.cs.washington.edu (Jon Jacky) Subject: Pitfalls of simulation (economic models) The 1 April 1988 issue [!!] of DATAMATION includes an article, "Economic Modeling Gains Despite Accuracy Concerns," by Gary McWilliams (pps. 43-54). I am not familiar with this field, and the article never really explains what the inputs and outputs of the models are, where they come from or how they are validated. Nevertheless, people apparently use them to forecast economic trends and seem to regard them as useful. One model, called Project Link, includes more than 20,000 equations. Much of the article appears to be based on an interview with Sam Cole, economist and model builder at SUNY Buffalo, and author of GLOBAL MODELS AND THE INTERNATIONAL ECONOMIC ORDER (Oxford Pergamon, 1977). The article reports, "The World Bank uses a global model in its lending, says Cole, sometimes to the detriment of its debtors. 'When the World Bank lends [a country] money, it expects that country to have a [repayment] plan, and usually pursuades the country to accept World Bank forecasts. Since its forecasts are usually wrong, these countries end up with debts and no way to repay them,' says Cole. The World Bank's use of optimistic growth forecasts often are built into the models for political reasons, according to Cole." - Jon Jacky, University of Washington ------------------------------ Date: Mon, 2 May 88 13:24:37 PDT From: brian@ucsd.edu (Brian Kantor) Subject: Re: bad checks In the middle 70s I was responsible for designing a simple on-line inquiry system for automating bad-check lookup for one of those firms that guarantee checks for retail merchants. The way this works is that for a monthly fee (based on average purchase amount and volume), the guaranteee firm would automatically guarantee any check up to some limit, and provide a guarantee for any higher amount check that was verified with them. Initially this consisted of having the guarantee firm's telephone operators page through a thick paper listing of bad checks and returning a code 1, 2, 3, or 4 (1=accept:guaranteed, 2=accept:follow ID procedures and we'll guarantee it, 3=do not accept:no guarantee, 4=do not accept:detain customer, police notified). For example, checks listed as "stolen" would return a code 4 (yes, they stored the range of check numbers so that they wouldn't flag unstolen checks on the same account). The default (we don't know that check) was code 2 [i.e., what the store should have done without the guarantee service]. Merchants would be paid by the guarantee service for a guaranteed check that didn't clear, and the guarantee service would then assume the responsibility of collecting on the bad check. Each inquiry was recorded for amount, the assigned approval number and code, check customer number (a reference to the name used to verify/guarantee the check), and the merchant number. This was printed in a ledger and cleared from the system each night. A new entry for someone was given code 2 until they'd been inquired about several times over some period of time (I seem to recall more than twice in 30 days), at which time they'd be advanced to code 1 on the assumption that they hadn't bounced any checks yet. Since the merchant's best interest was served by reporting bad checks ASAP, this seemed to work. Downgrade to code 2, 3 and 4 was manual and done by accounting types at the guarantee firm from bad check collections referred by the customer merchant. Perhaps they also used other data; I don't know. The whole premise was that each guarantee office usually served repeat check customers: it could build a payment history database. I think the assumption was that people who wrote several checks without bouncing them would probably continue to do so. We built the database for online inquiry by storing the last name Soundex-indexed (as a sort of hashing technique, if you will), and listing other information such as SSN, driver's license number, account number on the check, etc in a cross-reference. If more than one "hit" occured when an operator keyed in a last name, he was prompted for more information to resolve the hits, or he could page through a summary of the records on line to see if one fit the profile of the check being submitted. Clearly the RISK here is misidentification: the more information they stored and the more the merchant's clerk collected for check verification, the better they could do at eliminating false denials. The system was clearly biased towards generating accepts to avoid pissing off honest customers, but to contain the losses of the guarantees. Last I heard they were still using revisions of that software and making a chunk of money. Note that most of the actual data used to determine check acceptance RISK was not stored online. Probably it is now, but at that time (about 15 years ago) the disk storage was too dear and the retrieval time simply wasn't important: paper files in file drawers was quite good enough. Since the review was manual anyway, it seemed reasonable to have the relevant documents in human-readable form. One of them - the returned check - was always on paper anyway. This all ran on a Microdata REALITY system with 64K of main memory (the max) and one 10 Meg hard drive. Nowadays you'd do it on an ATKlone. Brian Kantor, UC San Diego ------------------------------ Date: Mon, 02 May 88 09:06:43 PDT From: jon@june.cs.washington.edu (Jon Jacky) Subject: Re: NORMAL ACCIDENTS The May 1, 1988 issue of the NEW YORK TIMES MAGAZINE has a feature article about Tom Clancy, author of the best-selling thrillers HUNT FOR RED OCTOBER and RED STORM RISING. In the background of the obligatory picture of the author in his study by his bookshelves, you can clearly see NORMAL ACCIDENTS by Perrow (p. 55, right edge of page, halfway down). - Jon Jacky, University of Washington ------------------------------ Date: Sat, 30 Apr 88 00:15:17 -0700 From: chase@orc.olivetti.com Subject: Re: Stores and SSNs and Perrow In reply to two articles by Stanley F. Quayle: > This store uses price scanners. It would be possible to establish a > profile of each check-paying customer with this system....If they > haven't thought of this already, I don't want to give them any ideas. Don't worry; they've already thought of it and do it. My wife reports that Stew Leonard's in Norwalk, Connecticut is one store that does; by name, and what you buy, and if it was on sale. Paying cash is the only sure way to avoid this. (on Normal Accidents) I think Perrow was studying nuclear power as it existed from 1979 to 1984, not as it might exist. I don't think his conclusions on nuclear power are weakened at all if someone tells me that we could build safer plants, but don't. You can rightly say that safe plants haven't happened for economic, political, legal, and bureaucratic reasons, and you still haven't weakened his conclusions. David Chase, Olivetti Research Center, Menlo Park ------------------------------ Date: Sun, 1 May 88 14:47:20 EDT From: adrion%capri.tcp.cs.umass.edu@RELAY.CS.NET Subject: W.H.J. Feijen Harvard Distinguished Lecturer Series, GB/SIGPLAN, and GB/SIGSOFT Present: W.H.J. Feijen, Visting Professor at University of Texas, Austin Professor at Technologie Universitat, Eindhoven, Netherlands Speaking on MAY 3rd, 7:00 pm, Lecture Hall B, Harvard Science Center, Cambridge, MA, Prof. Feijen promises to update Software Engineers on the latest developments in the Formal Specification of Programs. He is co-author with Edsger W. Djikstra of the recently released "Methods of Programming". (A large crowd is expected.) Host is Professor Mark Schneider, Harvard Univ. ------------------------------ End of RISKS-FORUM Digest ************************