Subject: RISKS DIGEST 13.21 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 2 March 1992 Volume 13 : Issue 21 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Leap year strikes again (Lee Laird via Jaap Akkerhuis, Mark Brader, Rob Slade, Paul Eggert) Leap day liquor licence problem (Douglas W. Jones) Another Happy Story (Alan Wexelblat) Montreal Life Insurance company destroyed by computer errors? (Peter Deutsch) Post Office uses only 7 characters to disable my husband's ATM card (Christine Piatko) Not quite anonymous FTP (William Rucklidge) Virus news-bite omits crucial information (jcav) Scud vs Patriot (Peter G. Neumann) Re: More on the Airbus A320 (Pete Mellor, Peter Ilieve) 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 domain 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: Mon, 02 Mar 92 15:24:32 EST From: Jaap Akkerhuis Subject: Leap year strikes again The next complaint was sent to rec.radio.shortwave. jaap (jaap@research.att.com) From: Lee.Laird@f7009.n124.z1.fidonet.org (Lee Laird) Newsgroups: rec.radio.shortwave Subject: forwarded from Date: 28 Feb 92 22:41:00 GMT Article-I.D.: ocitor.699420553.F00002 Posted: Fri Feb 28 17:41:00 1992 Sender: FredGate@ocitor.fidonet thanks to the authors of Imail -- feb 29 has caused systems to crash worldwide since the mail tosser and handler does not recognize the date and locks up the system.. any outgoing dates with 29 feb also has that problem ... to overcome the problem and move the messages from my system i have had to set the date back and forward messages containing 29 feb .... PLEASE DO NOT SEND REPLIES TO ME !!!!!!! reply to those who i forwarded the message from... thanks. lee * Origin: -Com Port 1 DFW Amateur Radio BBS (214) 226-1181 (1:124/7009) ------------------------------ Date: Sun, 1 Mar 1992 08:57:00 -0500 From: msb@sq.com (Mark Brader) Subject: Risks of Leap Years and Dumb Digital Watches All right now, how many people reading this have watches that need to be set back a day because they went directly from February 28 to March 1-- and *hadn't realized it yet*? (See Risks-6.34 and 6.35 for the previous version of this message, and commentary on this and other leap-year problems.) Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com ------------------------------ Date: Mon, 2 Mar 92 14:20:02 PST From: rslade@cue.bc.ca (Rob Slade) Subject: Re: Leaping Saturday Working on my home computer on Saturday, I noticed something interesting. One computer was smart enough to handle the leap year with no problem. The other *would not accept* a February 29th date ... but was smart enough to know that March 1st was a Sunday. Oh, well, I didn't get much done Saturday anyway ... ------------------------------ Date: Sun, 1 Mar 92 16:25:35 PST From: eggert@bi.twinsun.com (Paul Eggert) Subject: February 29th sneaks up again As most RISKS readers know, February 29th is International Software Calendar Bug Day. Yesterday's quadrennial event found a bug in Prime's MAGSAV program that caused the program to fail promptly at midnight, as reported in the Usenet comp.sys.prime newsgroup by Peter Maurath. Ironically, the big day was a Saturday, and Prime's 800 number for software support doesn't work on weekends. (Message-ID <17174.29aee0a1@bclcl1.im.battelle.org>) In the same forum, Richard H. Miller reported the usual workarounds: either use an older version of MAGSAV, or lie about the current date. He wrote, ``The indication is that it `snuck up on them' to paraphrase the Prime support person I talked with.'' (Message-ID <10383@gazette.bcm.tmc.edu>) ------------------------------ Date: 28 Feb 92 18:57:40 GMT From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Leap day liquor licence problem The state of Iowa made a bit of a mistake this year. All liquor licences that should expire at the end of this Februrary expired today, on the 28th. The new licences only become valid on March first, so a large number of liquor stores, bars and restaurants have no liquor licence tomorrow (leap day). The state liquor control people have announced that this was due to a "computer error" and they promise not to enforce the law tomorrow, at least, not as it applies to those caught by this glitch. Doug Jones jones@cs.uiowa.edu ------------------------------ Date: Fri, 28 Feb 92 17:19:49 -0500 From: wex@pws.ma30.bull.com Subject: Another Happy Story As people may know, the rock band U2 is starting a tour soon and is playing venues much smaller than the number of fans who would like to see them (13,000 seat arenas when they could easily fill 50,000+ seats). The group has been going to extraordinary lengths to prevent ticket scalpers from getting tickets, including selling some venues by phone only. This has led to some real messes (as when they put the tickets for the Boston Garden show on sale. Half a million calls in the first hour). One good computer-related side effect came to light the other day with the suspension of the manager of the Providence Civic Center. Seems this gentleman stands accused of deliberately overselling his arena with the extras going to scalpers. His scam was shut down after 150 extra tickets were sold. The oversell was detected by U2 people who were monitoring ticket sales from the central computer site in New York City. So for once computer monitoring worked the way it should. And in a widely- distributed system under high stress. Not too shabby. Additionally, each ticket sale was verified to ensure that no one made duplicate orders. According to local radio reports, computer checks for duplication were made against "name, address, and credit card number." "450 duplicates were caught" and the orders cancelled after "human verification." Again, I applaud appropriate use of technology -- the computer did the dumb brute work of finding possible matches and coughed up data to a human being for verification. I'm sure someone will write in with information on what telephone services were denied during the deluge of calls, but hey, nothing's perfect. --Alan Wexelblat, Bull Worldwide Information Systems, Billerica, MA phone: (508)294-6120 wexelblat.chi@xerox.com ------------------------------ Date: Sat, 29 Feb 92 02:53:59 EST From: peterd@cc.mcgill.ca (Peter Deutsch) Subject: Montreal Life Insurance company destroyed by computer errors? A recent article by reporter Jay Bryan of the Montreal Gazette in the paper's business section made some extraordinary claims about the effect that bugs in a newly-installed integrated computer program had on the demise of a Montreal-based life insurance company. It also has some things to say about both systems administration and systems integrators that might be of interest to the comp.risks readership. The article begins: "When Montreal Life Insurance Co., a growing, profitable insurer, decided to upgrade its main computer program 10 years ago, it jumped in with both feet. The new program, a kind called an integrated one, [ yeah, right :-)] would tie together every aspect of the company's operations. There was a small problem, though. The enormous program had been customized and installed in haste. Scattered through its one millions lines of computer instructions, there were a few undetected bugs. And since the system was integrated, every time a bug caused an error in one department's files, the error was immediately reflected in several other departments' files. Within a year, Montreal Life was losing money. After three years, the company was near collapse. errors in commission cheques, for example, drove away most of the company's agents. The agents took their clients with them. When agents weren't underpaid, they were overpaid, which accounted for another $1 million in losses. Finally, what remained of Montreal Life was sold by its owners and most of the company's top managers lost their jobs....." This horror story is credited to two "systems auditors", Marshall Govindan and John Picard, who "... are determined to send a wake-up call to all those corporate leaders who think running a caompany's information system is just a housekeeping detail." Govindan apparently once worked for Montreal Life. Despite its apparent "scare tactics" tone, the article goes on to discuss the need for proper systems management practices in which it makes a couple of good points about the need for suitable direction to systems staff from upper management. The point is made that "The systems people are basically a law unto themselves. They're accountable to nobody...this is because systems managers are treated as a kind of technological high priesthood. Their knowledge is considered so esoteric that top managers feel helpless to help them to the same standards of performance that are common in areas like marketing, operations or finance." Apparently Govindan and Picard have written a book on the subject entitled "Manifesto on Informations Systems Control and Management", published by McGraw-Hill Ryerson. No further details of the book were given. The article then describes a "success story", the Wal-Mart chain of retail stores, which apparently managed to speed checkout handling and minimize stocking with suitable, timely application of new technology. The article finishes with a description of how a successful systems integrator works to bring up new technology and manage the transfer of new clients onto their systems while minimizing their disruptions. The conclusion was "All this [careful client handholding] is a 'pain in the neck' for systems people who might prefer to be doing something more technologically glamorous than sweating over every detail of every new installation...But from the perspective of the company, it means happy customers, rising sales and an assurance that the new system will produce steady profits instead of unexpected losses." The article appeared in The Montreal Gazette, Saturday, February 22, 1992 on page C1 of the Business section, continuing onto page C4. The risks are obvious. The tone is a tad alarmist, but if true, the tale of the demise of Montreal Life contains lessons for those who would rush into implementation of such mission critical software, and then insist on staying with such an obvious failure for as long as three years. I would therefore suspect that the tale of the fall of this company has a lot more that was left unsaid. Would any comp.risks readers have any more details on this? - peterd ------------------------------ Date: Fri, 28 Feb 92 15:29:21 -0500 From: piatko@cs.cornell.edu (Christine Piatko) Subject: Post Office uses only 7 characters to disable my husband's ATM card Speaking of the post office -- (I know that another Ithacan has complained to you about the way mail gets forwarded in Ithaca, but I thought I'd add my husband's mail-forwarding story.) Last November my husband tried to use his ATM card over the Veterans' Day holiday weekend. The person in front of him successfully acquired cash from the ATM, but when he tried to get some money he got the uninformative error message "We're sorry, but we're unable to process your transaction right now." (This is the same message you might get when the machine is out of money, which often happens to this bank's machines during holiday weekends.) So he assumed he was just particularly unlucky that the person in front of him took the last of the cash in the machine. The next day he tried at a different machine, again just after someone had taken out some money. He got the same message about not being able to complete the transaction. Frustrated, he tried small amounts of money, $10, $20, thinking perhaps the machine was out of particular bills. That didn't work either. We also have an ATM card for our joint account with the same bank. He tried that card and it worked fine. (No, he didn't forget his PIN number and yes, the card was in one piece, and yes, this really does have to do with the Post Office.) Puzzled, he called the bank after the holiday and asked them why the ATM card for his account didn't work. They looked up his record and said "Well, it's because your last statement got returned to us 'addressee unknown'." So part of the story is that the bank was stupid and didn't call to verify if he had moved (he hadn't), and locked out his ATM card. And part of the story is that my husband didn't realize he hadn't yet received his bank statement for the previous month. But the rest has to do with the way the Post Office forwards mail. The bank gave him the statement that was still in its envelope with several yellow forwarding stickers on it. The hash function that the Post Office uses (at least in the Rochester branch of the Post Office) is first 3 numbers of the street address and the first 4 letters of the last name. My husband has a pretty common last name (Chang). Evidently, a Chang with a different first name who lived at a house numbered 216 on a completely different street (in a different section of Ithaca so the 9 digit zip codes didn't match either) recently moved out of Ithaca. Since my husband's name and address matched the 216CHAN hash function for forwarding, his statement was accidentally forwarded, and eventually got returned to the bank. Obviously, no one ever really compared the 2 addresses because the street names were very different. All sorts of risks in this whole scenario, but what I can't understand is why the Post Office uses just these 7 characters for their hash function. Seems like there should be a way of using a character from the person's first name and the street name to make it work a little better. Our friend Jenn Turney had problems a few years ago when someone named Turner (with a different first name, and different street name, but the same 3 digit house number) moved. Scanning the phone book, I wonder if Andy Chan, Kenneth Chan or Sak Chanthanak (all with 216 house numbers) have had any problems with their mail being forwarded... Christine Piatko (piatko@cs.cornell.edu) ------------------------------ Date: Sat, 29 Feb 92 18:04:14 -0500 From: William Rucklidge Subject: Not quite anonymous FTP The recent MBDF-A virus which was (allegedly) uploaded to SUMEX-AIM by two Cornell students shows a possible risk: it seems likely that the students were tracked down via examination of machine logs, both at Stanford and at Cornell. They might have been aware of the "last" log, showing who was logged in to what machine when, but probably were not aware that "anonymous" ftp accesses are routinely logged. While the username which you provide can, of course, be anything, it is much more difficult to disguise the source of the FTP transaction, and this can be logged. The risk is not so much that the logs are made, but more that the service is presented as "anonymous", leading people to believe that it actually is. William Rucklidge wjr@cs.cornell.edu ------------------------------ Date: Mon, 02 Mar 92 15:30:55 -0600 From: jcav@midway.uchicago.edu Subject: Virus news-bite omits crucial information This morning I happened to catch newsman Charles Osgood's "The Osgood File" on the local CBS AM all-news station. "The Osgood File" is a two-minute long daily radio "column" in which Mr. Osgood talks about something in the news that interests him. Today the topic was the "Michaelangelo" computer virus. Mr. Osgood spoke repeatedly of the danger to "your computer", and had a brief interview with a computer consultant who also spoke of the danger to "computers". AT NO TIME DURING THE PIECE DID ANYONE MENTION THAT THE VIRUS AFFECTS MS-DOS CLONE MACHINES ONLY. The gist of the piece was that viruses are bad and that all computers are in horrible danger of losing their files on the fateful anniversary this Friday. I called Mr. Osgood's office in New York City and spoke to a woman who was very pleasant to me, and seemed surprised that that particular bit of information had not been included. I'm not sure I was forceful enough in stating how crucial the missing information was to the story. I still can't believe that it was omitted. ------------------------------ Date: Mon, 2 Mar 92 14:57:57 PST From: "Peter G. Neumann" Subject: Scud vs Patriot James Paul just sent me a copy of a report to the Chairman, Subcommittee on Investigations and Oversight, Committee on Science, Space, and Technology, House of Representatives, from the US General Accounting Office, entitled Patriot Missile Defense: Software Problem Led to System Failure at Dhahran, Saudi Arabia. GAO/IMTEC-92-26, February 1992 along with letters from the Subcommittee Chairman, Congressman Howard Wolpe (Michigan) to Richard Cheney, John Conyers (Chairman of the Committee on Government Operations) and Les Aspin (Chairman of the Committee on Armed Services). If any of you want to see the report and/or the letters, please contact James Paul at paul@Nova.House.Gov or call 202-226-3639. You may also get a copy of the report directly from the US GAO, 202-275-6241; single copies of the report are free. The details are mostly known to RISKS readers. Appendix II shows the effect of extended run time, with a .3433 second time inaccuracy over 100 hours, and a shift of 687 meters in range gate. [Science Committee staffer James Paul was the author of the remarkable 1989 report, Bugs in the Program: Problems in Federal Government Computer Software Development and Regulation.] [I presume you all saw the Scud item in RISKS-13.19.] ------------------------------ Date: Fri, 28 Feb 92 12:42:25 GMT From: Pete Mellor Subject: Re: More on the Airbus A320 (Marchant-Shapiro, RISKS-13.19) > Any comments from qualified persons? My only qualification is that I have read the interim report of the commission of enquiry into the Strasbourg crash, and a few other documents. > MOST 320 aircraft have an alarm that informs the pilot that s/he > is flying too low, but France does not require this alarm and so aircraft > sold to and/or operated by French companies do not have this alarm installed. The Ground Proximity Warning System (GPWS) is standard equipment, and is mandated by international regulations. Air Inter, which operated the A320 which crashed at Strasbourg, are a purely domestic airline. Since their aircraft do not fly outside France, they are not covered by the international rules. Air Inter took a deliberate policy decision many years ago *not* to use GPWS, since such systems are (or were then) prone to giving false alarms. They argued that, in any case, their pilots were highly familiar with the terrain around the airports they served, and so didn't need GPWS. In its interim report, the commission of enquiry has been *very* careful not to draw any conclusions, or even entertain any theories, about the cause(s) of the crash. However they are aware that the use of GPWS would have made an accident of this type less likely, and the second of their three interim recommendations is that the French national regulations are amended as soon as possible to make the installation of GPWS mandatory on all aircraft large enough to carry one, including those used only on domestic routes. Note that international carriers, such as Air France, *are* covered by international regulations, and have always had GPWS in their A320s. > If so, this points to a particularly interesting human interface problem -- > perhaps the A320 tends to drop faster than other aircraft, but, since there > is no alarm, [some] pilots do not realize what is happening until they're > too low to do anything about it. The human interface problem which most concerns the commission, and which is the subject of their first interim recommendation, is the possibility of confusion between the two modes of descent: "Vertical Speed" and "Flight Path Angle". For a detailed description of how this confusion could arise, see Robert Dorsett's excellent description of the Flight Management System (FMS) in RISKS-13.11. One possible effect of the pilot selecting the wrong mode is that the aircraft would descend much faster than intended. Apart from that situation, as far as I know the A320 drops neither faster nor slower than any other airliner. On 28th January, the DGAC (French equivalent of the FAA) warned users of the A320 about the danger of confusing the two modes, and immediately put in place procedures and documentation to prevent this happening. The French Minister of Transport has directed the DGAC to monitor the effectiveness of these temporary measures carefully, and told them to direct Airbus Industrie, who manufacture the A320, to produce a detailed plan (within one month) of modifications to that particular part of the pilot-FMS interface. The implementation and certification of the modified FMS will obviously take much longer. Again, the report stresses that this recommendation does *not* imply that the commission have concluded that confusion of descent modes is the cause, or part of the cause, of the Strasbourg crash. The commission's third interim recommendation (again backed up by the Minister) is to make the automatic emergency radio beacon less likely to be damaged in a crash. At Strasbourg it was destroyed, and this has been suggested as one reason why it took rescue teams so long to get to the crash site. The Minister added a fourth directive to the DGAC to look into more rugged flight recorders, and improved protection for them. At Strasbourg, the Digital Flight Data Recorder (DFDR) was fried to a crisp, and the Cockpit Voice Recorder (CVR) and Quick Access Recorder (QAR) were damaged, but still readable in parts. In the last three years there have been five accidents in which the recorders have been destroyed, according to the Minister's statement last Monday. Recorders and emergency beacons are useful only after you've already crashed the 'plane, of course. Whether the crash could have been averted if a GPWS had been fitted is obviously still an open question. It would depend on the length of time before impact at which the warning would have been given, and I do not have this information right now. There is, however, another system, the radiosonde alarm, which gives a simulated voice warning as the aircraft passes down through certain thresholds of altitude, measured by a radio beam reflected from the ground. The top threshold is 200ft. This is separate from the GPWS, and *was* in use on the Strasbourg A320. The transcript of the CVR shows a single radiosonde announcement of "Two hundred feet". Although no time stamp is shown on the CVR transcript, this is the last thing that appears, and seems to have occurred a mere second or so before impact. Peter Mellor, Centre for Software Reliability, City University, Northampton Sq., London EC1V 0HB, Tel: +44(0)71-477-8422, JANET: p.mellor@city.ac.uk ------------------------------ Date: Mon, 2 Mar 92 13:26:14 GMT From: peter@memex.co.uk (Peter Ilieve) Subject: Interim commission of inquiry report into Strasbourg A320 crash On 25 Feb 1992, the papers here reported on the interim report of the French commission of inquiry into the Strasbourg A320 crash. Although they emphasise that they have not concluded what caused the crash it seems they are leaning towards the confusion of the vertical speed and flight path angle modes of descent as desribed by Robert Dorsett in risks 13.11. To show how confusing this is, the reports in the Times and the Independent (2 quality UK papers) contradict each other on the mode that the pilots should have been using. >From the Independent: The French government yesterday ordered modifications to the instruments of the Airbus A320, one of which crashed near Strasbourg last month. Paul Quil\`es, the Transport Minister, said the changes would affect the systems controlling descent. [He wanted Airbus] to report within one month on how it would carry out the modifications. ... The commission ... recommended to ``the ergonomics of the aircraft-crew interface linked to the `Vertical Speed' and `Flight Path Angle' modes''. On the A320 ... pilots select a pattern by pressing a button on the instument panel. The choice is determined by pressing the button once or twice. The Flight Path Angle would have been normal for the Strasbourg approach. [end quote] The story goes on to say that the government were ordering that GPWS should be installed in all aircraft. Air Inter did not have this as they had had reliability and false alarm problems with them. It also mentions the problem of slippage between the A320's map display and the position on the ground. Air France and Air Inter had stopped using this after a pilot flying into Bordeaux noticed a difference between indicated and real positions. The commission are not saying that this problem was linked to the Strasbourg crash but the report says that the cockpit voice recorder indicates that the pilots were concentrating on their lateral position just before the crash. >From the Times: The manufacturers of the A320 ... are to seek new ways of making their jets ``pilot-proof'' and preventing crews from mistaking their flight path angle for their speed of descent. Air accident investigators ... have yet to find the precise cause ... but their preliminary report suggests that the pilots could have programmed the computer wrongly because of confusion over the role of one of the instruments. ... As they approached Strasbourg and were told to make a standard descent, it is now thought likely that they ordered the aircraft to descent at an angle rather than at so many feet per minute. [end quote] The Times report is written with much more emphasis on pilot error. It doesn't mention the government order to Airbus to change things or the map problem. On Sunday 1 March the Sunday Times, a `heavyweight' (in both senses of the word, 9 sections and stilll growing) UK paper had a piece in its business section headed `Airbus has worst record'. Airbus Industrie, the European aircraft consortium, has suffered a new setback with the revalation that its A320 currently has the worst accident record of large passenger jets registered in Britain. An insurance industry report shows that crashes involving the plane, the most advanced flown by airlines, have led to a higher death rate among passengers than on aircraft designed nearly 25 years ago. ... Paul Hayes, director of Airclaims, the aviation consultancy which drew up the report, said it was too soon to draw conclusions over the safety of the four-year-old A320. ``Its loss rates are worse at the moment but this does not mean that it is a dangerous aircraft. If these are maintained over a longer time, however, it may indicate a serious problem for ASirbus,'' he said. The report examines the loss and fatality rates for all jet and turbo-prop aircraft over the past five years. It shows that one person was killed on A320s for every 331,900 carried, compared with one for every 1,401,100 on DC10s, the next worse. If the French disaster was included, the A320 figure would drop to one for every 270,000, a record more than eight times worse than the average for its generation of jets. The aircraft is shown to have had a fatal accident for every 241,700 landings, seven times worse than the performance of the Boeing 757, one of its main rivals. The older A300 and A310, which do not use the contoversial fly-by-wire system, have not had a fatal accident. ... Airbus said it was unfortunate that aircraft crashes were remembered for the type of plane involved rather than the cause. ``There have been three crashes and in the first two it was quite clear that the aircraft was not at fault,'' a spokeswoman said. [end quote] Airbus' comments in the last paragraph of this report seem suspect to me. Unless you assume that the pilots flying A320s are more stupid than average, then if pilots have more crashes in A320s than other planes, even if the cause is officially `pilot error', there must be something about the plane that makes errors more likely. Peter Ilieve peter@memex.co.uk ------------------------------ End of RISKS-FORUM Digest 13.21 ************************