Subject: RISKS DIGEST 13.71 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Friday 7 August 1992 Volume 13 : Issue 71 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: "Bug" or fraud? (John Kriens) Ship with computer-controlled ballast tanks tips over (Jon Jacky) Bugs in microcode of CPUs [REQUEST FOR EXAMPLES] (Brian A Wichmann) A problem with call waiting (Rick Pim) Phone service modification (Kraig R. Meyer) Re: Unreliable call-return phone feature... (Joe Konstan) Re: computer scoring at olympics (Jong, Gary McClelland) Sweet Old Things and User Interfaces (Anton Martin Ertl) Re: Mr. C. Baggage, ... (kennykb) Information Age course at Georgetown (Ross Stapleton) World Conference on Network Administration and Security (Hal Pomeranz) 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 YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 13, 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. For information regarding delivery of RISKS by FAX, phone 310-455-9300 (or send FAX to RISKS at 310-455-2364, or EMail to risks-fax@cv.vortex.com). 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: Fri, 7 Aug 92 14:12:46 GMT From: decoy!jkriens@uunet.UU.NET (24474-kriens) Subject: "Bug" or fraud? The following appeared in the Thursday, Aug. 7, 1992, NJ Star Ledger. "Bug" Backfires on Computer Consultant NEW YORK (AP) -- A computer consultant must pay $25,000 to a Manhattan law firm whose computer system crashed because he put a "bug" in it. Donald R. Lewis hoped the bug would cause the law firm of Werner, Zaroff, Slotnick, Stern and Askenazy to call him for repair work after the system collapsed, according to Civil Court Judge Richard F. Braun. Lewis was hired in 1985 to upgrade the firm's computer system, which tracks medical payments of auto accident victims to health care providers. The patients, under the state's no-fault insurance law, assign their awards to the health care professionals. Lewis initially estimated the upgrade would cost up to $5,000, but the firm eventually paid him some $21,000. In the months that followed, Lewis periodically called the firm's receptionist to see if the computer file had entered claim number 56789. In July 1986, six months after the firm made its last payment to Lewis, the computer system shut down. It had filed claim number 56789, Braun said. Lewis had put a "conditional statement" in the computer's software which caused it to stop functioning at claim number 56789, the judge said. The law firm paid another consultant $7,000 to fix the problem. [Once again this brings up the concern of people thinking that anything that happens in a computer system that wasn't expected by the end users is a bug. I'd like a job where I got paid $7000 to remove a "conditional statement." John Kriens jkriens@decoy.cc.bellcore.com] ------------------------------ Date: Fri, 7 Aug 1992 9:15:48 -0700 (PDT) From: JON@gaffer.radonc.washington.edu (Jon Jacky) Subject: Ship with computer-controlled ballast tanks tips over From THE SEATTLE TIMES, Wed. Aug 5, 1992, p. D1: "Ship makes list - the hard way" by Penelope M. Carrington F. Garcia had just rounded the corner ... yesterday when he saw the 300-foot fish-processing ship list to its right and crash into the neighboring dry dock. ... the vessel, the Dona Karen Marie, had been leaning since early yesterday morning. First it listed to the left --- portside. Then an engineer came to fix the problem. Workers watched as the ... ship leveled and then listed to the right --- starboard --- into the United Marine Marketing dry dock. Shipyard spokeswoman Ruth Nelson said something malfunctioned in the computer that controls the water-ballast tanks of the boat when the engineer tried to correct the original listing. As a result, all the water in the left tank "was swooshed down to the other side," said Nelson, who was unsure why the boat listed in the first place. There were no injuries, and no danger of the ship tipping over into Lake Union because it rested against the firmly anchored dry dock. Tacoma Boat, which built the Dona Karen Marie, was contacted to secure copies of the original plans to the ships ballasting system. The Seattle Fire Department hoped to find the pipes that would pump the water back to the port side. ... The Dona Karen Marie has been moored in the shipyard for weeks. Nelson said she could not identify the vessel's owner. [ I pass the scene every day on my way to and from work. It is quite a sight --- imagine a four-story building tipped over onto its neighbor. The ship is tipped about 30 degrees away from vertical, resting against the wall of the adjacent drydock. I don't know if it would have capsized if it hadn't struck the drydock, but it looks like it might have. It is lucky no one was hurt. ] - Jon Jacky, jon@radonc.washington.edu, University of Washington, Seattle ------------------------------ Date: Fri, 7 Aug 92 17:18:48 BST From: Brian A Wichmann Subject: Bugs in microcode of CPUs I have a long, but unfortunately, confidential article about bugs reported to me in the microcode of microprocessors, including those used in `safety-critical' systems. I would like to collect further examples. Clearly, such bugs could undermine safety-critical systems. I have a list of such bugs, but unfortunately, many are confidential. I should like to collect further examples. If I get enough non-confidential examples, I will post them to comp.risks. Please send E-mail information to me and state whether your example should be kept confidential or not. Give full details, such as the microprocessor, date, and nature of bug. Thanks. Brian Wichmann, National Physical Laboratory (baw@seg.npl.co.uk) ------------------------------ Date: Fri, 7 Aug 1992 11:58 EST From: Rick Pim Subject: a problem with call waiting (prompted by recent related anecdotes) Recently, a couple of entries attracted my attention: rex@iqsc.com (Rex Black) talked about "Unreliable call-return phone feature...", while CMHAM01@UKCC.uky.edu (Chuck Ham) mentioned problems associated with GTE's Personal Secretary (where a friend had troubles without even subscribing). I suspect that something like my small risk has been mentioned before, but who knows.... Last year, Bell Canada had a promotion in our area to flog (among other things) Call Waiting. It was mentioned in a glossy throwaway in our monthly bill that we were having Call Waiting installed on our lines (we have two) for a free trial period. Shortly after this, I was at home and my S.O. [significant other] was out curling. The arrangement was that she would call me when she finished, I'd pick her up, and we'd go scare up something to eat. While waiting, I dialled in to work and probably read news. After a while I got occasional bursts of line noise but ignored them - the local phone lines are sometimes noisy. The other phone never rang... The other half of the story is that there was an increasingly grumpy person at the curling club trying to find me: calling home (I wasn't there, because, of course, the phone was ringing and not being answered), work, friends' places, and the like. It took a long time before she thought of using the other phone number. The risk is small, but annoying: with the increasing use of phone lines for data, it is not necessarily the best decision to use a normal "ring" when a caller dials a busy line with call waiting on it. One should also read glossy throwaways more carefully. :-) ------------------------------ Date: Fri, 07 Aug 92 13:30:48 PDT From: kmeyer@aero.org Subject: Phone service modification About a year ago, I had my long distance service switched from MCI to AT&T without my authorization--and didn't find out until the bill came from my local phone company, Pacific Bell. I called AT&T who said they keep no record of where a switch request comes from (they insisted that I must have filled out a form, or that I told a telemarketer to switch me, etc). They did take down an incident report after I insisted on speaking to a supervisor's supervisor. Pacific Bell told me that they do no verification if a long distance carrier requests a switch on a customer's phone line; they receive a tape with phone numbers on it and switch every number listed on the tape to AT&T. (Pacific Bell also wanted me to pay to switch back to MCI, which MCI ended up paying). Kraig R. Meyer kmeyer@aero.org [This gets us back to the problem of the meaning of "unauthorized access" where no authorization is required, or in this case the meaning of "authorized access" when no authorization is requested! PGN] ------------------------------ Date: Thu, 6 Aug 92 17:55:42 PDT From: konstan@elmer-fudd.cs.berkeley.edu (Joe Konstan) Subject: Re: Unreliable call-return phone feature... In RISKS 13.70 Rex Black relates a story of being "called back" via RETURN CALL by a woman who believed he had made a harassing call. This is yet another version of an old set of pranks that involve connecting together unsuspecting phone users. While most of us are more familiar with the version where a prankster with 3-way calling connects together two strangers (while listening in), I haven't heard much about people making harassing calls while having CALL FORWARDING activated to deflect the return call. Unfortunately, until we can tell whether a call we make is being forwarded (which may mean until we get ISDN, or the messiah comes, I'm not sure which is likely to come first), there is no way to prevent a prankster from deflecting calls to another line. Rest assured, though, that the switch does know who placed the call, and that CALL TRACE would properly finger the prankster no matter what forwarding was in place. Joe Konstan konstan@cs.berkeley.edu ------------------------------ Date: Thu, 6 Aug 92 19:17:25 PDT From: Jong Subject: Re: computer scoring at olympics I would like to think that a user-interface problem, not judging incompetence or favoritism, was the cause of the shocking loss by the US boxer. In the third round of the fight, with the score tied at 2-2 (an obvious problem right there), the German threw a punch that missed, and the American landed a counterpunch that split the German's eyebrow open. The German was awarded a point! How did this happen? Each judge has a box with two levers, one for each boxer. If the boxer in red lands a punch, the judge presses the left lever; if the boxer in blue lands a punch, the judge presses the right lever. Now: The judges watch the fighters stalk each other, circle, and throw combinations. They press the left lever -- no, the right! Too late. I think the judges all pressed the wrong lever. ------------------------------ Date: Fri, 7 Aug 1992 10:26:46 -0600 From: mcclella@yertle.Colorado.EDU (Gary McClelland) Subject: Re: computer scoring at olympics (RISKS-13.69) Several RISKS contributors have correctly noted that the problem with the computerized scoring system used for Olympic boxing is not the computer but rather the button-pressing speed of the judges and the scoring rules that were implemented in the program. The computer RISK is that electronic implementation of complicated scoring systems, systems which would not be feasible without computers, allows scoring rules to be used whose consequences are not well understood. These new scoring systems often seem reasonable on paper but turn out to have surprising consequences. I'll bet boxing officials were surprised (embarrassed?) to learn that all judges could score a fight in favor of Boxer A but that the majority-rule-per-punch rule could give the decision to Boxer B. The larger RISK is that implementations of "electronic town meetings" and telephone voting will allow the use of creative scoring systems for electing candidates and making policy decisions. Without extensive forethought, such computerized voting systems will inevitably produce unexpected results with more serious consequences than who receives boxing medals. There need not be surprises. There is a large literature in the field of public choice on the formal analysis of voting and scoring rules. Kenneth Arrow won the Nobel Prize in Economics for, among other things, proving that if there are three or more options [not a problem for Olympic boxing] then it is impossible to have a scoring system without unpleasant surprises such as being manipulable and producing intransitive choices. Since then the search has been on for finding voting systems that have the fewest problems and a large array of analysis tools are available. The boxing officials ought to have consulted experts in the field of public choice as well as computer experts. Perhaps they did. The boxing rules may not be all that bad; they have a remarkable similarity to the rules NASA uses to resolve disagreements among on-board computers and NASA did consult with the public choice experts. However, in the boxing case, it is easy to show that conservative judges [these may not necessarily be the worst judges as alleged in the recent case] have a disproportionate impact because it is more likely that their votes will be decisive in forming the majority on any given punch. The punchline is that computers may allow us to get into kinds of political trouble with fancy scoring rules that would not have been possible with paper-and-pencil systems which are forced to be simple. Gary McClelland Univ of Colorado mcclella@yertle.colorado.edu ------------------------------ Date: Fri, 7 Aug 92 16:27:27 +0200 From: anton@mips.complang.tuwien.ac.at (Anton Martin Ertl) Subject: Sweet Old Things and User Interfaces (Re: RISKS-13.70) Ed Ravin (elr%trintex@uunet.uu.net) and Steve Summit (scs@adam.mit.edu) hope that the next generations will have less problems with (the user interfaces of) machines due to childhood training at Nintendos etc. I doubt this: I notice that I become more impatient the older I get. I spent countless hours learning the tricks of my programmable calculator. Nowadays I am too impatient to read the manual of my video recorder. When in ten years they force me to use ATMs, I will probably even be too impatient for learning that, especially if there are people waiting in the line (and it does not matter that learning the system is the fastest way to get it done). As an analogy, we have had forms since the invention of bureaucracy, but they still confuse us. M. Anton Ertl anton@mips.complang.tuwien.ac.at ------------------------------ Date: Fri, 07 Aug 92 10:16:23 -0400 From: kennykb@dssv01.crd.ge.com Subject: Re: Mr. C. Baggage, ... (Geoff Kuenning) In RISKS-13.70, Geoff Kuenning tells the story of a Mr. Cabin Baggage (actually a violoncello) having a ticket on an airline flight. Having to ticket cabin baggage that way is a potential RISK to a search and rescue party in the event that the airplane crashes, since if the ticket is used, the passenger list will show one more soul on board, and the rescuers will be looking for another potential survivor. It would be a tragedy if a rescuer someday lost his life trying to find Mr. Stradivarius Cello. I know that I've had cabin baggage successfully ticketed by United without having to come up with a fictitious name; some reservation systems do it right. But musicians seem to get into this type of trouble. The duo-pianists Stecher and Horowitz once arrived at the airport to find that the rear row of seats had been removed from the aircraft to accommodate the stretcher -- they'd been booked as `Stretcher patient, Horowitz!' [When dealing with computerized systems, we must be forewarned that we need to be forearmed. But for pianists, four-armed can be four-handed on one keyboard or duo-piano, on two. But the absence of seats cannot be forewarmed. PGN] [Incidentally, since I am already drifting in relevance (too much flying?), John Levine (johnl@iecc.cambridge.ma.us) noted that a professional cellist friend of his regularly buys a seat for his cello, but the airlines won't let the cello join a frequent flyer program. It would probably do violins to their computer system. At any rate, this is certainly enough for this topic... Thanks for your indolcence. PGN] ------------------------------ Date: Thu, 6 Aug 1992 15:33 MST From: "stapleton@misvax.mis.arizona.edu"@Arizona.edu Subject: Information Age course at Georgetown For those in the greater Washington DC area, I will be teaching a course in Georgetown University's continuing education program, surveying issues arising from our entry into the "Information Age." The course description is below, and it runs for eight Thursday evenings. Contact the School of Summer and Continuing Education at Georgetown for further information (and forward this note to others if you like). Ross * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ISSUES FOR THE INFORMATION AGE This course will address issues of the "Information Age" for a nontechnical audience, i.e., how computers and computer-based information and systems are transforming the world around us. What does it mean to say that "information about money is as valuable as money itself?" Many companies do nothing more than broker information, as an increasingly larger percentage of the U.S. economy. But where ought the boundary between commercial profit and personal privacy be drawn? Lotus Development Corp. cancelled its plans to market a database on consumers in the face of protests from those it would have monitored, and across the U.S. "caller ID" technology is facing severe scrutiny from all sides. In the wake of the failed Soviet coup, a U.S. communications company took out a full-page ad to congratulate Soviet citizens who, "armed with nothing more than information...saved the day." News of the Tiananmen Square massacre came to us out of China by way of portable satellite dishes and the fax machine. Information systems are making life more efficient, but never before has it been possible for a simple computer glitch to cause a billion dollars worth of damage--twice in 1991 software bugs crippled large portions of the U.S. telephone system, and a Cornell graduate student's program shut down tens of thousands of networked computers in 1988. [WELL, Cliff Stoll estimated 2,600 of the estimated 6,000 BSD Unix systems. PGN] The legal profession is scrambling to apply yesterday's laws to new realities, and "artificial reality" has been used in court testimony, while the FBI lobbies to make digital telephones easier to wiretap. What do we have to fear from "hackers?" Does computer crime pay? Readings will be provided, taken largely from the current press, to serve as background and focus for discussion. Dr. Ross Alan Stapleton is a science and technology analyst with extensive experience studying computer and information technologies in the former USSR and Eastern Europe. 8 sessions, Thursday evenings, 7:45 to 9:15 p.m., September 24 through November 12, 1992. ------------------------------ Date: Thu, 6 Aug 1992 12:59:17 -0700 From: pomeranz@nas.nasa.gov (Hal Pomeranz) Subject: World Conference on Network Administration and Security CALL FOR PAPERS AND PRE-ANNOUNCEMENT The 1992 World Conference On Network Administration and Security November 30 - December 4, 1992 Washington, DC THEME: Practical solutions for cost-effective network administration and security in a UNIX environment. ELIGIBILITY: Network administrators, system administrators, security administrators, technology managers, computer installation managers, and their staff. In addition, a limited number of places are available for staff members from organizations that offer off-the-shelf software and hardware products that support network management and security. LOCATION: Ramada Renaissance Techworld Hotel, 919 9th Street NW, Washington, D.C. 20019, (202) 898-9000 CONFERENCE DATES: Tutorials: November 30- December 1 Technical Sessions: December 2- December 4 INFORMATION: For pre-registration materials, send mail to: Program Chairman, Alan Paller, Conference Office, 4610 Tournay Road Bethesda, MD 20816 or send email to paller@fedunix.org. HOST ORGANIZATION: The Washington Area UNIX Users Group and the Federal Network Administration Council. CONFERENCE SPONSOR: the Open Systems Conference Board, a not-for-profit educational organization dedicated to removing the barriers to widespread adoption of UNIX and Open Systems. WHY YOU SHOULD PARTICIPATE: The demands of mission critical applications are driving the need for network innovation at an amazing pace. New technology and new standards promote confusion and interoperability problems while at the same time providing much needed connectivity and increased bandwidth. Cutbacks have forced fewer people to provide more service with less money. These challenges are particularly apparent and frustrating in the government agencies (both in the US and abroad), universities, and companies which have been in the vanguard of the move to open systems and networks of UNIX computers. This conference is designed to identify the current state of the art for cost-effective network administration and security so that the techniques and tools used by the most effective managers can be adopted by those still looking for solutions. Peer-reviewed papers will be complemented with invited papers plus "Ask the Experts" sessions where you'll find practical answers to your questions. "Best Of The Net" session where you'll learn which free programs available from the net are most useful. "Tips and Techniques" sessions in which conference attendees can share, in 5-minute presentations, their favorite techniques for solving recurring problems. These sessions are run as moderated BOFs with all conference attendees being asked, in advance, to contribute if they choose. "Ask OSF" session where you can learn from the people who brought you DCE. Informal Birds Of A Feather sessions in the evening to expand the sharing time. Please send your suggestions for topics with your registration. In addition, the Monday-Tuesday tutorials will be taught by several of America's top-rated instructors. Tutorial topics include TCP/IP and UNIX Network Programming, UNIX Security, OSF DCE and DME, UNIX Fundamentals, UNIX Internals, UNIX System and Network Administration (Basic and Advanced courses), and Perl Programming. ********************* ** CALL FOR PAPERS ** ********************* Papers are being sought for the technical conference from network administrators, system administrators, security managers, consultants, academics, and hardware and software developers. You don't have to have made a major breakthrough to have your paper accepted. The delegates will be looking for good problem definitions and practical solutions. And your presentation does not have to be long. You may choose a 15, 30, or 45 minute time slot. IMPORTANT DATES FOR SUBMISSION: Abstracts Due: September 14, 1992 Notification of Acceptance: October 12, 1992 Camera-Ready Papers Due: November 16, 1992 FORMAL REVIEW: Papers that have been formally reviewed and accepted will be presented during the conference and will be published in the conference proceedings. The Review Committee is composed of experts on network administration and security along with managers of large installations and architects from the vendor community. Among the people invited to serve on the Review Committee are Matt Bishop (Dartmouth), Michele Crabb (NASA Ames Research Center), Richard Stevens (author of several best selling books on Network and UNIX Programming), Marcus Ranum (Digital Equipment Corporation), Jonathan Gossels (OSF), and Bruce Hunter and Rob Kolstad (well-known columnists). The committee will decide whether your abstract addresses important challenges (large or small), whether your approach seems promising, or whether your abstract should be accepted for any other reason. TOPICS: Please feel free to submit abstracts on any topic. The list provided below may help prompt some ideas: 1. Managing heterogeneous networks 2. Policies and procedures on the network 3. Security policies 4. Network security monitoring 5. Network monitoring and performance testing 6. Training and education 7. Techniques for dealing with users 8. Networked backup schemes 9. Distributed mail systems 10. Domain Name Service configuration 11. Distributed console access 12. OSF's DCE and DME 13. Off-the-shelf tools 14. Tools you don't like and why ABSTRACTS: A good abstract will by 500 to 1,500 words in length and include the following: 1. A description of the problem(s) and its importance. 2. Your solution including details of how it worked. If this is work on emerging technology, try to show what the expected impact will be. If your solution is based on commercial hardware or software tools, name them. Abstracts from vendors are welcome, but should not be sales pitches. 3. Data on how well it works: before/after comparisons, direct savings, trade-offs, etc. 4. Lessons learned and what you might have done differently. Please also provide the following information about the author(s): name, title, organization, daytime telephone, surface mail address, email address (please), FAX if possible. Finally, tell whether you want a 15, 30 or 45 minute time slot for your presentation. WHERE TO SEND YOUR ABSTRACTS: Technical Program Chairman Hal Pomeranz NASA Ames Research Center M/S 258-6 Moffett Field, CA 94035-1000 Questions or abstracts (PostScript or ASCII) may be submitted via email to pomeranz@nas.nasa.gov. [Because many of our risks involve networking, it seems appropriate to include this item. On the other hand, as RISKS readers, you should be prepared to ask lots of nasty questions if you attend. PGN] ------------------------------ End of RISKS-FORUM Digest 13.71 ************************