Subject: RISKS DIGEST 13.01 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 6 January 1992 Volume 13 : Issue 01 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Customer Clogs Honda 800 number (Sanford Sherizen) Life-and-Death Computer (Warren M. McLaughlin) AIDS Computer Virus (Caesar Chavez) Snow at San Jose ??? (John Pettitt) ZIP+4 and privacy (Douglas W. Jones) Infra-red bar-coded security cards forgeable by laser printer (George Michaelson) Hot sun on car dash obliterates thermal printer output (George Michaelson) Screensaver doing "nothing" might be a resource hog (Karl Swartz) Recommended: Hamming's "The Art of Probability" (Doug Jensen) Review: A Pathology of Computer Viruses (Gene Spafford) Re: Airbus Fuel Monitoring (David C. Martin) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE INTERNET FROM: ADDRESS, especially .UUCP domain folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 12, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Thu, 2 Jan 92 21:57 GMT From: Sanford Sherizen <0003965782@mcimail.com> Subject: Customer Clogs Honda 800 number The Boston Globe (December 30, 1991) reported that a disgruntled Honda owner called its "Better Business Bureau Information Line" toll-free customer relations number so many times that he clogged the line. He did the same to other 800 numbers used primarily by Honda employees and dealers. In both cases, he presumably used an automatic redialing mechanism (daemon dialer). He then began tying up a Honda facsimile number by transmitting muti-page letters during a four-day period. American Honda Motor Co. says that it was forced to ask AT&T to step in and block the calls which allegedly came from a Holliston, Mass home. However, AT&T security said that it also had to block any calls to the Honda numbers for the entire 508 area code, which covers west and north of Boston. Attempts to reach the Holliston complainer was not possible since his phone is unlisted! I seem to remember that a televangelist's number was tied up in a similar fashion a few years ago and there has been rumours of political candidates' phones being plugged by their competition. How common is this form of destructive behavior? It will be interesting to see whether AT&T does some form of call or line blocking on this individual. How can phones be made open except for certain parties who overstep bounds? When are there too many calls and when is the line crossed into harassment? Is this a case where caller ID would have "proven" harassment? Under what conditions is someone no longer allowed "phone rights?" Was the Los Angeles judge's denial of telephone use by Ian Mitnick to prevent him from connecting to a computer in any way related in a legal sense to this present incident? Good story to end 1991. The year of ousted regimes, stalled economies, and phone disorders. Sort of an updated version of Sex, Lies, and Videotapes, to be called Lex, Slides, and Telegaps. Sanford Sherizen, Data Security Systems, Inc., Natick, MA 01760 ------------------------------ Date: Sun, 5 Jan 92 13:21 EST From: "Warren M. McLaughlin" Subject: Life-and-Death Computer The Washington Post, 5 Jan 1992, page C6 (the editorial page): As technologies become more powerful, the distinction between a helping tool and a decision-making tool keeps gaining importance. Nowhere is this clearer than in the case of the new diagnosis-aiding computers, which offer doctors the benefit of a gigantic data base -- far larger than their own experience could be -- compiled from the results of many thousands of cases nationwide. By conglomerating and analyzing the results of these cases, the computer can read out a series of alternative treatments, a probability rating on the success of a given procedure or -- most controversially -- the statistical risk of a patient's dying upon arrival in an intensive care unit in a given condition. Physicians with access to such a machine now bear a responsibility at least as weighty as that of diagnosis itself: that of balancing the computer's seemingly precise numbers and instant certainties with the knowledge that its results are dependent upon human judgement. According to the staff in a Michigan hospital using a program of this type called APACHE, the computer's predictions of a patient's statistical probability of dying -- calculated to two decimal points -- are used strictly as tools, rather as any doctor might estimate, say, a 10 percent chance of survival from a given operation. A better description of risk, in that scenario, need not govern the doctor's (or the family's) decision as to whether the risk should be taken, only inform it better than individual experience ever can. But the incomplete results of a different study performed in France suggested that doctors with access to that kind of risk data were more likely than others to terminate care. The fear among practitioners is that hospital administrators or health bureaucrats, all increasingly beleaguered and pushed by public pressure toward cost-cutting, might see computer-confirmed statistics on death risk as a road to easier triage. Given the capability for vastly enhanced diagnosis by means of computers, the medical profession will be stuck with the same responsibility -- also vastly enhanced -- as before: first, to recognize that a computer can serve the cause of accurate diagnosis only on the basis of properly entered information by the physician using his or her senses; second, to keep in mind a fact much of the general public has trouble with, which is that a statistic about the probability of an event bears no causal relationship to that event. A person with a 95 percent chance of dying under a procedure is not the same thing as a person whom that procedure cannot help, or a person from whom care can be withheld with no compunctions. Obscure that distinction, and you take a step toward making the computer the master -- a bad one. - Mike PO Box 54, Bridgewater, VA 22812-0054 ------------------------------ Date: Fri, 3 Jan 1992 04:32:47 PST Sender: Russ_Housley.McLean_CSD@xerox.com From: Caesar_Chavez.ES_AE@xerox.com Subject: AIDS Computer Virus Remember that "AIDS Computer Virus" that was distributed about two years ago? The following article appeared in Information Week on December 16, 1991 on page 40. Caesar Chavez - - - - - - "PC VIRUS BLACKMAIL "A bizarre British court case involving computer viruses has pointed up the vulnerability of users with careless policies on PC software. "Hearing the case of a U.S. scientist accused of computer blackmail late last month, the court granted a stay after lawyers successfully argued that the defendant, Joseph Popp, 41, was mentally ill. Popp was facing 11 charges of damaging computer systems and attempting to obtain a total of 6 million pounds ($10.7 million) through blackmailing numerous medical institutes worldwide around Christmas 1989. "Popp is alleged to have mailed more than 20,000 floppy disks to the research institutes. He promoted the disks as containing valuable information about AIDS. But the disks themselves contained a software virus, which has since also been dubbed AIDS. When users tried to access the disk, they got messages demanding 200 pounds (about $350) to eradicate the virus that had just infected their systems. "Popp was extradited to the United Kingdom, where a chorus of scientists from universities and research institutes claimed that their software had been damaged when the disks were loaded onto their systems. "One organization that fell foul of the virus was the Imperial Cancer Research Fund in London. Dr. Ron Catterall, director of the fund's computer research unit, was called as a witness for the prosecution. Catterall was smart: He loaded the disk onto his standalone PC rather than the network, and warned other users as he discovered the virus. `It took a long time to find out what was going on, and to clean up my machine,' he said. `It eventually started overwriting the hard disk.' Philip Hunter." ------------------------------ Date: Tue, 31 Dec 91 09:54:53 PST From: jpp@slxinc.specialix.com (John Pettitt) Subject: Snow at San Jose ??? The FAA has an on line pilot briefing sysem called DUAT (Direct User Access Terminal). The version of the service I use is provided by Contel Federal Systems. For those who are not familiar with aviation weather the raw data is supplied in a very cryptic form. To make simplify things for users DUAT has a decoder that expands this into `english'. However last night the FT (Terminal Forecast - a 24 hour forward forecast) for both San Jose (SJC) and San Francisco (SFO) was showing 3 VBSY which was being decoded as: Visibility 3 in snow and blowing spray There seem to be two possible causes: 1) a decode error (I don't know what the correct decode of VBSY is) 2) VBSY does mean snow and spray and the NWS screwed up the forecast. Either way computer weather briefing has a way to go yet. John Pettitt, Specialix International (jpp%slxinc@uunet.uu.net) [In response to my comment that Mt Hamilton is east of San Jose and Mt Diablo east of Oakland, and they do get snow now and then, John noted that the terminal forecast is for conditions on the airport and within the Airport Traffic Area (ATA), which is 5 miles radius. <"Anyway, I called the DUAT help desk and they thought the idea of snow was rather a good joke - `another bug for the list'." (John)> PGN] ------------------------------ Date: 2 Jan 92 22:58:44 GMT From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740) Subject: ZIP+4 and privacy I recently asked at my post office how many houses shared the same ZIP+4 code with my house. The answer was that if I lived in a single-family dwelling, I almost certainly have a unique ZIP+4 code. I note that the USPS now provides a complete database of ZIP+4 addresses in the country -- it is on CDROM, and it is included in the postal exhibit in Chicago's Museum of Science and Industry, where you can type in your address (as you would on a letter), and it gives you your ZIP+4 in response. I tried it on my address here in Iowa, and it worked correctly. The risk I see in this is that statistical data that has traditionally been available sorted by ZIPcode (for example, census data) may be released broken down by ZIP+4 codes. If this is done, it destroys any promise of confidentiality for such data. Of course, there is a benefit -- you should be able to send mail to me with only a ZIP+4; no need to mention city, state, street, or house number. Doug Jones ------------------------------ Date: Sat, 4 Jan 1992 12:54:31 +1100 From: George Michaelson Subject: infra-red bar-coded security cards forgeable by laser printer They handed the cards out in alphabetical order to staff, and the barcodes/card numbers were congruent and the batch was sorted. Skilled person (not self) examined 3 in sequence, calculated trivial encryption and checksum algorithm used, inferred card for senior member of staff, used Public Domain code to generate barcode strip on apple laserwriter, glued to card and swiped through lock. bingo! instant access to secured areas, leaving calling card of selfsame high-up all over the online logs. Infra-Red readers also handle normal light codes. Good eyes can read thick/thin sequences in strong light so even if numeric code on card doesn't match bars, its forgeable. Infra-Red also pretty trivial to obtain as it UV reader. I really think the local admin/security people have been blinded by science. Apart from anything else the electromagnets which operate the doorlocks look very subvertable. Another instance of hindering the novice and legitimate, whilst barely impeding anybody intent on skullduggery. -George ------------------------------ Date: Sat, 4 Jan 1992 12:47:55 +1100 From: George Michaelson Subject: Hot sun on car dash obliterates thermal printer output. Buy parking ticket @ 40c per hour. Vending machine has current TOD, allocates ticket to nearest 20 minutes to be displayed clearly on dashboard of parked car. Shows purchase time, and expiry time in large letters. Come back to car 7 hours later. It has been a hot muggy day, around 35C at the peak. Car was parked in full sunlight, and is dark (rusty!) brown. Interior could well have been 40C or over. (certainly felt sauna-ish inside) Entire parking voucher is black. Either the spot heat, the continual lower background heat, some emitted vapour from the car interior, or all three has made it do a disappearing fax trick in reverse. Illegible unless scrutinized at close range, certainly not readable through window. I hope nobody's using one of these to do "permanent" chart recording or whatever in hot locations... -George ------------------------------ Date: Fri, 3 Jan 92 0:07:51 PST From: kls@ditka.chicago.com (Karl Swartz) Subject: Screensaver doing "nothing" might be a resource hog This afternoon, a colleague at SLAC (the Stanford Linear Accelerator Center) was showing me the latest screen lock and saver program he had obtained for his workstation, a port of the one often found on Suns. This reminded me of an incident several years ago when I was visiting my friend George Berg. George is a professor of computer science at SUNY Albany, known in the department for his AI programs that run for days or even weeks at a time on several SPARCstations, grabbing every available CPU cycle. Over the weekend, George dialed in from home to check on the progress of his latest project and was a bit surprised to find that it seemed to be running much more slowly than it had during the week. When a later checkup again showed minimal progress he began to invistigate, and found that the machine was indeed busy -- running Life on the unused screen in his office! After disabling the screen saver the real work continued on without further competition. Getting back to SLAC today, this is quite relevent as some of our computing tasks involve many essentially unrelated events, work that can easily be farmed out to machines on the network with cycles to spare. Obviously productive use of our resources depends on users understanding that "their" machine isn't necessarily free to simulate life, compute pi to a million decimal places, or enumerate the nine billion names of God just because they aren't in the office. It's also easy to forget just how many resources some "cute" program can use. Karl Swartz uunet!decwrl!ditka!kls 1-415/854-3409 2144 Sand Hill Rd., Menlo Park CA 94025 ------------------------------ Date: Wed, 1 Jan 92 17:45:56 PST From: "DOUG JENSEN, DTN 223-1201, M.S. PKO3-1/22D" Subject: Recommended: Hamming's "The Art of Probability" I have recently been reading Richard Hamming's book "The Art of Probability," (Addison Wesley, 1991) and wish to strongly commend it to those of you who haven't yet seen it. Please allow me to whet your appetite with the following brief excerpts. "This book...is one man's opinion using a rather more scientific (as opposed to mathematical) approach to probability than is usual." "Most authors of probability books present one version of probability as if it were the true and only one. On the contrary, we have carefully developed a sequence of models on what seems to be a reasonably scientific approach." "The model of probability you adopt is often relevant to what actions you later take, though most statistics books do not make plain and clear just what is being assumed. Unfortunately, many times the statistical decisions affect our lives, from health, medicine, pollution, etc. to reliability of power plants, safety belts vs. air bags, space flights, etc." "The weak law of large numbers encourages one to think that the average of many repetitions will give an estimate of the underlying probability. But we have seen...that the number of trials necessary to give an accurate estimate of the probability may be much more than we can ever hope to carry out. And there are further difficulties. We assumed the existence of the mean; suppose it does not exist! (see the next Section 8.7). It is not that the author is opposed to statistics--there is often nothing else to try in a given situation--but the stated reliabilities that statisticians announce are often not realized in practice. Unfortunately, the foundations of statistics, and its applicability in many of the situations in which it is used, leaves much to be desired, especially as statistics will probably play an increasingly important role in our society." ------------------------------ Date: 31 Dec 91 23:09:21 GMT From: spaf@cs.purdue.edu (Gene Spafford) Subject: Review: A Pathology of Computer Viruses I recently received a copy of "A Pathology of Computer Viruses" by David Ferbrache of the UK Defense Research Agency. The book is copyrighted 1992, and is published by Springer-Verlag (ISBN 3-540-19610-2 and 0-387-19610-2). US price was $39.50. 300 pages. This book is an extraordinarily comprehensive book on the history, theory, and operation of computer viruses, and on virus countermeasures. It is the most complete book I have seen on the topic to date, and contains a very detailed description of how PC viruses work and spread, including viruses in networked environments, viruses in Amiga systems, and viruses in Unix. In fact, I expect David to get some criticism for the detail he presents, but it serves to make the subject matter much clearer. Chapter 1 is a general introduction to the topic of viruses, worms, and malware. Chapter 2 is devoted to the history of viruses and "malware" starting from the 1960s and thru the end of 1990. It has a very complete description of the earliest viruses, including some events and activities that have not been generally reported elsewhere. It also includes interesting information on related activities, such as the founding of the Virus-L mailing list. Chapter 3 is a nice introduction to the theory of computer viruses, including discussion of how computer viruses relate to biological viruses, and other related topics such as artificial life. Chapter 4 is a detailed discussion of how viruses operate in an IBM PC environment. This includes details on camouflage techniques and signatures as well as spread and activation. Chapter 5 provides extensive discussion of techniques to protect against computer viruses. Chapter 6 is a description of how viruses work in the Apple Macintosh. Chapter 7 discusses viruses in mainframes and Unix systems. Chapter 8 is devoted to "network viruses" -- worms. This includes analysis of early work, the Morris Worm, WANK, Christma Exec, and even a discussion of e-mail chain letters! The chapter also has a nice discussion of Internet protocols that lend themselves to abuse by malicious code. Chapter 9 is a chapter discussing reactions of the computing community, including some legislative history and information on the formation of response teams. Chapter 10 is a brief statement about the future of the problem. The book concludes with 18 appendices, listing everything from the DOS filestore structure to a PC virus family tree to all the CERT advisories to date. One of the appendices provides an extensive reading list. Overall, the book is one of the best books on computer viruses I've seen. David's illustrations are clear and his prose is quite readable. I found information and details in this book that I have not seen in any other virus book. The section on the history of computer viruses, in particular, is quite well done. There are some small problems with the book, however. First of all, I was very disappointed that there were almost no footnotes or citations in the body of the book. As I read through the material I noted material that I wished to pursue further -- unfortunately, there were no citations to allow me to seek original sources. I do not doubt the accuracy of the information presented, but I feel that the lack of specific citations is a flaw in such a scholarly work. The book suffered from spotty copy-editing. I found many places where there were quite obvious typos. In a few places, these typos obscured the text's meaning or distorted some information. I am not sure whether to fault the author or the publisher, but is is sad to see in an otherwise excellent book by an established publisher. Another minor complaint is that there is no presentation of formal theory about viruses or worms. Although this is not an area that has seen much good work, it would have been useful to have some coverage of that material here to complement the higher-level descriptions. The appendix listing other references was good, and contained some references I have not seen before, but it did not give any indication which of the many references were particularly noteworthy or why the references were cited. For instance, a number of limited-availability BBS postings and Usenet articles were cited without an indication of why they were included. At the same time, the references did not list either of the fine collections of readings by Professor Peter Denning ("Computers Under Attack" ACM Press/Addison Wesley) and Professor Lance Hoffman ("Rogue Programs" Van Nostrand Reinhold), nor did it reference any of the publications by the NCSA. The book is written primarily for a British audience. This means that the coverage of US-specific items, such as anti-virus legislation, is briefer than a US reader might prefer. It also means that some small translation of terms is necessary in spots; of course, this same criticism can be made of many US-centric books being published in a non-US market. Despite these criticisms, I strongly recommend this book to anyone who is interested in computer viruses and security. It presents material clearly and comprehensively, and provides unbiased coverage of the area (David is not involved with the marketing of anti-virus software or seminars as are many other virus book authors). (317) 494-7825 Gene Spafford, NSF/Purdue/U of Florida Software Engineering Research Center, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-1398 ------------------------------ Date: Tue, 31 Dec 91 07:32:25 PST From: owner-comp-sources-x@msi.com (David C. Martin) Subject: Re: Airbus Fuel Monitoring (Van Voorhis, RISKS-12.72) Fueling is performed by an external source, not by the plane (at least for all the American made planes that I have worked with, e.g. MD-80's, 727's, etc..) The plane has a control panel which works on conjunction with the fueling system from the tanker to indicate how much fuel the plane should take (i.e. how much do you want to put in) and then automatically cuts off the flow when either the limit of storage or the limit of input has been reached. There are internal pumps to move the fuel around from tank to tank. It sounds like the fueling panel on the plane was not working correctly and they needed to manually determine the amount to input. This is typically done my either disabling the fueling panel (or overriding the auto-cutoff) and determining the fueling progress from inside the cockpit. One problem with this technique is that it requires multiple people (one in the cockpit, one at the pumping station, and maybe others from the airline to supervise the override/disable of the fueling panel). This practice is quite common w/ older American jets and only occasionally causes problems, e.g. when fuel spills due to other malfunctions. ------------------------------ End of RISKS-FORUM Digest 13.01 ************************