The RISKS Digest
Volume 9 Issue 24

Thursday, 14th September 1989

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…

Contents

RISKS-9.22 and RISKS-9.23 problems had different causes!
PGN
Risks of RISKS: A bug in sendmail and RISKS-9.22
Scott Mueller
Phobos 1 & 2 computer failures
Ralph Hartley
Aircraft simulators
Rob Boudrie
Speeders' Delight?
Anthony Stone
Medical accreditation: based on "customer" clout?
Bob Ayers
RISKS in mainstream entertainment (Mission Impossible)
Benjamin Ellsworth
Software Safety Standards
Anthony J Zawilski
12th National Computer Security Conference
Jack Holleran
Info on RISKS (comp.risks)

 RISKS-9.22 and RISKS-9.23 problems had different causes!

"Peter G. Neumann" <neumann@csl.sri.com>
Wed, 13 Sep 1989 10:23:37 PDT
My sincere regrets for the annoyance to you (and to me receiving triple the
BARFMAIL) for the multiple mailing of RISKS-9.23 — especially when that issue
contained an explanation for the fact that readers received from ZERO to as
many as (at least) 12 copies of RISKS-9.22.  The problem this time was NOT the
long-list time-out problem, but rather the crash-in-the-middle problem with TWO
server crashes, resulting in many of you getting THREE copies.  (Strangely, a
few of you apparently got MORE!)

Although the first of yesterday's two crashes was accidentally human induced,
the second was intentional, necessary for our wizard to unwedge a serious
catastrophe that had downed an entire subnet of machines for most of the day.
But these were circumstances vastly beyond my control — which is very annoying
for someone who really tries to do things carefully.

There are some strong lessons for RISKS readers.  Distributed systems are full
of tricky problems (synchronization, timing, distributed atomicity, recovery,
fault tolerance, security, etc.) that are very demanding.  Furthermore, even if
everything were done right in the first place (which is most unlikely), there
would still be extreme difficulties in ensuring that such systems would
continue to work dependably in the presence of on-line evolutionary
development.  It is important that computer researchers and developers be
subjected to the use of the systems and networks that they develop, under
really stressed conditions.  Even then there will be lurking problems that are
not triggered.  So, it is time for some widely used really rugged, secure
network software that is hardware-fault tolerant and system-crash-tolerant.
For example, SENDMAIL should be resistant to time-outs, system crashes, certain
human screwups, debug option attacks, etc.  (Maybe such a version already
exists?)  Overall, you RISKS folks, whose awareness is already heightened, need
to play a stronger role in ensuring that R&D is really concerned about
stringent requirements.

[End of SoapBox]   Peter

P.S. In case you were wondering, I have no intention of making a career of
writing notes to RISKS explaining new ways for you to get multiple copies.  But
I certainly hope this does not recur.  [ReCur ==> doggedly persistent ?  No, I
do not want to be a REcur of havoc.  And NO, I am not trying to overflow the
mailboxes of private subscribers so that they will cancel their subscriptions.]


Risks of RISKS: A bug in sendmail and multiple copies of RISKS-9.22

Scott Mueller <scott@ardent.com>
Wed, 13 Sep 89 09:05:20 PDT
Your story of the sendmail bug reminded me of a somewhat similar bug in the
UUCP network smart mailer program SMAIL.  As nearly as I can tell, if there
is an address that needs automatic resolution near the end of an alias file
with many (~100) addresses, *that* recipient receives one copy of the mailing,
but a few of the other recipients in that part of the file get an extra copy.
Not nearly as extreme as the sendmail problem, but an irritant nonetheless.

Had you split the RISKS list BEFORE sending out the previous digest, would it
have been a 22 twain?

Scott Hazen Mueller, Ardent Customer Support
(408) 732-0400 x336 uunet!ardent!scott


Phobos 1 & 2 computer failures

Ralph Hartley <hartley@aic.nrl.navy.mil>
14 Sep 1989 08:23:27 EDT (Thu)
>From SCIENCE Vol 245, 8 September 1989 p1045

On 27 March ... the spacecraft was passing near Phobos for what was, by then a
routine session of imaging. "It was on automatic operation" he [Kremnev,
director of the soviet spacecraft manufacturing plant] said. "To conserve
energy, the transmitter was off during imaging. But at the time it was due to
restart, no signal was heard on Earth." the control group hurriedly sent up
emergency commands," Kremnev said, and they indeed were able to reestablish
contact. "They got 17 minutes of telemetry data. But the spacecraft was
tumbling so that the only communication was through the spacecraft's small
antenna.. Therefore they couldn't decipher the telemetry. Then they lost the
telemetry". Phobos 2 was never heard from again.

But since then, said Kremnev, "Considerable time has been taken, and we have
been successful in deciphering the telemetry." There is now no doubt that
the failure lay in the spacecraft's on board computer, he said, and was not
due to, say, a meteoroid collision. "after the failure of Phobos," he said,
"People at Babakan said 'We have luck only with women - not spacecraft!'"

Kremnev also offered new details as to how the Phobos 1 spacecraft was lost
last year on the way to Mars. As part of the ground checkout prior to launch,
he said, the spacecraft computer had been loaded with a program for testing its
steering. Once the test was completed, of course, the program was no long[er]
needed. However it was in "firmware" - read-only memory - which could only be
cleared with special electronics equipment. "We would have had to remove the
computer from the spacecraft and take it to the people who could do it," said
Kremnev. "[But] we had VERY little time before the voyage. So the program was
'locked in a safe.'" That is, it was sealed off and rendered harmless by other
software in the spacecraft computer.

Unfortunately, said Kremnev, "the key was found to unlock the safe." On 29
August 1988, not long after launch, a ground controller omitted a single letter
in a series of digital commands sent to the spacecraft. And by malignant bad
luck, that omission caused the code to be mistranslated in just such a way as
to trigger the test sequence. Phobos 1 went into a tumble that was not noticed
until the next attempt at contact, 2 days later. It was never recovered.
Kremnev said that future versions will have more on-board safeguards.

And what happened to the controller who made the error? Well Kremnev told
SCIENCE with a dour expression, he did not go to jail or to Siberia. In fact,
it was he who eventually tracked down the error in the code. Nontheless, said
Kremnev, "he was not able to participate in the later operation of Phobos"

                    Ralph Hartley


Aircraft simulators

<ROB.B@te-cad.prime.com>
13 Sep 89 21:39:21 EDT
A previous RISKS posting suggested that aircraft be programmed to simulate
various flight conditions for "practice" while in "routine flight", but
stressed the importance of not confusing reality and simulation.  How about
deliberately confusing the two - a pilot in an emergency situation would
not know if it was real or simulation, and could therefore be expected to
behave in a calm, professional manner without panic.  (Sort of like not
telling school children if the fire bell is a true alarm or a drill).
The computer would record response to simulated emergencies for review and
evaluations by the rear echelon boys.

There is also a vast untapped market for an "aircraft passenger simulator".
(get come cramped seats, small rest rooms, hard to view movies and poor food
for a few hours).  The market would be large, and there are many more aircraft
passengers than there are pilots.
                                                 Rob Boudrie


Speeders' Delight?

Anthony Stone <stone@nbc1.GE.COM>
Thu, 14 Sep 89 14:01:31 EDT
Digital Speed Limit Signs Malfunction, Set 75 mph Pace on New Jersey Turnpike

    NEWARK, N.J. (AP) - New Jersey native Bruce Springsteen's fabled
muscle cars might have a field day on the state's turnpike these
days, where digital speed limit signs are mistakenly sanctioning
speeds of 75 mph.
    State police and turnpike authority officials said the erroneous
speed limit has been showing up on about half a dozen of the signs in
northern New Jersey because of a computer programming error. The
legal limit is 55 mph.
    Gordon Hector, a spokesman for the authority, says technicians
were trying to correct the problem. He said workers have also been
correcting the signs manually while technicians ponder the trouble.
Meanwhile, some motorists found the problem amusing.
    "It was kind of strange to see everybody below the speed limit
for a change," joked Casey Raskob, a Springfield, N.J. attorney.
A state police spokesman, who asked not to be identified, said no
traffic problems were reported as result. "But I don't think any
judge is gonna buy that excuse," he said.


Medical accreditation: based on "customer" clout?

Bob Ayers <ayers@src.dec.com>
Wed, 13 Sep 89 10:46:37 PDT
In RISKS 9.23, Frank Houston, discussing the accreditation of
professionals, writes:

    The ultimate lever for accreditation [in the medical domain] is the
    willingness of paying customers, Medicare, to accept accreditation as
    a sufficient guarantee of quality service.

I suggest that this is an understatement. A stronger phrasing would be

    The ultimate lever for accreditation is the action of government in
    defining non-accreditation as proof of the absence of quality, and,
    ultimately, banning non-accredited service on that basis.

That's the way it works in U.S. medicine.

First, it's not that Medicare accepts accreditation as quality-proof, but
will accept real proof too — rather they accept (as I understand it) _only_
accreditation.

Second, there's the crime of "practicing medicine without a license."


RISKS in mainstream entertainment (Mission Impossible)

Benjamin Ellsworth <ben@hpcvlx.cv.hp.com>
Wed, 13 Sep 89 17:05:14 pdt
I was kind of watching Mission Impossible the other night (the episode had
something to do with a "man of 1000" disguises trying to frame the gray haired
guy).  For some reason the MI team wanted to access to the personnel records of
a facility (a prison?).  The electronic/computer penetration whiz (the black
fellow) says "Unfortunately, they're not on a computer system so I can't break
into the records [or words to that effect]."  The MI team go on to get the
records in a more mundane way (impersonation, breaking and entering, etc).

I was pleased to note the general effect of stating that computerized record
keeping was a security risk especially with regards to penetration from outside
the physical facility.  This mention of "computer fallibility" is a positive
change in the entertainment industry.

This message will self-destruct in five minutes....   ;-)

Benjamin Ellsworth, Hewlett-Packard Company   All relevant disclaimers apply.


Software Safety Standards

Zawilski, Anthony J <m16143@mwvm.mitre.org>
Friday, 8 Sep 1989 13:51:29 EST
             Working Group for IEEE Software Safety Standard
                          Organizational Meeting
                 October 2 & 3, 1989;  McLean, Virginia
                   (703) 883 5631  or  (703) 883 6086
                           ++++++++++++++++++
        This is the first meeting of the working group.  We will form
        working committees and identify major subareas for an IEEE
        draft standard on software safety.  Dr. Nancy Levenson will
        present a background briefing.  You are encouraged to attend
        if you want to be a working member of the standards drafting
        group.  Please post this message and forward as appropriate.
     *                                                               *
        Details as to times, locations, local hotel arrangements,
        and a written agenda may be obtained from:
             Cynthia Wright, SSWG Chair at (703) 883 5631
             CWRIGHT@MDF.MITRE.ORG  or
             Tony Zawilski, SSWG Vice Chair at (703) 883 6086
             M16143@MWVM.MITRE.ORG


12th National Computer Security Conference

Jack Holleran <Holleran@DOCKMASTER.NCSC.MIL>
Wed, 13 Sep 89 15:34 EDT
Dates:  October 10-13, 1989
Place:  Baltimore Convention Center
Registration:   12th National Computer Security Conference
                c/o Office of the Comptroller
                National Institute of Standards and Technology
                A807, Administration Building
                Gaithersburg, MD  20899

Payment:  $150.00 before September 25, 1989, $175.00 after September 25, 1989

Conference hotels in area, single cost, and local phone numbers:
      Hyatt Regency           $99.00      (301) 528-1234
      Days Inn Inner Harbor   $59.00      (301) 576-1000
      Holiday Inn             $69.00      (301) 685-3500
      Baltimore Marriott      $79.00      (301) 962-0202
      Radisson Plaza          $80.00      (301) 539-8400
      Best Western Hallmark   $52.00      (301) 539-1188

Additional information:  Tammie Grice  (301) 975-2775

Payment:  Mastercard, VISA, checks, money orders, training or purchase
          requests.  (payment to "National Institute of Standards and
          Technology/Computer Security Conference")

Please report problems with the web pages to the maintainer

x
Top