RISKS-LIST: RISKS-FORUM Digest Wednesday 8 June 1988 Volume 7 : Issue 6 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Buggy ATC Software (Paul Fuqua) The Challenger and visionary software architects (Kent Stork) How To Stop A War (Henry Spencer) UK Poly; another root typo (Matt Bishop) Re: The Australia Card (Amos Shapir) Re: Risks of bank ATM cards (John Pershing) ATM risks - the figures in UK (Alasdair Rawsthorne) 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, Requests to RISKS-Request@CSL.SRI.COM. PLEASE use a relevant "Subject:" line, not just "RISKS DIGEST i.j...". THANKS. For Vol i issue j / ftp kl.sri.com / get stripe:risks-i.j ... . Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85),(6,95). ---------------------------------------------------------------------- Date: Tue, 7 Jun 88 18:12:18 CDT From: Paul Fuqua Subject: Buggy ATC Software From the Dallas Morning News, June 7, 1988, without permission: "Glitches" in a new computer program used by air traffic controllers at Dallas/Fort Worth International Airport can temporarily obliterate information on altitude, airspeed, ... types of aircraft in the area ... the call signs [,] and intended destinations of aircraft. The same program is used at airports in Houston, Los Angeles, and Atlanta. "When the program is running and it detects a glitch in the system ... it will remove the alphanumerics on the screen for a period of 20 seconds or less," said Lawrence Parrent, assistant air traffic manager at the D/FW Terminal Radar Approach Control center, or TRACON. .... An audible alert is sounded when the data blocks are about to disappear, and FAA officials say the controllers have up to five seconds to either write down the information or memorize it. Parrent said FAA officials do not believe the glitch constitutes a safety hazard. "The radar has not failed," he said. "The primary target is still there." The radar image and a four-digit number assigned to each aircraft remain on the screen. .... Parrent said that the new program offers many features that improve the margin of safety in air traffic operations ... [Discussion of potential problems if the "glitch" occurs during holding patterns or handoff from en-route controllers to approach controllers.] FAA officials say controllers are able to determine the altitude of aircraft just as they did before the software was developed -- by asking the pilots. [Comments from Parrent about controller uneasiness.] [Testing began in January, increased to 24-hour-a-day use after April.] "The reason we are testing with live traffic is that we do not have the capability to simulate the number of targets in off-line conditions," Parrent said. "We have to test under actual conditions. "It's like other aviation-type equipment -- just like an airplane. You put it in a wind tunnel and it looks great, but you still have to go out there and put a test pilot in it and fly the darn thing." End of article. Comments: The system itself is obviously aware of a problem, or it wouldn't be able to sound a warning. Wouldn't it be better to leave the information on the screen, even if updates are frozen until the 20-second problem is over? Even if the only benefit is to avoid disturbing the controllers? And "up to five seconds" to record information on "up to ten" aircraft? (The number's in the article, I just omitted it.) Did anyone ask the controllers what *they* would like to see in the new program? The FAA apparently considers this a minor problem because when it fails it's just equivalent to the old system. What about (a) becoming dependent on the new features and (b) the "startle factor" when the warning sounds? Did the problem show up before the peak-period testing? If so, how come it hasn't been fixed in five months, and if not, isn't that an extra worry? Since I'm working on simulations and simulators at the moment, I can sympathise with the inadequacy of off-line testing, but I'd rather the field-test were on something less important than an air-traffic control system. Sounds like a good argument for better simulation technology and more computing power to use what's already there. Paul Fuqua, Texas Instruments Computer Science Center, Dallas, Texas ------------------------------- Date: Tue, 7 Jun 88 12:37:37 HST From: stork@humu.nosc.mil (Kent Stork) Subject: The Challenger and visionary software architects The May issue of Defense Science validates something that many computer scientists have probably suspected: ultimately, the failure of the Challenger and the death of the astronauts was due to a control loop software design oversight - just another bug. To what extent must software architects be visionaries? Certainly the requirements are proportional to the power of the system the software controls. Do such visionaries exist to design our Challengers and our other more aggresive weapons? ------------------------------ Date: Wed, 8 Jun 88 00:45:16 EDT From: mnetor!utzoo!henry@uunet.UU.NET Subject: How To Stop A War (Dunningan and Martel) Of some small relevance to Risks, and of possible interest to readers, is a recent book: "How To Stop A War", James F. Dunnigan and William Martel, Doubleday 1987. The authors are military analysts, not peace marchers. A good look at the realities of why wars start or don't. (Sample: "As long as there have been technically complex weapons, there have been accidents. For example, one sixth of the losses of modern battleships were due to accidental explosions. If such a formidable ship can accidentally demolish itself, it's no wonder users are fearful about the safety of current systems... During the 1986 Air Force raid on Libya, two F-111 aircraft were needed for every one that got through in working order to drop its bombs.") Henry Spencer @ U of Toronto Zoology {ihnp4,decvax,uunet!mnetor}!utzoo!henry ------------------------------ Date: Wed, 8 Jun 88 08:02:36 EDT From: bishop@bear (Matt Bishop) Subject: UK Poly; another root typo (RISKS-7.5) The UK Polytechnic that Ian Batten was talking about is described as case 78.066 in the book "Computer Insecurity" by Adrian Norman (Chapman and Hall, New York, c. 1983, p. 191.) This book, incidentally, is an excellent collection of incidents involving computer security (or lack thereof) and even does some analysis to show some things that lead to security problems. (The computer was a DEC10 system, not a PDP-11/44; other than that, though, the details are exactly the same.) Yet another root typo story: a certain person who had superuser privileges once accidentally typed "exit" rather than "halt" to leave superuser mode. The former does just that; the latter halts the CPU ... Matt ------------------------------ Date: 8 Jun 88 05:32:25 GMT From: nsc!taux01!taux01.UUCP!amos@Sun.COM (Amos Shapir) Subject: Re: The Australia Card [RISKS DIGEST 7.5] Israel does implement a system of a national ID card, used by all government agencies, banks, hospitals, employers, etc. There is no central database (yet!) but information cross-over is relatively easy. Last month a man requested for a loan from a bank; his request was denied because (the bank claimed) he had just applied for the same type of loan two years ago. Checking it out, the poor guy found out that there was another man with a similar name, who had the same ID number, and what's more, the other guy was a criminal wanted by the police. It seems that the criminal had lost his ID card a few years ago, requested a new one, and the Ministry of the Interior had issued him a new one - with the other man's number! They claim that since the system has been computerized by now, such a mistake cannot happen again... Amos Shapir, National Semiconductor (Israel) 6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261 ------------------------------ Date: 8 Jun 88 08:32:35 EDT From: John Pershing Subject: Re: Risks of bank ATM cards (more) (RISKS-6.94) In reply to Karl Denninger's posting... I don't see any risks in his story that can be attributed specifically to the use of ATMs, as opposed to the more general use of a Bank. If anything, the risk is assuming that a transaction that is "untouched by human hands" will be less likely to go wrong when, in fact, it is more likely to have something go wrong. Specific points: - The error undoubtedly *was* caught when the machine was counted out at the end of the day (assuming that your bank follows accepted accounting procedures). - They didn't know it was "your cash". The machine ended up the day with too much money, which means that one (or more) of the 500 people who used the machine that day got short-changed. Undoubtedly people were assigned to look into the problem if it has happening on a regular basis (probably a mechanic was sent out to clean and oil the ATM). - I have never gotten a receipt for a failed transaction. Requiring a receipt for a failed transaction sounds sort-of bogus to me, as one of the (dozens of) failures that can happen is that the receipt printer breaks or runs out of paper. - There is no such thing as a "true balance" from the bank's point of view, as you undoubtedly have a bunch of "paper" (checks, credit charges, etc.) floating around that they haven't seen yet. Also, contrary to popular opinion, electronic funds transfers are seldom posted against the "bank of record" in real-time -- rather, they go onto a tape somewhere and get fed in at night. So, any "balance" that your bank would report is necessarily flakey. Indeed, there are response-time requirements placed on banks that are wired in to ATM networks (typically a few seconds). Since the "real" records are on a tape in the back room, the "front-end" computer only has your balance as of last night (or, maybe the night before) plus the electronic transactions that it has seen go by. It may have missed some electronic transactions, e.g., due to crashing and/or a network failure. It hasn't seen any of the day's paper. The electronic transactions that it has seen haven't been verified yet. Electronic banking systems are incredibly complicated. It is impossible to even imagine the number of things that can go wrong, or the number of ways that clever consumers can subvert the system. Of course, this is nothing new with ATMs -- financial fraud has been around as long as banks. It is quite sensible for an ATM's programming to "lean" in the bank's direction is there is something amiss, because the consumer will always go complaining to a bank officer. When was the last time that you got *over*-changed and actually reported it? Go ahead and boycott the machines if you want. However, if you want them to improve, then you have to exercise the system so that the bugs will be found and fixed. If your bank is not responsive to your bug reports, then find another bank. John Pershing, IBM Research, Yorktown Heights ------------------------------ Date: Wed Jun 8 14:19:19 1988 From: Alasdair Rawsthorne Subject: ATM risks - the figures in UK I have always refused to possess an ATM card, on the grounds that the individual is not well protected against the banks' errors, particularly since bank employees perceptions of the possibility of malfunctions differ from mine. My feeling has been strengthened in the past by one or two highly publicised cases of the banks' intransigence in the face of complaints of ``phantom'' withdrawals from ATMs. I've not seen a case of this type now for a few years, and was beginning to succumb to the idea that the safeguards have improved, when I came upon an article describing the UK Banking Ombudsman. He is the arbiter of last resort for customer complaints, and will only accept cases that have exhausted the relevant bank's internal complaints procedure (usually at general manager level). According to Money Management(June '88), the Banking Ombudsman received 198 complaints in March 1988. The category with the highest number of complaints was..... ``Cashcards - unauthorised withdrawal'' with 17 (~9%) complaints. Are there any figures for other countries banking systems? ------------------------------ End of RISKS-FORUM Digest ************************