The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 7 Issue 06

Wednesday 8 June 1988

Contents

o Buggy ATC Software
Paul Fuqua
o The Challenger and visionary software architects
Kent Stork
o How To Stop A War
Henry Spencer
o UK Poly; another root typo
Matt Bishop
o Re: The Australia Card
Amos Shapir
o Re: Risks of bank ATM cards
John Pershing
o ATM risks - the figures in UK
Alasdair Rawsthorne
o Info on RISKS (comp.risks)

Buggy ATC Software

Paul Fuqua <pf@ti-csl.csc.ti.com>
Tue, 7 Jun 88 18:12:18 CDT
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


The Challenger and visionary software architects

Kent Stork <stork@humu.nosc.mil>
Tue, 7 Jun 88 12:37:37 HST
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?


How To Stop A War (Dunningan and Martel)

<mnetor!utzoo!henry@uunet.UU.NET>
Wed, 8 Jun 88 00:45:16 EDT
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


UK Poly; another root typo (RISKS-7.5)

Matt Bishop <bishop@bear>
Wed, 8 Jun 88 08:02:36 EDT
   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


Re: The Australia Card [RISKS DIGEST 7.5]

Amos Shapir <nsc!taux01!taux01.UUCP!amos@Sun.COM>
8 Jun 88 05:32:25 GMT
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


Re: Risks of bank ATM cards (more) (RISKS-6.94)

John Pershing <PERSHNG@ibm.com>
8 Jun 88 08:32:35 EDT
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


ATM risks - the figures in UK

Alasdair Rawsthorne <alasdair%unix.cs.man.ac.uk@NSS.Cs.Ucl.AC.UK>
Wed Jun 8 14:19:19 1988
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?

Please report problems with the web pages to the maintainer

Top