The RISKS Digest
Volume 18 Issue 38

Monday, 26th August 1996

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…


More on the American Airlines Cali crash
DarkStar UAV crash from software change - cost, $39M
David Wheeler
Electric meter halts mail/news server
Kolja Waschk
Denial of service attack brings down Netcom listservers
Sidney Markowitz
DNS failure [from Matthew Dillon]
Steven Weller
Re: SSN problem hits a Congressman
Craig Neth
Microsoft's warning
Mike Walsh
Microsoft's patch
Ed Felten
Why Java, Bash, Explorer, and other bugs keep hurting us
Fred Cohen
Too much integration
Nick Brown
Re: Computer testing of nuclear weapons
Frank C. Ferguson
Jake Donham
Mike McKinlay
Year 2000 Bites the Budget
Frank Christensen
Re: London train crash
Clive D.W. Feather
Re: "Inability to tinker not confined..."
Tom Zmudzinski
Once more Murphy's Law
Jim Horning
Dependable Computing for Critical Applications, Final Call for Papers
Catherine A. Meadows
Info on RISKS (comp.risks)

More on the American Airlines Cali crash

"Peter G. Neumann" <>
Fri, 23 Aug 1996 15:13:43 PDT
"David L. Oppenheimer" <davido@CS.Princeton.EDU> and (Jason Eisner) sent me the
identical item, one from the AP and the other from *The
New York Times*, 23 Aug 1996, entitled

Wrong Computer Command Led to Colombia Crash of American Airlines Boeing 757

American Airlines has noted that the pilots of the December 1995 crash of
Flight 965 were lost at the time, and attributed the crash to the captain
entering a computer command that steered the plane in the opposite
direction.  Unfortunately, the one-letter code for Cali on the flight chart
they were using was the same as the one-letter for Bogota, and caused the
plane to fly into a mountain, killing 159 of the 163 people aboard.  Pilots
have been alerted as to the discrepancies.  (Most airline computers use
different codes for the two cities.)

DarkStar UAV crash from software change - cost, $39M

David Wheeler <>
Fri, 23 Aug 1996 12:33:47 -0400
An uncoordinated software change cost $39 million, as reported in
"Inside the Air Force", July 5, 1996, page 10:

 "Lockheed Martin and Boeing completed negotiations last week on how to
split the team's share of the $39 million cost of replacing the high-altitude
unmanned aerial vehicle [UAV] which crashed in April near Edwards AFB, CA.
The partners will split equally what could be a $6 million to $12 million
bill from the Pentagon for the destroyed DarkStar, the same proportion
by which it divides the workshare of building the UAVs.
 The first flying DarkStar crashed shortly after take off from Edwards
on April 22, resulting in the total loss of the air vehicle, the only
flight test asset available at the time.
 Although finger pointing has been assiduously avoided by both companies,
industry and Air Force sources said the crash was the result of Boeing
having adjusted software controlling flight on the UAV without commensurate
changes being made in the system by Lockheed Martin's Skunk Works division.
`The left hand didn't know what the right hand was doing,' a source said.
 However, the problem has been addressed and the program should be back on
track shortly, pending the approval by the companies' lawyers of the terms
of splitting the cost for the crash.
 A May 16 letter to Rep. John Murtha (D-PA), the ranking minority member
of the House Appropriations national security subcommittee, from Defense
Airbourne Reconnaissance Office chief Maj. Gen. Kenneth Israel tagged the
cost of rapidly configuring another DarkStar UAV for flight and making up
lost time in the program at $39 million."

 [reprinted with permission from "Inside Washington Publishers - Defense
  Group". Permission Point of Contact: Richard Lardner, U.S. (703) 416-8530]

Related URLs include "" and

--- David A. Wheeler

Electric meter halts mail/news server

Kolja Waschk <>
24 Aug 96 21:24:23 +0200
I run a mail + news server at my home, serving only a few people but to these
the ability to receive and send e-mail is quite important.

Recently I had to leave home for a couple of weeks.
I spent a lot of time before to make the system quite fail safe, especially so
it could handle some tasks that I otherwise do manually. While I was away, it
worked more reliably than at any time before. Until one day. It was not
accessible anymore. I could not even call into a backup PC which was there
just to provide at least the ability to reboot the server system.

Why ? The wheel in the electric meter (a 35 or more years old
electromechanical device) used for counting the power consumed by the system,
somehow stopped rotating. I assume due to a problem in the bearing it was not
able to restart rotating after a simple power blackout (it restarted after
giving it a slap, manually). Well, this meter was designed to limit the
current to whatever it could count. Thus, no rotation, no current.

I understood that I'm responsible for the reliable operation of the PC hard-
and software, and I can rely on the power supplied by my PSC. But I forgot
there was one important device between their output and my system.

Kolja Waschk (, NIC-handle KW84)  Tel +49-40-8891-3034 BBS/Fax -3035  "Yo.COM news & mail service ..."

Denial of service attack brings down Netcom listservers

Sidney Markowitz <>
Fri, 23 Aug 1996 06:01:39 -0700
A mailing list I subscribe to started sending an endless loop of bounce
messages and another subscriber forwarded the following as explanation. I
have not verified the authenticity of the message with Netcom, but I have no
reason to doubt it. There are two denial of service attacks here: A person
was email bombed by someone who subscribed him to many mailing lists, and
then that person retaliated by bringing down the mailing lists.  Once again
we see an old problem that could have been prevented had the system
administrators simply configured known security measures before their system
was hacked.

[begin quoted message]

 Newsgroups: netcom.announce
 From: (Margaret)
 Subject: Temporary hiatus of mailing lists
 Organization: NETCOM On-line Communication Services (408 261-4700 guest)
 Date: Thu, 22 Aug 1996 03:42:16 GMT

Outgoing mail from Netcom mailing lists is temporarily being delayed
due to a mail looping problem, starting at 5:30 PM PDT today.

The problem was caused by a user at another site; someone subscribed
him to many Netcom mailing lists, and he responded by creating an
infinite loop of "bounce messages" to all the list subscribers.  List
mail is being queued until we can filter out these error messages.

Netcom is currently in the process of upgrading majordomo, and we hope
to implement improved security for all our lists.  In the interim, we
strongly recommend that listowners set their lists to "closed"; this
protects against all mass-subscription attacks.

Delivery of list mail should resume later this evening.  Thank you for
your patience.

[end quoted message]

 — Sidney Markowitz <>
    Apple Research Laboratories, Apple Computer, Inc.

DNS failure [from Matthew Dillon]

Steven Weller <>
Sat, 24 Aug 1996 08:53:31 -0700
The following describes DNS meltdown at my ISP the other day: all DNS
services were unavailable, despite multiple servers being online. Lack of
DNS assured that other working services were unavailable to everyone who
didn't have IP addresses written down.

    Here is a technical explanation of the DNS failure, for those of you

    First, a synopsis of how DNS works... every site on the net serves their
    own DNS records.  Some sites serve other people's DNS records.  For
    example, BEST serves the DNS records for,, and most
    of our customer's custom domains.  No site serves more then a small
    fraction of the DNS records on the internet from their own database.

    The way DNS works is that when a domain name needs to be resolved, our
    DNS server (anyone's DNS server) first goes to the NIC to ask where to
    go to resolve the domain name.  The NIC itself cannot resolve domains,
    it can only tell our DNS server where to go to resolve a domain.

    Our DNS server then goes to the specified remote site to resolve the
    domain name belonging to that site. The remote site replies with the
    answer which our DNS server (a) caches for future reference, and
    (b) returns to the original requester.

    The caching is important, because otherwise a DNS server would have to
    re-query the remote DNS server every time someone wanted to resolve a
    domain.  DNS records propagate through caches.  It is simply not possible
    to run a DNS system with caching turned off, it would create an impossible
    load on the internet.

    Around 4:00 a.m. yesterday, some unknown site's cache got corrupted.
    The corruption propagated to many (hundreds) of other sites on the internet
    and eventually propagated to us.  This corruption hit a bug in the DNS
    server program that wound up corrupting the program, causing DNS to
    loose major records.

    Restarting the server in this case does not solve the problem because,
    due to the caching on remote sites, the corrupted record repropagates
    almost instantly.  BEST was hit by this problem very hard due to the
    large number of custom domains we serve... so many DNS requests come into
    BEST and are made by BEST that our servers would hit the corruption out
    on the internet within 10 seconds of starting up.

    Worse, this particular corruption tended to destroy the root records
    (stored in memory), called SOA records, for the domains served locally.
    This destroyed the mail system causing mail messages to bounce rather then
    to simply be delayed, because the DNS server was saying 'site X does
    not exist' rather then timing out.  It's worst possible corruption that
    can occur in a DNS system.


    It turns out that the last two BIND releases contain a bug that,
    when a corrupted record of the type that started propagating at 4:00 a.m.
    is received, results in the destruction of other **unassociated**
    records stored in memory.

    The particular release of BIND that we were using had been running
    perfectly for several *months* before this incident.  It was not something
    recently installed.

    There are two fixes to the problem:  (1) One can lock out those sites
    where the corrupted records come from, and (2) One can revert to an older
    release.  (1) is not a good solution because, due to the nature of DNS,
    corruption can propagate to many sites and it would be impossible to keep
    up to date and lock all of them out.  We wound up taking action #(2)
    and reverting to an older release of bind which, fortunately, did not
    have the bug that caused the problem.  We had to revert to BIND 4.9.3.
    Unfortunately, we did not think to do this for many hours because we were
    all convinced that the problem was external in nature and just didn't
    think to try a reversion.  In hind sight, that is the first thing we
    should have tried since we had the friggin binary for the older version
    sitting in our source tree.

    As far as DNS goes... the DNS we run is not 'bsd' or 'sgi' .. it's the
    *official* world-wide BIND distribution run by Paul Vixie.  It is really
    not appropriate to run the older versions shipped with most operating
    systems due to massive, massive security holes.  The corruption problem
    was unavoidable.  What *was* avoidable was the long period of time that
    elapsed before the problem got fixed, which I take full responsibility for.
    We spent most of that time trying to track down where the corruption was
    coming from... a near impossible task.  Around 6:00 p.m. scuttlebutt
    started propagating regarding a possible bug in the last two BIND releases
    at which point we instantly reverted to an earlier version, which fixed
    the problem, then started banging our heads against the wall for not trying
    it earlier.

    Matthew Dillon   Engineering, BEST Internet Communications, Inc.

Re: SSN problem hits a Congressman (McCandlish, RISKS-18.37)

Craig Neth <>
Mon, 26 Aug 1996 10:42:24 -0400
Early last week, the Nashua, NH *Telegraph* ran a front page story about
U.S. Congress Bill Zeliff, who is current running for Governor of NH.  The
story asserted that the paper had discovered that the Honorable Mr. Zeliff
was registered for two SS numbers.  The excerpts I have seen from the
article indicated that the reporters from the newspaper had contacted two
`out of state' database firms that collect information from various sources
and make it available to various parties.  The data showed two SSN numbers
for Mr. Zeliff, one that was clearly his and one that looked to have been
created rather more recently.

The next day, the headline was something to the effect that the two numbers
might in fact be a database error, and included quotes from the database
firms saying that errors in these databases were common, and that they are
not responsible for errors - the errors are in the submitting systems, not
theirs.  Their was an interesting quote from one of the spokesman, something
to the effect of "The press shouldn't have access to our system".  In the
meantime the Mr. Zeliff has asked for apologies, etc.

By the third day the duplicate entry was definitely declared a mistake.

Interestingly, the influential (and decidely Anti-Zeliff) *Union Leader*
newspaper of Manchester, NH. decided to stay out of the fray, running only a
small sidebar on the issue the second day and one or two short editorials,
all of which showed amazing restraint.  (The *Union Leader* has an extremely
conservative editorial position and has the widest circulation in the state;
its statewide influence is considered to be *powerful* by most political
observers.)  Yesterday's Sunday Edition of the *Union Leader* also included
a discussion of the *risks* of such electronic databases; the article
mentions EFF and other 'privacy' advocates prominently.

As for the damage to Mr. Zeliff's election chances, the results are still
unclear, but seem minimal.  His main competitor in the Republican primary
did not make an issue of the problem, choosing instead to continue harping
on a ``fact-finding'' mission Mr. Zeliff made to South America last Winter
(at taxpayers expense, of course).

[I apologize for the sketchiness of this report: I have the newspapers at
home and should be able to substantiate some of the more relevant facts when
I get home this evening.]

Craig Neth  Digital Equipment Corporation  110 Spit Brook Road ZKO3-3/Y25
Nashua, NH 03062

  [Apparently the *other* SSN belonged to a four-year-old.  PGN]

Microsoft's warning

Fri, 23 Aug 96 09:43:00 +0200
Thomas Reardon of Microsoft points out that Internet Explorer 3.0 now
includes a warning of "suspect" software.  The Risk here is that this
warning is far too broad. That is you seem to get the warning for almost
everything.  Thus the typical user will almost certainly get into the habit
of pressing the Yes button every time - just as he/she already does on all
the idiot "are you sure" prompts.  The warning by itself is thus useless.
Another Risk is that the user can't distinguish between Intranet and
Internet usage. If we assume that on the Intranet he is allowed to download
ActiveX modules because they are considered safe there, but now (sorry NOT)
allowed to download ActiveX bits from the Internet, how is he able to tell
them apart. The browser certainly doesn't.  Mike Walsh, Pohjola, Finland

Microsoft's patch (RISKS-18.36)

Ed Felten <felten@CS.Princeton.EDU>
Fri, 23 Aug 1996 10:29:33 -0400
We have tested Microsoft's patch and have verified that it fixes the problem
we reported.  The patch is available from

Why Java, Bash, Explorer, and other bugs keep hurting us

Fred Cohen <>
Thu, 22 Aug 1996 07:37:07 -0700
This is just an editorial opinion from a non-editor of risks.  We see
increasing numbers of security holes formed from what would appear to be
minor design or implementation flaws in systems - particularly in the
user-level programs running on those systems.  Perhaps the real problem
comes from not using trusted systems. Some examples:

Java allows access to user files:
    A trusted system could prevent this regardless of any
    flaws in Java. Just provide it with a private area.

Bash error allows character code ff to act as a separator:
    A proper trusted system would not allow you to exploit this
    to any advantage.

Explorer error lets you overwrite system and other files:
    Again a trusted system would eliminate the problem.

Perhaps the real problem we face has to do with the lack of interest by the
community in using technologies that we know about and that are highly
effective in preventing a wide range of threats.  Instead of building on the
work of others, people keep on starting from scratch and making the same
mistakes again and again.

Fred Cohen can be reached at tel:510-294-2087 fax:510-294-1225

Too much integration

+33)88412674 < (Nick BROWN) (Tel>
Thu, 22 Aug 1996 15:49:15 GMT
For a long time, I've been coming to the conclusion that one of the biggest
RISKS in computing (and, since that's starting to touch every aspect of our
lives, everything else), is an excessive degree of integration.  It
increases system complexity (read: bugginess) exponentially for often
negligible benefits.

A couple of items in RISKS-18.36 bring this home:

> before Explorer downloads a dangerous file like a Word document,

Sorry ?  A Word document is dangerous ?  Ah yes - when you run it, an
auto-start macro buried in the document itself might get DOS to format your
hard disk... Why do the 99% of users who just want to edit a letter have to
risk their entire system integrity for what is basically a gee-whiz feature

(Does Word have some way to load documents without executing any auto-start
macros ?  Or would that be too complex because users could turn it off and
then forget they'd done it when they _needed_ to run an autostart macro ?)

> Friends of mine have a remote-controlled gas fireplace in their new home.

I tested this statement on several colleagues (all computer people).  They
all thought it was either (a) "hugely funny" or (b) "absolutely terrifying".

Typical reactions in the respective categories were

 (a) "who's so lazy that they want a real, old-fashioned-style,
back-to-nature log[-effect] fire, but can't be bothered do something
old-fashioned like getting their b*tt [AOL!] out of their chair" [I suppose
it may have been an unrequested feature of the house, put in by the builders
following input from their "marketing" types - NB]

  (b) "every electronic system fails at least once every 5 years or so - to
run something as dangerous as burning gas with a 27 MHz [we presume - NB]
$4.99 remote circuit is just insane".

The other day, I was in an electrical store (buying an overvoltage
protector...go figure) and the lady in front of me was trying to find a
replacement remote control for her shutters.  These had been stuck in the
down position for two weeks because the remote's cheap push buttons were
sticking.  If there was a manual override in the house, she sure didn't know
where it was.

These days, before buying almost anything, I try to work out what its
failure mode is likely to be, how long I can reasonably expect it to (a)
work and (b) be reparable.  The results of this calculation for personal
computers is one of several reasons why I don't own one (but that's another

Nick Brown, Strasbourg, France

Re: Computer testing of nuclear weapons (Ferguson, RISKS-18.36)

"Frank C. Ferguson" <>
Sun, 25 Aug 1996 17:40:47 -0400
On Sun, 25 Aug 1996, A. Lester Buck III wrote:

> >I suspect we would soon be building weapons that would never work when
> >the real trigger was actually squeezed.
> The very first nuclear weapon was designed (and tested!) using teams of
> women operating hand calculators.  Funny thing, it worked the first
> time!

The very first atomic bomb was tested (and destroyed) in the desert out
west.  The second and third atomic bombs were tested over Hiroshima and
Nagasaki.  Even though the first one worked, most of the scientists weren't
sure #2 and #3 would work because they were made differently.  One of the
main reasons that a demonstration wasn't conducted for the Japanese was
because our experts weren't sure it would work.  Computers are very useful
and should be used as much as possible, however, anyone who thinks that a
computer can reliably substitute for a "real" test is naive.

Re: Computer testing of nuclear weapons (Ferguson, RISKS-18.36)

Jake Donham <>
Mon, 26 Aug 1996 14:03:11 -0700
<> to use the new computer ... to determine which country wins a war
<> without actually fighting the war.

Perhaps the best fictional treatment of this idea appears in Philip
K. Dick's "The Variable Man". Dick's works (especially his short
stories) contain a wealth of RISKS-relevant ideas.

Re: Computer testing of nuclear weapons (RISKS-18.36/37)

Mike McKinlay <>
Fri, 23 Aug 96 08:33:00 PDT
  [In response to Frank C. Ferguson's response concerning the ancient
Chinese to Jonathan Kamens noting Star Trek's origin of "virtual war"]

     "We inwented the ancient Chinese." — Pavel Chekov

Year 2000 Bites the Budget

Frank Christensen <>
Thu, 22 Aug 1996 10:53:59 -0500
  [Frank sent in a long copyrighted Reuters item, 22 Aug 1996, on the Y2K
  problem, citing estimated costs to the U.S. Government of $9 to $30
  billions, with worldwide fixes costing from $300 to $600 U.S. billion.
  The article also noted that Nebraska is imposing a two-cent tax per
  pack of cigarettes, to help smoke out the state's reprogramming problem.

  Independently, Mark Brader forwarded an item from Malcolm Austin
  <>, who had suggested naming a project aimed at this problem
  ``Dreadnought'', but he was voted down with those preferring
  ``Odyssey 2000''.  In response, Malcolm noted that the original Odyssey
  project (Odysseus's voyage) ended up 20 years behind schedule, and
  killed off everyone involved except the lead manager.  I like Malcolm's
  chosen name, but suppose that a fractured American spelling, DreadNaught,
  might be slightly more appropriate.  PGN]

Re: London train crash (Poole, RISKS-18.37?)

"Clive D.W. Feather" <>
Fri, 23 Aug 1996 17:19:12 +0100 (BST)
> The northbound train (with the passengers) was the 17:04 which left on time.
> The preceding northbound train (16:54) was delayed by over 6 minutes which
> meant the southbound (empty) train would have been delayed by at least that
> in crossing over onto the other line.

Not necessarily. The signalman would have all three trains visible on his
panel. If the other train was that late, the signalman could have crossed
the empty train *before* the late train reached the area. This is the sort
of thing they do every day.

Clive D.W. Feather, <> Associate Director, Demon Internet Ltd.
<> Director, CityScape Internet Services Ltd. +441813711138

Re: "Inability to tinker not confined..." (Scott, RISKS-18.37)

"Tom Zmudzinski" <>
Fri, 23 Aug 96 11:35:30 EST
In RISKS-18.37, Alastair Scott <> wrote:

> Who was it who wrote that "any sufficiently advanced technology is
> indistinguishable from magic"?  They are right, and they are becoming
> more than right.

Answer: Arthur C. Clarke

And Dr. Stanley Schmidt once wrote, "Any sufficiently advanced magic is
indistinguishable from technology."

Rhetorically, Tom Zmudzinski

  [Also noted by Stanton McCandlish <>.  PGN]

Once more Murphy's Law

Jim Horning <>
Sat, 24 Aug 1996 11:24:32 -0700
This was in my inbox today, concerning an order scheduled for
delivery August 15 (fortunately, I was not in a hurry for it):

> Subject:
>      <Firm> order update
> Date:
>     Fri, 23 Aug 1996 09:44:46 -0700
> From:
>     <

Dependable Computing for Critical Applications, Final Call for Papers

Catherine A. Meadows <>
Mon, 26 Aug 1996 13:36:07 -0400 (EDT)
                           DCCA-6 Call for Papers
              Sixth IFIP International Working Conference on
              Dependable Computing for Critical Applications
                         Can We Rely on Computers?
                              March 5-7, 1997
                      Garmisch-Partenkirchen, Germany

Final deadline for original papers is 3 Sep 1996.

    Prof. William H. Sanders
    University of Illinois          Tel:    217 333 0345
    CRHC - Coordinated Science Lab  Fax:    217 244 3359
    1308 West Main Street       E-mail:
    Urbana, Illinois 61801 USA

Please report problems with the web pages to the maintainer