Subject: RISKS DIGEST 12.19 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Wednesday 28 August 1991 Volume 12 : Issue 19 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Phone Fraud (Ed Andrews summarized by PGN) (Assumed) False Alarm at Nuclear Plant (Rodney Hoffman) O, Oh, what a difficult name (Gene Spafford) Programs Pester Public Policy People (Jeffrey Sorensen) Re: 13 Aug 91 NY Nine Mile Point 2 Nuclear Plant Incident (Steve Bellovin) Re: Ada beats C++ according to the DoD (Brinton Cooper) Re: Unwarranted equivalence assumptions (Brinton Cooper) Re: TCAS sees ghosts (Steve Jay, Lars-Henrik Eriksson, Keith Hanlan) pugwash.dcs.ed.ac.uk goes nova too (John Butler) NIST High Integrity Lecture Series: talk by Laszlo Belady (Laura Strigel) 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 ignored! REQUESTS 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: Wed, 28 Aug 91 10:27:41 PDT From: "Peter G. Neumann" Subject: Phone Fraud Abstracted by PGN from an excellent article in the New York Times (28Aug91), Theft of Telephone Service from Corporations is Surging, by Edmund L. Andrews Telephone fraud is reaching epidemic proportions, with some companies getting billed for hundreds of thousands of dollars in bogus calls. Stolen credit cards and line tapping are old techniques. The new craze involves cracking into switches and PBXs (private branch exchanges). ``It is by far the largest segment of communications fraud,'' said Rami Abuhamdeh, an independent consultant and until recently executive director of the Communications Fraud Control Association in McLean, Va. ``You have all this equipment just waiting to answer your calls, and it is being run by people who are not in the business of securing telecommunications.'' Mitsubishi International Corp. reported losing $430,000 last summer, mostly from calls to Egypt and Pakistan. Procter & Gamble Co. lost $300,000 in l988. The New York City Human Resources Administration lost $529,000 in l987. And the Secret Service, which investigates such telephone crime, says it is now receiving three to four formal complaints every week, and is adding more telephone specialists. In its only ruling on the issue thus far, the Federal Communications Commission decided in May that the long-distance carrier was entitled to collect the bill for illegal calls from the company that was victimized. In the closely watched Mitsubishi case filed in June, the company sued AT&T for $10 million in the U.S. District Court in Manhattan, arguing that not only had it made the equipment through which outsiders entered Mitsubishi's phone system, but that AT&T, the maker of the switching equipment, had also been paid to maintain the equipment. For smaller companies, with fewer resources than Mitsubishi, the problems can be financially overwhelming. For example, WRL Group, a small software development company in Arlington, Va., found itself charged for 5,470 calls it did not make this spring after it installed a toll-free ``800'' telephone number and a voice mail recording system machine to receive incoming calls. Within three weeks, the intruders had run up a bill of $106,776. to US Sprint, a United Telecommunications unit. The article goes on to document the experiences of WRL, pirate call-sell phone operations, voice-mail cracking, etc., familiar to RISKS readers, and discusses the possibilities of blocking calls by area, shutting down out of hours, verifying callers (!), monitoring for unusual traffic, etc. In the past, long-distance carriers bore most of the cost, since the thefts were attributed to weaknesses in their networks. But now, the phone companies are arguing that the customers should be liable for the cost of the calls, because they failed to take proper security precautions on their equipment. [...] Consumertronics, a mail order company in Alamogordo, N.M., sells brochures for $29 that describe the general principles of voice mail hacking and the particular weaknesses of different models. Included in the brochure is a list of ``800'' numbers along with the kind of voice mail systems to which they are connected. ``It's for educational purposes,'' said the company's owner, John Williams, adding that he accepts Mastercard and Visa. Similar insights can be obtained from 2600 Magazine, a quarterly publication devoted to telephone hacking that is published in Middle Island, N.Y. It's a good article for those of you whose telephone systems are being cracked (but good for crackers as well!)... ------------------------------ Date: Wed, 28 Aug 1991 08:44:37 PDT From: Rodney Hoffman Subject: (Assumed) False Alarm at Nuclear Plant NUCLEAR PLANT'S SIREN WAILS BY MISTAKE San Juan Capistrano - A high-decibel siren warning of a major accident at San Onofre nuclear power plant sounded by mistake Sunday, Southern California Edison Co. reported.... [T]he siren ... went off during the late afternoon and was reported to Edison about 5:30 pm by Orange County emergency management workers. By the time a repair crew reached the siren, it had stopped operating. [!] ...[T]he warning device was disconnected [!!] and an investigation begun into why it went off. Edison, which operates the San Onofre Nuclear Generating Station, received no complaints from the public about the mishap.... The siren, which warns of a nuclear accident, is part of a network of 50 such devices in [nearby towns]. - - - - - - - This was a brief item in the 26 August 1991 `Los Angeles Times.' No explicit mention is made of computers, but this seems relevant to RISKS on several counts. Unfortunately, the story does not tell why Edison was and remains so certain that it was a false alarm; I presume that the other 49 sirens were silent. As for "no complaints from the public," most people probably assumed it was just a particularly obnoxious car alarm. Perhaps the sirens should be replaced by voice, shouting, "Major nuclear accident underway." That would probably get some public attention! ------------------------------ Date: Wed, 28 Aug 91 11:10:06 EST From: Gene Spafford Subject: O, Oh, what a difficult name From: The Associated Press (and sharply abridged by PGN) WASHINGTON -- Oh, woe is O. For months, Stephen O has been hassled by credit card companies. It's not because he's a bad credit risk. It's simply that his last name is too short. Twice the 23-year-old South Korean native has applied for new credit cards, and twice he's been turned down. The banks say their computers cannot recognize a single-letter last name. His automobile finance company says he's "S.O. Stephen." The computer at the Virginia Division of Motor Vehicles says he's OO, which stymied his efforts to get car insurance for a year. To make matters worse, the computer at the Credit Bureau Inc., which furnishes merchants with individual credit references, insisted that O was nobody, even though he has carried American Express and Visa cards since he was a college student. Instead, the credit bureau listed him as "Ostephen," which confused everybody. [... He has now changed his name to Oh. ...] Since he was a kid, being an O has been both embarrassing and amusing. "I always hated the first day of school," he said. "The teacher would call the roll through the M's and N's and then stumble over the O. `Is this a typographical error?' he'd ask, and I'd say, `That's me'." [...] [I guess he did not read The Story of O, by Pauline Reage. But, how about "O'O"? Computers would love it! PGN] ------------------------------ Date: Wed, 28 Aug 91 13:35:29 EDT From: sorensen@spl.ecse.rpi.edu (Jeffrey Sorensen) Subject: Programs Pester Public Policy People In the Aug 24, 1991 issue of _Science News_ p. 127 "Faulting the Numbers": A brief article discusses the topic of the accuracy of computer models when used as the basis for changes in social and tax programs. "A National Research Coucil panel warns that these estimates are...of unknown quality and may be seriously flawed." The problems are lack of objective measures for assessing the reliability and validity of the resulting figures. One example cited is the underestimate of the popularity of the individual retirement accounts which thus led to an underestimate of the subsequent revenue lost. "Arguing that detailed simulations...are important to the policy process, the panel strongly urges the government to allocate sufficient resources to improve the quality of current computer models used for making cost estimates." Whether this is a case of the government expanding to meet the needs of an expanding government is left as an exercise for the reader. The problem of bad statistics used as the basis for bad decisions has been with us alot longer than computers have. For some good examples check out: _Systems Analysis in Public Policy: A Critque_ by Ida R. Hoos Berkeley : University of California Press, 1983. Also in Science News: * "Greenhouse Snow: Melting the preconceptions" about the various different outcomes of computer models that raise questions about the feedback effect of melting snow: more heat -> less snow -> darker land -> more heat -> less snow... may actually turn out to be more heat -> less snow -> more clouds -> a little cooler -> more snow or even more heat -> less snow -> more radiation to space -> a little cooling * "Phone glitches and software bugs" says that the DSC equipment responsible for the June phone problems suffered from three faulty lines of code in a program with several million lines. (a 1E-8 error percentage :-) * "String and springs net mechanical suprise" gives details of a problem that has to be seen to be believed. A discussion of problems that are counterintuitive including Braess paradox which demonstrates that adding roads to a congested network can actually increase the amount of congestion. Also an electrical equivalent so that "when you add extra current carrying paths, less current flows." * And, the cover story, the risk free :-) buckyballs and fullerenes with about four and 1/2 pages dedicated to research in these new forms of carbon. Jeff Sorensen sorensen@ecse.rpi.edu (518) 276-8202 ------------------------------ Date: Tue, 27 Aug 91 20:27:49 EDT From: smb@ulysses.att.com Subject: Re: 13 Aug 91 NY Nine Mile Point 2 Nuclear Plant Incident Reassessed An AP wire story indicates that the problem was dead batteries in the backup power supply. The NRC has no standards for battery replacement, the manufacturer says change them every four years, and these were six years old. Utility officials blame unclear manuals, and say that the backup systems weren't wired the way the manual said they should be. Also worth noting is that the batteries weren't inspected on schedule. However, the inspection wouldn't have measured their charge level in any event. Some inspection procedure... ------------------------------ Date: Wed, 28 Aug 91 10:07:49 EDT From: Brinton Cooper Subject: Re: Ada beats C++ according to the DoD (Stoffel, RISKS-12.18) John F Stoffel reports on a set of US DoD studies purporting to show that "... the DoD mandated programming language Ada is superior in a variety of ways to its newer rival C++..." Of course, consider who conducted the studies: TRW anbd CMU's Software Engineering Institute, each of which have, no doubt, obtained millions of dollars in DoD contracts associated with the use and promotion of Ada. "Can you say conflict-of-interest, boys and girls?" "CTA Inc. looked at the productivity of the two languages based on actual projects and found Ada programmers on average produced 210 source lines per month while C++ programmers turned out 187 lines." Does this mean "More code is better code?" Perhaps it shows that Ada is less expressive than C++ and requires more source code to say the same thing. _Brint ------------------------------ Date: Wed, 28 Aug 91 10:12:34 EDT From: Brinton Cooper Subject: Re: Unwarranted equivalence assumptions (Koenig, RISKS-12.18) Andrew Koenig discusses four cases of "Unwarranted equivalence assumptions." His arguments make a lot of sense, but one is flawed. His fourth example is: `I'm sorry, Sir; but even if you are indeed the Ambassador, we can't let you into the Embassy building without a proper pass.' He argues, "Perhaps the Ambassador was appointed only a week ago, has been outside the country since then, and therefore hasn't had the opportunity to pick up the pass that has been waiting for him." Suppose the denial had been by computer: "Incorrect password: Login aborted." Would he argue that this might have been the *genuine* user who had forgot her password and that the "system" should have known better because the login was from site known to her office? In fact, both my hypothetical case and that of newly-appointed Ambassador Strauss are examples of *Authentication* systems. They must be left in place. Even if the State Department guard *knew* Ambassador Strauss personally, it was proper to deny him admission without a building pass. Who knows why the pass may have not yet been issued? Did anyone ever hear of Clark Clifford? _Brint ------------------------------ Date: Tue, 27 Aug 91 16:53:05 PDT From: shj@ultra.com (Steve Jay) Subject: Re: TCAS sees ghosts (Horning, RISKS 12.16) > Wahag defends Collins' quality control procedures, which were approved by > a team of FAA software experts. "We had a simple human error where an > engineer misclassified the changes in the software," he told SPECTRUM. > "It didn't show up in our testing because one of the essential elements was > absent: you have to have many, many TCAS-equipped airplanes in the sky," > as in the high-traffic-density areas where the ghost problem appeared. > > To prevent similar omissions, Collins now requires that a committee of > software engineers review changes before a program is released. "More than > one pair of eyes must review these things and make a decision," Wahag said. Am I the only one who sees a non sequitur here? "We didn't catch the bug because we didn't test it in realistic conditions, so next time we'll look at it harder before we release it." Seems like some folks don't learn real fast. Steve Jay, Ultra Network Technologies, 101 Dagget Drive, San Jose, CA 95134 shj@ultra.com ...ames!ultra!shj (408) 922-0100 x130 ------------------------------ Date: Wed, 28 Aug 91 09:06:36 +0200 From: Lars-Henrik Eriksson Subject: Re: FAA seems misled (Re: TCAS Sees Ghosts) >Not quite. TCAS is a backup system. It's a redundant backup. Primary >responsibility for "see and avoid" is with the pilot (FAR part 91). The air >traffic control system, with all it's eyes, ears, and radar exists to help the >pilot avoid situations that can develop into genuine emergencies. The "see and avoid" responsibility is only applicable in visual flight conditions. In instrument flight conditions, the pilot don't have any such responsibility (Obviously - since he cannot see much outside his own aircraft). Also, it is a fact that "see and avoid" doesn't work well with aircraft flying at high speed. Many investigations of midair collisions have shown that although the pilots had a theoretical possibility to see each others aircraft in time, the practical possibility was very slight. >... TCAS and air traffic control are at crossed purposes. TCAS gives >authority to the pilot, and ATC takes it away. ATC authorities (both FAA and those of other countries) have the legitimate concern that pilots will react unnecessarily to TCAS alerts and cause other incidents by doing unauthorised deviations. I understand that the TCAS technology and the procedures being applied when a TCAS alert occurs have developed to a point when this risk is at an acceptable level. Lars-Henrik Eriksson, Swedish Institute of Computer Science, Box 1263, S-164 28 KISTA, SWEDEN Phone (intn'l): +46 8 752 15 09 Internet: lhe@sics.se ------------------------------ Date: 28 Aug 91 11:17:00 EDT From: Keith (K.P.) Hanlan Subject: Risks of developer testing (was TCAS sees ghosts) The article on TCAS failure quoted by Jim Horning (RISKS 12.16) illustrates an deficient software development process: "The problem arose in the course of testing, because Collins engineers had temporarily disabled the program's range correlation function--a few brief lines that compare a transponder's current response with previous ones and discard any intended for other aircraft. Without this filter, the system can misinterpret a response as coming from a fast-approaching airplane." "After testing the systems, Collins shipped them to airline customers without re-enabling the range correlation." The flaw here is that the same group is doing development, testing, and "manufacturing" (loadbuilding). I'd suggest that if the CASE tool I work on uses indepentant testers and loadbuilders, an aviation safety device merits similar precautions. Designers must of course do their own testing but the code they submit to loadbuilders should be intended for production. The independent testers should only work with this "production" code. And the product should only be produced from the loadbuilder's software. Thus even if the designer accidently submits test code, the testers should detect the flaw and fail the software. And similarly, if the testers wish to insert faults, those faults can not get back into the production code. On a related note, inserting faults by changing code is never a good idea and this mistake clearly illustrates why. Let me add that when I refer to "independent" testers, I mean physically disjoint human beings. I, as a developer with intimate knowledge of the inner workings, *know* that if this test-case works then all these others will work as well. This is, of course, until Michelle comes along with her cunning pathogical special case. This happens time and time again. Finally, by "loadbuilding" I mean that the activity of configuration management, compiling, linking and installation. My apologies for using terms that may only have local meaning. Keith Hanlan keithh@bnr.ca Bell-Northern Research, Ottawa, Canada 613-765-4645 ------------------------------ Date: Wed, 28 Aug 91 12:57:36 bst From: jhb@dcs.edinburgh.ac.uk Subject: pugwash.dcs.ed.ac.uk goes nova too Followup to posting in RISKS DIGEST 12.17 from joe@montebello.soest.hawaii.edu (Joe Dellinger) 1 Aug 91 Well I guess we've located the newest way of keeping ourselves warm in the winter nights or at least gassing ourselves so we don't notice. We have (had) a Sun 3/110 with a Hitachi 15" LC monitor in a lab here. A week or so ago the occupants of the lab evacuated hastily complaining of a strong smell watering eyes, sore throat etc. I would describe the smell as similar to the sweetish smell you get around a badly ventilated clothing dry cleaners and would guess a halocarbon of some sort. We instantly blamed the air-conditioning units and went looking for coolant leaks. By this time the security services had been called and they in turn called in the Fire Brigade who threw us all out and did a thorough survey in full chemical isolation gear and breathing apparatus. It's not easy to locate the source of a smell in full gear and so it was well into the afternoon before someone noticed this monitor was still on and we traced it. If the smell had been the usual yukky smell you get off any torched electronics we'd have got it instantly - this was a new one on us. Culprit was what looked like a torodial transformer in the EHT side of the monitor which was sitting in a little puddle of plasticised slag. We have no idea what we've been breathing but the city Medical Officer has requested further tests and we are sending him an intact monitor plus the slagged transformer. This incident is still in progress here as we have yet to have any extensive talks with Sun but I'm posting this meanwhile as it appears there is a real safety risk. John Butler, Computer Science, The University of Edinburgh, Kings Buildings, Edinburgh EH9 3JZ UK Telephone: +44-(0)31-650-5181 ------------------------------ Date: Tue, 27 Aug 91 11:26:58 EDT From: Laura Strigel Subject: NIST High Integrity Lecture Series: talk by Laszlo Belady NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY COMPUTER SYSTEMS LABORATORY LECTURE SERIES ON HIGH INTEGRITY SYSTEMS The Engineering of Software for High Integrity Laszlo A. Belady Chairman and Director of the Laboratory Mitsubishi Electric Research Laboratories October 11, 1991, 2:00 p.m., NIST Green Auditorium Software is now paramount in determining the qualities of man-made and man-machine systems. Problems of integrated, networked information systems and of machinery in which software is the significant component are particularly acute. The design of these software-rich systems must be based on combined expertise in computers and in the application domain. This leads to design by teams of many experts whose efforts also need the support of information technology. A few emerging solutions, some still in the research stage, will be discussed, and the importance of technology infusion and education emphasized. The goal of the lecture series, open to the public free of charge, is to alert federal and industry managers, technical staff, and users of the issues they must be concerned with in the management of valuable information resources. FUTURE LECTURES: November 8, 1991: Early Error Prediction: Better Error Management and Improved Process Control; Dr. John Gaffney, Manager, Measurement and Economic Modeling, Software Productivity Consortium December 3, 1991: Toward a Routine Practice for the Engineering of Software; Dr. Mary Shaw, Professor of Computer Science, Carnegie Mellon University For further information contact: Dolores Wallace (301) 975-3340 or Laura Strigel (301) 975-5248. ------------------------------ End of RISKS-FORUM Digest 12.19 ************************