RISKS-LIST: RISKS-FORUM Digest, Saturday, 1 Feb 1986 Volume 2 : Issue 2 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: More on Shuttle destruct systems (Martin J. Moore, Sean Malloy, Brint Cooper) The Challenger [non]accident (Herb Lin) Redundancy (D. Cook) Galileo Plutonium power (Martin Schoffstall, James Tomayko) VDT's and birth defects in mice (Dan Hoey) ORCON dissemination constraint on RISKS 1.43 (Ted Lee) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. (Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA.) (Back issues Vol i Issue j stored in SRI-CSL:RISKS-i.j.) ---------------------------------------------------------------------- Received: from eglin-vax.ARPA Fri 31 Jan 86 07:25:36-PST From: "MARTIN J. MOORE" Subject: More on Shuttle destruct systems To: "risks" This morning I talked to my successor at the Cape, who was in the Range Safety area during the launch. I've got a few things to report and some questions to answer from previous issues. I found out that the Range Safety Officer commanded the destruction of the SRBs approximately 20 sec after the main explosion, as they were careening wildly away from the site. Both SRBs did explode on command. The mood at the Cape is described as "devastated", especially among those who went outside to watch live. My successor also reported that Range Safety had been officially cleared as of yesterday, with respect to any responsibility for the accident; but that they expected *much* closer scrutiny than before (which is, of course, perfectly fine.) Interestingly, many of the media and a large percentage of the general public were not aware of the existence of the destruct system. The latest theory I have heard contains a "leak" in one of the SRBs resulting in a 6000 C jet of flame cutting into the tank and igniting its fuel. Now, individual responses: > From: John Carpenter > As I read the article [by Martin Moore in RISKS-1.43,] it occurred to me > that as we discuss the risks of the destruct system we could be creating > another risk by revealing the nature of it's operation... > If the destruct system is public information, I would like to know why, > If it isn't, it certainly has no place on the net. Your point is well taken, and I did have some misgivings about posting the original article; not because I was revealing anything I shouldn't, but because I have no wish to be drawn into a national media controversy. Hence the restrictions on dissemination of the article. None of the information in the article was classified, and all of it was publicly available; and NASA is very good about providing access to any information that isn't classified. As to *why* it is public information...I think Neumann's response in 1-45 sums this up pretty well. Also, if it's not public, then the question that will be raised is "what are they hiding?" Incidentally, my successor told me that there is an article in this morning's (1/31) Orlando Sentinel about the destruct system, at about the same level of detail as my article in 1-43. Would some Central Florida reader be kind enough to send me a summary or a copy of that article? > From: Jeff Siegal > Is there someone who knows enough about the security at NASA/KSC to be > able to estimate the difficulty that a malicious party would have in > getting getting physical access to the shuttle/SRB/MFT prior to the launch? I'm not a physical security expert, but I believe that it would be extraordinarily difficult to get physical access to the shuttle itself at any time. Regarding the possibility raised by Kyle of a rifle shot, NASA maintains a "clear zone" 1.5 miles (I think) in radius around the shuttle when it is on the pad. This includes the closing of a public beach while the shuttle is on the pad, invariably causing complaints from some local citizens. > From: b-davis@utah-cs.ARPA (Brad Davis) > It also brings up an important question. If the hardware system is > redundant, what about the software system? Is the same software running > on all of the redundant hardware systems or are there more than one > software packages developed. If there is only one software package then > if one system fails due to a software failure then the other systems' > software may fail since the same conditions may still be in effect. Each member of a redundant set runs the same software (obviously, computers with different functions run different software). The danger you note is a real one; however, I believe the best solution is to make each piece of software as robust and fail-safe as possible. Consider that if redundant computers were running different software, you could have a failure of computer A and switchover to computer B without being able to reliably predict what computer B was doing at that instant! The whole idea of redundancy is that if a tool breaks in my hand, I want to be able to slap another one of the same kind of tool into my hand and not miss a beat. What your point leads to is to have additional tools for cases where the first one doesn't apply; this is a good idea, but it actually falls under the heading of "robustness" rather than "redundancy." mjm ------------------------------ Date: Fri, 31 Jan 86 07:05:50 pst From: malloy@nprdc.arpa (Sean Malloy) To: RISKS@SRI-CSL.ARPA Subject: Re: Possible triggering of the self-destruct mechanism & (non)accident >Date: 30 Jan 86 09:23:53 PST (Thu) >From: Peter G. Neumann >Subject: Possible triggering of the self-destruct mechanism [The physicist ... who speculated that the explosion in the solid-fuel rocket booster set off the self-destruct mechanism ... suggested that it could not have been a hydrogen leak because hydrogen burns clear and the Shuttle explosion had an obvious orange glow] is a classic example of what happens when people overspecialize themselves. Here we have a physicist making inaccurate statements about a fact of chemistry. I would suggest that this physicist watch the film of the Hindenberg disaster, and watch the bright, opaque flames of hydrogen burning in an insufficient quantity of oxygen for complete consumption. Only when hydrogen has a sufficient quantity of oxygen to burn completely does it burn with a clear blue flame. One of the problems that this brings up is the tendency of the average person to regard any statement made by a scientist about a scientific subject as being correct because "they've been trained in science, so they know what they're talking about", whether they are making a statement within their field or out of it. Particularly when a scientist says that something is impossible or impractical. Too many scientists over history have delcared something impossible or impractical that is commonplace today to reject some line of research because of such pronouncements. >Date: Thu 30 Jan 86 20:22:37-EST >From: Jeff Siegal >Subject: The Challenger [non]accident >I have heard speculation that some fuel leaking (LHY or LOX) from the >MFT and a unexpected flame could be seen (on slow-motion videotape) >for some time prior to the explosion. This seems consistent with >rifle bullet impact/puncture, long before the actual explosion >occured. This is one of the possibilities that the NASA investigating board is going to be looking at. However, the existence of the flames in the turbulent area just aft of the external tank is also consistent with a leak in the fuel pipes from the external tank to the orbiter. If it did occur from an external impact, then the leak would have to have started after the shuttle had taken off, because the plume of escaping LHY would have caused enough condensation to be visible on the gantry monitors, a situation that would have halted the launch. I don't know of any way that someone shooting at the shuttle could be sure that the bullet would only damage the tank enough to fail at max Q, rather than penetrate and start a leak immediately. Or, failing that, to hit the external tank after launch, with the shuttle rolling and pitching into its climb attitude. Sean Malloy (malloy@nprdc-arpa) ------------------------------- Date: Fri, 31 Jan 86 9:54:00 EST From: Brint Cooper To: "Peter G. Neumann" cc: RISKS@sri-csl.arpa Subject: Re: Possible triggering of the self-destruct mechanism But the news has consistently been reporting that, after the explosion that destroyed Challenger, the Air Force used the destruct mechanism to destroy the boosters (?) because one had gone off course and threatened populated areas. If this is true, can we not assume that the destruct mechanism did not cause the accident? Is it not a 'one time only' capability? Brint [As Martin Moore said in RISKS-1.43, there are FIVE destruct receivers: one on the ET and two on each of the SRBs. I was talking about the one on the ET; the SRBs somehow survived until they were intentionally destroyed. PGN] ------------------------------ Date: Fri, 31 Jan 86 10:41:51 EST From: Herb Lin Subject: The Challenger [non]accident To: JBS@DEEP-THOUGHT.MIT.EDU cc: LIN@MC.LCS.MIT.EDU, RISKS@SRI-CSL.ARPA From: Jeff Siegal I have heard speculation that some fuel leaking (LHY or LOX) ... ... This seems consistent with rifle bullet impact/puncture, long before the actual explosion occured. Depends on what you mean by "long". The licks of flame at the base of the SRB occurred at most 2 sec before the main explosion. It was going at 2900 fps, so at best its altitude would have been 1 nautical mile lower when the bullet hit, meaning 8 nm altitude. Pretty far out to imagine a rifle bullet hitting at that point. There has been no public mention of the possibility of terrorism. Terrorists claim credit for events. To my knowledge, no one has claimed credit. ------------------------------ Date: Fri, 31 Jan 86 10:49 EST From: dcook@SCRC-STONY-BROOK.ARPA Subject: Redundancy To: risks@SRI-CSL.ARPA cc: Spool@SCRC-STONY-BROOK.ARPA, dcook@SCRC-STONY-BROOK.ARPA There is a point in the redundancy argument that has bothered me since I interviewed at Stratus a year or so ago. Using the Stratus example, they run two copies of what they call a dipole. One copy is "live" and one is shadowing the live one. Each dipole is two mirror image processors with a high-speed comparator in the middle. When the live module gets a miscompare, it lights a LED and hands control over to the backup module. The operating system is able to do whatever clean up has to be done to brief module 2 so that computing is essentially non-stop. (Oh, one little "goodie" is that the module connectors are designed so that *the customer* can pull out the lighted module and put in a new one without shutting off the machine.) Now the $64,000 question: isn't the compare logic a single point of failure? (Note that because in this example you have a total of 4 CPU's, this isn't necessarily a crash.) But in the shuttle version, as I understood it, the systems were only redundant and therefore a comparator or checker failure could, it seems, knock the system out. ------------------------------ Date: Fri, 31 Jan 86 09:56:32 EST From: Martin Schoffstall To: risks@sri-csl.ARPA Subject: Galileo Plutonium power I'm not sure how much information is publicly available on the generating systems of various satellites but I would like to point out something that has been published that is somewhat analogous: cardiac pacemakers. As I remember it the plutonium powered ones were designed such that the containment device could not be penetrated by: - .38 special at 15 feet. - cremation temperatures (natural gas) - aircraft impact. Obviously I am being very coarse here and I don't have the details but I'm sure others do but if the above is "close" I'll throw out some number estimates that I'm sure others will correct: - .38 special at 15 feet, say 1000 feet/sec 300 foot-lbs??? - natural gas burns at 2000 degrees? - say 9gs at impact? The point is as follows: If pacemakers are designed to handle stresses such as that I would assume that the satellites are designed much better, especially since the Soviets dumped a load on Canada (did they ever pay damages for that?). marty schoffstall ------------------------------ Date: Friday, 31 January 1986 13:41:14 EST From: James.Tomayko@a.sei.cmu.edu To: RISKS@sri-csl.arpa Subject: Galileo Plutonium power Message-ID: <1986.1.31.18.22.7.James.Tomayko@a.sei.cmu.edu> Re Larry Shilkoff's note on Galileo carrying plutonium: Not only plutonium, but the spacecraft was to be deployed atop a new version of the Centaur hydrogen/oxygen upperstage used on the Atlas-Centaur and Titan III boosters. Therefore, aside from several hundred pounds of plutonium the Shuttle would be carrying several thousand pounds of highly volatile fuel the cargo bay, adding considerable energy to any explosion. Worse yet, Galileo was to be the user of the new upperstage, which shares little with its predecessor except the name. It has new tanks, engines, and instrumentation. In contrast to previous unmanned missions, only Galileo has been built. Considering that the cost of building a second one would only have been 15% of the cost of the first, NASA is taking a big chance by launching its only Jupiter orbiter on an untested upperstage, in view of the multiple failures of Shuttle-carried upperstages such as the IUS and various satellite kickstages. Sadly, the Galileo launch has already been delayed several years for various reasons (including one to switch it from the IUS to Centaur) and is likely to be delayed again. If the Shuttle fleet is not declared spaceworthy by May, the precession of Jupiter dictates a 13-month launch delay. Some of the parts of the spacecraft are nearly six years old now, and many have been in test for years on end. Even though the mission is projected to be shorter than Voyager, the spacecraft itself may actually "live" longer. As a footnote specific to the risks question, a friend of mine who is a an astronaut trainer for NASA said to me several months ago that crews training for Galileo and the Solar Polar launch also using Centaur were wary because of critical questions relating to aborts. If the Shuttle has to do a return to launch site abort or an abort to Africa before deploying Galileo, what are the dangers of trying to land with a full load of hydrogen and radioactive isotopes? The possibility of explosions never came up. Now it has to. ------------------------------ Date: 31 Jan 1986 17:45:15 EST (Fri) From: Dan Hoey Subject: VDT's and birth defects in mice To: Risks@SRI-CSL.ARPA Yesterday I heard a radio report that a Swedish study found that video display terminals increased the incidence of birth defects in mice. Does anyone have more information on this? I have not previously heard of any controlled research in the area that has identified a hazard. I am interested in trying to find out what the results of the study indicated, whether it is a new result, and how credible it is. Dan ------------------------------ Date: Fri, 31 Jan 86 23:35 EST From: TMPLee@DOCKMASTER.ARPA Subject: ORCON dissemination constraint on RISKS 1.43 To: Neumann@SRI-CSL.ARPA You realize, of course, that Martin Moore's fascinating and worthwhile piece is accessible to *ANYONE* on the net who is allowed to use FTP by their home site since SRI-CSL supports anonymous FTP logons and since you have the RISKS back-issues in a public file. [... or indeed from any BBOARD receiving RISKS, not even necessarily on the ARPANET! PGN] Ted (For readers not familiar with it, ORCON is a handling marking in some circles that means "further distribution only with permission of the originator, i.e., ORiginator CONtrolled." It is a non-trivial task to get a computer system to implement that handling marking in a secure but natural way, especially across a network.) [Yes, of course. Less obscurely, someone can even ask to be put on the RISKS list, which I presume would permit me to send them the back issue within the spirit of Martin's constraints. I think what Martin may have been more concerned about was wholesale rebroadcastings. So what we have is an experimental exercise in self-control, to see if our network community is mature enough to adhere to his constraints. I would be very interested in hearing of any postings contary to his caveat. But you are very correct in suggesting that enforcing ORCON is a nasty problem that cannot be adequately addressed in most computer system environments today. That is one reason why overclassification occurs. PGN] ------------------------------ End of RISKS-FORUM Digest ************************