The RISKS Digest
Volume 1 Issue 45

Friday, 31st January 1986

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…


Risks from discussing Reliability of Shuttle Destruct System
John Carpenter
Peter G. Neumann
Possible triggering of the self-destruct mechanism
Peter G. Neumann
Challenger and Living with High-Risk Technologies
Dave Benson
The Challenger [non]accident
Jeff Siegal
Shuttle Explosion — Plutonium on Galileo
Larry Shilkoff
Reliability in redundant systems
Brad Davis

Risks from discussing Reliability of Shuttle Destruct System

Thu, 30 Jan 86 07:51:58 PST
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.  I had no prior
knowledge of this system and now I know, generally, how it works, it's
redundancy level, and it's physical location.

I am aware that much of the technical information about the shuttle is a
matter of public record.  I don't know what sort of information is public
and what isn't.  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.

Respectfully, John Carpenter

Risks from discussing Reliability of Shuttle Destruct System

Peter G. Neumann <Neumann@SRI-CSL.ARPA>
Thu 30 Jan 86 10:49:44-PST
To: cbosgd!akgua!whuxlm!whuxcc!crash@UCBVAX.BERKELEY.EDU

Your concern is of course very valid.  The existence of such a mechanism
represents a serious risk.  The details of how that mechanism are thought
not to be spoofable or accidentally triggered are of course the subject of
an age-old controversy.  On one hand, pretending that such a mechanism is
safe because it is not publically known is disastrous — especially if the
mechanism is intrinsically not safe.  On the other hand, publishing the
details of a mechanism that is not entirely sound is also dangerous, because
it may suggest the flaws to an interloper.  However, unless there can be
scrutiny by dedicated experts, the flaws will persist.  A further comment in
this chain of reasoning is that no mechanism can be guaranteed 100% sound --
there are ALWAYS circumstances outside of the set of assumptions.  On
balance, openness appears preferable, tempered by the recognition that if
the risks are otherwise too great, then what is being done should probably
NOT BE DONE THAT WAY AT ALL.  This is a very difficult problem, and I and
many of my colleagues seem to come down fairly consistently on the side of
forthright discussion rather than hiding one's head in the sand under a
blanket of obliviousness.  What you don't know CAN hurt you.  What you do
know can also.  There are no easy answers.  Peter

[I use "safe" and "sound" loosely to imply reliable, available, secure,
 nonspoofable, nontamperable, free of Trojan horses, etc.]

Possible triggering of the self-destruct mechanism

Peter G. Neumann <Neumann@SRI-CSL.ARPA>
30 Jan 86 09:23:53 PST (Thu)
Much to my surprise — since it did not seem too likely — I heard of a
report on the radio last night by a physicist (and head of a company that
does something with solid-fuel rockets) who speculated that the explosion in
the solid-fuel rocket booster set off the self-destruct mechanism, resulting
in the destruction of the orbiter.  He suggested that it could not have been
a hydrogen leak because hydrogen burns clear and the Shuttle explosion had
an obvious orange glow.

The Challenger [non]accident

Jeff Siegal <JBS%DEEP-THOUGHT@mit-eddie.MIT.EDU>
Thu 30 Jan 86 20:22:37-EST

  From: Herb Lin at MC.LCS.MIT.EDU

  It is obvious that at the time of the explosion, no rifle bullet hit
  it.  Thus, any shot must have been fired much sooner.  The rifle shot
  must then be timed in such a way that it is fast enough to weaken the
  casing, but not strong enough to penetrate it.  It seems that that
  window is pretty small.

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

I have, in general, been concerned about the fact that, except for a
single question asked by one reporter at the first news conference,
there has been no public mention of the possiblity of terrorism.

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 haven't noticed any great measure of security (except DoD
flights), but perhaps this has been the result a NASA P.R. effort make
the Space program appear as "open" as possible.

Jeff Siegal

Shuttle Explosion — Plutonium on Galileo

Thu, 30 Jan 86 17:05 PST
To: "risks" <risks@sri-csl.ARPA>

I understand the Galileo probe which was planned to be on a shuttle
flight this summer is powered by plutonium. Had Galileo been on this
flight, it seems to me a whole bunch of plutonium particles would have
been raining along the coast of Florida.

Any comments?


Reliability in redundant systems

Brad Davis <b-davis@utah-cs.ARPA >
Thu, 30 Jan 86 09:08:52 MST
Martin Moore's report on the self destruct devices was very informative.
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.

                    Brad Davis

Please report problems with the web pages to the maintainer