Text File

RISKS-LIST: RISKS-FORUM Digest Monday 10 April 1989 Volume 8 : Issue 53

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

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

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. * RISKS MOVES SOON TO csl.sri.com. FTPable ARCHIVES WILL REMAIN ON KL.sri.com. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. FOR VOL i ISSUE j / ftp KL.sri.com / login anonymous (ANY NONNULL PASSWORD) / get stripe:<risks>risks-i.j ... (OR TRY cd stripe:<risks> / get risks-i.j ... Volume summaries in (i.j)=(1.46),(2.57),(3.92),(4.97),(5.85),(6.95),(7.99).

----------------------------------------------------------------------

Date: 10 Apr 89 10:25 From: herbison%ultra.DEC@decwrl.dec.com (B.J.) Subject: Product Recalls Due to Software Error

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.

------------------------------

Date: Tue, 4 Apr 89 12:53:52 bst From: Jerome H Saltzer <jhs%computer-lab.cambridge.ac.uk@NSS.Cs.Ucl.AC.UK> Subject: Airliners running out of fuel in mid-flight (RISKS-8.48)

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

------------------------------

Date: Fri, 7 Apr 89 08:41:56 +0200 From: howard@strindberg.ericsson.se (Howard Gayle TX/UMG) Subject: Good press in Flying

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.

------------------------------

Date: Sat, 8 Apr 89 21:29:49 -0400 From: henry@utzoo.UUCP Subject: Re: More on 1983 Air Canada near-disaster

>(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

------------------------------

Date: Sat, 8 Apr 89 02:09:33 cdt From: pwolfe@kailand.kai.com (Patrick Wolfe) Subject: PC causes multiuser host to drop off the network

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.

------------------------------

Date: Sat, 8 Apr 89 22:24:22 CDT From: mentat@louie.cc.utexas.edu (Robert Dorsett) Subject: Auto Risks [...cs.utexas.edu!walt.cc.utexas.edu!mentat]

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]

------------------------------

Date: Mon, 10 Apr 89 00:33 EDT From: Matthew Wall <WALL@BRANDEIS.BITNET> Subject: Risk of Living in Nova Scotia

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.

------------------------------

Date: Thu, 06 Apr 89 13:11:27 E+ From: Eric Roskos <roskos@ida.org> Subject: Otis elevator software (Re: RISKS-8.50)

> "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.

------------------------------

Date: Mon, 10 Apr 89 09:27:44 EDT From: Don Alvarez <boomer@space.mit.edu> Subject: Elevator Units

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]

------------------------------

Date: Mon, 10 Apr 89 10:02:37 EDT From: smb@arpa.att.com Subject: Nuclear-powered vessels

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

------------------------------

Date: Mon, 10 Apr 89 09:34:42 EDT From: ephraim@Think.COM Subject: (Deep-seated) Presumption of innocence -- for computers

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.

------------------------------

Date: Thu, 6-Apr-89 22:35:41 PDT From: jsl@cup.portal.com Subject: Re: Authenticating Internet mail (Peter Scott, RISKS-8.50)

[...] 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

------------------------------

Date: Mon, 10 Apr 89 10:15 EST From: <BRIAN%UC780.BITNET@CUNYVM.CUNY.EDU> Subject: Passwords in plaintext (Stafleu, RISKS-8.52)

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

------------------------------

Date: Mon, 10 Apr 89 09:58:14 -0400 (EDT) From: Eric Thayer <eht@cs.cmu.edu> Subject: Re: Cellular telephones

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.

------------------------------

Date: 23 Mar 89 01:22:39 GMT From: daveb@geaclib.UUCP (David Collier-Brown) Subject: Re Cellular Phone Encryption

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

------------------------------

End of RISKS-FORUM Digest 8.53 ************************