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 8 Issue 53

Monday 10 April 1989

Contents

o Product Recalls Due to Software Error
B.J. Herbison
o Airliners running out of fuel in mid-flight
Jerome H. Saltzer
o Good press in Flying
Howard Gayle
o Re: More on 1983 Air Canada near-disaster
Henry Spencer
o PC causes multiuser host to drop off the network
Patrick Wolfe
o Auto Risks
Robert Dorsett
o Risk of Living in Nova Scotia
Matthew Wall
o Otis elevator software
Eric Roskos
o Elevator Units
Don Alvarez
o Nuclear-powered vessels
Steve Bellovin
o (Deep-seated) Presumption of innocence -- for computers
ephraim
o Re: Authenticating Internet mail
John Labovitz
o Passwords in plaintext
Brian McMahon
o Re: Cellular telephones
Eric Thayer
David Collier-Brown
o Info on RISKS (comp.risks)

Product Recalls Due to Software Error

B.J. <herbison%ultra.DEC@decwrl.dec.com>
10 Apr 89 10:25
The following article on product recalls appeared in this morning's paper.  Of
the five items mentioned in the article, three of them cite `software error' as
the reason for the recall.  All three cases involve medical products.
                                                    B.J.

    PRODUCT RECALLS
    by Mylene Moreno, States News Service 
    [from The Boston Globe, Monday 10 April 1989, page 14]

   WASHINGTON - The federal government announced the following product recalls
last week.  Unless otherwise noted, the recalls were voluntarily initiated by
product manufacturers, importers, distributors or retailers.  The list includes
products distributed in New England and nationwide.

        Food and Drug Administration

           o  Nellcor Inc. of Hayward, Calif., recalled 164 N-1000
        Multi-function Monitors containing Display Software Version
        1.0.7, serial numbers [...] produced [...].  The product is
        intended for use as an adjunct monitor of blood oxygen
        saturation, airway carbon dioxide and nitrous oxide gas levels
        by trained medical physicians.  Due to software error, the
        monitor innacurately reports the partial pressures of nitrous
        oxide and carbon dioxide at altitudes of 2,000 feet or higher. 
        Approximately 51 units, which were distributed nationwide and in
        Canada, remain to be corrected.

           o  Hewlett-Packard Co., Andover Division of Andover, Mass.,
        recalled 428 Hewlett-Packard brand Sonos 100 Ultrasound Imaging
        Systems, models 77000A and 77010A, serial numbers [...], a
        scanner for qualitative and quantitative echocardiography and
        echoradiology applications.  The blood velocity may be
        incorrectly calibrated due to a software defect resulting in
        erroneous reading under certain conditions.  Product was
        distributed nationwide and internationally.

           o  Hewlett-Packard Co., Andover Division of Andover, Mass.,
        recalled its series 77020 Ultrasound Systems and Upgrade Kit
        Software Part No. 77120-10051, an ultrasound scanner designed
        for radiology applications.  Product may product incorrect strip
        chart recordings due to software error.  1,428 units were
        distributed nationwide and internationally.

           o  Norfolk Scientific, doing business as Statspin
        Technologies of Norwood, Mass., recalled 539 boxes of Statspin
        Disposable Roto-Products, product number RD01, lot numbers
        [...].  The product , distributed nationwide, is used for plasma
        separation.  Poor welds may cause the blood to leak at the seam
        at the lower or upper part of the rotor.

        Consumer Safety Commission

           o  The Vendo Company of Fresno, Calif., launched a voluntary
        retrofit program for 115,000 Vendo soft drink machines that are
        at least 38.5 inches wide.  Vendo will install anti-theft
        devices in the machines to dissuade individuals from dangerously
        rocking or tipping the machines to obtain free products.  In
        recent years, rocking and tipping has resulted in an increasing
        number of deaths and serious injuries.  The public is encouraged
        to call Vendo at 1-209-439-1770 for more information.


Airliners running out of fuel in mid-flight (RISKS-8.48)

Jerome H Saltzer <jhs%computer-lab.cambridge.ac.uk@NSS.Cs.Ucl.AC.UK>
Tue, 4 Apr 89 12:53:52 bst
The recent comments on use of dipsticks to measure aircraft fuel level
when some number of electric gauges are malfunctioning prompts me to
point out that use of electric gauges itself is actually one of the
older examples of fly-by-wire introductions.  No old-time pilot would
consider taking off unless:

     1.  He or she had personally dipped a thumb in both wing tank
     filler holes and verified that the tanks were topped off,
 and
     2.  The sight gauges (glass tubes on either side of the cockpit in
     a high-wing plane) were filled with something that looked like
     fresh gasoline.

It took a long time for people to accept electric fuel gauges; they somehow
just didn't give one the same level of confidence.
                                       Jerry


Good press in Flying

Howard Gayle TX/UMG <howard@strindberg.ericsson.se>
Fri, 7 Apr 89 08:41:56 +0200
From an article on an airline accident in Flying, March 1989, p. 27:

   Should an airplane or an engine be designed so that
   forgetting a single item could lead to a spurious but
   convincing appearance of a life-threatening
   malfunction---not immediately, but once the airplane is
   airborne and the omission has faded from memory?

   Computer programmers face this kind of question constantly;
   they never know what the novice user will come up with, and
   so they design their programs to survive any kind of abuse.


Re: More on 1983 Air Canada near-disaster

<henry@utzoo.UUCP>
Sat, 8 Apr 89 21:29:49 -0400
>(4) Ambiguous rules for minimum equipment and line of responsibility in
>    determining whether the airplane was flight-worthy.

Ambiguous rules, yes; ambiguous responsibility, no.  Aviation regulations
and laws are *extremely* clear on this:  ultimate authority and
responsibility rest with the pilot, and nobody else.  Even air-traffic
control is advisory only:  the pilot is the judge of whether their
advice is safe and should be followed, and if he does something clearly
stupid because they told him to, it is legally *his* fault.  The line of
responsibility for determining flightworthiness may be confused in the
middle, but the pilot is most definitely at the top.  Aviation is one
of the few fields where things are this clear-cut.

This is not to deny that pilots often are under a lot of pressure to get
the plane to its destination on time, or that a cautious pilot may find
himself in trouble with management.  Or that a pilot with years of boring
airliner flying behind him will tend to unconsciously assume that safety
is inherent in the system, making him more willing to take chances when
the heat is on.

                                     Henry Spencer at U of Toronto Zoology


PC causes multiuser host to drop off the network

Patrick Wolfe <pwolfe@kailand.kai.com>
Sat, 8 Apr 89 02:09:33 cdt
The other day I accidentally discovered how to disrupt operations on one
of our multiuser BSD UNIX hosts from an MS/DOS PC with PC/NFS.  The PC was
having a boot time problem where the message "use NET START RDR hostname"
was being displayed.

I misunderstood the message, thinking that command was used to assign the
host that performs authentication, and issued it substituting in the
hostname of our Sequent Symmetry host.  A few moments later people
starting complaining that the Symmetry was down.

Actually, the "NET START RDR" command identifies the hostname of the PC,
which it looks up in its HOSTS file to determine its IP network address.
A message on the Symmetry's console explained why it was unavailable,
b"Duplicate IP address on the network".

The risks should be obvious.  System Managers should not be allowed to
touch PCs without re-reading the manuals first.  :-}

        Patrick Wolfe   (pat@kai.com, kailand!pat)
        System Manager, Kuck & Associates, Inc.


Auto Risks [...cs.utexas.edu!walt.cc.utexas.edu!mentat]

Robert Dorsett <mentat@louie.cc.utexas.edu>
Sat, 8 Apr 89 22:24:22 CDT
I didn't think I would run across something to surpass the BMW weight-dependent
anti-theft system so soon, but today I received the Buick _Dimension_ promo
disk.  For those who aren't familiar with it, the Macintosh version runs a 
Hypercard-like slide-show (with music, sound, and animation) detailing the
Buick product line.  This year's disk mentions a new feature (with animated 
demonstrations): a "remote access" system on the Riviera and Riatta, two 
sports cars.  Here's what they have to say:

  "Remote Keyless Entry is designed to unlock and lock your car's doors and
  unlock the deck lid from up to a 30 foot radius.  On some Buick models, you
  also control the interior lighting.  On those with factory equipped theft
  deterrent systems, locking and unlocking automatically arms and disarms the
  deterrent system.

  "One of billions of unique codes are programmed into the systems Erasable
  Programmable Read Only Memory (EPROM).  Using 4 or 8-bit microprocessors,
  the system reacts to an operational code such as "unlock the doors," only
  after receiving a valid identification code.

  "The benefits of this system are fully realized only after using it.  How
  about identifying your car from others at night in a crowded parking lot by
  pressing a button, or being able to open the deck lid when approaching your
  car with your arms full of packages?

  "The Keyless Entry System is standard on the Reatta, and is available as an
  additional feature on the Riviera and Electra/Park Avenue models."

     [The problem with the KES is that this one is real -- in contradistinction
     to the BMW promos.  The vulnerabilities are obviously considerable.  PGN]


Risk of Living in Nova Scotia

Matthew Wall <WALL@BRANDEIS.BITNET>
Mon, 10 Apr 89 00:33 EDT
The Friday, April 7th Boston Globe ran a front-page story about an MIT
graduate student whose car was marked as abandoned, towed, and compacted into
a neat cube of steel in the space of four hours. It turns out the student
was in my wife's department, and I have managed to confirm these facts:

Omitting the fact that the Massachusetts law allowed the car to be marked
as abandoned based on the word of a neighbor, the Boston city police
department and the Bureau of Motor Vehicle registration seem to be subjecting
the driving public to the risk of parking your car, or at least parking
a car from a foreign country. The student in question had previouslyst
registered the car in Massachusetts, and had then returned home to Nova
Scotia and had the car registered there. When he returned to Massachusetts,
in accordance with state law, he maintained the Canadian registration.

The towing authorities checked his Massachusetts registration information
and found that the registration had expired a few years ago, which convinced
them it was abandoned. The Globe article indicates they didn't bother
checking the Nova Scotia registration (valid) because they would be
forced to use the Interpol network, which is reserved for felonies.

The car was worth $2500, pre-compaction. I wonder if $2500 vandalism
constitutes a felony offense?

The city of Boston is now attempting to recover towing fees, a $250
fine for abandoing the car, and a $110 fee for compacting the car.
The student, Michael Picard, is suing the city.

The police seem to have relied quite heavily on a negative result from
their computerized database -- an expired registration here, that means
no valid registration anywhere, right? And they assumed that since the
registration had expired, there was no point in using their address
information to try to contact Picard.

Admitted that this might have happened to a double-parked chariot in
Mesopotamia, but computers seem to have allowed the authorities to
act thoughtlessly and destructively with impressive speed.


Otis elevator software (Re: RISKS-8.50)

Eric Roskos <roskos@ida.org>
Thu, 06 Apr 89 13:11:27 E+
> "The elevator was open and she took one step inside. But she didn't
> take the other one because the door closed and went up." ' [Idil Adam]

This is really bad news, since it suggests something worse than just a
malfunction.  In the old mechanical elevators I've looked at closely, the latch
that locked the outside door had a switch built into it.  The latch consisted
of a hook on the door that hooked into a hole in a metal box attached to the
door frame.  One surface of this hook was laminated with an insulating material
covered with a plate of metal.  (Thus, the plate was insulated from the hook
and everything around it.) When the hook latched the door into a closed
position, this metal plate would bridge two metal contacts inside the box the
hook latched into, closing a circuit that allowed the elevator to move.

This was a clever design for several reasons.  First, it wasn't possible for
the switch to jam closed due to dirt, etc., since the bridging contact was
pulled several feet away from the switch terminals by the door opening.  It
could get shorted by a piece of metal falling across the contacts, but they
were about an inch apart, and inside the metal box.  Second, if you manually
reached inside the box, you would get an electric shock, which tended to
discourage tampering (as well as discouraging people who were curious how the
switch was constructed :-)).  It appeared, if the designers had done this
intentionally, that they had decided that the risk of the deterrent electric
shock was much less than the risk of the elevator moving with the doors open.

If this elevator had the same type of switch, it sounds as if maybe someone had
bypassed the safety mechanism during one of the past repairs.  Elevators are
extremely powerful (the motors that move them are enormous, even for small
elevators), and it appears that a lot of thought goes into the safety
mechanisms used in them.


Elevator Units

Don Alvarez <boomer@space.mit.edu>
Mon, 10 Apr 89 09:27:44 EDT
Someone who used to work for Otis (I trashed my mbox and lost the name) just
sent a very informative note in to RISKS regarding the design of Otis
elevators.  One point made in the letter is in error, in my opinion, and shows
a common mistake of people assessing new technology.  The author noted that the
elevator buttons are polled in a 96 millisecond loop, and hence it is not
possible for someone to push a button without the elevator noticing.  The
impression is that 96 milliseconds is very fast, because it is measured in
milliseconds.  If you restate the sentence as "the elevator only polls the
buttons every 1/10th of a second," then the impression is that the exact same
amount of time is very slow, because now it is measured in seconds.

    When dealing with human major muscle motions (like moving your arms or
walking), it is typical to see components of the motion happening at 50Hz.
This suggests (but does not prove) that 10/second isn't fast enough to assure
that the button press gets sensed.  Better numbers come from a stopwatch -- I
can start and stop a stopwatch in about 0.04 seconds (mine has separate start
and stop buttons. With a one-button stopwatch, the time is generally just under
0.2 sec). My depressing two buttons independently in 0.04 seconds does not
necessarily mean that I can depress and release one in 0.02 seconds (=20
milliseconds = 1/50th second), but it does mean that 1) 50Hz is a reasonable
bandwidth for my fingers and 2) I can certainly depress and release a button in
well under 1/10th of a second.  The 0.2 second time for two presses of the same
button with the same finger also indicates that 10/second isn't fast enough,
since a simple division by two indicates that something is happening at 10Hz,
and that 10Hz number ignores all the time I spend accelerating and decelerating
my finger in between button presses.  Finally, when I rode the elevator to my
office this morning, I was able to press and light the button five times in a
row without the button polling electronics noticing the action, indicating that
in at least one elevator the polling loop is too slow.

Don't make performance decisions based on units.  Make performance decisions
based on performance.
                        -Don Alvarez
MIT Center For Space Research, 77 Massachusetts Ave 37-618, Cambridge, MA 02139
(617) 253-7457            

  [While we are on the subject of elevator repair people, anyone who thinks
  that this profession is unable to attract high quality personnel might be
  interested in Nick Christoffel, a self educated elevator repairman who is
  was responsible for a wide variety of important contributions to tensor
  analysis and general relativity theory.  Don]


Nuclear-powered vessels

<smb@arpa.att.com>
Mon, 10 Apr 89 10:02:37 EDT
In an article on the fire about a Soviet submarine, the AP reports that five
months ago, a reactor aboard an icebreaker in Murmansk almost melted down when
a worker drained cooling water from an operating reactor instead of one that
was shut down for repairs.  They attribute that story to the newspaper Vodny
Transport.
                            --Steve Bellovin


(Deep-seated) Presumption of innocence -- for computers

<ephraim@Think.COM>
Mon, 10 Apr 89 09:34:42 EDT
Peter da Silva (ficc!peter@uunet.UU.NET) writes:

    One thing to bear in mind is that the computer can be mistaken,
    but it can't be malicious. The computer program won't deliberately
    try to defraud a (bank/travel agency/government department/whatever).

He thereby illustrates just how deep-seated faith in computers can be! It's
true that the computer *program*, lacking volition, won't deliberately defraud
you, but can you say the same for the *programmer*?

Usually, yes.  Categorically, no.


Re: Authenticating Internet mail (Peter Scott, RISKS-8.50)

<jsl@cup.portal.com>
Thu, 6-Apr-89 22:35:41 PDT
[...] I came upon the following scheme which would authenticate > that
a given message was sent by the specified (user,host)

[Peter describes a scheme where basically a receiving host delivers a given
message to the destination user, then asks the sending host whether or not the
message originated there.  If so, another copy of the message is delivered to
the destination user, with a header line stating that this copy is
authenticated.]

This seems like a good idea, except from the point of view of the user
who receives such mail.  Assuming that this becomes the standard way
of transmitting mail, a user ends up receiving two copies of every
message -- one unauthenticated, and one authenticated.  (Except for
the folks who always get fake mail. :-)

I think a better way would be to have the mail sent as usual from the
sending host to the receiving host, but with an option to authenticate
immediately. This would be done by having the sending host look at the
received message, parse out the supposed sending host and user (from
the "From:" line), open a connection to an "authentication daemon" on
that host, and ask "did user <x> send message-ID <y>?"

If the sending host did not support authentication, the connection
would fail, and the receiving host would add a header to the message
stating that the message was possibly fake.

If the connection was successful, but the authentication failed (i.e.,
the receiving host didn't have the message ID in its database or the
username didn't match up), the header would state that this was
probably a fake message.

And of course if both the connection and the authentication were
successful, the header would state that this was a genuine message.

The only problem I can see with this modified scheme is that mail sent
through multiple hosts (for instance, on the UUCP network) would take
three times as long to get to their destination.

John Labovitz jsl@cup.portal.com


Passwords in plaintext (Stafleu, RISKS-8.52)

<BRIAN%UC780.BITNET@CUNYVM.CUNY.EDU>
Mon, 10 Apr 89 10:15 EST
May I add to the list of flagrant security violators the Hewlett Packard
Corporation?  Under MPE/V (the current OS for HP/3000 machines), all batch jobs
must begin with a JOB card (those of you living in the late 1980s, substitute
"line of text") which contains user and group passwords in plain text.

Interestingly, one of our systems programmers (who shall remain nameless)
spoke of this as a FEATURE, because it allows users to submit batch jobs
for other accounts!

Brian McMahon, Administrative Computing, University of Maryland 


Re: Cellular telephones

Eric Thayer <eht@cs.cmu.edu>
Mon, 10 Apr 89 09:58:14 -0400 (EDT)
Steven C. Den Beste, denbeste@BBN.COM, quotes a Boston Globe story
about cellular phone eavesdropping and says that the article claims that

> that the FCC says such eavesdropping is illegal.

Has the law changed?  I was led to understand that the FCC does not ban the
reception of any signal.  Of course, banning the reception of certain signals
is going to be tough to enforce anyway.


Re Cellular Phone Encryption

David Collier-Brown <daveb@geaclib.UUCP>
23 Mar 89 01:22:39 GMT
karl@sugar.hackercorp.com (Karl Lehenbauer), commenting on the security of 
electronic mail quoth:
> Cellular phone data encryption is a relatively simple matter as well.  I don't
> think we'll see any movement in that area until the users demand it, and the
> government isn't likely to push heavily for it, a few strong proponents of
> personal privacy in the legislature nonwithstanding.

  Just for information, significant levels of encryption for cellular phone
services have been considered by various vendors.  I'm constrained not to
comment on the details, but one vendor did speak with an associate and me
about the time and cost of getting access to proper encryption devices for
their product line.  They were constrained to deal with an american company
to do so, though, so I haven't heard anything more about it.
 --dave (sometime security maven) c-b

David Collier-Brown, Interleaf Canada Inc., 1550 Enterprise Rd., 
Mississauga, Ontario  yunexus!lethe!dave  utzoo!lethe!dave@gpu.utcs.toronto.edu

Please report problems with the web pages to the maintainer

Top