Subject: RISKS DIGEST 13.50 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Sunday 17 May 1992 Volume 13 : Issue 50 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Food stamp computer misbehaves in Maryland (Joseph E. Richardson) Spelling checker advocates massive drug abuse (Randy Lindsey) Credit card databases prefer St. to zip codes (David C. Kovar) Risk of TRW Not Having Enough Information (S. Peter Loshin) Re: Free TRW Credit Report (R. R. Hauser) Yet more Software-in-the-Air scares (Simon Marshall) More on the F-22 crash: pilot error now blamed (PGN) Re: F-22 crash, cont'd. (Daniel P. Johnson, Larry, Bob Rehak) Final Announcement for IFIP/Sec '92 (Guy G. Gable, Carlos Delgado Kloos) FTC Newsletter Volume 9 (FTCS-92 + workshop on Fault-Tolerant Par.Dist.Sys.) 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. 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, 13 May 92 09:43:21 EDT From: joseph@bse.com (Joseph E. Richardson) Subject: Food stamp computer misbehaves in Maryland Food Stamp Computer Clogs in Md. -- Overloaded System Causes Long Lines By Retha Hill - Washington Post Staff Writer [Washington Post, 13 May 1992] Maryland food stamp clients using a new electronic benefit system were unable to buy groceries [on 6 May 1992 ] after the state-of-the-art computer system failed, causing long lines at hundreds of stores in the state. The system, which the U.S. Department of Agriculture has said it plans to use as a model for the rest of the coutry, became overloaded for the second time in a month and shut down for about two hours as hundred, and possibly thousands, of recipients tried to use their plastic benefit cards to make purchases. Typically, the first few days of the month are heavy shopping days because that is when clients receive benefits. The system "reached a point where it clogged," said Helen Szablya, a spokeswoman for the Maryland Department of Human Resources. She said that she did not know if other benefits that are encoded on the plastic cards, such as welfare payments and child support, were affected. About 31,000 Maryland residents in Montgomery, Prince Georges and Cecil counties and Baltimore now have the cards. Clients in Baltimore, Howard and Anne Arundel counties are to get the cards by mid-summer, and eventually 200,000 recipients will use them. Szablya said the electronic benefit transfer system is better than the old method [Electronic systems are always "better", aren't they? :-) JR] of issuing coupons to clients and said that problems are going to happen because it is the first of its kind in the country. The system last stopped working April 11 for about two hours. "It's going to have a few blips. We are happy with the fact that we haven't had more," she said. Shoppers and grocery store officials complained of long lines and carts loaded with groceries abandoned as checkout stations. Food stamp clients were given $50 vouchers to make purchses, but cashiers had to call a toll-free number to verify each transaction. "We just think it's unfortunate that this happens and that it inconveniences our customers," said Mitchell D. Herman, senior vice president for corporate affairs for Shoppers Food Warehouse. [How true, how true. -- JR] Joseph E. Richardson, Berard Software Eng., Inc., 101 Lake Forest Blvd, Ste 360, Gaithersburg, MD 20877-2611 (301) 417-9884 joseph@bse.com ----------------------------------------------------- Date: Tue, 12 May 92 12:57:56 PDT From: Randy Lindsey Subject: Spelling checker advocates massive drug abuse It is not uncommon in large companies to require an annual "payout", in which each employee picks up their paycheck in person, displaying ID. I think this is to guard against payroll padding. At the facility where I'm doing a project, all 1,500 employees received a memo ordering them to report to the cafeteria for their annual "peyote". Peyote appeared several times in the memo, and even in the title line! Eventually one of my colleagues ran "payout" through the spelling checker, and sure enough it suggested "peyote" as the alternative. Perhaps the spelling checker writers are junior staff with closer ties to their college counter-cultural days than to corporate terminology... Randy Lindsey ------------------------------ Date: Wed, 13 May 1992 09:38:32 -0400 From: "David C. Kovar" Subject: Credit card databases prefer St. to zip codes About two years ago, I started getting some credit card statements a few days late. All of them had an incorrect zip code and the post office had corrected them by hand and resent them. I called up the offending credit card companies and tried to correct the problem. Two of them corrected it, one of them couldn't/wouldn't. I eventually cancelled the card belonging to the bank that couldn't get the address right. Well, for various reasons, I've taken my time in paying off the account, so I still get statements from them, still with the wrong zip code. Apparently the Post Office is cracking down on bad zip codes because both AT&T and this particular bank called me up this week to verify my address. About three months ago I finally figured out what I thought was the problem. I live on Broadway, and my zip code is 02174. People frequently want to know if it is Broadway Rd, Broadway St, Broadway Ln? It's just Broadway. All of the offending statements had my address as Broadway St, and my zipcode as 02111. Someone's database, somewhere, mapped Broadway St. to a 02111 zip code and, if the zip code was corrected but the street address wasn't, it would modify the zip code again to what it believed was correct. So, I explained all this to the person from the bank, had her change the street address and the zip code, and we'll see if it works. If anyone has any more information on this problem, I'd be interested in hearing about it. I don't have enough time at the moment to track down which database these guys are using. If anyone is curious, the bank is Chase Manhattan. -David Kovar [We have had a spate of similar tales of woe in the past. In this case, please send responses to David. If anything exciting comes up, I am sure he will share it with us. PGN] ------------------------------ Date: Tue, 12 May 1992 16:20:00 EDT From: "S. Peter Loshin" Subject: Risk of TRW Not Having Enough Information This might be of some interest, as I recently was denied credit (temporarily) due to inability of the credit grantor to verify my address. I cleared that up by sending copies of utility statements to the credit grantor, but out of curiosity I took advantage of the free copy of the TRW credit report that caused the denial. Maybe I'm just different - I use my middle name and don't use my given first name, and I use a PO box for as much correspondence as possible - but the report was VERY sparse. My address was three years out of date and they had no info on my employer or on any of the credit cards that I customarily use. There were NO negative reports from any of the institutions listed, and only one neutral report. Overall, I was fairly pleased with the lack of complete information on me - unless it was all a ruse to lull me into a false sense of security about my privacy. Peter Loshin | peter@draper.com | 555 Technology Sq Cambridge MA 02146 ------------------------------ Date: Fri, 8 May 1992 13:03:45 -0500 From: rrh@gabriel.b11.ingr.com (R. R. Hauser) Subject: Re: Free TRW Credit Report (RISKS-13.46 and 47) Three credit reporting agencies exist (to my knowledge): TRW, Transunion (Merchants), and Holloway Credit Bureau. Since I happen to have my credit report in hand (Holloway) which lists address/phone for Transunion and TRW, I called TRW long-distance and spoke with a representative about the free credit report. She gave me this number 1-800-392-1122. The risk seems low IF you do the following rather than trusting some bulletin board posted P.O. Box address. Go to a local credit bureau and get your report (~$10) or borrow someone's to get valid address/phone for TRW. Call and inquire. Since this may cost a bit you could call the 1-800 number I got from TRW and wait until a representative comes on. The risk in trusting this posted phone number can be reduced by waiting until a person comes on rather than trusting a computerized voice. When questioned, the TRW representative (how knowledgeable?) implied that _establishing_ any kind of credit had nothing to do with this service. Also, a bill is not necessary ... just anything with the name-address linkage. Hmmm... Seems that the risk of someone easily obtaining your credit report from TRW may be higher now. R. R. Hauser DOMAIN: hauserr@infonode.ingr.com ------------------------------ Date: Sun, 17 May 1992 16:06:12 +0000 From: Simon Marshall Subject: Yet more Software-in-the-Air scares Here are yet more stories concerning flight control software going wrong in commercial passenger aircraft. It is taken from the front page of the UK ``Sunday Telegraph'' May 17, 1992, a so-called ``quality newspaper''. The article is quoted in its entirety. Air scares over computers", Robert Matthew and Christopher Elliott. A spate of software errors forcing planes into sudden changes of speed and direction has rekindled concern about the use of computers by the aircraft industry. An internal British Airways document discloses 10 serious incidents involving computer errors in January, including: - January 13, when the flight-management system on a Boeing 747-400 from Washington to Heathrow suddenly ordered a speed reduction of 50 knots. - January 26, when a Boeing 747-200 flying to Gatwick from Barbados experienced a sudden increase in thrust due to a software error. - January 27, when a Boeing 747-200 from Manchester to Islamabad suddenly pitched upwards. The crew had to turn off the auto-pilot to bring the aircraft back into normal flight. Other computer errors have led to navigational deviations and to the auto-pilot wandering from the correct route. British Airways said action had been taken to rectify the problems, which did ``not present any threat to the safety of the aircraft''. A spokesman added that the software had Civil Aviation Authority approval and had been tested by BA for more than 100 hours before entering service. But leading computer experts are worried that there is no adequate way of testing the enormously complex software routinely used by the aircraft industry. The British Computer Society will call this week for international standards on the design of safety-critical software, and for special qualifications from [sic] those working the field. Professor John Cullyer, of Warwick University, chairman of the society's Safety Critical Systems Task Force, said: ``We haven't for enough highly educated and trained checkers. We actually know what we ought to be doing but we just don't have enough men and women sufficiently qualified.'' Professor Bev Littlewood, of City University, London, has told the American Association for Computing Machinery that the aircraft industry could not substantiate claims for computer reliability." There are couple of things that made me post this article. Firstly, the number of incidents - 10 in a single month with BA. This implies that software is not working in normal, routine, flying conditions, where you might expect the behaviour of such systems to be correct. There are no suggestions in the article that "the pilot flew to low", "the pilot applied full thrust too late", and so on, but that the systems themselves failed to perform correctly in normal conditions. The second is that at least some of the "software errors" were within auto-pilot control systems (it may be all, the article is not clear - maybe BA does not fly any fly-by-wire aircraft anyway, I don't know). These systems are, as I understand it, typically not used for takeoff or landing, but to fly from A to B once airborne. Given the number of years these systems have been around, it worries me to think that these relatively simple systems fail at this frequency, while fly-by-wire, with its increased complexity and the increased reliance upon those systems for the safety of the aircraft, is now being applied to commercial aircraft. The third is that the software had "CAA approval", as if this is meant to make us feel any better, and that it had been tested by BA themselves (not the CAA), for "100 hours before entering service". This does not seem particularly rigorous to me! The fourth came with the old call for qualifications for those working in safety-critical software design; lack of suitably trained people. Maybe the CAA and aircraft manufacturers should be training their software personnel? Simon Marshall, Dept. of Computer Science, University of Hull, Hull HU6 7RX, UK Email: S.Marshall@Hull.ac.uk Phone: +44 482 465181 ------------------------------ Date: Thu, 14 May 92 12:10:56 PDT From: "Peter G. Neumann" Subject: More on the F-22 crash: pilot error now blamed (RISKS-13.46) Those of you who read RISKS-13.46 noted that computer software seemed to be implicated in the crash of the only flying F-22 prototype. A later report now suggests pilot error. As usual, the real causes are probably some combination of a poorly designed human interface, software design and implementation problems, hardware-software system response delays, and pilot problems (training, complexity, etc.). An AP report somewhen during 11-13 May (while I was in D.C.) had these statements (starkly excerpted): A new Air Force videotape of the crash, shot from the plane's side, shows the radar-eluding aircraft with its landing gear down as it nears the runway at the California base. The landing gear is then drawn back up about the same time the afterburners go on. The plane then bucks wildly before hitting the pavement, sliding several thousand feet and burning. [...] Congressional sources, who requested anonymity, said the Air Force now suspects that pilot error caused the crash. A final report is not expected for several weeks after the Air Force completes its investigation. Air Force Chief of Staff Merrill McPeak [quoted in RISKS-13.46 as hoping that it was software, because that would be "relatively straightforward" to fix] testified before Congress he suspected the crash was the result of a mechanical malfunction in the plane's computer system. "I am utterly convinced personally that this is a very meritorious design," said McPeak [...]. The Air Force chief of staff said he saw no need to change the program, which calls for 650 of the fighter planes to become operational in 2002. ------------------------------ Date: Mon, 11 May 92 09:08:43 CDT From: drdan@src.honeywell.com Subject: Re: F-22 crash (Watson, RISKS-13.47) I haven't entered this discussion because there are a lot of people with more solid credentials, but there are some elementary points to be made. If I get my ears pinned back, so it goes. When something goes seriously wrong in a control system, a common result is that the system goes unstable. The wild motions of the tail are due to positive feedback between the control system, the pilot, and the aircraft responses. As to what caused the instability, it can be almost anything, software error, design error, hardware failure. A likely explanation would be that the aircraft had some unexpected aerodynamic characteristics in the low altitude, high weight regime that it was flying (to be expected in a prototype aircraft, that's how test pilots earn their pay). The result was a "PIO" (Pilot-Induced Oscillation). One can view this as a software error since the fix is to change the software to allow for the unexpected dynamics, or as a pilot error since he was part of the positive feedback loop, but it is better to classify it as a design problem since one of the goals of the design is to avoid creating a situtation in which a PIO is possible. Daniel P. Johnson, Honeywell Systems and Research Center, MN65-2500, 3660 Technology Drive, Minneapolis, MN 55418 drdan@src.honeywell.com 612-782-7427 ------------------------------ Date: Wed, 13 May 92 13:23:50 MDT From: Subject: Re: F-22 crash, cont'd. (Watson, RISKS-13.47) I recorded the same footage and played it several times in slow motion to observe the porpoising motion of the ship. A flash from the cockpit (assumed to be the ejection system) could be seen at the end, just before the ship kissed the runway. I believe you'll find that large, rapid movements of control surfaces are a common feature of modern fly-by-wire control systems for fighters. It is necessary because of the complex flying modes involved, particularly on take-off and landings, which limit control surface effectiveness. Special [non-linear] servo modes are involved. Such problems are likely to be exacerbated on the YF-22 which is probably an unstable design to begin with (to achieve maximum maneuverability) stabilized by the computerized control system. > Odd that the software should be seen as a possible cause of the crash, ... You can almost bet that the pilot was NOT the problem. The handful of people who can qualify as test pilots are not the sort to make the mistake of extreme pilot input. Many have been known to cooly report problems and symptoms in the last few seconds of their lives. As for software, someone observed that if buildings were constructed like programs, the first woodpecker to come along would destroy civilization! (Still, I would expect this particular control program to be a state of the art example of good software..) > I though most aircraft could dump/vent excess fuel, you don't have to be at low > altitude to do this, do you? That's another problem. Suppose we suddenly reduce the flight weight of a fighter by a significant percentage? It seems reasonable that the ship might need to be retrimmed quite a bit after a major fuel dump, so it is probably not prudent to do it at low altitudes. Larry ------------------------------ Date: Mon, 11 May 92 10:15 CDT From: Bob Rehak Ext. 3-9437 Subject: Re: F-22 an speaking out of turn (Watson, RISKS-13.47) All well designed aircraft have a fuel jettison system for dumping fuel. Most fuel is dumped at higher altitudes so that it evaporates before it hits the ground; however, if your aircraft is in distress and is at a low altitude and you are someplace isolated like the F-22 was, who cares if you jettison the fuel. The claim that the F-22 was doing these low altitude high speed passes to reduce its fuel load so it could land with a greater saftey margin sounds bogus to me. If the aircraft was in distress these aren't the kind of maneuvers a prudent pilot would be doing. Also, what about the risks of speaking out of turn. I feel Gen. McPeak's statements are a bit premature and could bias the accident investigators. I don't how many times I have gone done the wrong path in tracking down a software problem because I was biased by the information given to me by a software developer (who's judgement, expertise, ect. I trusted). Moral of the story, start at the beginning and follow your judgement not theirs. If the investigators were to think: Hey, let's look at the s/w and computers because that's where the Gen. says the problem is... well you know what happens next. Bob Rehak, DBA At Large, A20RFR1@MVS.CSO.NIU.EDU ------------------------------ Date: Sat, 16 May 92 07:24:36 SST From: "Dr. Guy G. Gable, IFIP/Sec '92 Program Chair" Subject: Final Announcement for IFIP/Sec '92 THE IFIP/SEC'92 8th INTERNATIONAL INFORMATION SECURITY CONFERENCE May 27-29, 1992 Raffles City Convention Centre Singapore [FULL TEXT IS FTPable from CRVAX, cd RISKS: , file IFIP.1992 , or get it from Guy Gable. PGN] ------------------------------ Date: Thu, 7 May 92 19:47:27 +0200 From: cdk@dit.upm.es (Carlos Delgado Kloos) Subject: IFIP'92 registration form [FULL TEXT IS FTPable from CRVAX, cd RISKS: , file IFIP.1992 , or get it from Carlos Delgado Kloos. The DEADLINE FOR EARLY REGISTRATION DISCOUNT is 25 May. NEXT MONDAY!!! PGN] ------------------------------ Date: Thu, 23 Apr 92 11:34:32 CDT From: ftcsnews@snowy.crhc.uiuc.edu (FTCS NEWS) Subject: FTC Newsletter Volume 9 ELECTRONIC NEWSLETTER ON FAULT-TOLERANT COMPUTING VOLUME 9, APRIL 1992 EDITOR: Prith Banerjee, University of Illinois CONTENTS: (Each item can be searched by keyword ITEM and separated by a line of =========) 1. GENERAL INFORMATION AND REGISTRATION FOR FTCS-92, 7-10 JULY 1992, The Lafayette Hotel, Boston, Massachusetts USA 2. ADVANCE PROGRAM FOR FTCS-92 3. WORKSHOP ON FAULT TOLERANT PARALLEL DIST. SYS. Campus Center Hotel, Amherst, Massachusetts USA, July 6-7, 1992 4. CALL FOR PAPERS (HICSS-26) DEADLINE EXTENSION 5. COURSE ANNOUNCEMENT (FAULT-TOLERANT DISTRIBUTED COMP.) [Full text of this issue can be found on CRVAX, cd RISKS: , file FTCSNEWS.9 , or from ftcsnews@snowy.crhc.uiuc.edu (FTCS NEWS). The deadline for discount registration for FTCS-92 is 25 June. PGN ------------------------------ End of RISKS-FORUM Digest 13.50 ************************