Subject: RISKS DIGEST 12.61 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Thursday 7 November 1991 Volume 12 : Issue 61 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: [Some miscellaneous backlog items; end stuff incrementals...] Cop Charged with Doctoring Computerized Citation Record Legal status of digital signatures (Steve Bellovin) The dangers of telco competition (Lauren Weinstein) Oven temperature regulator problem (Jane Beckman) No Power backup on Electronic Fuel Injection (Gareth Howell) Another smart card risk (34AEJ7D) UK Phone charge card risk (Graham Toal) Risks of telephones with status displays (Neil Strauss) Don't bank on computer viruses! (Gene Spafford) [WWN strikes again!] NSF researchers required to undergo security checks? (Nancy Leveson) Re: Have you tested your machine lately? (Matt Crawford, Dave W. Hamaker) Re: Blaming the computer (again) (George Malits, Paul J Karafiol) Re: A new twist on "Speed Controlled by Radar" (Clive Dawson) Re: Electronically controlled bus transmission (Adam V Reed, Jamie Mason) 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: Thu, 7 Nov 91 9:15:27 PST From: "Peter G. Neumann" Subject: Cop Charged with Doctoring Computerized Citation Record Emily Fields, a San Francisco police officer, has been charged with evading payment and tampering with records after accumulating almost $700 in traffic citations. Assigned to the PD's warrant section, she allegedly gained access to the police computer and cleared a warrant issued against her for nonpayment of tickets, changing the record to indicate she had been arrested and taken into custody. (She had previously defaulted on payment and failed to appear in court, which resulted in the warrant appearing in the computer database.) [San Francisco Chronicle, 5Nov91] ------------------------------ Date: Wed, 06 Nov 91 20:08:37 EST From: smb@ulysses.att.com Subject: Legal status of digital signatures I'm looking for information the legal status of documents authenticated by digital means, i.e., RSA, ElGamal, the recent proposal by NIST, etc. Do any countries have laws, regulations, or judicial precedents governing such matters? Are such records admissible as evidence in civil or criminal trials in these jurisdictions? Will the relevant government authorities, or non-government financial practices bodies (i.e., the FASB in the United States) accept digital signatures in contexts where a paper audit trail had been required? I'm thinking of things like employee time cards, payment vouchers, purchase orders, etc. Please reply by mail. I'll be happy to compile a summary for any interested parties (and for the list as a whole, if demand so indicates, and the quality of the information received permits). --Steve Bellovin smb@ulysses.att.com ------------------------------ Date: Tue, 5 Nov 91 19:25:29 PST From: lauren@vortex.com (Lauren Weinstein) Subject: The dangers of telco competition There are quite a number of reasons why various items now on the local telcos' agendas, especially those relating to the provision of information services or television programming, would ultimately be bad news for most consumers. Fundamentally, the problems relate to there being, in practice, an extremely uneven "playing field" involving local telcos vs. any outside competition. It can be expected that most enhanced services that telcos operate will be priced in such a way as to undercut competition, either in terms of pricing, or in terms of features that only the telco can provide, due specifically to the telco's unwillingness to provide equal access to their switches at "fair" prices. Meanwhile, the telcos have the ability to jack up the price on those services for which there is no effective competition and for which most consumers have nowhere else to go. Exactly this is happening right now in California, with the two main telcos, PacBell and GTE, requesting massive increases in basic local service rates, theoretically in exchange for lower rates for certain types of toll calls. Unfortunately, any consumer or small business who has a number of lines and doesn't make enough of the "correct" type of toll calls loses out big time. While there is supposed to be a division between telco enhanced services and basic services in terms of funding and cost factors, in practice the two are usually so intertwined that its essentially impossible to control. I mentioned the uneven playing field above. There's an obvious example of this right now. Look at the telco provided "voicemail" services in comparison to the similar services provided by outside firms. With outside firms, you have to call forward into the service, and if you're on a measured rate phone line (as most businesses are these days, usually by edict, and increasing numbers of residence subscribers as well) you have to pay for every call transferred to the voicemail vendor. When you want to check to see if you have messages, you have to make yet another call to check on the status of your voicemail box. Now look at the telco systems, which are tightly integrated with their switches. The voicemail system is directly trunked to the various central offices. No forwarding, no call charges for each call. If messages are waiting, you get a "stutter" dialtone when you pick up the phone. The outside vendors of voicemail services would very much like to get access to the switch on the same basis. But at this stage of the game, they can't. Eventually a complex set of FCC rules may supposedly allow for the access of outsiders to various network "elements" as individual units. However, it appears that the pricing of such elements will be quite predatory and in practice continue the telcos' pricing advantage as it relates to tightly coupled enhanced services. Other similar cases already exist. Various telco-sponsored information services for cellular phone users, accessible more easily (fewer digits) and more cheaply (even free!) than outside services, have already been announced. Now the telcos want to do video (Cable TV) too! They're waving the promise of fiber-to-the-home in front of Congress, and waxing poetic about all sorts of glamorous future information services (most of which, by the way, sound much the same as services available now from outside vendors). Little (if any!) mention of pricing ever comes up in these discussions (the high rates for current ISDN implementations may be instructive here). Nor is it mentioned that, inevitably, the telcos will keep coming back to the local basic service ratepayers to help bail them out from any failed projects. You can also be sure that most telco information services will be oriented toward dense urban areas and well-heeled business customers. The example of the French Minitel system comes up from time to time as a "successful" telco-related info service with many outside vendors. I don't believe that this example can be applied to the U.S. telecommunications market. The French government provided most of the Minitel terminals for "free", and even now, after all these years, the system requires large government subsidies to stay in operation. The government/private industry/telecommunications structure there is fundamentally different from what we see in the U.S. environment, with government control and government funding/subsidies playing much more central roles than would be tolerated in this country. This message can but give a taste of the issues involved; it's all a very complex matter. But boiled down to its essence, the problem is that in practice we cannot depend on the owners of the fundamental "pipelines" (the telcos) being able or willing to provide truly equal access, both in terms of pricing and features, to their competitors who need to use those same pipelines. This is especially critical since the telcos are in the enviable position of having that handy collection of basic ratepayers to fall back on, one way or another--theoretical provisions to prevent this notwithstanding. --Lauren-- ------------------------------ Date: Mon, 28 Oct 91 18:02:05 PST From: jane@stratus.swdc.stratus.com (Jane Beckman) Subject: Oven temperature regulator problem Seeing the recent discussion of furnace thermostats going haywire reminded me of a recent problem a friend had with her oven. Her stove is one of these modern models with electronically regulated oven temperature control, digital readouts, etc. These things are great, until... She was baking some cookies, and when she took them out, she thought it was weird that they were overdone. The timing was right, but the oven temperature seemed to be way too high. She turned off the oven and didn't think a thing about it until she put a casserole in a couple days later. The casserole seemed to be cooking too fast, and the oven was like a blast furnace, and yet the stove told her everything was fine. So she decided to turn off the oven. The oven would not turn off. For the next couple hours, she tried to turn off the oven, to no avail. The kitchen was getting pretty warm, by then. The final solution to this was to turn off the gas to the stove. She called the repairman, and when he came out and evaluated the problem, it turned out some vital piece of electronics had shorted out, and the cost of replacement was $200, which was a sizable chunk of the price of the stove! She seriously discussed simply replacing the stove with a $400 non-electronic stove, for fear of this happening again, but finally broke down and had it fixed. She has had other problems, since, with the temperature not being what the sensors think it is. It sounds like the entire sensor system may have had design problems, from the first. (Sorry, I don't remember the brand of stove.) Jane Beckman [jane@swdc.stratus.com] ------------------------------ Date: Thu, 03 Oct 91 04:57:15 BST From: garethh@sadss.uucp (Gareth Howell) Subject: No Power backup on Electronic Fuel Injection This concerns the risk to the environment when the Electronic Control Unit (ECU) for the fuel injection doesn't have a protected power supply. I used to own a Rover 800 (sold as a Sterling in the US). One of the models in the range (820E) has a 2litre single-point fuel injected engine. The configuration setup of the ECU (which controls the fuel-air mixture, and hence controls emissions) is held in volatile RAM, which is powered from the car's battery. Unfortunately, if you disconnect the battery the RAM is cleared, and whilst you can still run the engine, it runs in a default state which can cause excess emissions. The detailed workshop manual contains a method of re-tuning the engine if the settings are lost, but it doesn't indicate that disconnecting the battery (which has to be done for many repair/ service type operations) will cause the ECU settings to be wiped. Here in the UK, we have just introduced emission checks on all cars as part of their annual safety check - I wonder how many 820E's will fail because either their owners or the garage didn't re-set the ECU settings? 73 Gareth Note: As far as I know the other models in the range don't suffer from this problem. Gareth Howell, Information Technology Services Agency, Department of Social Security, Lytham St Annes, England, FY8 1ZZ garethh@sadss.uucp sadss!garethh@eros.uknet.ac.uk garethh@cix.compulink.co.uk +44 (253) 797096 ------------------------------ Date: Mon, 04 Nov 91 11:36:47 EST From: 34AEJ7D@cmuvm.bitnet Subject: Another smart card risk The Florida-based Advanced Promotion Technologies has developed a smart card, dubbed a "Vision Value Card" to accumulate details of buying patterns, etc. at various mega-markets. I believe the VVC is in use, or testing, in the Mormon-owned Safeway foodstore chain. The card also doubles as an electronic "trading stamp" by accumulating "bonus points" awarded for purchasing certain products. These points are redeemable for "gifts" from a catalog published by APT. ------------------------------ Date: 31 Oct 91 23:32:26 GMT From: gtoal@gem.stack.urc.tue.nl (Graham Toal) Subject: UK Phone charge card risk This may be old news to comp.risks or comp.dcom.telecom, but it was the first time it was drawn to *my* attention; Barry Fox has an article in this week's New Scientist (UK weekly) explaining that phone charge cards in the UK work by dialling 144 + card no + PIN + phone no; it seems that Hotel/business/etc call loggers (understandably) record this string of numbers as the number dialled. He doesn't say that this *has* been used to fraudulently use someone's account, but I think that's a fair assumption. (There has been talk on uk.telecom of possible large-scale fraud going on recently) Fox says that 'Telecomms Regulation Review' trade magazine had informed BT of this some time ago, but BT have done nothing to warn their customers. [I wonder what sort of warning would be appropriate?] Graham PS I'm posting to comp.risks for the risk aspect; to comp.dcom.telecom because I wonder how this problem was solved in the US who have had this technology much longer than us. ------------------------------ Date: Thu, 7 Nov 91 15:31:05 EST From: neil@ps.quotron.com (Neil Strauss) Subject: Risks of telephones with status displays I recently used a telephone at a customer of ours to call my office voicemail. This phone had a LED display which echoed every button I pressed from the time the handset was raised until I hung up. This resulted in my voicemail password being prominently displayed to any passing individual. The risks of my voicemail being compromised are relatively small, but the same type of compromise would have occurred if I had been using a telephone credit card. I learned after completing the call that there is a button on the phone which will prevent button presses from echoing, but this button was not clearly labelled and could not be used by an uneducated user. The most logical approach to a status display on a phone is to echo the phone number to prevent wrong numbers and then inhibit echoing after the call has been connected. I also wonder if a phone that displays my keystrokes may not also be recording them somewhere for accounting purposes. ------------------------------ Date: Mon, 04 Nov 91 20:34:19 EST From: spaf@cs.purdue.edu Subject: Don't bank on computer viruses! [WWN strikes again!] We've heard all about the usual stealth computer viruses and "armored" viruses that are being written these days. It seems that in some places the writing of nasty viruses has become a national pasttime. Some of these authors delight in finding new methods of damage and camouflage. The problem has mainly been for IBM PCs, and the most sophisticated virus-writing has been in Bulgaria and the USSR. Now, however, we have a new and far worse problem from South America, according to the November 12th issue of the "Weekly World News." [This is the "newspaper" you may find at supermarket checkout lines with the kind of headlines you don't see in the more mainstream media. Obviously, a conspiracy by the mainstream media. The November 12th issue is headlined with "Ohio Woman has a 3rd Eye -- in the back of her head!"] On page 7, there is an article by one Sally O'Day, "special to the WWN," and entitled: "Demon Computer Kills 2 Workers!" It is subtitled "Exorcist called in after experts discover virus-bred evil spirit!" The article goes on to explain how a computer system installed in a bank in Valparaiso, Chile is possessed by a demon. A consultant from the computer company that installed the system claims that it must be the result of a virus installing an evil demon that has caused: * observers to see a hideous horned demon appear on the screen * anyone who tries to turn off the machine to black out and fall to the floor * Carmen de la Fuente to have a fatal heart attack within 2 minutes of sitting down at the terminal * Maria Catalan to be found sitting at the terminal with her head in her lap [decapitated, I presume, rather than a contortionist] * a computer expert to began babbling like a madman when he got within 10 feet of the terminal This brings up many interesting questions: -- How long before commercial anti-virus vendors start advertising that their products work against this type of virus? -- Does the exorcism ritual end with extinguishing the candle, closing the book, and sounding the BEL? -- Could this actually be the result of using Ada rather than a virus? -- Do you know any computer experts who don't begin to babble when within 10 feet of a computer? -- Does normal business insurance cover an exorcism? -- Maybe it's a Unix system and this is the first time they've seen the sendmail daemon? -- Will Fred Cohen allow this to be entered in his virus-writing contest? Or, it could be that Ms. O'Day has recently seen the movie "Evilspeak"? [If you have yet to see the movie, rush right out and rent it. Lay in a supply of beer and pizza, and invite the neighbors over. It is a classic wherein a nerdy Ken Howard (Ron's little brother -- the one who used to hang out with Gentle Ben) summons up the devil on an Apple II computer. He should have guessed something was amiss when he started getting Stardent-level graphics on his little Apple, and when it started demanding blood sacrifices. The credits include mention of the "stunt demons" and "Satan's Sows." Not to be missed.] Hey, it must be true if they printed it, right? :-) [It is astounding how they manage to recycle old stories. The basics of this appeared years ago in WWN, 3 March 1987 (see RISKS-4.50, 23 February 1987, , and Softw.Eng.Notes April 1987, vol.12, no. 2, p.14), and has now been embroidered by WWN to suit the virus craze. I run this item here to demonstrate the hokeyness of WWN's reporting. PGN] [Also noted by SCANDORA@aes.cmt.anl.gov (Tony Scandora 708-972-7541) and Martin Minow .] ------------------------------ Date: Fri, 01 Nov 91 06:18:33 -0800 From: leveson@cs.washington.edu Subject: NSF researchers required to undergo security checks? The Washington Post, on Tuesday 29 Oct. 1991, page A21, contains an article about the new NSF Presidential Faculty Fellows program (like PYI but more money). The article states: Recipients of the Presidential Faculty Fellows awards will have to be formally approved by the White House, though Bromley said no one will be denied a grant for political reasons. They will also have to undergo an FBI background check. Presidential approval is OK -- that is also part of the PYI program and is probably just a formality -- but why should an FBI background check be required to receive an NSF research award? Surprisingly, the author of the Post article did not mention the fact that this might be out of line (the article only expressed concern that the award was just a shell game that would actually reduce the total number of young scientists supported in the combined PYI and PFF programs). This seems like a very dangerous trend, and I am shocked that NSF would agree to go along with this. nancy [This item is marginally related to computer risks, but seemingly relevant to some of the related threads running through RISKS, such as privacy of computer scientists who might apply for PYIs? PGN] ------------------------------ Date: Wed, 30 Oct 91 16:04:16 CST From: "Matt Crawford" Subject: Re: Have you tested your machine lately? (Roberts, RISKS-12.54) > All the software using floating point is broken -- in mysterious ways. A few months back we had a problem with a VAX/8650 running VMS. approximately 9 out of 10 attempts to log in would fail as if the password were wrong. It sounds like the classic Trojan horse login program, but it was actually a bad floating point board. It took a few days to figure it out, but eventually some vax guru inside DEC gave field service the answer. ------------------------------ Date: 25 Oct 91 17:33:54 GMT From: dwh@eco.twg.com (Dave W. Hamaker) Subject: Re: Have you tested your machine lately? (Roberts,RISKS-12.54) In RISKS-12.54 Boyd Roberts writes about his tribulations with his DECstation 5000 when its FPU failed. A day of his time was consumed trying to figure out why strange things were happening, and the problem became evident only after he started trying hardware swaps. This necessitated rebooting and the self tests then incidentally revealed the true problem. This reminds me of the time the FPU in a mainframe had a failure which took me only a few minutes to diagnose. I was responsible for taking care of the system software. It was reported to me that many DBMS users were getting incorrect results. I knew the software hadn't been changed recently and there were too many reports for me to suspect "user error." Hardware seemed the only other alternative. "But why isn't the whole system crashing?," I thought. "Maybe the operating system doesn't use floating point," and a few quick tests showed the results of floating point adds and subtracts always came out negative (1 + 1 = -2). Sometimes one is fortunate enough to ask the right question first. At another job, a colleague got the source code for a quick instruction set diagnostic from the computer vendor's service engineers and spliced it into the operating system's "idle" loop. When the machine wasn't doing anything else, it would be testing itself. As I recall, that this caught a hardware failure at least once. Perhaps this is something hardware vendors might do that would help with the kind of failure Boyd Roberts experienced. Dave Hamaker ------------------------------ Date: Thu, 7 Nov 91 09:33:02 EST From: malits@sgtyork.sw.stratus.com (George Malits) Subject: Re: Blaming the computer (again) (Schwartz, RISKS-12.60) Concerning the article on the $1M tax bill. Deja Vu all over again. If you've ever read _The Elements of Programming Style_ there is a very similar example. This was back in the days of punch cards and a data entry error shifted one of the fields by one column. The result was that the rightmost character in one field ended up in the leftmost column of the next field. This turned out to place a letter in what was supposed to be a numeric field. No matter, the software managed to "interpret" the letter into a digit. The result was that some poor guys Chevy was valued at several million dollars. The best part of the whole thing was the error was detected (by manual inspection and not by the software) and a new card punched but somehow the old card was not destroyed. The tax payer received 2 bills, one correct and one very wrong. In this case, the town could/would not print new tax bills at a higher rate so they were forced to cut the town budget to make up the deficit BTW: All of this is from memory so I apologize in advance for any errors in detail that might have crept in. ------------------------------ Date: Thu, 7 Nov 91 14:07:47 -0500 From: karafiol@husc.harvard.edu Subject: ORegon Misassessed property tax (Re: Schwartz, RISKS-12.60) >[a farm in rural Oregon] should have received an $8,850 assessment, >instead of the $97 million property valuation. Their tax bill should have >been for just $117 [...]. whereas, according to the Oregonian, they were billed for $986,312. So, Schwartz notes, >Bill for someone [else's] $70K home will go from $710 to $760 to make up >for the deficit from the bad math. There is another problem that came out in a similar case in Massachusetts last spring: the county may well have counted on their share of the incorrectly billed $986,312. This indeed happened in the Mass. case, which led to a fiscal crisis: the county had by that time committed itself to spending money which it just wasn't going to get, (a) because it wasn't owed it, (b) because the possibilities for a small town getting a million-dollar loan to cover such a screwup are low, and (c) because there was no clear governmental agency willing or able to cover them. Questions, comments, solutions? Note that it wasn't at all the county's fault: they got a printout from the state that said, "Your share of local property taxes is going to be so-and-so-much." And while we would like to say that the state owes them the money, realistically speaking, that would probably be an unacceptable solution. == paul j karafiol ------------------------------ Date: Thu 31 Oct 91 07:54:33-CST From: Clive Dawson Subject: Re: A new twist on "Speed Controlled by Radar" A recent message from Andrew Green (acg@hermes.dlogics.com) described the use of unattended radar transmitters to cause vehicles to slow down by triggering their radar detectors, and raised the question of how failure of these transmitters could be detected. About ten days ago while visiting Canada, I was driving from Toronto to Buffalo and noticed a similar system. During the approach to a particularly sharp turn along Queen Elizabeth [Free]Way, I observed the usual warning signs indicating that it would be a good idea to slow down. I slowed down slightly, but not down to the recommended speed. When the turn was imminent, I saw a large red sign directly ahead suddenly begin to flash "TOO FAST". My instant reaction as I immediately slowed down further was, "Wow, what an effective feedback device!" I would suggest that adding a visual sign of this sort to the system ain Chicago would not only serve to warn vehicles without radar detectors as well, but would also address the risk of error-detection, since a transmitter failure would be much more obvious. What about other uses for unattended radar? I know of several residential neighborhoods that use huge(!) speed bumps (the kind would rip out your suspension at anything over 15 mph but are a pain at any speed) to enforce speed limits. I can imagine a system in which radar could raise physical devices which would make speeding noticeable (1-inch bumps), unpleasant (4-inch bumps), or impossible (parking-lot-style spikes?! ;-), thus allowing a smooth ride for vehicles within the speed limit. One of the Risks which I find fascinating is the idea that once people are accustomed to having a system like this provide a warning about a speed-limit (or any other law or regulation), then failure of the system causes people to think they have temporary license to ignore the law, even in the face of all of the conventional warning signs, etc. The more general theme here is that any time we allow a computer to assume the role of a conscience, we must remember that a failure does not imply that people will automatically and immediately revert to a backup system, i.e. using their own consciences! Clive Dawson, MCC, Austin, Texas ------------------------------ Date: Wed, 6 Nov 91 22:25:15 EST From: avr@mtfmi.att.com (Adam V Reed) Subject: Re: Electronically controlled bus transmission (Seecof, RISKS-12.60) More on risks of accepting human-hostile design! ===> A car with misplaced pedals is just as faulty as one with misplaced gears. [Audi...] Blink. Are the pedals any less a part of the car's acceleration control subsystem than is the transmission? Audi lost half it market share because its wanna-be-"engineers" placed the brake and accelerator pedals so close together, that drivers could not tell what they were stepping on. This, even though reliable standards for the placement of mechanical controls, including pedals, have been available since the early 1950s. As an engineer and a human, I find Audi's fate justified, market forces vindicated, and consequences salutary. Adam_V_Reed@ATT.com ------------------------------ Date: Thu, 7 Nov 1991 04:23:30 -0500 From: jmason2@utcs.utoronto.ca (Jamie Mason) Subject: Re: Electronically controlled bus transmission (Seecof, RISKS-12.60) The problem here is the `computer knows best' attitude. Far too many problems arise because of this. Not only does that automatic transmission make decisions that a competent human should be making (the choice of gear), but it also ignores an explicit override. This is one of many reasons why I chose to drive manual transmission vehicles. When you have a stick physically linked to a gearbox, it is hard for the car to second-guess you. Unfortunately, this is not the first time I have heard of automatic transmissions doing this. Many expensive cars have this feature, I believe the Benz will prevent you from putting the car in an 'inappropriate' gear. I'm not sure what it would do if you put it in "LO". I think the Tiptronic manual/auto transmission on the new Porsche is like this as well. (You would think that those who could afford a car like THAT would not put up with their car telling them what to do!) It's a bad day when critical systems have NO manual override. There should always be SOME way for the OPERATOR to have the final word. Unfortunately, some designers must not realize how critical the control systems of an automobile are. I hope the designers of "electronically controlled super-highways" keep this in mind. The driver is smarter than a tachometer. Even if the passengers DID NOT MATTER, and the sole purpose of the rev-limiter was to protect the engine (from over-revving) the device FAILED at its task. Afterall, the engine WAS destroyed in the crash, wasn't it? :-) Jamie ... ------------------------------ End of RISKS-FORUM Digest 12.61 ************************