The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 14 Issue 88

Wednesday 25 August 1993

Contents

o Re: Mars Observer
Lee Mellinger
Michael Stern
o Re: RISKS of elaborating on ... known RISKS
Bob Brown
Douglas W. Jones
o Re: Telephone verification
Tom Swiss
o Re: Digital Markets
A. Padgett Peterson
o Re: Child-Prodigy or Prodigy-Child?
Bob Frankston
o 911 & Call Privacy *67 problems (US West)
David Kovanen via Richard Jensen
o More Gripen Griping
Peter B Ladkin
o Info on RISKS (comp.risks)

Re: Mars Observer (Neumann, RISKS-14.87)

Lee Mellinger <leem@tsunami.Jpl.Nasa.Gov>
Thu, 26 Aug 1993 20:29:45 GMT
Just a few comments.  I'm on the Mars Observer project, and some of the
information published in public sources has been somewhat misleading or
incorrect.  First, the spacecraft did not cost $1B, is was about $300M, the
Titan booster was about $500M and ground systems and ops about $200M.  In
NASA's new way of doing business all costs are lumped together, so to make a
fair comparison to other projects, you must understand that the costs quoted
in the past did not cover the launch and sometimes not the ground system.
Second, the communications with the spacecraft were not "disrupted" [actually
David Perlman in the Chron said Pike noted that Mission Control engineers at
JPL had ``lost contact with the Mars Observer'' --- PGN] as John Pike has
said, nor "interrupted", they were intentionally turned-off.  The transmitter
beam voltage was shut down to protect the filament when the fuel and oxidizer
pyro valves were blown to pressurize the tanks.  The beam voltage was supposed
to be turned back on after the tank pressurization event by the command
sequence stored in the SCP, the spacecraft control processor.  We do not konw
what happened after the beam-off was executed because the downlink was not
seen again, and that is all we know for sure.

We have been commanding a series of events, presuming that certain scenarios
have occurred.  None has been successful as far as we know.  We continue to
send commands because the Command Detector Unit is connected to the Low
Gain Antennas and do not require precise pointing by the spacecraft to
achieve command reception.


We do not know that whatever happened, happened when the pyro valves were fired
because that did not occur until sometime after the beam voltage was turned
off.  There was a time interval to allow sufficient cooling of the filament.

We are at this moment waiting for the expiration of the the secondary
command loss timer, which will reconfigure the spacecraft telecom to 10bps
and the Low Gain Antennas for downlink.  That will occur (assuming that
no commands have be accepted since last Friday) at 93/238-21:56:35 UTC,
that is today, the 27th at 14:56:35 PDT.

Lee F. Mellinger, Caltech/Jet Propulsion Laboratory - NASA, 4800 Oak Grove Dr.
Pasadena, CA 91109 818/354-1163      leem@jpl-devvax.JPL.NASA.GOV


Re: Mars Observer (RISKS-14.87)

Michael Stern <stern@deshaw.com>
Thu, 26 Aug 1993 17:15:33 -0400
Unfortunately I can not provide the names of my sources for this material,
as it would not be fair to them. Treat anonymous sources with appropriate
skepticism; I think you'll find this an interesting tidbit nonetheless.

Apparently the tank pressurization system on the Observer was tested
exactly once, and it "blew up." Whether this phrase is meant to imply
an explosion or merely a bad leak is an exercise left to the reader.

NASA had one spare tank.

Result: the Observer was launched with the second tank, with no further
testing or development.

/stern


Re: RISKS of elaborating on exploitation of known RISKS

Bob Brown <bbrown@gmcf.org>
Thu, 26 Aug 93 15:52:58 EDT
The issue raised by David P. Reed is indeed sticky, and I agree with the
moderator that the first step upon identifying a risk is to bring it to
the attention of someone who can do something about it.

In some cases that someone chooses, for whatever reason, to do nothing.  In
other cases, there *is* no someone.  Smart answering machines are as good an
example as I can think of.  Publishing a "generic" warning doesn't give one
(er, at least not *this* one) enough information to realize that DTMF tones
can be recorded on the answering machine, then played back into the phone
network.

Somewhat reluctantly I find I have to disagree with Reed.  Publishing
specific details of RISKS does create the risk that someone will exploit
those details.  *However*, trying to express risks generically doesn't do
much to keep bad guys from exploring and exploiting the RISKS.  The
bad guys will take time to think about the generic risks, searching for
areas to exploit.  The good guys (that's us) will probably *not* take
time to ponder the generic risks, but we probably will respond to a
report of a specific threat.


Re: RISKS of elaborating on ... known RISKS (Reed, RISKS-14.87)

Douglas W. Jones <jones@pyrite.cs.uiowa.edu>
Thu, 26 Aug 93 13:47:21 CDT
... discussed...  Not only in RISKS!  Consider the following essay, quoted
from Charles Tomlinson's Rudimentary Treatise on the Construction of Locks,
published about 150 years ago.  (This quote has been bouncing around the net
for a while, but it bears repeating.)  These issues have been hashed over for
a long time!
            Doug Jones  jones@cs.uiowa.edu

  A commercial, and in some respects a social, doubt has been started
  within the last year or two, whether or not it is right to discuss so
  openly the security or insecurity of locks.  Many well-meaning persons
  suppose that the discussion respecting the means for baffling the
  supposed safety of locks offers a premium for dishonesty, by showing
  others how to be dishonest.  This is a fallacy.  Rogues are very keen
  in their profession, and already know much more than we can teach them
  respecting their several kinds of roguery.  Rogues knew a good deal
  about lockpicking long before locksmiths discussed it among themselves,
  as they have lately done.  If a lock -- let it have been made in
  whatever country, or by whatever maker -- is not so inviolable as it
  has hitherto been deemed to be, surely it is in the interest of
  *honest* persons to know this fact, because the *dishonest* are
  tolerably certain to be the first to apply the knowledge practically;
  and the spread of knowledge is necessary to give fair play to those
  who might suffer by ignorance.  It cannot be too earnestly urged, that
  an acquaintance with real facts will, in the end, be better for all
  parties.

  Some time ago, when the reading public was alarmed at being told how
  London milk is adulterated, timid persons deprecated the exposure, on
  the plea that it would give instructions in the art of adulterating milk;
  a vain fear -- milkmen knew all about it before, whether they practised
  it or not; and the exposure only taught purchasers the necessity of a
  little scrutiny and caution, leaving them to obey this necessity or not,
  as they pleased.

  ...  The unscrupulous have the command of much of this kind of knowledge
  without our aid; and there is moral and commercial justice in placing
  on their guard those who might possibly suffer therefrom.  We employ
  these stray expressions concerning adulteration, debasement, roguery,
  and so forth, simply as a mode of illustrating a principle -- the
  advantage of publicity.  In respect to lock-making, there can scarcely
  be such a thing as dishonesty of intention: the inventor produces a lock
  which he honestly thinks will possess such and such qualities; and he
  declares his belief to the world.  If others differ from him in opinion
  concerning those qualities, it is open to them to say so; and the
  discussion, truthfully conducted, must lead to public advantage: the
  discussion stimulates curiosity, and curiosity stimulates invention.
  Nothing but a partial and limited view of the question could lead to the
  opinion that harm can result: if there be harm, it will be much more
  than counterbalanced by good.


Telephone verification (Re: Grodberg, RISKS-14.85)

not Swift, not Suiss, Swiss!) Thu, 26 Aug 93 14:36:04 -0400
     I'd like to comment on my experience with Citibank on this.

     About a year ago, I called to confirm receipt of a new card. For
verification, the representative on the other end asked for my zip code
(which, if someone had intercepted this card in the mail, or found it in my
wallet, would be easily known), then for my mother's maiden name.

     Trained by RISKS reading to look for security holes when giving out
personal information, I asked, "Do _you_ know my mother's maiden name?"

     "No." (Imagine the implications if she'd said "Yes"!)

     "So I could tell you anything, couldn't I?"

     "Yes, but we'll use that next time you call as verification."

     "But, if I weren't the person who was supposed to have this card, I
could tell you anything, and have the use of this card."

     "Um, yes. Hmmm..."

     To her credit, the rep seemed to understand the problem once it was
pointed out, and promised to bring it up "at the next meeting".

     A few months ago, when I had to repeat the procedure, the rep asked
for my SSN (he was willing to accept a subset of the digits when I
expressed reluctance), then for the maiden name, which will be used for
future verification. (I suppose I should have asked if he already knew my
SSN or not...)

     Of course, this means that my mother's father's last name has now
become information I have to regard as "confidential".

     Citibank gives out an ATM PIN with it's cards. Why in the world they
don't use that as telephone authentication (after some intial check like
the SSN to confirm the right person got the card and the PIN), I have no
idea. Wouldn't it be easier to use information I already keep secure,
rather than ask me to keep other information - which, prior to this, I
might have given out with a thought - secure?

     On a side note: preparing this post made me realize that, although I
haven't thought about it in years, keeping my Social Security card in my
wallet probably isn't the best of ideas.

Tom Swiss/tms@cs.umd.edu


Re: Digital Markets (Agre, RISKS-14.87)

A. Padgett Peterson <padgett@tccslr.dnet.mmc.com>
Thu, 26 Aug 93 14:46:09 -0400
>What does this mean in practice?  You'll have to hire a management consultant
>to help you figure that out.

In the computer world we have been seeing this for some time: buy software
(really the documentation) once, and everything thereafter is electronic.  One
of the first was "Using MS-DOS Kermit" from Digital Press. The software is
"free", however since the on-line documentation is now minimal (last full copy
I have is dated 1989), the book is a near necessity, only the updates come
with the software when you FTP it (ver 3.13 now). Of course we are now getting
to the point where you need to buy the second edition also to stay current
8*(.

Another example is the use by some manufacturers of "Flash ROMs", while this
is supposed to be an aid to updating, it looks more like an excuse for
slip-shod engineering (we had several from a well-known manufacturer who
shall remain nameless but is famous for selling high priced monitors as "15
inch" that have 13.8 inch (diagonal) viewing surfaces that would not
recognize a "three finger salute" until the ROM was updated...).

In the same token, Compuserve seems to be becoming the center for software
updates & "slipstreams" for problems that should never have occurred. (For
me, US Sprint & a Supra 14.4 modem (plugs) make direct connections to the
mfr - those that do not have FTP sites that is -  cheaper than the Compuserve
hourly charges for anything interesting).

Once upon a time, software was difficult to update so manufacturers, those
that expected to stay in business, took pains to test software before
releasing it. DOS 3.3 lasted from 1987 to 1991 (admittedly partly because
DOS 4.x didn't work). Today the world seems to be one long beta test.

What we might expect in the future is "upgradable" hardware. Want to toast
bagels in your four-slice pop-up ? Dial 1-900-4NOBURN and connect to the
serial port. Your washing machine doesn't do the newest fabrics properly ?
1-900-NEWDUDS. Automotive recalls do not require stopping at the dealer,
just an ISDN connection. Latest & greatest or just an invitation to do
away with quality control ? You decide.
                        Padgett


Re: Child-Prodigy or Prodigy-Child? (Schiller, RISKS-14.86)

<Bob_Frankston@frankston.com>
Thu, 26 Aug 1993 15:23 -0400
Jeff writes; "At MIT I supervise the campus computer network, the MIT portion
of the Internet.  We have an internal policy that we do *not* monitor messages
between individuals. We, however, state that our staff *may* inadvertently
encounter personal mail due to our maintenance activities (more then likely
because the mail system barfs and the message is delivered to the dead letter
bin for manual routing)."

In my own gateway implementation, I purposely suppress the body of messages
that get reported to the administrator. Systems designers need not only
refrain from invading privacy but proactively avoid inadvertent disclosures.
Perhaps one should go so far as to simple scrambling of email messages stored
on disk simply to avoid inadvertent display when looking at system logs or
dumps.

First Class mail tends to be sent in envelopes. Those who send post cards are
accepting the risks of disclosure.


911 & Call Privacy *67 problems (US West) [David Kovanen]

Richard Jensen <rjensen@mimir.persistence.com>
Thu, 26 Aug 93 11:43:23 PDT
I've forwarded this by request of David Kovanen [kovanen@first.com].

Richard Jensen, Persistence Software, Inc., rjensen@persistence.com

----- Begin Included Message -----

Date: Wed, 25 Aug 1993 20:07:25 PDT
From: uunet!First.Com!Kovanen (David Kovanen)
To: wizard@moz.hookup.net
Subject: 911 & Call Privacy *67

I recently ran into an embarrassing problem that was created by my local
telephone company (US West.)  The problem involved the new "Caller ID" feature
and my local police @ 911.

In anticipation of the introduction of Caller ID here in Washington state I
began to insert *67 before all telephone numbers in my computer dialing
directory.  After all, I didn't want people calling me back on my data line.

Everything worked fine up until February 1993.  At that time US West began to
install a new and "improved" version of the call blocking software.  This
"improved" version resulted in several calls from my computer to 911:

Previously, a computer could dial *67 and immediately dial the desired
telephone number without waiting for a second dialtone.  (As can still be done
with *70 to block Call Waiting.)

The "improved" Central Office software now *REQUIRES* that the dialing device
wait for a second dialtone and the C.O.  ignores all dialed digits for
approximately 1/2 second after the code has been dialed.  There is no
technical reason for this to be done, other than the fact that US West
dislikes being forced by the Utilities Commission to offer Caller ID blocking.

Here is the problem: I was calling a local telephone number, 572-5911 as
follows: "ATDT*675725911".  The four digits after the *67 (572-5) were
suddenly ignored and the call promptly went to 911!  It took several tries
until I realized what happened.

It is important to note that the operation of most of the central Office codes
still do not insert this mandatory pause, including *67 prior to February
1993.

There is one other problem with Call Vlocking that people with laptops should
be aware of: *67 CAN NOT be dialed from a line that has blocking enabled for
all calls.  Thus, if you use your laptop on some lines with blocking and some
without, you must keep two entries in your directory.  This is a pain!  It
should be possible to dial *67 on a Blocked line to confirm that the call will
be blocked.

Incidentally, the problem with calls to 911 is equally true with any phone
that has a redial feature: The redial feature will generally not store a pause
after *67 and so the redial is effectively disabled (inoperable) for calls
that you wish to block Caller ID on.

This entire situation was brought to the attention of US West in March of 1993
and they responded that Caller ID would not be available until August 1993 so
why was I complaining.  It is now August and their response is: So don't use
Call Blocking on your computer.  As for my redial button: They say don't use
it--buy their $3/Month "Continuous Redial".  (Which incidentally is not like
the PBX Automatic Callback feature--it only "looks" at a busy number about
once every 45 seconds!)

David J. Kovanen Kovanen@First.Com ...  (206) 925-1000
10 Caledonia Summit NE, Browns Point, Washington, U.S.A. 98422-1620


More Gripen Griping

Dr Peter B Ladkin <pbl@compsci.stirling.ac.uk>
26 Aug 93 20:30:00 BST (Thu)
Flight International, 24-31 August 1993, p5, `Report Challenges Gripen
Controls' by David Learmount.

Saab says that it was aware of the fly-by-wire (FBW) system software
inadequacy which caused the crash of its [..] Gripen [...] on 8th August [...].
The "software limitation" had been reported by one of the company's programme
test pilots, but was believed to be at a corner of the flight envelope
unlikely to be used. Saab says that the corrections [....were....] set for
October, but may be delayed.
    The Swedish Accident Investigation Board's preliminary report says:
"The accident was caused by the flight-control system's high amplification of
stick commands in combination with large, rapid stick movements by the pilot.
This led to the stability margins being exceeded and the aircraft entering a
stall."
    A contributory factor, says the report, was the "late display" of the
angle-of-attack warning, "...which gave the pilot too little time to react".
    The report, based on flight-data-recorder information, says that
Saab test pilot Lars Radestrom had flown a left-hand turn at 154kt [..]
with 65 [degree] bank, at 2g, with a high 21 [degree] angle of attack.
    Radestrom attempted to roll sharply out of the turn by applying
full-right aileron and, simultaneously, a sharp pitch down. Instead of
stopping at wings level, as intended, the aircraft continued to roll to 20
[degrees] right bank. The pilot reacted to the bank by a full control column
movement to the left, still with pitch down.
    At this point, the software started to produce control over-reaction,
and the pilot started compensating with three of four more full-deflection
control-column cycles. Radestrom felt that he had lost control and ejected.
    As the aircraft then entered a steep descent, it appeared to have
recovered to stable flight. "The aircraft's control system includes a recovery
mode. We have observed that this mode has operated in the intended manner,"
says Saab, while admitting that there was not enough height for recovery.

[End quote]

The last paragraph paragraph is particularly .... interesting. Maybe someone
should be collecting examples of airplane-industry double-speak. It seems to
surface when fly-by-wire systems are involved, or is it just my impression? I
don't recall anyone from Boeing saying "the safety bolts on ..... functioned
to specification" when El Al crashed into the apartment building in Amsterdam
last year, or someone from MD saying `the slat controls worked as intended'
when China Airlines killed 2 people and injured the rest with an inadvertent
slat deployment on an MD11 at cruise over the Aleutians earlier this year.

Peter Ladkin

Please report problems with the web pages to the maintainer

Top