26-Jun-87 22:49:15-PDT,19395;000000000000
Return-Path: <NEUMANN@f4.csl.sri.com>
Received: from csl.csl.sri.com (CSL.SRI.COM) by F4.CSL.SRI.COM with TCP; Fri 26 Jun 87 22:41:06-PDT
Received: from F4.CSL.SRI.COM by csl.csl.sri.com (3.2/4.16)
id AA18671 for RISKS-LIST@f4.csl.sri.com; Fri, 26 Jun 87 22:42:56 PDT
Message-Id: <8706270542.AA18671@csl.csl.sri.com>
Date: Fri 26 Jun 87 22:39:47-PDT
From: RISKS FORUM (Peter G. Neumann -- Coordinator) <RISKS@csl.sri.com>
Subject: RISKS DIGEST 5.5
Sender: NEUMANN@csl.sri.com
To: RISKS-LIST@csl.sri.com
RISKS-LIST: RISKS-FORUM Digest Friday, 26 June 1987 Volume 5 : Issue 5
FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
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)
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, nonrepetitious. Diversity is welcome.
Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM.
FTP back issues Vol i Issue j from F4.CSL.SRI.COM:<RISKS>RISKS-i.j.
Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97).
----------------------------------------------------------------------
From: jbuck@epimass.epi.com (Joe Buck)
Subject: Re: Immoderation and Nonmoderation
Date: 25 Jun 87 21:01:55 GMT
Organization: Entropic Processing, Inc., Cupertino, CA
>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]
------------------------------
Date: Wed, 24 Jun 87 10:14:47 edt
From: atj@mirror.TMC.COM (Alex Jenkins)
To: RISKS@csl.sri.com
Subject: "Computer woes hit air traffic" [Boston Globe, Monday, June 15, 1987]
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
------------------------------
Date: Thu, 25 Jun 87 22:21:20 EDT
From: msb@sq.com (Mark Brader) [from Usenet]
To: risks@csl.sri.com
Subject: BBC documentary filming causes Library of Congress computer crashes
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.
------------------------------
From: harvard!munsell!ssm@seismo.CSS.GOV (Steve McLafferty)
Date: 24 Jun 87 17:22:12 GMT
To: comp-risks@seismo.CSS.GOV
Subject: Running out of gas could be hazardous!
Keywords: Electronic steering, fly-by-wire
Organization: Eikonix Corp., Bedford, MA
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.
------------------------------
From: Eugene Miya N. <eugene@ames-pioneer.arpa>
Date: 25 Jun 1987 1708-PDT (Thursday)
To: risks@csl.sri.com
Subject: NASA Safety Reporting System
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
------------------------------
Date: Thu, 25 Jun 87 21:30:49 CDT
From: David Chase <rbbb@rice.edu>
Subject: EGP madness
To: risks@csl.sri.com, egp-people@ccv.bbn.com
Cc: mills@udel.edu
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
------------------------------
Date: Fri, 26 Jun 87 0:24:03 EDT
From: Mills@UDEL.EDU
To: David Chase <rbbb@rice.edu>
Cc: risks@csl.sri.com, egp-people@ccv.bbn.com, mills@UDEL.EDU
Subject: Re: EGP madness
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.
------------------------------
Date: Fri, 26 Jun 87 0:28:41 EDT
From: Mills@UDEL.EDU
To: David Chase <rbbb@rice.edu>
Cc: risks@csl.sri.com, egp-people@ccv.bbn.com, mills@UDEL.EDU
Subject: Re: EGP madness
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.
------------------------------
Date: 24 Jun 87 11:49:00 PST
From: "IMS/Steve Schultz" <steve@afsc-bmo.arpa> [ info-law ]
Subject: FCC Information Tax -- Risks of Networking
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
------------------------------
End of RISKS-FORUM Digest
************************
-------