The RISKS Digest
Volume 5 Issue 05

Friday, 26th June 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…

Contents

Re: Immoderation and Nonmoderation
Joe Buck
Roy Smith
"Computer woes hit air traffic"
Alex Jenkins
BBC documentary filming causes Library of Congress computer crashes
Howard C. Berkowitz via Mark Brader
Running out of gas could be hazardous!
Steve McLafferty
NASA Safety Reporting System
Eugene Miya
EGP madness
David Chase
Dave Mills [2]
FCC Information Tax — Risks of Networking
Steve Schultz
Info on RISKS (comp.risks)

Re: Immoderation and Nonmoderation

Joe Buck <jbuck@epimass.epi.com>
25 Jun 87 21:01:55 GMT
>From: Peter G. Neumann <Neumann@csl.sri.com>
>A few of you have received a UUCP message through "cbosgd" that intended to
>demonstrate that systems are not really very secure and that it is easy to 
>bypass moderation on supposedly moderated news groups...  However, the message
>was sent not through RISKS@CSL but through one of our innumerable 
>redistribution points (and thus was received by only a very small fraction of 
>all RISKS readers).

Wrong.

The parochialism of our Arpanet brethren never ceases to amaze me.  The vast
majority of RISKS readers are on Usenet.  Usenet is far larger than the
Internet, Bitnet, etc, and almost every Usenet site that receives RISKS (alias
comp.risks).  UUCP is just a transport mechanism (Usenet != UUCP-net); many
ARPA Internet sites now receive their mailing lists Usenet-style using the
nntp system.  The forged article in question travelled to every Usenet site
(including those Internet sites that use nntp).  Usenet does not use mail,
but rather a flooding mechanism; every site sends it to all their downstream
links until everyone has the article.  If many people didn't see it, that's
because several people issued "cancel" messages to make it disappear.
(These messages were forged also).  — - Joe Buck jbuck@epimass.EPI.COM
          {seismo,ucbvax,sun,decwrl,<smart-site>}!epimass.epi.com!jbuck
          Old arpa mailers: jbuck%epimass.EPI.COM@seismo.css.gov

    [Thanks for the comments.  I maintain a large list of direct addresses to 
    redistribution centers (and a few individuals) on ARPANET, MILNET, CSNET, 
    BITNET, etcNET — with many indirections — and those readers simply did
    not get the message in question.  They did not miss anything.

    By the way, "forged" is not quite right.  On the basis of the dialogue,
    I conclude that the message was REALLY-FROM "apc".  It was just a public
    misuse of a useful but totally unsound facility — subject to loss of
    privacy at each forwarding, loss of data integrity on any message, and 
    complete denial of service if a message is cancelled along the way.  (Use 
    of the RISKS banner and standard DIGEST format would have constituted
    forgery.  It is interesting to contrast this with Piet Beertema's 
    "Chernenko@MOSKVAX" — Software Engineering Notes, vol 9, no 4, July
    1984.)  PGN]

  [ From: cmcl2!phri!roy@seismo.CSS.GOV (Roy Smith)
  Organization: Public Health Research Inst. (NY, NY) 
  ... In its alter-ego, RISKS appears on the wild-and-wooly Usenet as the
  newsgroup comp.risks.  Netnews has lots of advantages over mailing lists but
  security isn't one of them.

  ... suffice it to say that ["apc" 's abuse of RISKS] was stupid and childish,
  and the tail-end of some totally absurd argument that has been going on for
  weeks all around the net.  Roy Smith, {allegra,cmcl2,philabs}!phri!roy ]
     [Note: There are advantages of unmoderated newsgroups and advantages
     of moderated newsgroups.  I try to maintain a relatively open policy
     (subject to the masthead guidelines); at least the "official" version  
     of RISKS will remain moderated.  PGN]     


"Computer woes hit air traffic" [Boston Globe, Monday, June 15, 1987]

Alex Jenkins <atj@mirror.TMC.COM>
Wed, 24 Jun 87 10:14:47 edt
Boston (AP) - "A computer problem that blanked the radar screens of air
traffic controllers from New England to the Great Lakes for six minutes
delayed flights at Logan International Airport, but posed no hazard, an
official said.  When the outage occurred Saturday afternoon, planes
immediately were ordered to fly more slowly and at greater distances from
each other, according to Mike Ciccarelli, a spokesman for the Federal
Aviation Administration.  He said some flights were rerouted and planes
scheduled to fly into New England were ordered to remain on the ground.
'There were delays of incoming flights, naturally, because if they wanted
to leave Newark, for example, they couldn't,' Ciccarelli said.  He said
Logan has a separate monitoring system which kept the controllers in radar
contract(sic) with flying aircraft."

   [The SF Chron reported this on 21 Jun 87.  After quoting Ciccarelli that
   there was no hazard for air travelers, it went on to say, ``... although a 
   controller who asked not to be identified described the situation as
   "very dangerous".''  Increasingly the air traffic control operations are
   coming under scrutiny.  Oprah Winfrey had a fine show the other day.  PGN]

Alex T. Jenkins, Mirror Systems, Cambridge Massachusetts     atj@mirror.TMC.COM


BBC documentary filming causes Library of Congress computer crashes

Mark Brader <msb@sq.com>
Thu, 25 Jun 87 22:21:20 EDT
The following article was in comp.misc on Usenet.  It was posted as a
followup to the "exploding computers" articles [RISKS-5.6], but it is really
a separate topic and an interesting hazard. [Forwarded to Risks by Mark Brader]

  From: howard@COS.COM (Howard C. Berkowitz)
  Message-ID: <312@cos.COM>
  Date: 4 Jun 87 13:44:18 GMT
  Organization: Corporation for Open Systems, McLean, VA

  In the late '70's, I worked at the Library of Congress.  We had
  IBM and Amdahl mainframes with STC tape drives as our main data base
  machines.  Given the role of the world's largest library, our computer
  room received considerable attention.

  The British Broadcasting Corporation was given access to much of 
  the Library, to film a documentary.  We found that some major system
  crashes began to happen when they were in the computer room.  We 
  thought it might be their video equipment, floods, etc., but could
  not find the cause.

  The symptom was clear:  periodically, ALL of our tape drives would
  simultaneously stop, rewind, and unload, no matter what they were
  doing.  The operating system could not deal with such simultaneous
  events, and would crash.

  It turned out to be an intermittent event:  most BBC work was film
  or video, but they occasionally took still photographs.  When their
  electronic flash pointed at the front of the tape drives, the short
  burst of light was reflected into the photoelectric end-of-tape
  sensors of each tape drive, causing EVERYTHING to simultaneously
  sense (erroneously) end-of-tape.


Running out of gas could be hazardous!

Steve McLafferty <harvard!munsell!ssm@seismo.CSS.GOV>
24 Jun 87 17:22:12 GMT
Several months ago I posted an article to comp.risks (RISKS 4.46) about the
electronic steering in the Pontiac Pursuit project car.  All four wheels on
the car can be steered, and the force required to turn the wheels comes from
DC powered motors that are computer controlled.  There is no direct physical
connection from the steering wheel to any of the wheels.  This article
triggered a small debate in RISKS over the use of electronics in automobiles.

The June 22, 1987 issue of AUTOWEEK contains a follow up story on the Pursuit.
They took a test drive of the car, fortunately at a closed race track rather
than on the highway.  During the test drive, the car ran out of gas.  When
the engine stopped, so did the 24-volt alternators which supply power to
the steering system. The steering failed, and the car ran off the track!  
Apparently there was no battery backup for the 24-volt system. 


NASA Safety Reporting System

Eugene Miya N. <eugene@ames-pioneer.arpa>
25 Jun 1987 1708-PDT (Thursday)
NASA NEWS
NASA ESTABLISHES SAFETY REPORTING SYSTEM
    NASA has established a voluntary, confidential safety reporting
system for its 100,000 employees and contractor personnel to alert NASA
management of safety concerns.
    The new reporting system supplements existing safety reporting
procedures and, initially, will focus on safety concerns associated with
NASA's Space Transportation System, more familiarly known as the Space
Shuttle program. The new system is being established as a result of the
Shuttle Challenger accident.
    The NASA Safety Reporting System (NSRS) will encourage employees
to supplement existing safety reporting procedures by completing and 
submitting an NSRS confidential report form to Battelle Memorial Institute's
Columbus Division, Columbus, Ohio. Battelle Institute is under contract
to NASA to develop and administer the NSRS for NASA Headquarters'
Safety Division. 
    Use of the NSRS report form will provide anonymity to the maximum
extent possible within the law for individuals disclosing their safety
concerns. The form will contain a section at the top for individuals to
include their names, addresses and telephone numbers.
    Upon receipt of the report form, the Battelle NSRS team will
remove this top section unless team members determine that additional
data would be useful. If so, the team will contact the sender for the
needed information and then remove, stamp and return the top section
to the sender as proof that the sender has successfully filed a NSRS
report. No record will be maintained of reporting individual's identities.
    Battelle NSRS and NASA specialists then will determine whether
the reported concern is of a critical nature requiring immediate action.
    The Battelle NSRS team will summarize all reported concerns, 
store the deidentified data in a computerized data management system
and forward summaries to the NASA Headquarters Safety Division for
further analyses in cooperation with a technical advisory group.
    The Safety Division and technical advisory group also will
determine what corrective action should be taken and track the 
resolution of these recommendations.
 = = = = = = = = = = = = = = = = = = = = = = = = = = = =
NASA NEWS Release 87-91
By David W. Garrett, Headquarters, Washington, D.C.
Reprinted with permission for electronic distribution
 = = = = = = = = = = = = = = = = = = = = = = = = = = = =

A comment on anonymous reporting systems: the AEC (then ERDA, then NRC
and the DOE) have had such a reporting system for years.  Every nuclear
facility in the country has a special phone with a direct line to
Washington DC, but it is rarely used and is poorly maintained.  Many
"employee suggestion" programs have not worked for various fears.
Some have supposedily worked in Japan.  I have noted no such systems
on computers since E-mail always has had return addresses.  What can
we do to get people to use such systems?

--eugene miya,   NASA Ames Research Center


EGP madness

David Chase <rbbb@rice.edu>
Thu, 25 Jun 87 21:30:49 CDT
Recently Rice University was the victim of a little Internet EGP madness.  I
will try to give a coherent summary, though we still don't know how it came
about.

Sometime in the evening of June 23, Libra.Rice.EDU, Rice's ARPANET gateway,
started receiving packets destined for "css-ether" (Center for Seismic
Studies Ethernet, including the machine "seismo.css.gov") and "univ-ariz"
(University of Arizona Ethernet).  Libra.Rice.EDU (10.4.0.62, 128.42.1.64)
is an LSI-11 running Dave Mills's "Fuzzball" software.  Because of the
address space limitations of the PDP-11 architecture, Libra occasionally
runs out of room in its routing table.  We suspected that such an event
might have confused Libra's EGP to the point where it sent out bogus routing
updates.

A quick check showed that Libra still knew the correct routes to css-ether
and univ-ariz.  Still, we were worried because the tables were in fact full,
so we took the gateway down for about an hour around Midnight and restarted
it with expanded tables.  We then did our best to determine that we were not
advertising ourselves as a gateway to either network.

After midnight, we continued to receive packets destined for seismo, with
sustained traffic about 4 times higher than normal.  We called BBN the
following morning (June 24), and learned that bbnnet2-arpanet-gw, one of the
three "public" EGP-speaking core gateways, continued to list us as the
gateway, with metric 2, for css-ether and univ-ariz.  The other two core
gateways had the correct routes, and BBN confirmed that Libra was
advertising only legitimate routes. The erroneous traffic fell off markedly
when bbnnet2-arpanet-gw was rebooted that afternoon, but occasional
misdirected packets persisted until late this morning (June 25).

The same evening that Libra's gateway tables filled up, BBN had loaded "new
test software" into that gateway machine, so there is no clear smoking gun
here.

This story has a "happy ending", because our Fuzzball stayed up the
whole time and dutifully forwarded packets and sent ICMP squawks to the
offending machines.

Now, the bad part.  At least 78 hosts were fooled (that is, 78 hosts
were fooled in some given hour, because the log file wrapped around
about once per hour), including machines from nets 8, 10, 18, 26,
128.{8,32,41,45,59,83,84,95,102,103,104,105,115,121}, 192.1.2,
192.5.{25,58} and 192.12.{31,33,119,206,221}.  We don't know the cause
of this problem, but it does seem like a bit of a security hole.  We
could easily have wiretapped all the traffic for seismo.css.gov, or
even substituted our own more "interesting" packets.  Thus we were
particularly amused to find traffic from Milnet hosts (11 of them)
passing through us.

David Chase and Paul Milazzo
Department of Computer Science, Rice University


Re: EGP madness

<Mills@UDEL.EDU>
Fri, 26 Jun 87 0:24:03 EDT
Interesting. During the time you report loyal fuzzball linkabit-gw was
having exactly the same problem, mounds and mounds of traffic sloshing
in and getting dutifully redirected. However, another fuzzball dcn-gw
was having no such prolem. All squawk the same EGP code as yours and
linkabit-gw at least has the same table-space problem as yours.

There is a clue in the clock-synchronization system that you may have
noticed. I began seeing frequent clock resets, with measured roundtrip
times one hop away as the ARPANET flies reaching twenty seconds or
more (!?). When I checked the INOC for core gateway routes, I found
the directly-connected macomnet client of linkabit-gw as reachable
via purdue-gw! Something was badly wrong in the core system.

Prompted by a note from Joe Weening at SU, I found a wee bug in the fuzzball
EGP code that would, under bizarre conditions I hastily add, result in a
nonsense address in a redirect message sent by the fuzz. The bog is now
fixed in linkabit-gw and dcn-gw. I can't see how the bog would affect the
slosh you an I saw over the last few days anyway, but it might under unlikely
conditions result in a j-random host, having mistakenly been redirected to
your gateway, not being redirected back to the proper gateway.


Re: EGP madness

<Mills@UDEL.EDU>
Fri, 26 Jun 87 0:28:41 EDT
I forgot to add that table overflow will not affect what you send the
core, only what you can reach. If the table does overflow, the net(s)
lost will appear unreachable. I'm working on that. Also, I saw evidence
that the core tables were being corrupted with martians (net 112?!)
that reached back to touch us in the swamps. I also saw broadcasts
(sic) coming from a 128.205 hosts landing at linkabit-gw, truly a
martian who lost his compass.


FCC Information Tax — Risks of Networking

<"IMS/Steve Schultz" <steve@afsc-bmo.arpa> [ info-law ]>
24 Jun 87 11:49:00 PST
  From: hadeishi@husc4.HARVARD.EDU (mitsuharu hadeishi)
  Subject: ATTENTION ALL MICRO USERS!!! FCC INFORMATION TAX AHEAD!!
  Date: 12 Jun 87 15:13:37 GMT

    A terrible piece of news I just read about in the New York Times
  this morning.  The FCC just voted 4-0 to impose a $4.50 - $5.50 an HOUR
  tax on people who are using the phone system to transmit information
  across state lines.  This INCLUDES anyone hooking up to a network,
  not just people dialing out of state!!  I suppose people dialing
  into a system with access to Arpanet or even USENET might be charged
  this tax; the information services (Compuserve, etc.) are slated
  to be charged this tax as of January 1.  This is an outrageous tax
  which would squelch the burgeoning telecommunications industry,
  and is totally unjustified.  I would urge people to write letters
  to their Congressman to protest this unfair and exorbitant "information
  tax" which is based on superstition and lack of understanding of
  the telecommunications industry.
                    -Mitsu
                        John Langbein

Please report problems with the web pages to the maintainer

x
Top