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 15 Issue 69

Friday 25 March 1994


o Another ATM failure (with a happier ending)
Mark Connolly
o Bugs hold up farm cheques
Mich Kabay
o Nut behind the wheel
Mich Kabay
o Digital Telephone Switches and Modems
Bob Oesterlin
o Grammatik bug mistaken for racial putdown
Marni Elci via Roy Beimuts
o Re: Denver Baggage Handling
John Gersh
Marcus J Ranum
Bear Giles
o Re: Funny Money article
Sean Eric Fagan
Curtis Jackson
Tobias Ulmer
o Re: RISKs of safe ATMs
M. Hedlund
o Re: Comment on earlier [Don Norman] posting
Marcus J Ranum
o CFP: 2nd ACM Conference on Computer and Communications Security
Li Gong
o Info on RISKS (comp.risks)

Another ATM failure (with a happier ending)

Mark Connolly <>
Thu, 24 Mar 1994 08:22:14 -0500
Is there any interest in yet another ATM contribution? This one has all the
familiar elements plus a reward for honesty to at least one of the
participants (but not the other). Here are extracts from a newspaper story.
[Mark Connolly, Connolly Design Inc., Waterloo, Ontario, Canada]

  Bank machine runs amok; Honest customer returns bag full of cash
  SouthamStar Network

  EDMONTON -- All Barry Inkster wanted when he slipped his bank card into the
automated teller was $200 to shop for a birthday gift for his wife. Instead he
got a Las Vegas-style payoff when the machine spat out nearly $5,000 in $20
bills ... "I grabbed all the money in a great big wad and walked to a doughnut
shop and asked them to give me a bag."... Inkster said he's been ripped off by
automated tellers in the past, only to be told by bank personnel that machines
don't make mistakes. ... the machine had been causing problems all weekend ...
a number of people complained ... the machine was subtracting their
withdrawals, but not handing out any money.  ... No one from the bank was
available for comment. A repair crew worked on the machine Monday morning but
obviously it didn't fix all the problems ...  Inkster called the bank, took
the money back and watched the tellers count about $4,800. ... "All I was
concerned about was if the transaction had taken $5,000 out of my account."
The bank assured him it hadn't. Inkster said he was well rewarded with a pen,
key chain and free dinner for his honesty.

Bugs hold up farm cheques

"Mich Kabay / JINBU Corp." <75300.3232@CompuServe.COM>
23 Mar 94 09:15:44 EST
>From the Associated Press newswire via Executive News Service (GO ENS) on

  Disaster Checks (By ROBERT GREENE, AP Farm Writer)

  WASHINGTON (AP, 22 Mar 1994) -- The glitches stole Christmas from many Dade
  County, Fla., growers expecting disaster payments from the Agriculture
  Department.  Because of processing errors, many checks for those who
  suffered losses in Hurricane Andrew have been held up for three months.

The author explains that about 5,000 cheques (a total of about $25 million)
were to have been mailed in December.  However, staffers found serious errors
such as a $140,000 overpayment.  As a result of procedural and computer bugs,
"Of the $24.8 million in payments, $14 million has been reissued. And so far,
$1.8 million worth of payments has been canceled.  Another $11 million in
payments remains on hold."

  [It's bad enough to fight bugs in the fields without having to fight bugs in
  the banks.]

Michel E. Kabay, Director of Education, National Computer Security Association

Nut behind the wheel

"Mich Kabay / JINBU Corp." <75300.3232@CompuServe.COM>
23 Mar 94 09:15:48 EST
>From the United Press International newswire via Executive News Service (GO
ENS) on CompuServe

  Survey: few merchants check conflicting credit-card signatures
  written by Peg Byron, edited by Harold H. Martin, in New York

  NEW YORK (UPI, 21 Mar 1994) -- Credit-card fraud may get an unintentional
  boost from retailers, Money magazine reported Monday in a survey that found
  95 percent of clerks and cashiers they tested failed to check signatures on
  charged purchases.  Money magazine said signatures for purchases that
  conflicted with the name on the credit card seldom caused clerks or cashiers
  to check for fraud.

The article continues with details of the experiment.  Staffers used the wrong
cards or signed false names in 127 cases (they had letters authorizing them to
perform the experiment).

Only 5% of the store employees checked the signatures at all.  "In one case, a
male Money editor was not questioned even when he used a woman's card to
charge a $114 meal in a New York restaurant and signed the credit slip `Daffy

The cost of such fraud, entirely passed on to consumers, is about $55 per card
user in the U.S.

  [Human factors control the effectiveness of security measures.  We really do
  have to insist on PINs for credit cards.]

Michel E. Kabay, Director of Education, National Computer Security Association

Digital Telephone Switches and Modems

Bob Oesterlin <oester@vnet.IBM.COM>
Fri, 25 Mar 1994 11:57:09 -0600 (CST)
Early last month, our local phone company (US West) replaced our "aging"
analog telephone switch with a new digital one, which was designed to bring us
"into the information age".

Well, no sooner was the switch installed, people started having problems
connecting to our dial-in service for home terminal support.  The current
system consists of a front-end box (made by Traqnet) and a Cisco terminal

The problems seemed to be widespread but intermittent:

- Dropped connections
- Can't connect at 14.4 KB (drops back to 1200!)
- Can't connect at all

After some lengthy (and still ongoing) investigation, the problem
turned out to be that the time bases of 3 digital switches
involved are not in sync! The 3 are:

- The Rochester switch (run by US West)
- The IBM Rochester Local ROLM switch (local PBX)
- The NPN Switch (which connects IBM to the corp network run by Advantis, Inc)

Comments from our local communications rep:

"I have been told that there are 3 national master clocks. Each phone
company must sync their digital switch with one of these master clocks."

"U.S. West's switch is sync'd with a master, I don't know which."

"NPN's switch is sync'd with a master too, this may be the same master
that U.S. West is sync'ing to but, this is not important yet."

"Our ROLM switch is sync'd with NPN and cannot be changed."

BTW, the problem "seems" to be getting worse as time passes.

It would seem to me that this could become a widespread problem as more DSS's
are used. Is someone causes a master clock to become out of step, then you
could (potentially) disrupt communications over wide areas.

Bob Oesterlin, IBM AS/400 Division, Dept 54T, Rochester MN 55901  (IBM IPNET:  (507)-253-4528

Grammatik bug mistaken for racial putdown

"Roy Beimuts, Melfort Research Station, AGR CA" <>
24 Mar 1994 15:27:50 -0500 (EST)
The following letter to the editor appeared in the March 23rd Globe and
Mail; a very eloquent response to what must have been a very upsetting

Another illustration of how the most noble of programming intentions can
backfire in the most unexpected ways due to an unforeseen bug:

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Letter header:  Software bug led to misunderstanding

     I was distressed to read Mark Charendoff's essay Dear WordPerfect:
I'm A Jew (Facts and Arguments -- March 8).  Mr. Charendoff expressed
dismay that Grammatik, WordPerfect's grammar and style checker, responded
to the noun "Jew" with the message "Avoid this offensive term."
     Mr. Charendoff's dismay is understandable.  The message is absurd in
that context.  It was intended for "jew" used as a verb (e.g., "he jews
them down").  Grammatik's extensive dictionary contains two entries for
"Jew"; one, capitalized, for the noun, and another, labelled "offensive,"
for the lower-case verb.  When "Jew" or "Jews" occurs as the first word of
a sentence, a bug in the program is calling the lower-case entry instead
of the correct upper-case one.  Ergo, the message is erroneously output.
     The bug will be fixed.  Its appearance in a program that I helped
develop and am proud of is upsetting enough.  That it resulted from our
sincere efforts to identify and eliminate ethnic slurs troubles the whole
Grammatik development team.
     But other aspects of the situation disturb me personally as well.
Please note that the opinions below are my own, not necessarily shared by
WordPerfect Corp.
     Mr. Charendoff remarks that many Jews he spoke with about this
argued that "Jew" really is an offensive term.  They tried to find some
rationalization for the message.  That troubles me.  A word which
identifies a whole heritage, a word as valid as "Protestant," "Buddhist,"
"Italian," or "Canadian," does not become offensive just because bigots
use it, whether to demean or even to decimate.  When Jews bend to that
point of view, they reflect the confusion of a people that has survived
oppression, only to be left with shame about its identity.
     The automatic assumption by Mr. Charendoff and others that the
message was an intentional racial putdown, not a mistake, bothers me too.
Bugs occur often in software programs, especially those as complex as
Grammatik.  Parsing English is not easy.  Granted, a bug involving one's
religion may be hard to recognize as just an error.  Although I wish he
had written to us rather than The Globe and Mail, I cannot really blame
Mr. Charendoff for his indignation.
     Grammatik's goal has always been to help users find and fix problems
in their writing.  We think we have had good success so far, and we are
constantly working to improve our performance.  We are grateful that this
mistake has been found so that we can correct it.  But I would like the
record to be clear -- this bug resulted from trying to eliminate
prejudice, not propagate it.
     Note:  I come from a family of Orthodox Jews.  Most of the members
of my family who survived the Second World War now live in Toronto.

          Marni Elci, English Linguist at WordPerfect Corp.
                              Albuquerque, N.M.

Re: Denver Baggage Handling (Alan Wexelblat, RISKS-15.68)

John R. Gersh <>
Wed, 23 Mar 1994 15:38:17 -0500
It gets even more interesting...

The 7 Mar 1994 issue of *Aviation Week* has a story on the airport's
yet-again-delayed opening. The hangup is indeed the complex automated
baggage-handling system. The article says that the underlying problem is
simply that system testing has not been completed in time, but it also
describes some specific problems that have arisen. One is that:

"When United ran its tests, ticket counter agents were generating on-line
printed baggage tags too rapidly, causing United's Apollo computer
reservations system to communicate improper data to [the baggage system
manufacturer's] baggage sorting computers. As a result, properly tagged
luggage were being routed to a manual hold station instead of the aircraft,
according to [the manufacturer's president]. 'It was mostly a training
glitch,' he said. After the agents slowed down, the system operated nominally,
he said."

While it's not entirely clear what "generating tags too rapidly" means here
from the limited information given, one can envision various ways in which
problems might arise. For those of us who spend all too much time in airport
waiting lines, though, it's naturally disconcerting to hear that the system
design requires the agents to work more slowly than they would like to!

It's even more disconcerting, however, to hear this described as a "training
glitch," rather than a system design problem. My first reaction was to
classify this as a typical case of blaming the user rather than the builder
for problems in system design or implementation. Consider the following
analogy, though: Airport check-in agents put luggage on a conveyor belt for
dispatch to the baggage-handling area. Suppose there were a problem with
agents "putting bags on the belt too rapidly" (i.e., piling bags on top of
each other so that they fell off the belt or jammed the mechanism). Assuming
that the belt speed was reasonably specified (based on other considerations),
wouldn't it be proper to classify that as a training or procedural problem? Is
that different from the overly-speedy tag printing?

Of course it is, and therein lies the key point. It's visually obvious what
the proper placement of the bags on the belt should be; is it also obvious
when the next acceptable tag-printing moment arrives? Suppose, only for the
sake of argument, that other reasonable design constraints sometimes produce a
significant communications delay between the two systems; that delay might
result in the reservation system being able to print a baggage tag which the
baggage system was not yet able to handle. In that case the real problem lies
in not showing the agents that the overall system was not ready to print a tag
or accept a bag. If, in fact, the agents can "generate tags too rapidly," then
there is almost certainly something other than a "training glitch" at work.
One might think either that the data generation or interchange timing is not
as it should be or that the design of the agents' terminals does not
adequately portray or control the effect of such possible timing problems.

John R. Gersh      
The Johns Hopkins University Applied Physics Laboratory

Re: Denver Baggage Handling (Alan Wexelblat, RISKS-15.68)

Marcus J Ranum <>
23 Mar 1994 21:51:15 GMT
    One thing that's particularly fascinating is that many of the problems
they are facing (conveyor problems, zebra tags getting ripped and damaged,
etc) are problems that Federal Express and UPS have apparently already solved.
I suppose UPS and Federal Express have the advantage that they can enforce
packaging size limits and so forth, but it seems to me that one of the big
RISKS we're seeing here is the ever-present danger of not doing your research.

Re: Denver Baggage Handling (Alan Wexelblat, RISKS-15.68)

Bear Giles <bear@tigger.cs.Colorado.EDU>
23 Mar 1994 20:07:42 GMT
You won't hear much griping from the politicians because *they* are the ones
to blame for the delay.  After the contract was signed, Denver kept asking for
change after change to the luggage system.  Nobody can develop a system on
time and on budget if what they're developing keeps getting redefined!

On top of that, Denver made certain technical promises (e.g., a "clean" power
supply) which it has been unable to fulfill.  This directly lead to the
failure of some of the early tests; a power surge would blow out circuitry,
overrun motors, etc.

>It'd probably be the usual uninformed pablum about how complex systems
>"always" have a few "small" problems, and no thought given to how the
>problems might have been prevented in the first place.

It's pretty clear that Denver has a lot of airheads at the new airport.  My
favorite design flaw was the massive water sculpture directly over the main
power transformers... requiring a large stainless steel catch basin.

Another good one (not directly related to the airport) was the initial
proposal that one-way bus fare from Boulder to the airport would run about
$17.  In contrast, the current bus fare from Boulder to Stapleton is about
$2.50.  (The increase in distance would be about 30%).  Toss in high taxi
fares, and high car parking fees, and most people would choose to have a
spouse or friend drop them off and pick them up.  The impact on air quality is

Just remember, the mayor of Denver who pushed this monstrosity on us is now
the Secretary of Transportation.

Re: Funny Money article in THE SCIENCES (Kabay, RISKS-15.68)

Sean Eric Fagan <>
Wed, 23 Mar 94 11:00:13 PST
>MK thinking out loud: AI pattern recognition algorithms coupled with a
>library of currency images could permit a smart copier to blank out all
>attempts to photocopy money.

It already exists.  Xerox demonstrated it I think within the past year or two.
When given money (both US and many non-US), it ignores it, and you end up with
a blank spot on the paper.

The risks are obvious (to me, at least) and many.

Re: Funny Money article in THE SCIENCES (Kabay, RISKS-15.68)

Curtis Jackson <>
Wed, 23 Mar 94 12:35:04 PST
The new versions of the Canon Color Laser Copiers, the CLC 350 and CLC 550
(replacing the former CLC 300 and CLC 500) have exactly this type of
protection built in, supposedly at the request (?demand?) of the U.S.
government. I have no insight into the method used to prevent the copying of
U.S. currency; I only know that the protection is in place in these products.

Curtis Jackson   or

Re: Funny Money (Mich Kabay, RISKS-15.68)

Tobias Ulmer <>
Fri, 25 Mar 1994 13:04:27 +0100 (MEZ)
Such photocopiers are already in existence. I remember a demonstration in
the German "Knoff-hoff" TV show (an entertainment show dealing with
popular-science topics; and yes, the name is indeed derived from "know how")
about one or two years ago. On the occasion of the introduction of new
Deutsch-Mark bills at that time, the host explained the techniques that
were used to make the bills counterfeit-proof. He finally concluded the
discussion by taking a bank-note out of his wallet and laying it on a
photocopier that he announced to be one of the latest inventions regarding
the growing problem of counterfeit by use of those rapidly spreading
color copiers. He pressed the button, not forgetting to mention smilingly
that he was only allowed to do so because they had obtained a special
permission and with police officers sitting in the first row of the
audience, watching closely. What the machine produced was a verbatim
copy of the bill but with colors changed to brilliant pop art. The host
then showed a microchip that was the nucleus of the device that was said
to recognize some dozens of bills from various currencies.

I would not expect such a chip to contain any such thing as protection
codes to activate/deactivate the pattern recognition circuit, but instead
a non-alterable read-only memory holding the images of the bills. So the
difficulty isn't to protect the chip against being cracked but to prevent
that its inhibiting output signal be disabled by means of a simple short
cut. This can only be accomplished if some part of the system that is
essential to the copying process is incorporated within that same
microchip. The system has to be designed in such a manner that you cannot
get the copier working without that chip so that it has the power to decide
whether or not to copy. On the other hand, little can be done against a
criminal attempt to replace the entire electronic control circuit board.

A more severe problem seems to be the fact that every once in a while new
bills keep coming up which the device wouldn't yet be able to recognize. This
requires that it is ensured that of every such existing copying machine the
built-in firmware be updated (by replacing the chip with a newer version)
every time when new notes are introduced with (at least) any of the leading
currencies in the world.

Tobias Ulmer (
Student of Electrical Engineering

Re: RISKs of safe ATMs (Markowitz, RISKS-15.68)

M. Hedlund <>
23 Mar 1994 13:14:52 -0800
>  "[...] if a thief tries to use a card which has been stolen, our ATMs
>  are programmed to lock the doors and call the police. [...]"
>So if you use one of their cards, you had better hope that there are no
>data entry errors when a card with an account number similar to yours is
>reported stolen. [...]

That's not'd also better hope: (1) you're not inside those doors
when an actual thief tries to use a stolen card, not knowing or not caring
about the "security" measures; (2) no natural nor manmade disasters occur
while you're waiting for release; (3) the police know how to unlock the door;
(4) your boss doesn't walk by the ATM atrium while you're stuck; (5) the bank
installs a restroom (or at least, that you don't happen to need one); (6) the
automated system succeeds in reaching the police and conveying your location;
(7) the bank doesn't decide they're getting better use of your money while
you're penned up.....

M. Hedlund     <>

Re: Comment on earlier posting (Norman, RISKS-15.68)

Marcus J Ranum <>
23 Mar 1994 22:16:32 GMT
>In my defense, however (the never-give-up defense), I still wish to argue
>that spelling errors are a result of what would amount to "poor design"
>were language and spelling actually designed.

    How can something that wasn't "designed" be an example of poor design?

    Languages evolve (with exceptions like volapuk and esperanto) rather
than being created from whole cloth by some rational process.  Obsoleting a
"living" language is a lot harder than fixing a programming language -- the
installed base is potentially huge. Some legacy systems still actively
communicate using Latin.

    English, with all its commas and apostrophes and other bits of charm,
is the result of a process of *translation* between the street English of the
day and an approximation of written English. If I tried to write some of the
street speech from my neighborhood in ascii, it might look a lot like,
"yo'm'a, cah yuh spa' me a qua'tuh?"  Unlike compiled languages used by
computers, spoken languages don't *NEED* to be designed and probably never
will (the feelings of L'Academie Francaise aside).

    Human minds are flexible enough to cope with the vagaries of "badly
designed" languages. Spelling mistakes are a result of inattention to detail,
ignorance, or apathy. The good news is that generally, the listener/reader
will relatively painlessly absorb the error, rather than dumping core or
giving a cryptic error like my compiler does when I forget punctuation.

CFP: 2nd ACM Conference on Computer and Communications Security

Li Gong <>
Fri, 25 Mar 94 15:11:20 -0800
               Call for Papers
          2nd ACM Conference on Computer and
               Communications Security
                 Nov 2-4 1994
              Fairfax, Virginia

Sponsored by: ACM SIGSAC, Hosted by: Bell Atlantic, George Mason University

High quality unpublished original research and practice papers in the area of
computers and communications security are invited for consideration for the
2nd ACM Conference on Computer and Communications Security.  All aspects of
security are relevant, including:-

THEORY AND TECHNIQUES: Access Control, Cryptanalysis, Digital Signatures,
Intrusion Detection, Audit, Cryptosystems, Formal Models, Randomness,
Authentication, Cryptographic Protocols, Hash Functions, Viruses and Worms,
Authorization, Database Security, Integrity, Zero Knowledge.

Security APIs, Smart Cards, Electronic Commerce, Network Firewalls, Security
Architectures, Telecommunications Security, Enterprise Security, Open Systems
Security, Security Management, WAN Security.

SOCIAL AND POLICY ISSUES: Cryptographic standards, Information Privacy, Legal
Issues, Technology Export.



Format: FIVE copies of your paper (not to exceed 7500 words) in a form
suitable for ANONYMOUS review (no author names, affiliations, obvious
references, etc.) and a cover sheet with author name(s), address, phone and
fax.  Where possible all communications to authors will be via e-mail, so
PLEASE PROVIDE an e-mail address.

SUBMIT TO: Prof. Ravi Sandhu, ISSE Dept., MS 4A4, George Mason University,
Fairfax, VA 22030, USA (Ph#: 703-993-1659 E-Mail: or
Prof. Jacques Stern, ENS/ DMI, 45 rue d'Ulm, 75230-05 Paris, France (Ph# 1 44
32 20 29 E-Mail:

Deadline: Papers must reach us by JUNE 1, 1994. Sorry, we cannot accept late
submissions, and they will be returned unopened.

Authors will be notified of the Program Committee's decision by AUGUST 5,
1994, and will have to submit final camera ready papers by AUGUST 26, 1994.

GENERAL CHAIRS Dorothy Denning, Georgetown U and Raymond Pyle, Bell Atlantic

PROGRAM CHAIRS Ravi Ganesan, Bell Atlantic and Ravi Sandhu, George Mason U

TREASURER Richard Graveman, Bellcore



  Steve Bellovin, AT&T          Eli Biham, Technion
  Joan Feigenbaum, AT&T         Virgil Gligor, U of MD
  Li Gong, SRI                  Rich Graveman, Bellcore
  Sushil Jajodia, GMU           John Kimmins, Bellcore
  Carl Landwehr, NRL            Stewart Lee, U of Toronto
  David Maher, AT&T             Roger Needham, Cambridge
  Clifford Neuman, USC ISI      Paul Oorschott, BNR
  Bart Preneel, KUL             P. Samarati, U of Milan
  Robert Shirey, MITRE          Jacques Stern, ENS/DMI
  Byron Stump, Bell Atlantic    Paul Syverson, NRL
  Bhavani Thuraisingham, MITRE  Roger Tjarks, SAIC
  Michael Wiener, BNR           Raphael Yahalom, Hebrew U

Please report problems with the web pages to the maintainer