Subject: RISKS DIGEST 16.59 REPLY-TO: risks@csl.sri.com Errors-To: risks-request@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Weds 30 November 1994 Volume 16 : Issue 59 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks), disclaimers ***** ***** NOTE, SRI RISKS ARCHIVE SOURCE IS MOVING SOON TO ANOTHER HOST. ***** Contents: The IRS knows "everything about you that we need to know" (John Sullivan) RISKs of electronic ticketing on buses (Rhys Weatherley) Why You Need a UPS For Your Bread Machine (Curtis Jackson) Listserv Loops (Richard Klau) NYNEX touts Credit Card authorization over Cell Phones (Paul Green) Re: Iowa phone switch (Matthew Charles Wetmore) Re: Reasonably Large Water Bill (L. P. Levine) Risks on TV: Eye-to-Eye-to-RFI (Jan I. Wolitzky) British Telecom "hacker" article was a hack! (Sidney Markowitz) The risks of media hack reports (Rob Slade) Re: Pentium FDIV bug (Wilson P. Snyder II, Peter da Silva, Ron Heiby, Dale R. Call, Andy Grove via Richard Wirt) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Wed, 30 Nov 1994 13:02:17 -0600 From: sullivan@geom.umn.edu Subject: The IRS knows "everything about you that we need to know" I read this paragraph from Wired in EDUPAGE (listproc@educom.edu) and found the implications disturbing: IRS PLANS GOLDEN EAGLE TAX RETURN The project manager for the Internal Revenue Service's Document Processing System described the "Golden Eagle" return, in which the government would automatically gather all a person's tax info and then compute the tax. "If I knew what you've made during the year, if I know what your withholding is, if I know what your spending pattern is, I should be able to generate for you a tax return. I am an excellent advocate of return-free filing. We know everything about you that we need to know. Your employer tells us everything about you that we need to know. Your activity records on your credit cards tell us everything about you that we need to know. Through interface with Social Security, with the DMV, with your banking institutions, we really have a lot of information ... We could literally file a return for you. This is the future we'd like to go to." (Wired, Dec.'94, p.174) -John Sullivan sullivan@geom.umn.edu [For info on receiving EDUPAGE, see RISKS-16.58. PGN] ------------------------------ Date: Mon, 28 Nov 1994 09:46:06 +1000 (EST) From: Mr Rhys Weatherley Subject: RISKs of electronic ticketing on buses The Brisbane City Council's bus service here in Australia is in the process of introducing an electronic ticketing system on all buses. The old system used a bunch of "ticket pads" of different denominations: the driver would rip off a ticket from the right pad (you'd hope! :-) ), punch a hole in it, collect your money, and then give you the ticket. The new system replaces the pads with a console which has a number of buttons for the denominations together with a printer to print the tickets. There are also two green boxes just inside the door in which commuters can insert the new magnetically encoded weekly and monthly bus tickets to have them checked. I have yet to get my first magnetic monthly bus ticket so I can see how easy it would be to reprogram it, but I'm fairly confident that with the right equipment it is doable. For purely educational purposes of course. :-) RISK #1. I'm also interested in seeing if there is any identifying information on the cards permitting tracking of a person's movements. RISK #2. The other day a schoolkid was waiting at my bus stop, and due to various stuff-ups in the scheduling, he was forced to catch my bus rather than the normal school bus. During peak hour my bus is a full fare bus, but of course the kid only had money for a half fare on him. In such cases, some drivers are complete mongrels and won't allow the kid on, but most will grumble a bit and then let the kid on for a half fare. The driver stared at his console for a few seconds and then said (paraphrased) "There is no way to override this thing. Looks like you get a free ride today" and let the kid on for nothing. The console had automatically detected peak hour and disabled the half fare ticket buttons. RISK #3 is fairly familiar: while enforcing "the rules" can be a good idea, sometimes it is necessary to override them for reasons of human kindness. RISK #4 is that if an override button was provided, the console might log the fact and the driver might get in trouble (and then again, it might not: I don't know anything about the internals of the consoles yet). At least with the free ticket, no trace is left for the bus inspectors to whinge about. :-) More information on the magnetic tickets as it comes to light ... Rhys Weatherley, Queensland University of Technology, Australia. ------------------------------ Date: Wed, 30 Nov 1994 00:27:33 GMT From: cjackson@adobe.com Subject: Why You Need a UPS For Your Bread Machine In order to more closely stick to a self-imposed lowfat diet, I finally broke down and bought a bread machine -- easy quick bread with no added fat. I was so pleased with the machine that I bought my breadophilic mother one and lugged it across the country to her house last week. They were short on counter space in the kitchen, so they put the machine on a side-table and plugged it into an outlet that was activated by a wall switch that also controlled a light in the room. (I think you can guess what is coming next, and, yes, I did warn them. They said it was only a temporary placement and they'd remember.) Sure enough, in the middle of the bread machine's 4-hour cycle, my stepfather turned off the light in the room (and thus removed power from the bread machine). I noticed this some indeterminate time later. Problem #1: The bread machine has no NVRAM. So I had no idea whether it had been through only its first rise, or through a first rise, punchdown ("gas squeeze out"; this was a Japanese machine), and second rise. Problem #2: The machine has a dough setting that will allow you to make dough, but not bake the dough. But there is no setting that says, "I already have dough, I just want you to bake it." Problem #3: Neither my stepfather nor I had ever baked a loaf of bread by hand. Not once in our lives. And bread is quite a bit more sensitive to time and temperature than most other simple food items. Luckily, I had also purchased a bread machine cookbook for my mother that suggested that one make a loaf of bread by hand first to get a feel for the process, then proceed to using the machine. I used the book's baking time/temperature settings and ended up with an edible loaf of finished product. But, had we not had that book.... Curtis Jackson cjackson@mv.us.adobe.com ------------------------------ Date: 28 Nov 1994 21:30:27 GMT From: klaurich@uofrlaw.urich.edu (Richard Klau) Subject: Listserv Loops Along with Erik Heels (The Legal List), I own a list for law students discussion law & technology (StudentLawTech). We have just weathered a particularly disturbing incident, and would like some feedback on what has been done in the past with issues like these. The facts, as near as we can tell, are these: a user set his e-mail system to refuse mail from the list. The system generated a refuse message for the sender to notify the sender that the message had not been read. Since the list was the sender, this refusal notification was sent to the list. Because the e-mail system did not stamp the message with a "mailer-daemon" or some other appropriate flag, the list did not filter it out. The refusal notification was sent to the list. Because the original user was not set to nomail (opting, instead, to do this at his level, rather than at the list level), he received the refusal notification. This notification in turn produced a notification of its own. The loop was started, and multiplied exponentially. The system was not fully corrected until Saturday night, a full three days after the loops had begun. While we can't be sure, we think the total number of these looped messages prior to the fix on Saturday was near 1000 messages to each subscriber. Needless to say, many have unsubscribed from the list. In addition, countless law students are now faced with the annoyance of having to delete mass quantities of mail. Most worrisome, of course, are those that pay for incoming e-mail. So -- has this happened before? If so, what systems were involved? How was the situation remedied? What were the consequences? Any advice is very welcomed. Replies by e-mail are preferred, but I will monitor this list. Thanks for your help! Rick Klau, Co-owner, StudentLawTech@Listserv.Law.Cornell.edu ------------------------------ Date: Tue, 29 Nov 94 17:43 EST From: Paul_Green@vos.stratus.com Subject: NYNEX touts Credit Card authorization over Cell Phones >From the September/October 1994 (Vol 9, #5) issue of "Accessability", a newsletter that came with my most recent statement for my cell phones. Reproduced without permission. The flyer generally contains the typical marketing hype about ways to use your cell phone "more productively" (i.e., run up a bigger bill). The following anecdote is quoted in its entirety. AIRTIME - Your Cellular Success Stories Greg Maida Herkimer, NY "We are in the craft business, and we use our NYNEX Mobile cellular phone to transmit credit card charges. This has saved us a lot of brief, because we are able to get credit card approvals within about 30 seconds. The cellular phone gives us the convenience of a phone at any locations and enables us to offer more purchasing options to customers." *** What can I say? Why worry about sending your credit card over the Internet, when this vendor will send it out over radio waves for you! Just to add a little irony to this whole discussion, in the very same newsletter, on the facing page, appears the following "tip": "Remember to lock your cellular phone! You will reduce the risk of incurring fraudulent calls if you phone is stolen. Don't consider this precaution an inconvenience. Lock your phone whenever you park your car with a parking attendant. If your phone can be removed, we recommend carrying it with you when you leave the car unattended." The only word that springs to mind here is chutzpah! PG [accessability Marcia Williams Cromer, Editor NYNEX Mobile Communications 2000 Corporate Drive Orangeburg, NY 10962 (c) 1994 - All Rights Reserved] ------------------------------ Date: Mon, 28 Nov 94 17:33:46 -0800 From: mwetmore@polyslo.csc.calpoly.edu (Matthew Charles Wetmore) Subject: Re: Iowa phone switch (RISKS-16.58) Phone systems do not exist in a vacuum, nor is restarting them as simple as flipping a switch. In this case, there'd be diagnostics to make sure that nothing actually *was* burned out. Then reloading the phone database and configuration information. The information might include special features with each phone for caller ID, forwarding numbers, voicemail options, et cetra. Next comes routing information from the various neighborhood multiplexors to the central office. Last, but not least, you have to convince any other computer system you are connected with (long distance carriers, billing computers, ...) that your system is alive and well again. >Lessons: First, this failure seems to be a perfect example of the fact that >grounding problems are notoriously difficult to diagnose. Second, I suspect >that nobody involved in the design of modern ESS systems would have guessed >that it would take 2 hours to restore service after the fault was repaired. "You get what you pay for," may be the case here. A "small" town with one system has all or nothing failures. New York, on the other hand, can shunt calls over to other offices while one is restoring. Multiple redundancy is the most common "solution" to make a system fault tolerant. These are only the technological factors... A human factors: A new system having been recently installed: how many trained technicians did they have on hand, well versed in the new system lore? There's a fair chance a technician from the system manufacturer had to race out, and this accounted for a bulk of that time. Matthew C. Wetmore -- ACM, c/o CSc Dept., California Polytechnic State Univ, San Luis Obispo, CA 93407 -- USA mwetmore@galaxy.CSc.CalPoly.EDU ------------------------------ Date: Sun, 27 Nov 1994 09:09:46 -0600 (CST) From: "Prof. L. P. Levine" Subject: Re: Reasonably Large Water Bill (Politte, RISKS-16.56) Some years ago I received a water bill from the Village of Shorewood in Wisconsin that was about 30 times too large. In my case also the problem was due to a failed repeater that mounted on the outside of my house and was delivered an electrical pulse each time 100 cubic feet of water was registered by the actual meter in the basement. The system had been installed over ten years ago and had (apparently) been missing pulses from the very first. No one had noted the slight decrease in billing until the system finally had a hard failure and reported no water use during a quarter-year. When the new repeater was installed it was manually set to agree with the water meter in the basement (Wisconsin folks are smarter than they are in Missouri) and therefore included all of the "ticks" missed over a ten year period. They all appeared on the next bill. Since we had, in fact, used the water that was billed there was no question we should pay. What was in doubt was just how much. Water rates had increased substantially during the period because of the inclusion of sewer costs within the water bill during recent years. Negotiation with the village over the question "how much water was used when" settled the issue. What's the risk? New machinery will soon enable more and more utility billing to be done automatically. Many of these systems will depend on repeaters for their data collection with the true numbers still available on more conventional meters located on site. My hundred dollar water bill will seem small compared to the complexity of just which owner/renter used the missing electricity after failed meter systems are fixed and their meters updated. Prof. Leonard P. Levine, Computer Science, University of Wisconsin-Milwaukee Box 784, Milwaukee, WI 53201 levine@cs.uwm.edu 1-414-229-5170 ------------------------------ Date: Mon, 28 Nov 94 10:50:50 EST From: wolit@library.mt.att.com Subject: Risks on TV: Eye-to-Eye-to-RFI This week's "Eye-to-Eye with Connie Chung" is scheduled to include a segment on radio-frequency interference risks. I was interviewed by one of her crews, demonstrating an automatic cardiac defibrillator being messed up by a public-safety band walkie-talkie. Other examples reportedly include an electric wheelchair being spoofed by a cellular phone, aircraft instruments confused by PCs, etc. I haven't seen any of the tape yet, so I don't really know whether I want to be announcing this, but it's likely to be of interest to participants of this forum. Thursday night, 1 Dec 1994, CBS, 10pm EST. Jan I. Wolitzky, AT&T Bell Laboratories, 600 Mountain Avenue, Room 3D-590 Murray Hill, NJ 07974-2070 USA 1 908 582-2998 wolit@library.att.com ------------------------------ Date: Tue, 29 Nov 1994 19:36:24 -0800 From: sidney@taurus.apple.com (Sidney Markowitz) Subject: British Telecom "hacker" article was a hack! [Thanks to sidney@apple.com (Sidney Markowitz) for letting me see copyrighted Newsbytes material, which I have starkly abstracted. PGN] Steve Fleming, the reporter noted in RISKS-16.58 as responsible for the article on the "hacking" of BT's Customer Service System (CSS), has admitted that he himself was the unknown Internet hacker. ``Instead of gaining unauthorized access to the BT computers, he actually worked for a lengthy period of time (three months, according to Newsbytes sources) and was required to access the CSS computer system as part of his job. "I didn't realize how sensitive the information was, but I was horrified how easy it was to get into the system," he is quoted as saying in the London Observer newspaper.'' Fleming may be prosecuted. ------------------------------ Date: Sun, 27 Nov 1994 03:30:22 EST From: "Rob Slade, Social Convener to the Net" Subject: The risks of media hack reports (BT and the Queen) in re: Mathew Lodge's posting in 16.58: I was wondering if this was going to make it into RISKS. I saw a TV report on the story (a re-use of an NBC story of the BBC story, apparently). There was the mention of the Internet, there was the use of the word "hacker", but there was, technically, no security system "breaking". Social engineering, definitely. Stupidity, beyond question. Loss of confidentiality, loss of privacy, yes, and again, yes. But no hacking, cracking or phreaking. Indeed, since the original informant is still unidentified, the word "hacker", even in its most debased usage, is extremely suspect. The risks as I see it, is that once again the public is being led to believe that evil and powerful "hackers" can invade even the most highly protected inner sanctum of one of the worlds best secured telecom systems. In reality the "keepers of the keys" have simply left the doors wide open. DECUS Canada Communications, Desktop, Education and Security group newsletters Editor and/or reviewer ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733 ------------------------------ Date: Mon, 28 Nov 94 17:38:23 EST From: Wilson P. Snyder II (DTN 225-5592 HLO2-3/C8) Subject: Re: Pentium FDIV bug [random testing] Can't speak for Intel, but at Digital, our Alpha AXP processors are tested using psudo-random techniques which do exactly that. Random testing often finds interesting problems that would never be found by just writing specific tests. (The genetic algorithm folks can give lots of data on why this is so.) To implement the random method though, you have to code a entire simulation of the results that the CPU will produce. Unfortunately, as readers of this group will appreciate, occasionally the template that describes the correct response, or limiting the range to test will be itself in error. (Comparing a transistor model to a bad software model is a good example of the first kind of error.) Even if all is set up perfectly, I've seen cases where it took several weeks to expose a bug. ------------------------------ Date: Mon, 28 Nov 1994 09:43:03 -0600 From: peter@nmti.com (Peter da Silva) Subject: What are the odds Intel would pick this phrasing at random? The problem I have with Intel's handling of this is the use of the word "chance", as if there was a random factor involved, that a calculation will work right one time and fail the next so you can just run it again and get the right result. Of course no such thing is true, but that's the impression Intel's (deliberately?) spreading. Also, people hear about a "1 in 10^10" chance and think it refers to some statistical probability that their system will have a problem, rather than a measure of the proportion of inputs that will (consistently) produce an invalid response. For programs that require double precision calculations and involve arbitrary input the "chance" of that program hitting the bug approaches unity. Nope... Pentium Bingo isn't a game of chance at all. ------------------------------ Date: Mon, 28 Nov 1994 21:52:12 GMT From: heiby@falkor.chi.il.us (Ron Heiby) Subject: Re: Pentium FDIV bug The chairman of the Computer Science Department at Hope College (when I was attending, and probably still), Herbert Dershem, told one of my early CS classes that, "any idiot can write a very fast sort routine, if it doesn't have to put the elements into the correct order." (That may not be an exact quote, but pretty close.) It looks like intel has figured out that they can write a very fast floating point unit, if it doesn't have to produce the correct results! Ron ------------------------------ Date: Wed, 30 Nov 1994 10:52:33 -0800 From: dalec@ibeam.jf.intel.com (Dale R. Call) Subject: Re: Pentium FDIV bug For more information on the Pentium FDIV bug, and Intel's response, take a look at our corporate presence server (www.intel.com): http://www.intel.com/about-intel/press/andy-msg.html This message was also posted on various net newsgroups. Dale R. Call, Intel Architecture Labs ------------------------------ From: [several anonymous sources] Subject: My Perspective on Pentium - AGS Date: 27 Nov 1994 19:31:21 GMT Andy Grove has asked me to post the following for him. Since it is the weekend and we are out of the office, I am posting from my home system. Richard Wirt Director SW Technology Intel Corp This is Andy Grove, president of Intel. I'd like to comment a bit on the conversations that have been taking place here. First of all, I am truly sorry for the anxiety created among you by our floating point issue. I read thru some of the postings and it's clear that many of you have done a lot of work around it and that some of you are very angry at us. Let me give you my perspective on what has happened here. The Pentium processor was introduced into the market in May of '93 after the most extensive testing program we at Intel have ever embarked on. Because this chip is three times as complex as the 486, and because it includes a number of improved floating point algorithms, we geared up to do an array of tests, validation, and verification that far exceeded anything we had ever done. So did many of our OEM customers. We held the introduction of the chip several months in order to give them more time to check out the chip and their systems. We worked extensively with many software companies to this end as well. We were very pleased with the result. We ramped the processor faster than any other in our history and encountered no significant problems in the user community. Not that the chip was perfect; no chip ever is. From time to time, we gathered up what problems we found and put into production a new "stepping" -- a new set of masks that incorporated whatever we corrected. Stepping N was better than stepping N minus 1, which was better than stepping N minus 2. After almost 25 years in the microprocessor business, I have come to the the conclusion that no microprocessor is ever perfect; they just come closer to perfection with each stepping. In the life of a typical microprocessor, we go thru half a dozen or more such steppings. Then, in the summer of '94, in the process of further testing (which continued thru all this time and continues today), we came upon the floating point error. We were puzzled as to why neither we nor anyone else had encountered this earlier. We started a separate project, including mathematicians and scientists who work for us in areas other than the Pentium processor group to examine the nature of the problem and its impact. This group concluded after months of work that (1) an error is only likely to occur at a frequency of the order of once in nine billion random floating point divides, and that (2) this many divides in all the programs they evaluated (which included many scientific programs) would require elapsed times of use that would be longer than the mean time to failure of the physical computer subsystems. In other words, the error rate a user might see due to the floating point problem would be swamped by other known computer failure mechanisms. This explained why nobody -- not us, not our OEM customers, not the software vendors we worked with and not the many individual users -- had run into it. As some of you may recall, we had encountered thornier problems with early versions of the 386 and 486, so we breathed a sigh of relief that with the Pentium processor we had found what turned out to be a problem of far lesser magnitude. We then incorporated the fix into the next stepping of both the 60 and 66 and the 75/90/100 MHz Pentium processor along with whatever else we were correcting in that next stepping. Then, last month Professor Nicely posted his observations about this problem and the hubbub started. Interestingly, I understand from press reports that Prof. Nicely was attempting to show that Pentium-based computers can do the jobs of big time supercomputers in numbers analyses. Many of you who posted comments are evidently also involved in pretty heavy duty mathematical work. That gets us to the present time and what we do about all this. We would like to find all users of the Pentium processor who are engaged in work involving heavy duty scientific/floating point calculations and resolve their problem in the most appropriate fashion including, if necessary, by replacing their chips with new ones. We don't know how to set precise rules on this so we decided to do it thru individual discussions between each of you and a technically trained Intel person. We set up 800# lines for that purpose. It is going to take us time to work thru the calls we are getting, but we will work thru them. I would like to ask for your patience here. Meanwhile, please don't be concerned that the passing of time will deprive you of the opportunity to get your problem resolved -- we will stand behind these chips for the life of your computer. Sorry to be so long-winded -- and again please accept my apologies for the situation. We appreciate your interest in the Pentium processor, and we remain dedicated to bringing it as close to perfection as possible. I will monitor your communications in the future -- forgive me if I can't answer each of you individually. Andy Grove ------------------------------ Date: 23 November 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to (which is not yet automated). SUBJECT: SUBSCRIBE or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. 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. All other reuses of RISKS material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using RISKS material should obtain permission from the contributors. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: or cwd risks:, depending on your particular FTP. Issue j of volume 16 is in that directory: "get risks-16.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 15, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00, in both main directory and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and WAIS are alternative repositories. See risks-15.75 for WAIS info. To search back issues with WAIS, use risks-digest.src. With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 16.59 ************************