26-Jun-87 22:49:15-PDT,19395;000000000000 Return-Path: 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) 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-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 >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,}!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. 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 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 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 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" [ 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 ************************ -------