Subject: RISKS DIGEST 12.54 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 22 October 1991 Volume 12 : Issue 54 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Oki Telephone Programming (Stuart Bell) Nintendo lottery sidetracked for now Single Point of Failure in L-1011 Intercom (Craig H. Seidel) Computer reads water meter (John Sullivan) Risks of software controlled safety switch (Diomidis Spinellis) Re: Licensing of Software Engineers (David Parnas) Law requiring bug fixes (Mark Seecof) Re: Yet another journalistic... (Amos Shapir) More ATM anecdotes (Ralph Moonen) Re: TRW misreports local taxes (Matt Bishop) Re: JSC SMS rehost (David Carlson) Avis vs. Spaf (Gene Spafford) Re: Have you tested your machine lately? (Boyd Roberts) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. REQUESTS please to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 12, 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. 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: Tuesday, 22 Oct 1991 09:28:11 EDT From: stu@mwvm.mitre.org (Stuart Bell) Subject: Oki Telephone Programming My wife just purchased one of the new Oki programmable cellular telephones with a built in beeper. When it didn't beep for a day or so, we tried to originate a call and found it had not been activated by the vendor. No problem, he said, "Just bring it in and I'll change its number to the one I entered by accident." Turns out, he had accidentally transcribed a number so the incorrect number was activated. My wife objected to the trip - so the man nicely explained how to reprogram the internal memory and change the number of the telephone! The risk is obvious: tired of paying those high telephone bills and don't know where to buy one of the chips described earlier in RISKS that change your telephone number? Just buy an Oki and reprogram it to any number (within limits) you choose and off you go. Or, examine your bills very carefully. Stu Bell (713) 333-0906 ------------------------------ Date: Fri, 18 Oct 91 16:45:20 PDT From: "Peter G. Neumann" Subject: Nintendo lottery sidetracked for now (See RISKS-12.27,39,41,42) Game Over For Nintendo Lottery MINNEAPOLIS (AP) [18Oct91] A controversial plan to introduce the state lottery into homes with the popular Nintendo video games was dropped amid complaints it would harm children and encourage compulsive gambling. State Lottery Director George Andersen said more discussion of the play-at-home system the first such plan unveiled in the nation is warranted in light of lawmakers' complaints. "I still think it's a good idea," he said. "But we never want to operate without as broad a consensus as we can." [...] ------------------------------ Date: Tue, 22 Oct 91 16:23:38 -0700 From: seidel@puma.sri.com Subject: Single Point of Failure in L-1011 Intercom On October 19 I was on TWA Flight 843 from JFK to SFO which was delayed 2 1/2 hours while repair crews located and repaired a wiring harness in the intercom system used for communications through the aircraft. The intercom is essential for safe operations because it is used for communications in case of any emergency in-flight (for example, on another flight a Pan Am pilot told me of the time a flight attendant informed him that a wing-tip fuel tank was losing fuel, something he could not see from the cockpit). What I found interesting about the intercom system is that it is wired like christmas tree lights where any failure in the chain causes a complete failure and requires a check of each component. If this is truly an essential system, I would expect more redundancy--I can imagine many emergencies that would disable this system. The intercom wiring harness in the TWA L-1011 simply wore out (each time the flight attentant sits down, the harness is bent), a consequence of flying planes for so many years. What will happen to modern fly-by-wire aircraft after they have been in the air for 30 years? ------------------------------ Date: Tue, 22 Oct 91 19:14:12 CDT From: sullivan@geom.umn.edu Subject: Computer reads water meter Minneapolis will be introducing "Easy Reader", a computerized water meter reading system, over the next five years. You get a new meter and an interface unit plugged into your phone line. Once a month, a reading will be taken automatically, and sent to a central billing computer. This will happen between midnight and 7am. Presumably the unit in your house places the call; they say "Your telephone will not ring". They have anticipated several objections people might have to the service. They promise your phone service will not be interrupted: "If you do happen to be on the phone ... Easy Reader will get a busy signal [sic] and try again later. If you pick up the phone while the meter is being read, [it] will instantly disconnect." They also reassure you that nobody will use this equipment to listen in to your phone conversations, and perhaps most curiously, reassure people with unlisted numbers that "Telephone numbers need only be disclosed during the installation of the system. After the initial contact with your home phone has been made, your number is no longer needed. The Water Works will gladly respect your privacy by not recordeing your number anywhere in its files." Why would they even need the number temporarily to set up service? They don't promise that the system won't accidentally dial 911 in the middle of the night :-) John Sullivan, Univ. of Minnesota, sullivan@geom.umn.edu ------------------------------ Date: Tue, 22 Oct 91 18:56:19 BST From: Diomidis Spinellis Subject: Risks of software controlled safety switch A portable CD player I was experimenting with, features a safety switch, located on the hatch door, which turns the unit off once the door is opened. The role of that switch is to ensure that the laser in the unit will not operate with the door open. A number of other appliances (microwave ovens come to mind) have similar safety switches. One day I decided to deeply discharge the batteries of the unit (i.e., drain the them as much as possible) as a precaution against the NicCad "memory effect." The unit has an auto-power-off feature whereby when the batterie voltage falls bellow a certain level it switches itself off. Every time the unit switched itself off, I pressed "play" again to switch it on. The objective of this procedure was to drain the batteries as much as possible. After some time the unit crashed. The display had some strange segments lit and the auto-power-off feature was no longer functioning. My first conclusion was that the auto-power-off was software controlled. My next move was to check what other things were software controlled. I plugged mains power to the unit so that I would not loose this crashed state and tried opening the hatch door. As I was expecting the safety switch was also, apperently, software controled because the unit remained on. Now, I was faced with a unit turned on, with full power applied to it and with an open door hatch. Moral: Software emulation of safety interlocks is not a good idea. Even with formaly proven correct software, we would still need hardware that was formaly proven to correctly function under all probable conditions to implement a safe product. Direct control methods (such as a switch connected to the power supply in this case) are more appropriate. Diomidis Spinellis, Department of Computing, Imperial College ------------------------------ Date: Tue, 22 Oct 91 12:59:10 EDT From: parnas@qusunt.eng.McMaster.CA (David Parnas) Subject: Re: Licensing of Software Engineers (RISKS-12.52) There seems to be a false assumption in some of the comments made by those who fear this concept. They assume that the body that issues the licenses is the government. That is not the case for other engineers. In many jurisdictions there is a professional body that is charged with this task. In Ontario it is the APEO, Association of Professional Engineers of Ontario. In Australia there is an "Institution of Engineers". Thus, it becomes the job of professionals to set the standards for their own profession and to enforce them. Why should the software field be different? ------------------------------ Date: Tue, 22 Oct 91 11:20:02 -0700 From: Mark Seecof Subject: Law requiring bug fixes (Hanlon, self-regulation, RISKS-12.52) In RISKS-12.52 Richard Hanlon suggests: > ..with a minimal intrusion by the government, [by] making it a law to > provide free bug fixes (there's ALWAYS at least one more bug). Such a law might have horrible consequences for software vendors. Fred Brooks in _The Mythical Man Month_ (Addison-Wesley, Menlo Park, 1982) reports (in Ch. 11, adducing evidence which I've elided here) that: The fundamental problem with program maintenance is that fixing a defect has a substantial (20-50 percent) change of introducing another. So the whole process is two steps forward and one step back. and ...All repairs tend to destroy the structure [of the software], to increase the entropy and disorder of the system. Less and less effort is spent on fixing original design flaws; more and more is spent on fixing flaws introduced by earlier fixes. As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress. [...] Systems program building is an entropy-decreasing process, hence inherently metastable. Program maintenance is an entropy-increasing process, and even its most skillfull execution only delays the subsidence of the system into unfixable obsolescence. So I suggest that any law interfering with the allocation of resources to maintenance or development (often of a replacement system) by the presumably expert management of a software vendor would be unwise and ultimately destructive. Customers exercising a legal privilege to demand that bugs in a senescent system be fixed could force a software vendor right into the Pit of Despair. Mark Seecof ------------------------------ Date: Tue, 22 Oct 91 09:03:58 +0200 From: amos shapir Subject: Re: Yet another journalistic ... > I've listed the relevant allegations - I guess Amos Shapir or > somebody will probably send you the full article. Well, the full article is too long to post (and nothing new to most RISKS readers). I agree with most of Simon's conclusions, but there are some inaccuracies in his quotes. I understand his indignation at having *his* system exposed in public, but he'd rather leave the posting to the guy who had actually read the article. > Four years ago, he broke into her account - he claims > that by chance, her password happened to be the same at the time of the > demonstration. I have no evidence to contradict this,although it seems more > likely that he guessed her current password using the information he had from > the old one. Actually, she was asked about it and is quoted in the article as admitting to reusing the same old password. > Claim #2: He stated that the account name had a prefix which indicated that > the account was special, and that this showed how naive the system > managers were. (This is not a correction, it just reminds me of something that happened here). On CDC's NOS system, privileged accounts are the ones which begin with a C. You can guess what happened when a somewhat ignorant administrator assigned the Computer Science department accounts which begin with CS... > Claim #6: He claimed he could destroy all the back-ups. > Lie: Maybe if he stuck magnets on a few SCUD-C's and lobbed them at the > various tape archives. It's a lot harder to spoof a human being, > especially when you're a 24 year old male, and the spoofee is a 50ish > woman. Not exactly. What the cracker claimed was that he could use the administrator's account to ask operators to mount the backup tapes, then destroy them; the operators could have no way of knowing that the request wasn't legitimate. The spokesman's response in the article is along the line "if we'd get such a request we'd probably call back and ask what it's for". Amos Shapir, The Hebrew Univ. of Jerusalem, Dept. of Comp. Science. Givat-Ram, Jerusalem 91904, Israel Tel. +972 2 585706 ------------------------------ Date: Tue, 22 Oct 91 11:17 MET From: hvlpa!rmoonen@att.att.com (Ralph 'Hairy' Moonen) Subject: More ATM anecdotes I am a frequent user of ATM's. As banks in The Netherlands are closed after 17:00 and in the weekends, the only way you are going to get cash after that time is through an ATM. Unfortunately not all off them are the same, and some display a most peculiar behaviour. Example: ATM: INsert card Me: I insert my card ATM: key in your PIN code. Me: I do so. ATM: There are no receipts available currently. Choose the amount of cash you wish to withdraw. Me: I choose 100 Guilders ATM: There are no receipts available currently. Do you want a receipt? Me: I press the "No" key. ATM: We're sorry, there are no receipts available currently. ATM: Please wait..... ATM: Retrieve cash from ATM please. There are no receipts available currently. Me: I KNOW THERE ARE NO RECEIPTS!!! Please quit whinig and give me my money. [withdrawal hatch opens, and my money is there, so I take it] ATM: Please take your card out. Me: I take my card out. ATM: Please wait for your receipt. There are no receipts available currently. RISKS? Well, none really, but quite frustrating..... Another example is funny stuff is the banks apparently can edit the on-screen messages on the fly, for once I was making a withdrawal, and the screen is flashing a bank advertisement on the bottom two lines. Something like: "Open a new account now, and receive this great CD with the greatest hits of 1991, PLUS a whopping 5.4% interest" When suddenly, the cursor moved to that line, and lo and behold, they edited the interest rate. The ATM continued my trans- action perfectly, but is was pretty weird to see the line edited *on-screen*. For a last weird stuff thing, I once arrived at an ATM, that looked in pretty bad shape. Someone had apparently drank too much and decided to unload his lunch over the keyboard. I took one look and decided to, well, not make the planned transaction. At that point a van stopped and some service guy gets out. So I wait and see. The guy goes through a door next to the ATM, does something to the inside, comes out, and lifts the complete front off. Puts it into his van, and replaces it with a new one. I asked why, and he said well, would you like to have to poke in someone others puke. I said, but you don't need to replace the whole *front* for that, you could just clean it! The answer was a vague story about disinfecting the thing, and AIDS (!!) and that he didn't fancy having to clean it. --Ralph Moonen rmoonen@hvlpa.att.com ------------------------------ Date: Tue, 22 Oct 91 09:06:29 -0400 From: Matt Bishop Subject: Re: TRW misreports local taxes (DeBoer, RISKS-12.52) > Why is it that inaccurately negative credit reporting [doesn't | shouldn't] > constitute libel under the law? "DOESN'T": It's (US federal) law. As I understand it (admittedly, I'm no lawyer), the credit reporting agencies are protected unless they maliciously report the information. If they make a mistake, that's not actionable. (The explanation given to me also included the statement, "Well, they have so many records, you can't expect them to have everything right, so as long as their errors aren't deliberate, they shouldn't have to pay." Unfortunately, I don't remember WHO gave me that explanation but I'd be interested in knowing if that is in fact the reason behind the law shielding the agencies.) Matt ------------------------------ Date: Fri, 18 Oct 91 9:49:38 EDT From: David Carlson Subject: Re: JSC SMS rehost (RISKS-12.47,48,49) I read recently in RISKS the serious question by a Johnson Space Center employee on the risks of rehosting a large realtime program currently on minicomputers manufactured by my company. It was some amusement that two contributers offered parochial suggestions that their favorite hardware was clearly the "right" choice for such a large problem. This misses (and yet reinforces) the point the original contributor made that cost of the rehost to IBM/workstations would be larger than understood by management. The reinforcement of the original idea is that the two followup contributors answered a software complexity unknown by asserting "it will be easy using " rather than by quantifying the complexity of the Shuttle Mission Simulator. I find this cavalier professional attitude not unlike a hospital administrator declaring that at *my* hospital we could cure your cancer without knowledge of the diagnosis of the patient. Medical professionals are very careful not to tele-diagnose. As computers professionals we should strive to be as circumspect. David F. Carlson, Concurrent Computer Co. dave@bigguy.ocpt.ccur.com Fairport NY ------------------------------ Date: Fri, 18 Oct 91 21:41:37 EST From: Gene Spafford Subject: Avis vs. Spaf Yesterday, I flew into Chicago O'Hare airport from Vienna, Austria. I wasn't too awfully jet-lagged, and rather than wait 8 hours for the next flight to West Lafayette, I decided to cash in my ticket and rent a car one-way. (West Lafayette is a 2.5 hour drive from O'Hare.) I got to the car no problem. The agent at the counter said it was in stall J-32, and that is where the bus dropped me. So, the keys were in the ignition and the driver's side door was unlocked. I threw my coat in and tried to open the back door to toss in my portable PC. It was locked. So, I hit the powerlock button on the driver's side door to unlock all the doors, and then went to get my PC. A gust of wind blew the driver's side door shut. I then discovered I had LOCKED all the doors by pushing the button the wrong way! (This was a Chevy Lumina.) On my old 1975 car, one must hold the handle out when closing it, or lock it with the key after closing -- a form of fail-safe behavior compared to this. To make matters worse, the car was to be rented one-way, so they had given me a car originally from Maryland...with no duplicate keys to be had locally. It took 2 of their mechanics working together for about 30 minutes to break into the car without excessive damage. If my coat hadn't been in the car, they would have just rented me a different one. Sigh. But wait, it gets better! On the way our of the lot, the guard checked my rental agreement against the sticker on the car. The numbers didn't match! I had to go back because I had the wrong car for the agreement, and he couldn't let it out of the lot. The woman at the counter sort of rolled her eyes when I came back in for the third time, but she forced a smile and said that rather than switch the car, she would just adjust the contract to show the car I had. Some quick keypresses, a new contract agreement off the printer, and I was on my way. This morning, I drove the car out to the airport here to return it and pick up my car in the parking lot. As I was transfering my briefcase & books from rental car to personal car, the wind must have blown the rental agreement off the car seat and into the surrounding fields. I couldn't find it anywhere. Sigh. Trudge into the airport. Give the person at the counter the keys and mumble "I seem to have lost my agreement somewhere." No problem -- she'll just take the ID off the keys, enter the final mileage, and print a duplicate agreement. The benefit of having one of those marvelous computer networks, eh? So, she puts in the mileage and vehicle number, confirms that my rate was $89 with the corporate discount, and prints the receipt. As she hands it to me, she smiles and says "Have a nice day Mr. Anderson" (I don't remember the exact name). This takes me a bit aback, and I ask "Anderson?" fearing the worst. I look at the rental agreement. The name, home address, and so forth are not mine. The agreement shows that the car was rented at Dulles Airport and was not to be returned until tomorrow -- back to Dulles. It had someone else's credit card number. It was the correct car, but the wrong renter. After struggling with the computer for about 20 minutes, the clerk then called Chicago and spoke to 9 different people (we counted) in 30 minutes before getting someone who could help find my rental record. It seems Avis's system does not allow (for privacy reasons?) any field agent to do a lookup based on name, based on credit card number, based on rental location, or based on anything else I had with me or could produce. It needed either the rental agreement number, which was lost, or the vehicle ID, which was incorrect. The folks in Chicago had to find the duplicate PAPER copy of the rental record in their files to get the correct number. Once my agreement was finally corrected, they had to fix the record for "Mr. Anderson" because he hasn't returned his car. However, they can't cancel a transaction in the system, I guess because it might allow employee fraud ("Mr. Spafford, our records do NOT show a checkin -- either produce the car or we swear out a warrant."). Instead, they have to issue a special form of checkout that negates the effect of the checkin. Unfortunately, the computer now showed that the vehicle was checked in, because the local office had file a record to indicate they had the car. The system won't allow a car marked as present at a local office to also be marked as "rented." Between Chicago and locally, they decided to take the car "out of service" somehow, thus removing it from the ken of the system. They then did a correction checkout on Mr. Anderson. He's in for a surprise, probably, when he tries to check HIS car in tomorrow. I hope he doesn't have a flight to catch. Then again, maybe he'll do an express checkin where he simply throws the keys and the agreement envelope into a mailslot, and add even more entropy into the mix. This whole mess took almost 45 minutes to get straightened out. I bet their records are still messed up, with the car I had now marked out of service and some other car lost in the system. I wonder if they will ever get it evened out. As for me, no more rentals on windy days! ------------------------------ Date: Thu, 17 Oct 91 13:14:35 +0100 From: boyd@prl.dec.com Subject: Re: Have you tested your machine lately? Two weeks ago we had a power outage which damaged various bits of hardware in some of our DECstation 5000's. I had been out of the lab for 8-10 days and I wasn't around when the outage occurred. So I wasn't really sure of the state of the world, but it didn't sound good. I log in on my 5000 (it has two big colour screens and runs X) and immediately I see some _very strange_ things happening. 1. `sunclock' paints a white icon and then exits. `sunclock' shows a map of the world with the land illuminated by the sun in white, and the dark areas in black. 2. `xman's buttons are missing the semi-circular edges on the left hand side of the buttons. `xman' is the X implementation of `man'. 3. Clicking on some of `xrn's buttons crashes my X server. `xrn' is an X based newsreader. 4. Most everthing else works. At this stage I conclude that something is seriously wrong. But just where is the problem? Is it the X clients, the server, a font problem, the display or a real machine problem? I just don't know, so I have to go looking. So I start with `sunclock' because I believe that it is probably a simple system and a sound test case. I was right, but I dismissed my conclusion because I don't trust the debugger I was using (`ups'). `ups' was telling me that the math library was returning NaN and `sunclock' would use this bogus value, compute with it, and then index off the end of an array -- and dump core. I wasn't trusting `ups' because it likes to second guess the compiler on ULTRIX 4.2. It _knows_ where the SP is. When it sees the SP is not where it should be it aborts. I commented the line out, and it works, but I don't place a great deal of trust in it, given my knowledge of the MIPS archictecure/compiler is not large. So where to next? Is it in the X server? We have quite a few field test X servers here, and maybe the new wiz bang version will fix this. After trying a few I conclude that this is not the case. Is it in the display hardware? So I board swap the display hardware and then reboot. This is what I should have done in the first place. The self test tells me the FPU failed its self test, and I conclude that it's returning garbage to the math library. All the software using floating point is broken -- in mysterious ways. This consumed a day of my time. The thing that really worries me is that when confonted with a problem with these `modern' systems you just have too many variables of which you have to know _a lot_ about to diagnose the problem. I can't see this trend ending. In the future I can see that 5 or 6 people with diverse, non-intersecting knowledge will be required to analyse the simplist of problems. This is a disturbing conclusion. Boyd Roberts ------------------------------ End of RISKS-FORUM Digest 12.54 ************************