The RISKS Digest
Volume 4 Issue 48

Wednesday, 18th February 1987

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…


o Four near air misses in 1986; Radar failure
Lindsay F. Marshall
o Computer failure causes flight delays
Rodney Hoffman
o Real RISKS (as opposed to virtual risks) of aircraft
Eugene Miya
o Trojan Horse alert
Al Stangenberger
o Computerized Town Data Vanish
Jerry Leichter
o Re: UCSD work on human error
Alexander Glockner
o Connector risk
Rob Horn
o Re: Electronic steering
Brint Cooper
o Info on RISKS (comp.risks)

Four near air misses in 1986

"Lindsay F. Marshall" <>
Wed, 18 Feb 87 10:11:29 GMT
          From the Observer 15th Feb 87:

17 March 86. A crowded One-Eleven jet and a Short 330 commuter aircraft descend
to land simultaneously on Aberdeen's single runway.  The jet screams over the
top of the slower plane, cuts through its descent path, then aborts landing,
narrowly averting catastrophe.  An Aberdeen radar controller is blamed.

28 November 86.  An Iran Air jumbo jet is told to stay at 6,000ft but instead
climbs and almost collides with an Air UK Fokker F27 in holding stack over
Heathrow.  The Iranian crew's poor English makes analysis of the incident

13 December 86.  Over Detling, Kent, a Britannia Airways 737 from Luton to
Munich comes within half a mile of a One-Eleven bound for Amsterdam from
Gatwick.  The controller handling 14 aircraft simultaneously, had forgotten
the 737's existence.

22 December 86.  A British Midland One-Eleven en route from Heathrow to
Leeds is instructed to climb to 28,000ft.  Over Cranfield, Bedfordshire, it
passes a United States Air Force KC135 tanker aircraft crossing the airway
at the same altitude. The pilot of the passenger jet takes evasive action.
A trainee controller had forgotten the presence of the military jet.

Radar failure (From the Observer 15th Feb 87)

<"Lindsay F. Marshall" <<>
Wed, 18 Feb 87 10:11:58 GMT
At 6.30 a.m. on 15 November 1986 the London Air Traffic Control Centre (LATCC)
at West Drayton suffered a total loss of main power as the morning rush of
flights began.  A standby generator also failed.  Radar screens covering Wales
and England south of Newcastle went blank.  The IBM 9020 computer shut down,
halting updating of flight progress strips.  Controllers had to revert to
writing strips manually.

Radio contact with aircraft was precariously maintained by a battery supply
with a life of 30 minutes.  Pilots continued to fly in the busy airspace
without radar by scrupulously maintaining their separation from other
planes.  But without radar monitoring by controllers on the ground little
could have been done if a jet had strayed.

Power was restored five minutes before the batteries gave out.  The fault
was blamed on a freak sequence of events started by the failure of a small

Managers were eager to clear the backlog of flights but the computer would not
function normally.  It displayed some radar blips but not others.

The LATCC controller said: 'We were pushed to handle more aircraft but refused
because the computer could have gone down at any time.

'There were many near misses that morning, all due to equipment failures.  We
were lucky.  If the same sequence of events occurs in the summer, the effect
does not bear thinking about.'

Computer failure causes flight delays

18 Feb 87 08:06:35 PST (Wednesday)
Excerpted and edited from the Los Angeles Times, Feb. 15, 1987:

            By Dean Murphy

  Flights from airports throughout Southern California were delayed
during most of the day on Friday because of a 30-minute early morning
computer failure at the Los Angeles Air Route Traffic Control Center at
Palmdale, according to Federal Aviation Administration spokesman Russ
Park.  A backup system was activated 14 minutes after the outage.

  The aging computer, known as the 9020, has been the source of numerous
controllers' complaints, and is expected to be replaced later this year.
It provides information abot the flight plans of aircraft over a
180,000-square-mile area of Southern California, southern Utah, southern
Nevada and western Arizona.  Palmdale controllers give flight
instructions to pilots while they are flying above 10,000 feet between
areas that are covered by controllers at individual airports.  The 9020
failed 12 times during the last six months of 1986, with an average
failure time of about four minutes.

  The outage Friday forced air traffic controllers to ground flights for
15 minutes during the morning rush period at airports throughout the
area.  Combined with heavy air traffic and rainy weather, delays
continued through much of the day.  Airport and airline spokesmen said
that most of the delays were minor, describing the situation as more of
an irritation that a significant disruption in service.  The outage
posed no safety hazard to passengers.  Controllers lost flight plan
information — including such things as the flight number, altitude and
airline of each flight — during the 14-minute transition to the backup
system, but they were able to continue tracking the planes on radar

  — Rodney Hoffman 

Real RISKS (as opposed to virtual risks) of aircraft

Eugene Miya <eugene@AMES-NAS.ARPA>
Tue, 17 Feb 87 18:23:18 pst
Been some time since I've sent something in, but Alan Marcum brings up some
good issues with respect to flying aircraft.

Alan brings up some good buzzwords like a systems approach to training.
What does this really mean?  You don't want a pilot doing "long-hand"
reasoning as the plane is falling out of the sky.  This is not to say they
are reading paper when they are going down either.

Pilots get a systems approach (so believed right now), but it is not
clear what they don't need to know.  A friend at the MVSRF (featured
in the Nova episode for NASA/Ames) pointed out in a local meeting
at PARC a couple of months back that checklists are written in blood.
(Obviously dramatic, but true.)

I have also learned in recent days that war gaming and battle management
can be regarded as `batch' rather than `interactive' in nature.  There are
those local `interactive' things called "engagements," but good commanders
set up battles months and weeks in advance to anticipate the widest variety
of contingencies, and not to fight or fly "on the fly."  This is part of why
checklists exist.  They are hardcopy versions of our memory.  They don't
forget, or suffer interference.  We try to think of contingencies before
they exist.  Sure, they are hardwired, and have lots of
problems, and there are people doing research on check lists here
and other places.

Yes, if we get lax because of computers, this is a computer associated
risk.  The human factors people have done LOTS of work to differentiate
knobs in planes.  If we computer people fail to do a similar job with
software (as an example), then we will kill people.

--eugene miya, NASA Ames Research Center

p.s. would you trust your life to any single line of code you wrote?
     think about it, before answering.  I've worked on flight (space) projects,
     but not man-rated, don't know if I could.

Trojan Horse alert (from

Mon, 16 Feb 87 15:58:01 PST
... This one could be serious, given the popularity of PC-Write.
    Al Stangenberger, Forestry, U.C. Berkeley

  Date: Thu, 12 Feb 87 11:12:22 EST
  From: "Peter J. Laughton" <PJL%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
  Subject: PC-Write Trojan Horse

  In light of the announcement of PC-WRITE availability to Info-IBMPC
  readers (volume 6, issue 8), I considered that it would be valuable to
  share the following warning:


  The latest INFOWORLD (02/09/87) reports the discovery of a bogus version
  of PC-WRITE.

  Tom Wilkinson, the sysop in Los Angeles who discovered it says "the trojan
  version when invoked, destroys the file allocation table of a user's hard
  disk, and initiates a low level format, destroying the hard disk's data."

  The bad version pretends to be the latest version, PC-WRITE 2.71 and is
  98,274 bytes long.

  The real version of 2.7 is 98,242 bytes long, and the real version of 2.71
  is 98,644 bytes.  Wilkinson says the version posted on Compuserve is the
  real version.

  INFOWORLD reports that "Quicksoft, PC-WRITE's developer, is offering $2500
  reward for the first person who identifies the creator of the bogus program
  and a $5000 reward for the person who provides proof that convicts the
                                         Don Richardson, 02/10/87

  From: jam@mitre-bedford.ARPA

    According to Quicksoft, the publisher of PC-Write, the latest 
  version is 2.71. Version 2.72 is a hack containing a booby trap, and
  trashes hard disks. BEWARE!

    Version 2.71 is a minor update of 2.7. They will not release a 
  version 2.72. They are trying to notify bulletin boards of the existence
  of the bogus version, but are walking a thin line: they don't want to
  scare people away from PC-Write. 

    I use version 2.7 and like it a lot. 

        Joshua Morris, jam@mitre-bedford

``Computerized Town Data Vanish''

16 FEB 1987 13:04:53 EST
   (From the Sunday 15 Feb 87 New York Times)

Prescott Valley, Ariz., Feb. 14 (AP) — All the computerized financial
records of this Rocky Mountain community have been erased, leaving officials
with no idea how much money has been spent this year or how much cash the
town has left.

Mayor Phil Beeson told the Town Council on Thursday that the account shows a
balance of zero.

He called it "positively a case of deliberate attack."  Lyn Newton, assistant
town clerk, said Friday that there is "strong circumstantial evidence pointing
to one person" whom she would not identify.

Ms. Newton said she discovered the problem over the weekend as she began
closing out the books for January for the town of 2,700 residents.

"All our expenditure accounts and all of our revenue accounts were erased,"
she said.  "The thing that scared me so badly is that we have no valid means of
knowing where we are.  By the time this was discovered, we could have been way
over budget."

The records apparently were erased sometime between Jan. 1 and last week, Ms.
Newton said.

They can be reconstructed, she said, but the task will be time consuming and
expensive and will be complicated by the fact that the town manager, assistant
town manager and town clerk all left office in recent weeks.

And, she said, it is time to begin preparing next year's budget.

Re: UCSD work on human error (RISKS DIGEST 4.47)

Alexander Glockner <sdcsvax!beowulf.UCSD.EDU!glockner@ucbvax.Berkeley.EDU>
Mon, 16 Feb 87 23:12:23 pst
Regarding the UCSD work on human error mentioned in the last line of the
most recent risks digest:

      Donald Norman (norman%sdics@sdcsvax.ARPA) is the 
      investigator who has done the most work here on the subject.

Connector risk

Rob Horn <wanginst!infinet!rhorn@harvard.HARVARD.EDU>
Mon, 16 Feb 87 17:57:08 est
The growing popularity of using the RJ series connectors (aka `telephone
modular jacks') for terminal cabling is exposing a lot of people to a major
risk.  These jacks are directly interchangable with normal telephone jacks,
and you can be sure that people will make mistakes and plug terminals into
telephone equipment.  This can do tremendous damage, and may even pose a
health risk.

When a telephone rings, the ring signals are a pulsed DC that can reach as
high as 150 volts! In terms of vaporized semi-conductors, this is just as
destructive as plugging your connector into an electric outlet.  The
frequency, voltage, and power don't quite match standard electric power but
they are more than enough to totally destroy any unprotected electronics.

The health risk arises from the potentially poor grounding of the digital
electronics.  These circuits are not normally designed to be safe with 150
volts on them.  This risk may be shortlived since the digital circuit will
quickly self destruct.  Telephone extension cables with RJ connectors pose a
greater hazard.  When the phone rings there is high voltage on that
connector.  If a child is chewing on it when the phone rings there is a real
risk of death from electrocution.  (The hazard to adults is lower since they
don't normally chew on cables, and the power levels are low enough that the
odds are in favor of a nasty jolt instead of fatal one.)

Beware of using these connectors in inappropriate circumstances.  (I was
warned quite thoroughly by our Mechanical Design people when I suggested it.
I learned then for the first time that telephones are not UL approved, nor
will they ever be, because of this 150 volt risk.)

                Rob  Horn
    UUCP:   ...{decvax, seismo!harvard}!wanginst!infinet!rhorn
    Snail:  Infinet,  40 High St., North Andover, MA

[Amos Shapir: Re: Electronic steering]

Brint Cooper <abc@BRL.ARPA>
Tue, 17 Feb 87 9:30:06 EST
    The following makes me wonder why no widespread concern exists
about failure of "conventional" power steering and brakes when an auto
engine dies.  I have had both experiences, fortunately without accident,
and they are frightening.  If we haven't worried about that risk, will
we collectively worry about the risk of an electronic system failure?


  > From: Amos Shapir <decwrl!nsc!nsta!instable.ether!amos@ucbvax.Berkeley.EDU>
  > In RISKS-4.46 Steve McLafferty writes:

  >The killer (pun intended) is the electronic four-wheel steering.  There is
  >no mechanical connection whatsoever between the steering wheel and the
  >steering gearboxes!

I really hope that scheme never makes it to production! Last time I heard,
power steering and brakes are designed in such a way that even when all power
is lost, the driver can still control the car and stop manually.

    Amos Shapir

Please report problems with the web pages to the maintainer