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 4 Issue 26

Wednesday, 10 December 1986

Contents

o Computer Error Endangers Hardware
Nancy I. Garman
o "One of the Worst Days Ever for Muni Metro, BART"
PGN
o Korean Air Lines Flight 007
Steve Jong
o Plug Compatible Modules; Criminal Encryption
David Fetrow
o More on skyscraper control
Mike Ekberg
o Satellite interference
James D. Carlson
o (Il)legal Encryption
Richard Outerbridge
o Software article in _Computer Design_
Walt Thode
o Heavy metal and light algorithms
PGN
o Suit against Lotus dropped
Bill Sommerfeld
o Info on RISKS (comp.risks)

Computer Error Endangers Hardware

Nancy I. Garman <ngarman@venera.isi.edu>
Wed, 10 Dec 86 08:44:43 PST
I work for a group that also manages an offsite computer center.  There has
been so much difficulty with the contractor who is supposed to keep the
floor clean that our hardware folks were worried about disk drive
contamination from the dirty floor.

I spoke with the Director of Sales for the cleaning company.  He blamed their
computer for the dirty computer room floor that was risking damage to our disk
drives.  Apparently, their computer had us erroneously scheduled for fewer
cleanings than our contract called for.  

Of course, it is likely to be a data entry error.  Still, it makes me wonder -
what does their computer have against our computers?!

- Nancy Garman
  NGarman@VENERA.ISI.EDU


"One of the Worst Days Ever for Muni Metro, BART"

Peter G. Neumann <Neumann@CSL.SRI.COM>
Wed 10 Dec 86 17:38:57-PST
(From an article by Harry W. Demoro and Carl Nolte in the San Francisco
Chronicle, 10 December 1986, p. 2.)

"... doors, signals, switches, brakes, and even a speedometer broke."

The worst mess began at 6 a.m. when an electrical short circuit caused
a "ghost train" to appear on the signaling equipment that guides Muni
Metro streetcars in and out of the Embarcadero station.  [This prevented
the switches from working automatically.]  Muni troubleshooters did not
eliminate the "ghost train" until 8:14 a.m...

By that time BART was a mess...  [for the second morning in a row]  At 5:10
a.m., a train broke down at the Richmond Yard.  Then at 7:10 a.m., the
switches that route trains through the MacArthur station in Oakland stuck,
creating a bottleneck because two lines converge there.  [Workers used hand
cranks.] The problem was fixed at 9.07 a.m.  Also at 9:07, switches stuck at
the Daly City station (18 miles away).

At 7:14 a.m. a door stuck open at MacArthur.  At 7:25 a.m. a train was taken
out of service because brakes locked for no apparent reason.  At 7:33 a.m. a
train stalled when the door stuck.  At 8:04 a.m. another train broke down in
the repair yard.  At 8:38 a.m., a train refused to budge because of a stuck
door.  At 9 a.m the speedometer stuck on a train, which had to be sidetracked.
At 10:28 a.m. another train was stalled by a stuck door.  The problem
"finally cleared itself up at noon," said a spokesman.  [Bad Car-ma resolved?]

Things have been fairly smooth for BART and Metro Muni for some time.  I
don't recall BART having such a disastrous day since 6 years ago.  (See
Software Engineering Notes 6 1, January 1981)  The "ghost train" problem 
had plagued Muni Metro in its early days, but I had not heard about it
recently.  (See Software Engineering Notes 8 3, July 1983)

Although the computer systems were not implicated, this "bad day" serves
to remind us that when we plan for things not going well, we need to plan
for things going REALLY BADLY.  


Korean Air Lines Flight 007

Steve Jong/NaC Pubs <jong%derep.DEC@decwrl.DEC.COM>
Tuesday, 9 Dec 1986 11:07:53-PST
In his book "The Target is Destroyed" (1986), Pulitzer Prize-winning writer
Seymour M. Hirsh strives to explain why Korean Air Lines Flight 007 flew
serenely over the Soviet Union to its doom on September 1, 1983.  Since none
of the crew survived and the flight recorders were never recovered, any
explanation is highly conjectural, but he presents the arguments of a
veteran pilot, one who has flown that route many times.  After exhaustive
studies, including his knowledge of how flight crews work with their
equipment, the pilot concluded that a combination of human errors caused the
navigational snafu.  One of the errors was postulated to be a well-known
blind faith in the plane's inertial navigation system (INS).

This triply-redundant, highly accurate system flies the plane automatically
once coordinates are entered.  The crew enters starting, ending, and
"waystation" coordinates into each of the three components.  If there is an
entry error, or if the plane seems off course, an alarm sounds.

The full scenario is too complex to cover here, but the gist of it
is that a crew member fat-fingered the "you are here" coordinates.

How is it a RISK?  Consider the anecdotal evidence of other flights:

o   Crews place complete faith in INS.  They don't have to fly the
    plane, and sometimes have been known to nap in the cockpit.

o   Crews trust INS more than their radar.  The pilot who
    developed this scenario said if the KAL crew looked at
    their radar and saw the Kamchatka Penninsula where there
    should have been open ocean, they probably shut off the
    radar, because the INS was functioning normally.

o   The INS is so sensitive that if the plane strays down the
    wrong taxiway, it sounds off.  Crews will shut off the alarm.

o   Entry errors are common on long flights, because crews must
    enter three sets of ten coordinates (over a hundred numbers).

o   Though it is strictly against airline policy to do so, at
    the touch of a button the crew can "autoload" coordinates
    from one INS to another.

If you accept the scenario, 269 people died at least partly because of blind
faith in computers and a tedious interface that was too simply circumvented.

    [Reminder:  There are quite a few books on this subject.  Each tries to
     justify its own theory, but all seem to come to somewhat different
     conclusions.  PGN]


Plug Compatible Modules; Criminal Encryption

David Fetrow <fetrow@entropy.ms.washington.edu>
Mon, 8 Dec 86 01:45:09 PST
 Item 1: Plug Compatible Modules

 Concerning the Nurse who accidentally electrocuted a little girl by plugging
in AC power to heart monitor electrodes at Seattles' Childrens' Orthopedic.

 AP gave the impression that the heart-monitor plug was like a wall-plug. This
was not the case: The heart monitor plug consisted of three simple metal probes
(like those on an ohm meter). They were accidentally plugged into the slots
of the female end of an AC extension cord; which resembled the unit the probes
should have been attached to. The solution doesn't change: make unique plugs
for everthing around an ICU patient. (Source: KING TV on camera interview with
hospital administrator).

 Item 2: Criminal Encryption

 I remember reading in the Seattle Times a couple years ago about a computer
expert who encrypted his kid-porn information on a disk. The police had a
warrant for his files but couldn't crack the encryption. They turned to
hacker who tried the "decrypt" command without a key. It worked; the
evidence was admissible.  [No documentation for this one, though.]


More on skyscraper control

Mike Ekberg <weitek!mae@decwrl.DEC.COM>
Fri, 5 Dec 86 17:11:15 pst
One of the buildings in Boston is indeed balanced by computer. I think it
is the John Hancock Building.

At any rate, the building was designed by I.M. Pei, a rather famous architect.
It was one of the first buildings ever built that is a parallelpiped with
non-90 degree angles. The skin of the building is almost solid glass. Soon
after the building was finished, glass sheets began falling off the building
onto the plaza below. (I don't know if anybody was squashed) This only occured
when the wind blew.

An aeronautical engineer at nearby MIT found out why the glass fell. He 
modelled the building as an vertical aircraft wing fixed on the bottom end.
When the wind blows, the wing(building) generates lift on one side. The
upper part of the building twists and window dimensions are altered causing
the glass to fall.

The solution was to install in the upper floor a large weight controlled by
computer. When the computer detects the building being twisted, it counters
the torque by moving this weight. 

In addition, all the glass in the building was replaced with a type more 
resistant to the effects of the building being twisted. The new glass has the
property that its optical characteristics are significantly modified 
when the panes are twisted. In periods of high wind, spotters near the 
building can monitor its status by using binolculars looking at sections
of glass.

mike   {turtlevax,cae780,pyramid}!weitek!mae

PS Most of this was related to me by a structural engineer living in Boston.


Satellite interference

James D. Carlson <jc37@andrew.cmu.edu>
Mon, 8 Dec 86 20:06:02 est
  From Lauren Weinstein:

  > While misaimings and such are fairly common, they rarely result in total
  > capture of a satellite transponder, since it takes considerable power to
  > completely override the main signal.  In the case of the described 
  > problem with CNN Headline News, the explanation is almost certainly very 
  > simple and has nothing whatever to do with interfering signals.

Unfortunately, uplink signals are usually fairly weak, about one watt,
since they are very narrow beam.  The uplink is also frequency
modulated, which means that another signal only 1dB stronger aimed in
the same direction will take over the satellite's receiver.


(Il)legal Encryption

Richard Outerbridge <outer%csri.toronto.edu@RELAY.CS.NET>
Mon, 8 Dec 86 20:41:18 est
In >The Codebreakers< David Kahn tells of several cases involving crooks,
codes and evidence, but none with 5th amendment implications.  A related
issue is high-order homophonic and "subliminal channel" coding, which are
capable of conveying two (or more) legitimate messages depending on the
key employed: using Key A out pops Grandma's secret recipe for marzipan;
use Key B and out pops the chemistry of the latest designer drug.  Even
were I legally compelled to divulge my keys, if the analyst can't find
'Key B' how can he prove that I haven't complied by revealing 'Key A'?


Software article in _Computer Design_

<thode@nprdc.arpa>
10 December 1986 0824-PST (Wednesday)
There is an article in a recent issue of _Computer Design_ magazine (the
November 15 issue) titled "Approaches to Software Testing Embroiled in
Debate."  Its author is William E. Suydam.  It covers a lot of the same
ground as some of the contributions to this list.  Quotations from David
Parnas, Nancy Leveson, and others are included.  It seems, from my inexpert
perspective, to be a decent summary of the problems in software reliability.

--Walt Thode (thode@NPRDC)


Heavy metal and light algorithms

Peter G. Neumann <Neumann@CSL.SRI.COM>
Wed 10 Dec 86 17:31:32-PST
Dave Parnas called my attention to an oversimplification in which I indulged
when I noted in RISKS-4.20 that "an algorithm is an algorithm is an algorithm"
(This was in connection with Steve Gutfreund's note on encoding algorithms in
"smart metals".)

Indeed, Dave is right in suggesting that "the metal algorithm would be, to a
very useful approximation, a continuous function or at least piecewise
continuous with very few points of discontinuity.  As such it could be much
more easily analyzed and studied than its counterpart as a digital computer
program."

This raises interesting questions about the relative precision, accuracy,
and soundness of "metal algorithms" and comparable analog devices in
general.  The situation is somewhat akin to higher-level programming
languages.  Perhaps one is less likely to make low-level design and program
errors in the directly-implemented analog case, but it is of course still
possible to choose the wrong model.


Suit against Lotus dropped

Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Wed, 10 Dec 86 13:15:08 EST
The following article may be of interest to Risks readers; it is from page
81 (the first page of the business section) of the Boston Globe of 10 Dec 86.

    Lawsuit charging errors in Lotus software dropped
               By Ronald Rosenberg, Globe Staff

  A case seen as a test for settling responsibility when computer software
  fails was dropped yesterday, a victory for an industry that had stood by
  nervously as the issue made its way to court.

  James A. Cummings, Inc., a Florida construction firm, yesterday ended
  its suit against Lotus Development Corp. of Cambridge [Massachusetts],
  a lawsuit that the industry feared could open the door to a host of
  liability claims against software developers.

  In its suit, Cummings had charged that errors in the Lotus software caused
  to underbid on, and lost a contract.  The company had sought $254,000 in
  damages from Lotus, a leading maker of personal computer software.

  If the case had gone to trial, it would have been the first to question
  whether a supplier of software tools, such as Lotus, is liable for wrong
  information produced by users of its programs.

  Neither Cummings nor its attorney, John R. Squitero of Miami, will receive
  anything from Lotus.  Squitero, who talked openly about the case last
  summer, refused to comment yesterday.

  Lotus said that under the termination agreement, Squitero and James A.
  Cummings, president of the Fort Lauderdale contracting company, agreed not
  to discuss [the] case.

  ``Lotus is pleased that this attack upon the integrity of Symphony, one
  [of] our leading products, has ended with the complete vindication of both
  Symphony and Lotus,'' said Jim P. Manzi, Lotus chairman and president.

  Squitero had expected to fly to Boston yesterday to take depositions from
  Lotus employees. Late Monday evening, Squitero decided to throw in the towel.

  ``I think they (Cummings and Squitero) hoped that there would be a financial
  settlement by now, and we persuaded them that we would never settle -- not a
  penny,'' said Hank Gutman, an attorney with O'Sullivan, Graev and Karabell
  of New York, which represented Lotus.

  Peter Marx, general counsel to the Information Industry Assn., a trade
  organization for 500 software and computer companies including Lotus,
  applauded the dismissal:

  ``Our fear was that as long as the case was hanging out, it might have
  encouraged creative lawyers to file suits that have no merit.'' 

Please report problems with the web pages to the maintainer

Top