The RISKS Digest
Volume 12 Issue 54

Tuesday, 22nd October 1991

Forum on Risks to the Public in Computers and Related Systems

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

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


Oki Telephone Programming
Stuart Bell
Nintendo lottery sidetracked for now
Single Point of Failure in L-1011 Intercom
Craig H. Seidel
Computer reads water meter
John Sullivan
Risks of software controlled safety switch
Diomidis Spinellis
Re: Licensing of Software Engineers
David Parnas
Law requiring bug fixes
Mark Seecof
Re: Yet another journalistic...
Amos Shapir
More ATM anecdotes
Ralph Moonen
Re: TRW misreports local taxes
Matt Bishop
Re: JSC SMS rehost
David Carlson
Avis vs. Spaf
Gene Spafford
Re: Have you tested your machine lately?
Boyd Roberts
Info on RISKS (comp.risks)

Oki Telephone Programming

Stuart Bell <>
Tuesday, 22 Oct 1991 09:28:11 EDT
My wife just purchased one of the new Oki programmable cellular telephones with
a built in beeper.  When it didn't beep for a day or so, we tried to originate
a call and found it had not been activated by the vendor.  No problem, he said,
"Just bring it in and I'll change its number to the one I entered by accident."
Turns out, he had accidentally transcribed a number so the incorrect number was

My wife objected to the trip - so the man nicely explained how to reprogram
the internal memory and change the number of the telephone!

The risk is obvious: tired of paying those high telephone bills and don't know
where to buy one of the chips described earlier in RISKS that change your
telephone number?  Just buy an Oki and reprogram it to any number (within
limits) you choose and off you go.

Or, examine your bills very carefully.         Stu Bell      (713) 333-0906

Nintendo lottery sidetracked for now (See RISKS-12.27,39,41,42)

"Peter G. Neumann" <>
Fri, 18 Oct 91 16:45:20 PDT
     Game Over For Nintendo Lottery
   MINNEAPOLIS (AP) [18Oct91]
   A controversial plan to introduce the state lottery into homes with the
popular Nintendo video games was dropped amid complaints it would harm children
and encourage compulsive gambling.  State Lottery Director George Andersen said
more discussion of the play-at-home system the first such plan unveiled in the
nation is warranted in light of lawmakers' complaints.  "I still think it's a
good idea," he said. "But we never want to operate without as broad a consensus
as we can."   [...]

Single Point of Failure in L-1011 Intercom

Tue, 22 Oct 91 16:23:38 -0700
On October 19 I was on TWA Flight 843 from JFK to SFO which was delayed 2 1/2
hours while repair crews located and repaired a wiring harness in the intercom
system used for communications through the aircraft.  The intercom is essential
for safe operations because it is used for communications in case of any
emergency in-flight (for example, on another flight a Pan Am pilot told me of
the time a flight attendant informed him that a wing-tip fuel tank was losing
fuel, something he could not see from the cockpit).

What I found interesting about the intercom system is that it is wired like
christmas tree lights where any failure in the chain causes a complete failure
and requires a check of each component.  If this is truly an essential system,
I would expect more redundancy--I can imagine many emergencies that would
disable this system.

The intercom wiring harness in the TWA L-1011 simply wore out (each time the
flight attentant sits down, the harness is bent), a consequence of flying
planes for so many years.  What will happen to modern fly-by-wire aircraft
after they have been in the air for 30 years?

Computer reads water meter

Tue, 22 Oct 91 19:14:12 CDT
Minneapolis will be introducing "Easy Reader", a computerized water meter
reading system, over the next five years.  You get a new meter and an interface
unit plugged into your phone line.  Once a month, a reading will be taken
automatically, and sent to a central billing computer.  This will happen
between midnight and 7am.  Presumably the unit in your house places the call;
they say "Your telephone will not ring".

They have anticipated several objections people might have to the service.
They promise your phone service will not be interrupted: "If you do happen to
be on the phone ... Easy Reader will get a busy signal [sic] and try again
later.  If you pick up the phone while the meter is being read, [it] will
instantly disconnect."

They also reassure you that nobody will use this equipment to listen in to your
phone conversations, and perhaps most curiously, reassure people with unlisted
numbers that "Telephone numbers need only be disclosed during the installation
of the system.  After the initial contact with your home phone has been made,
your number is no longer needed.  The Water Works will gladly respect your
privacy by not recordeing your number anywhere in its files."  Why would they
even need the number temporarily to set up service?

They don't promise that the system won't accidentally dial 911 in the middle of
the night :-)
                   John Sullivan, Univ. of Minnesota,

Risks of software controlled safety switch

Diomidis Spinellis <>
Tue, 22 Oct 91 18:56:19 BST
A portable CD player I was experimenting with, features a safety switch,
located on the hatch door, which turns the unit off once the door is opened.
The role of that switch is to ensure that the laser in the unit will not
operate with the door open.  A number of other appliances (microwave ovens come
to mind) have similar safety switches.

One day I decided to deeply discharge the batteries of the unit (i.e., drain
the them as much as possible) as a precaution against the NicCad "memory
effect."  The unit has an auto-power-off feature whereby when the batterie
voltage falls bellow a certain level it switches itself off.  Every time the
unit switched itself off, I pressed "play" again to switch it on.  The
objective of this procedure was to drain the batteries as much as possible.
After some time the unit crashed.  The display had some strange segments lit
and the auto-power-off feature was no longer functioning.  My first conclusion
was that the auto-power-off was software controlled.  My next move was to check
what other things were software controlled.  I plugged mains power to the unit
so that I would not loose this crashed state and tried opening the hatch door.
As I was expecting the safety switch was also, apperently, software controled
because the unit remained on.  Now, I was faced with a unit turned on, with
full power applied to it and with an open door hatch.

Moral: Software emulation of safety interlocks is not a good idea.  Even with
formaly proven correct software, we would still need hardware that was formaly
proven to correctly function under all probable conditions to implement a safe
product.  Direct control methods (such as a switch connected to the power
supply in this case) are more appropriate.

Diomidis Spinellis, Department of Computing, Imperial College

Re: Licensing of Software Engineers (RISKS-12.52)

David Parnas <parnas@qusunt.eng.McMaster.CA>
Tue, 22 Oct 91 12:59:10 EDT
There seems to be a false assumption in some of the comments made by those who
fear this concept.  They assume that the body that issues the licenses is the
government.  That is not the case for other engineers.  In many jurisdictions
there is a professional body that is charged with this task. In Ontario it is
the APEO, Association of Professional Engineers of Ontario.  In Australia there
is an "Institution of Engineers".  Thus, it becomes the job of professionals to
set the standards for their own profession and to enforce them.  Why should the
software field be different?

Law requiring bug fixes (Hanlon, self-regulation, RISKS-12.52)

Mark Seecof <>
Tue, 22 Oct 91 11:20:02 -0700
In RISKS-12.52 Richard Hanlon suggests:

> ..with a minimal intrusion by the government, [by] making it a law to
> provide free bug fixes (there's ALWAYS at least one more bug).

Such a law might have horrible consequences for software vendors.
Fred Brooks in _The Mythical Man Month_ (Addison-Wesley, Menlo Park, 1982)
reports (in Ch. 11, adducing evidence which I've elided here) that:

  The fundamental problem with program maintenance is that fixing a defect
  has a substantial (20-50 percent) change of introducing another.  So the
  whole process is two steps forward and one step back.


  ...All repairs tend to destroy the structure [of the software], to increase
  the entropy and disorder of the system.  Less and less effort is spent on
  fixing original design flaws; more and more is spent on fixing flaws
  introduced by earlier fixes.  As time passes, the system becomes less and
  less well-ordered.  Sooner or later the fixing ceases to gain any ground.
  Each forward step is matched by a backward one.  Although in principle
  usable forever, the system has worn out as a base for progress. [...]
  Systems program building is an entropy-decreasing process, hence inherently
  metastable.  Program maintenance is an entropy-increasing process, and even
  its most skillfull execution only delays the subsidence of the system into
  unfixable obsolescence.

So I suggest that any law interfering with the allocation of resources to
maintenance or development (often of a replacement system) by the presumably
expert management of a software vendor would be unwise and ultimately
destructive.  Customers exercising a legal privilege to demand that bugs in a
senescent system be fixed could force a software vendor right into the Pit of
                        Mark Seecof <>

Re: Yet another journalistic ...

amos shapir <>
Tue, 22 Oct 91 09:03:58 +0200
>    I've listed the relevant allegations - I guess Amos Shapir or
>       somebody will probably send you the full article.

Well, the full article is too long to post (and nothing new to most RISKS
readers).  I agree with most of Simon's conclusions, but there are some
inaccuracies in his quotes.  I understand his indignation at having *his*
system exposed in public, but he'd rather leave the posting to the guy who had
actually read the article.

>    Four years ago, he broke into her account - he claims
> that by chance, her password happened to be the same at the time of the
> demonstration. I have no evidence to contradict this,although it seems more
> likely that he guessed her current password using the information he had from
> the old one.

Actually, she was asked about it and is quoted in the article as admitting
to reusing the same old password.

> Claim #2: He stated that the account name had a prefix which indicated that
>           the account was special, and that this showed how naive the system
>           managers were.

(This is not a correction, it just reminds me of something that happened here).
On CDC's NOS system, privileged accounts are the ones which begin with a C.
You can guess what happened when a somewhat ignorant administrator assigned the
Computer Science department accounts which begin with CS...

> Claim #6: He claimed he could destroy all the back-ups.
> Lie:  Maybe if he stuck  magnets on a few  SCUD-C's and lobbed them at the
>       various tape archives. It's a lot harder to spoof a human being,
>       especially when you're a 24 year old male, and the spoofee is a 50ish
>       woman.

Not exactly.  What the cracker claimed was that he could use the
administrator's account to ask operators to mount the backup tapes, then
destroy them; the operators could have no way of knowing that the request
wasn't legitimate.  The spokesman's response in the article is along the line
"if we'd get such a request we'd probably call back and ask what it's for".

Amos Shapir, The Hebrew Univ. of Jerusalem, Dept. of Comp. Science.
Givat-Ram, Jerusalem 91904, Israel     Tel. +972 2 585706

More ATM anecdotes

Ralph 'Hairy' Moonen <hvlpa!>
Tue, 22 Oct 91 11:17 MET
I am a frequent user of ATM's.  As banks in The Netherlands are closed after
17:00 and in the weekends, the only way you are going to get cash after that
time is through an ATM.  Unfortunately not all off them are the same, and some
display a most peculiar behaviour.  Example:

ATM: INsert card
Me:  I insert my card
ATM: key in your PIN code.
Me:  I do so.
ATM: There are no receipts available currently. Choose the amount of cash you
     wish to withdraw.
Me:  I choose 100 Guilders
ATM: There are no receipts available currently. Do you want a receipt?
Me:  I press the "No" key.
ATM: We're sorry, there are no receipts available currently.
ATM: Please wait.....
ATM: Retrieve cash from ATM please. There are no receipts available currently.
Me:  I KNOW THERE ARE NO RECEIPTS!!! Please quit whinig and give me my money.
[withdrawal hatch opens, and my money is there, so I take it]
ATM: Please take your card out.
Me:  I take my card out.
ATM: Please wait for your receipt. There are no receipts available currently.

RISKS?  Well, none really, but quite frustrating.....  Another example is funny
stuff is the banks apparently can edit the on-screen messages on the fly, for
once I was making a withdrawal, and the screen is flashing a bank advertisement
on the bottom two lines.  Something like: "Open a new account now, and receive
this great CD with the greatest hits of 1991, PLUS a whopping 5.4% interest"
When suddenly, the cursor moved to that line, and lo and behold, they edited
the interest rate.  The ATM continued my trans- action perfectly, but is was
pretty weird to see the line edited *on-screen*.

For a last weird stuff thing, I once arrived at an ATM, that looked in pretty
bad shape.  Someone had apparently drank too much and decided to unload his
lunch over the keyboard.  I took one look and decided to, well, not make the
planned transaction.  At that point a van stopped and some service guy gets
out.  So I wait and see.  The guy goes through a door next to the ATM, does
something to the inside, comes out, and lifts the complete front off.  Puts it
into his van, and replaces it with a new one.  I asked why, and he said well,
would you like to have to poke in someone others puke.  I said, but you don't
need to replace the whole *front* for that, you could just clean it!  The
answer was a vague story about disinfecting the thing, and AIDS (!!)  and that
he didn't fancy having to clean it.
                                     --Ralph Moonen

Re: TRW misreports local taxes (DeBoer, RISKS-12.52)

Matt Bishop <>
Tue, 22 Oct 91 09:06:29 -0400
> Why is it that inaccurately negative credit reporting [doesn't | shouldn't]
> constitute libel under the law?

It's (US federal) law.  As I understand it (admittedly, I'm no lawyer), the
credit reporting agencies are protected unless they maliciously report the
information.  If they make a mistake, that's not actionable.  (The explanation
given to me also included the statement, "Well, they have so many records, you
can't expect them to have everything right, so as long as their errors aren't
deliberate, they shouldn't have to pay."  Unfortunately, I don't remember WHO
gave me that explanation but I'd be interested in knowing if that is in fact
the reason behind the law shielding the agencies.)

Re: JSC SMS rehost (RISKS-12.47,48,49)

David Carlson <>
Fri, 18 Oct 91 9:49:38 EDT
I read recently in RISKS the serious question by a Johnson Space Center
employee on the risks of rehosting a large realtime program currently on
minicomputers manufactured by my company.  It was some amusement that two
contributers offered parochial suggestions that their favorite hardware was
clearly the "right" choice for such a large problem.  This misses (and yet
reinforces) the point the original contributor made that cost of the rehost to
IBM/workstations would be larger than understood by management.

The reinforcement of the original idea is that the two followup contributors
answered a software complexity unknown by asserting "it will be easy using

Avis vs. Spaf

Gene Spafford <>
Fri, 18 Oct 91 21:41:37 EST
Yesterday, I flew into Chicago O'Hare airport from Vienna, Austria.  I wasn't
too awfully jet-lagged, and rather than wait 8 hours for the next flight to
West Lafayette, I decided to cash in my ticket and rent a car one-way. (West
Lafayette is a 2.5 hour drive from O'Hare.)

I got to the car no problem.  The agent at the counter said it was in stall
J-32, and that is where the bus dropped me.  So, the keys were in the ignition
and the driver's side door was unlocked.  I threw my coat in and tried to open
the back door to toss in my portable PC.  It was locked.  So, I hit the
powerlock button on the driver's side door to unlock all the doors, and then
went to get my PC.  A gust of wind blew the driver's side door shut.  I then
discovered I had LOCKED all the doors by pushing the button the wrong way!
(This was a Chevy Lumina.)  On my old 1975 car, one must hold the handle out
when closing it, or lock it with the key after closing — a form of fail-safe
behavior compared to this.

To make matters worse, the car was to be rented one-way, so they had given me a
car originally from Maryland...with no duplicate keys to be had locally.  It
took 2 of their mechanics working together for about 30 minutes to break into
the car without excessive damage.  If my coat hadn't been in the car, they
would have just rented me a different one.  Sigh.

But wait, it gets better!  On the way our of the lot, the guard checked my
rental agreement against the sticker on the car.  The numbers didn't match!  I
had to go back because I had the wrong car for the agreement, and he couldn't
let it out of the lot.

The woman at the counter sort of rolled her eyes when I came back in for the
third time, but she forced a smile and said that rather than switch the car,
she would just adjust the contract to show the car I had.  Some quick
keypresses, a new contract agreement off the printer, and I was on my way.

This morning, I drove the car out to the airport here to return it and pick up
my car in the parking lot.  As I was transfering my briefcase & books from
rental car to personal car, the wind must have blown the rental agreement off
the car seat and into the surrounding fields.  I couldn't find it anywhere.

Trudge into the airport.  Give the person at the counter the keys and mumble "I
seem to have lost my agreement somewhere."  No problem — she'll just take the
ID off the keys, enter the final mileage, and print a duplicate agreement.  The
benefit of having one of those marvelous computer networks, eh?

So, she puts in the mileage and vehicle number, confirms that my rate was $89
with the corporate discount, and prints the receipt.  As she hands it to me,
she smiles and says "Have a nice day Mr. Anderson" (I don't remember the exact
name).  This takes me a bit aback, and I ask "Anderson?"  fearing the worst.  I
look at the rental agreement.  The name, home address, and so forth are not
mine. The agreement shows that the car was rented at Dulles Airport and was not
to be returned until tomorrow — back to Dulles.  It had someone else's credit
card number. It was the correct car, but the wrong renter.

After struggling with the computer for about 20 minutes, the clerk then called
Chicago and spoke to 9 different people (we counted) in 30 minutes before
getting someone who could help find my rental record.  It seems Avis's system
does not allow (for privacy reasons?) any field agent to do a lookup based on
name, based on credit card number, based on rental location, or based on
anything else I had with me or could produce.  It needed either the rental
agreement number, which was lost, or the vehicle ID, which was incorrect.  The
folks in Chicago had to find the duplicate PAPER copy of the rental record in
their files to get the correct number.

Once my agreement was finally corrected, they had to fix the record for "Mr.
Anderson" because he hasn't returned his car.  However, they can't cancel a
transaction in the system, I guess because it might allow employee fraud ("Mr.
Spafford, our records do NOT show a checkin — either produce the car or we
swear out a warrant.").  Instead, they have to issue a special form of checkout
that negates the effect of the checkin.  Unfortunately, the computer now showed
that the vehicle was checked in, because the local office had file a record to
indicate they had the car.  The system won't allow a car marked as present at a
local office to also be marked as "rented."

Between Chicago and locally, they decided to take the car "out of service"
somehow, thus removing it from the ken of the system.  They then did a
correction checkout on Mr. Anderson.  He's in for a surprise, probably, when he
tries to check HIS car in tomorrow.  I hope he doesn't have a flight to catch.
Then again, maybe he'll do an express checkin where he simply throws the keys
and the agreement envelope into a mailslot, and add even more entropy into the

This whole mess took almost 45 minutes to get straightened out.  I bet their
records are still messed up, with the car I had now marked out of service and
some other car lost in the system.  I wonder if they will ever get it evened
out.  As for me, no more rentals on windy days!

Re: Have you tested your machine lately?

Thu, 17 Oct 91 13:14:35 +0100
Two weeks ago we had a power outage which damaged various bits of hardware
in some of our DECstation 5000's.  I had been out of the lab for 8-10 days
and I wasn't around when the outage occurred.  So I wasn't really sure of
the state of the world, but it didn't sound good.

I log in on my 5000 (it has two big colour screens and runs X) and immediately
I see some _very strange_ things happening.

    1. `sunclock' paints a white icon and then exits.

       `sunclock' shows a map of the world with the land illuminated by the sun
       in white, and the dark areas in black.

    2. `xman's buttons are missing the semi-circular edges on the left
       hand side of the buttons.

       `xman' is the X implementation of `man'.

    3. Clicking on some of `xrn's buttons crashes my X server.

       `xrn' is an X based newsreader.

    4. Most everthing else works.

At this stage I conclude that something is seriously wrong.  But just where is
the problem?  Is it the X clients, the server, a font problem, the display or a
real machine problem?  I just don't know, so I have to go looking.

So I start with `sunclock' because I believe that it is probably a simple
system and a sound test case.  I was right, but I dismissed my conclusion
because I don't trust the debugger I was using (`ups').  `ups' was telling me
that the math library was returning NaN and `sunclock' would use this bogus
value, compute with it, and then index off the end of an array — and dump

I wasn't trusting `ups' because it likes to second guess the compiler on ULTRIX
4.2.  It _knows_ where the SP is.  When it sees the SP is not where it should
be it aborts.  I commented the line out, and it works, but I don't place a
great deal of trust in it, given my knowledge of the MIPS archictecure/compiler
is not large.

So where to next?  Is it in the X server?  We have quite a few field test X
servers here, and maybe the new wiz bang version will fix this.  After trying a
few I conclude that this is not the case.

Is it in the display hardware?  So I board swap the display hardware and then
reboot.  This is what I should have done in the first place.  The self test
tells me the FPU failed its self test, and I conclude that it's returning
garbage to the math library.

All the software using floating point is broken — in mysterious ways.

This consumed a day of my time.  The thing that really worries me is that when
confonted with a problem with these `modern' systems you just have too many
variables of which you have to know _a lot_ about to diagnose the problem.  I
can't see this trend ending.  In the future I can see that 5 or 6 people with
diverse, non-intersecting knowledge will be required to analyse the simplist of
problems.  This is a disturbing conclusion.
                                                     Boyd Roberts

Please report problems with the web pages to the maintainer