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 09

Wednesday 22 June 1988

Contents

o Risks of ATM manufacturers
Philip E. Agre
o Risks of bank ATMs
Mary-Anne Wolf
Larry E. Kollar
o Yet more on the Blackhawk helicopter Jan Wolitzky)
o Re: root typos
Dave Curry
nyssa
o Notice to the OTA mailing list
Eric Roberts
o Challenger Payoff?
Richard Outerbridge
o Info on RISKS (comp.risks)

Risks of ATM manufacturers

"Philip E. Agre" <AGRE@AI.AI.MIT.EDU>
Thu, 9 Jun 88 02:05:54 EDT
In reading Risks over the last couple years, I've noticed that responses to
attempts to complain about uncorrected technical problems tend to take
certain recurring forms.  John Pershing's message about ATMs illustrates a
remarkable number of these forms of argument, all of which will be familiar
from previous Risks discussions of related topics, such as privacy
violations and whistle-blowing at NASA.

What has happened?  Someone, in this case a customer though in other
cases it has often been an employee, complains that something is badly
amiss with some system, receives no redress, and finds that their
reports are ignored.  So they make noise about it.  The response?

1. Misplaced accusations of uncooperativeness.  `You have to exercise
the system so that the bugs will be found and fixed.'  The person
*has* exercised the system and discovered and reported difficulties
with it, but the organization in question ignored the reports and thus
(we must presume) neither found nor fixed any bugs.

2. Condescending lectures about how `incredibly complicated' the
systems in question are and how hard it is to anticipate all possible
problems.  Nobody has demanded that all problems be anticipated, only
that attempts be made to repair detected problems, especially ones
that cause unnecessary loss or injury.

3. Misplaced appeals to the market.  `If your bank is not responsive
to your bug reports, then find another bank.'  The ATM didn't just
have a bug, it stole this person's money.  And presumably it is
stealing other people's money.  Why doesn't the knowingly misdesigned
software constitute a company policy to defraud its customers?  And
don't ATMs, as a legal matter, fall under some version of the notion
of implied warranties of merchantability?

4. Casting misdesign as an irremediable act of God.  `It is quite
sensible for an ATM's programming to "lean" in the bank's direction is
there is something amiss ... .'  Wouldn't the really sensible thing be
to make a record, whether on a paper receipt or in a computer file,
and preferably both, that something was amiss in this particular
transaction?

5. Diagnosing the system is the victim's job.  `... the consumer will
always go complaining to a bank officer.  When was the last time that
you got *over*-changed and actually reported it?'  It is even more
sensible to "lean" in the customer's direction, because the bank will
always be motivated to fix problems that cost it money.  When was the
last time a bank discovered it had over-changed you and actually let
you keep the money?

6. This-is-nothing-new.  `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.'  Such a statement requires that we define the
problem far too abstractly.  The story concerned a particular
misdesign.  Taking it as an abstract attack on ATMs misses the point.

7. Blaming the victim.  `It is impossible to even imagine ... 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.'  A customer gets defrauded, yet somehow the
issue has gotten twisted around into customers committing fraud.  Note
the irony of the last bit: banks have committed financial fraud as
long as there have been banks.


Risks of bank ATMs

Mary-Anne Wolf <MWolf@BCO-MULTICS.ARPA>
Thu, 9 Jun 88 11:38 EDT
The ATM itself is not all that you need.  Baybanks in (Eastern) Massachusetts
has a dial-less telephone next to their ATMs, which reaches an office staffed
24 hours a day.  I have only used this phone for information, but I assume
that, if anything went wrong, it would be possible to inform someone and check
the state of the machine immediately.  If the bank decided to wait until
business hours to check the machine, they could still have a record of who
claimed to be short-changed.  These ATMs also have a camera behind glass
pointing at the customer, and although I never know when it's running, it seems
unlikely that someone would fake a complaint.  One pays for this convenience
with relatively high minimum balances and relatively low interest, but, as long
as I have the money, it's worth it.  (When I didn't have the money, I got a
better deal at a bank with only 2 branches that didn't offer ATMs at all, and a
check-cashing card in a 24-hour supermarket for emergencies.)

I suspect that the problem is less the machine than the attitude of the bank.
A bank should probably rather risk losing a little money than a lot of
customers, and I would boycott banks rather than ATMs if I boycotted at all.

Mary-Anne Wolf, MWolf -at BCO-Multics.ARPA, Honeywell Bull, Billerica MA
These opinions are my own, and my only connection with any bank is as a customer.


Re: Risks of bank ATM cards

Larry E. Kollar <dcatla!mclek@gatech.edu>
Fri, 10 Jun 88 16:43:31 EDT
>From: John Pershing <PERSHNG@ibm.com>
>
>  -  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.

The ATMs around Atlanta always give you a receipt, whether or not your
request went through.  Usually they have a code on the front, with a list
of codes and what they mean on the back.

As for the printer breaking or running out of paper, it's not a hard thing
for an ATM to detect the lack of paper flow and put itself out of service.
Whether or not ATMs do that is yet another question.

Earlier, Karl Denninger relates that the bank told him "no receipt, no fix."
ATMs keep an internal printout of account numbers, as an audit trail.  It came
in handy for us a couple of years back when my wife deposited $400 in cash,
threw the receipt away, and the ATM crashed that evening and forgot to transmit
the transaction.  We didn't know what had happened until checks started
bouncing on us.  This safeguard must be on all machines; Georgia isn't much of
a consumer-oriented state to require that kind of special modification.

    Larry Kollar    ...!gatech!dcatla!mclek


Yet more on the Blackhawk helicopter

<wolit@research.att.com>
Fri, 17 Jun 88 10:15 EDT
Additional details on the incident Dave Horsfall reported in RISKS DIGEST
7.8, from 'Aviation Week & Space Technology,' June 13, p. 31:

  The most recent tests were conducted near a dense antenna field of nearly 1
  sq.  mi. that radiates on a broad range of frequencies with a power level

  potential well above 400 MW, according to Army officials.  During the tests,
  the aircraft experienced uncommanded rudder pedal movements that caused the
  UH-60 [Blackhawk] to begin turning, stiffness in the rudder pedals and
  illumination of caution and advisory lights in the cockpit.

  Specifically, the test UH-60 experienced a simultaneous loss of hydraulic
  pressure to both tail rotor servos for approximately 5 sec. and a jamming of
  the tail rotor control pedals.  Both malfunctions were attributed to the
  susceptibility of the hydraulic logic module to the high energy levels.  As a
  result, the service has decided to accelerate the hardening of the module for
  both production and retrofit as the first priority under the modified ECP
  [Engineering Change Proposal 384].

Jan Wolitzky, AT&T Bell Labs, Murray Hill, NJ; 201 582-2998; mhuxd!wolit
(Affiliation given for identification purposes only)


Re: root typos

Dave Curry <davy@intrepid.ecn.purdue.edu>
Thu, 16 Jun 88 12:49:07 EST
Ken Yap relates his problems with ^P and the Vax console.  Fortunately,
^P is not the standard rlogin escape.

Here's a better (worse?) one:  the console escape character on the CCI Power
6/32 ("tahoe") is the tilde.  And, so is the escape character for Berkeley
mail.  You guessed it... log in on the console, send some mail, and do a "~h"
to see the headers.... ooops, the machine just halted.

CCI also cleverly placed the "reboot" switch, an up/down toggle, on the
front of the cabinet, not recessed, and at knee level.  Fortunately,
UNIX seems to ignore the switch.

--Dave Curry

P.S. - Don't get me wrong; the tahoe is a really *nice* machine, regardless
       of the above demonstrations of poor design judgement.


Another Root typo

<nyssa@terminus.att.com>
Fri, 10 Jun 88 13:59 EDT
This has taken on an almost urban legendary status in our group:

Four summers ago, we were doing a beta test at a customer site.
Our field support person had to remove some files in a directory, so
he had to use the "su" command.  This he did, followed by an rm -rf *

The problem was that he typed "su -" which moved him to the root
directory.  Not even a series of messages like "/bin/rm: Cannot remove,
file busy" detered him, until the machine was wiped out...


A catch for coughin'

Dave Horsfall <munnari!stcns3.stc.oz.au!dave@uunet.UU.NET>
Sat, 18 Jun 88 15:57:42 est
From "Computing Australia" 13 June 1988:

"System slip leads to danger dosage

 An error in instructions given to a pharmaceutical manufacturer's computer
 has resulted in the production of two dangerous batches of cough mixture.

 A spokesman for South Australian Hamilton Laboratories, which makes the
 Neo-Diophen Elixir, said during preparation of the master batch documents
 for the computer, a decimal placing was typed incorrectly [another decimal
 point error?].

 Some of the mixture was found to contain 10 times the normal level of a
 certain chemical, he said.  He said about 6,400 bottles of the mixture
 had left the laboratory, but less than half had reached retail outlets.

 The Federal Community Services and Health Department issued an instant
 recall on the batches and last week department inspectors were investigating
 the mistake."


So it's not the cough that carries you off, but the coffin they'll carry
you off in...

Dave Horsfall (VK2KFU), Alcatel-STC Australia, dave@stcns3.stc.oz
dave%stcns3.stc.OZ.AU@uunet.UU.NET, ...munnari!stcns3.stc.OZ.AU!dave


Eric Roberts <roberts@decwrl.dec.com>
Mon, 13 Jun 88 15:54:26 PDT
I found this amusing, particularly in light of the fact that the
OTA has been investigating SDI software feasibility.  /Eric


                                        Congress of the United States
                                        Office of Technology Assessment
                                        Washington, DC  20510-8025
                                        June 6, 1988

     TO OTA'S MAILING LIST:

          Thank you for your effort in filling out and returning OTA's
     yellow update flyer last March and April.  Unfortunately, some
     software problems have delayed the recording of the new information.
     While we are in the process of diagnosing and solving the software
     problems, we will be using the non-updated list for sending out
     Report Briefs....
          We anticipate having the mailing list up and running as normal
     in August.

                                        Cordially,

                                        OTA Congressional and
                                             Public Affairs Office



Challenger Payoff?

Richard Outerbridge <csri.toronto.edu!outer@uunet>
Sun, 12 Jun 88 21:44:18 EDT
Recently I heard a litigation lawyer speak on the connection between insurance
premiums and corporate motivation.  He claimed that despite the shuttle disaster
Morton Thiokol still received a $65 Million dollar "early completion" bonus
on the contract that included the Challenger launch.  Is this true?  'Twere
scandalous 'twere so, but stranger (and sorrier) things have been known true.

Please report problems with the web pages to the maintainer