Subject: RISKS DIGEST 14.88 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Wednesday 25 August 1993 Volume 14 : Issue 88 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Re: Mars Observer (Lee Mellinger, Michael Stern) Re: RISKS of elaborating on ... known RISKS (Bob Brown, Douglas W. Jones) Re: Telephone verification (Tom Swiss) Re: Digital Markets (A. Padgett Peterson) Re: Child-Prodigy or Prodigy-Child? (Bob Frankston) 911 & Call Privacy *67 problems (US West) (David Kovanen via Richard Jensen) More Gripen Griping (Peter B Ladkin) The RISKS Forum is a moderated digest discussing risks; comp.risks is its USENET counterpart. Undigestifiers are available throughout the Internet, but not from RISKS. Contributions should be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to risks@csl.sri.com, with appropriate, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. PLEASE SEND REQUESTS FOR SUBSCRIPTIONS, archive problems, and other information to risks-request@csl.sri.com (not automated). BITNET users may subscribe via your favorite LISTSERV: "SUBSCRIBE RISKS". Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 14, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. If you are interested in receiving RISKS via fax, please send E-mail to risks-fax@vortex.com, phone +1 (310) 455-9300, or fax +1 (310) 455-2364 for information regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; instead, as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Thu, 26 Aug 1993 20:29:45 GMT From: leem@tsunami.Jpl.Nasa.Gov (Lee Mellinger) Subject: Re: Mars Observer (Neumann, RISKS-14.87) 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 ------------------------------ Date: Thu, 26 Aug 1993 17:15:33 -0400 From: stern@deshaw.com (Michael Stern) Subject: Re: Mars Observer (RISKS-14.87) 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 ------------------------------ Date: Thu, 26 Aug 93 15:52:58 EDT From: bbrown@gmcf.org (Bob Brown) Subject: Re: RISKS of elaborating on exploitation of known RISKS 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. ------------------------------ Date: Thu, 26 Aug 93 13:47:21 CDT From: Douglas W. Jones Subject: Re: RISKS of elaborating on ... known RISKS (Reed, RISKS-14.87) ... 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. ------------------------------ Date: Thu, 26 Aug 93 14:36:04 -0400 From: tms@cs.UMD.EDU (Tom Swiss (not Swift, not Suiss, Swiss!)) Subject: Telephone verification (Re: Grodberg, RISKS-14.85) 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 ------------------------------ Date: Thu, 26 Aug 93 14:46:09 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Re: Digital Markets (Agre, RISKS-14.87) >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 ------------------------------ Date: Thu, 26 Aug 1993 15:23 -0400 From: Bob_Frankston@frankston.com Subject: Re: Child-Prodigy or Prodigy-Child? (Schiller, RISKS-14.86) 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. ------------------------------ Date: Thu, 26 Aug 93 11:43:23 PDT From: rjensen@mimir.persistence.com (Richard Jensen) Subject: 911 & Call Privacy *67 problems (US West) [David Kovanen] 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 ------------------------------ Date: 26 Aug 93 20:30:00 BST (Thu) From: Dr Peter B Ladkin Subject: More Gripen Griping 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 ------------------------------ End of RISKS-FORUM Digest 14.88 ************************