Subject: RISKS DIGEST 16.58 REPLY-TO: risks@csl.sri.com Errors-To: risks-request@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Friday 26 November 1994 Volume 16 : Issue 58 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 ***** Contents: Hacker learns intelligence secrets (Mathew Lodge) Automated Weather Reports for Pilots (Tom Keenan) Extended Phone Failure in Iowa City (Douglas W. Jones) Enormous water bills - gigo strikes again (James M. Politte) Computer-generated bridge-tournament hands (G. Gates/M. Brader/PGN) The PC as a RISC (how could I resist 8*) (A. Padgett Peterson) Problem with 911 service in Philadelphia (Paul Robinson) Department store security cameras linked to computer (David Hembrow) Children on the Infobahn (Bradley K. Sherman) Re: Pentium FDIV bug (Mike Carlton) Re: Cell-phone ergonomics side-effect (Bill Innanen, Paul Robinson) Re: Anon. on "TEN Q's" (Mark Seecof PSD x77605) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Thu, 24 Nov 94 09:09:38 GMT From: Mathew Lodge Subject: Hacker learns intelligence secrets The London "Independent" newspaper of 24-Nov-94 leads with a story that a "hacker" gained access to a sensitive database of telecommunications information at British Telecommunications (BT), the UK's largest (and ex-state owned) carrier. The story was also carried by all the major television and radio news programmes. Tim Kelsey, author of the Independent story, reveals that details such as telephone numbers and addresses for secret installations of the Ministry of Defence, MI5 (the British intelligence agency responsible for the UK) and MI6 (like MI5, but handles non-UK affairs). "Thousands of pages of highly confidential BT records were sent across the Internet to a young Scottish journalist, Steve Fleming, in July". Mr Fleming received the information after making a news posting asking for information on BT and hacking. The informant remained anonymous -- details of how this was achieved are not given. The hacker also gave details to Mr Fleming about how he too could access the information. He applied through an employment agency for a short-term contract at BT as a database designer, clearly stating on his CV that he was a freelance journalist. He got the job, and was able to gain access to the information because passwords were just left lying around the office. BT is still going through a major staff restructuring programme, and as a result has a large number of temporary (contract) staff. These staff need passwords to the system to legitimately carry out their jobs, but because of the constant flow of people, the passwords are often written down. Mr Fleming learned, among other things, * The location of MI6's training centre ("spy school"), located in a non-descript building next to a pub in south London * Information about the bunker in Wiltshire where the Government would go in the event of nuclear war * Details of telephone installations at Buckingham Palace and 10 Downing Street [the Prime Minister's home], including personal lines to John and Norma Major. The system itself, the "Customer Services System", was designed and implemented by an American company, Cincinnati Bell. It is supposed to have internal mechanisms to prevent hacking (!) So, what are the risks (briefly!) 1) Allowing temporary staff passwords that allow almost any data to be retrieved. It sounds as if the security levels of the database were either non-existent, or compromised. 2) Keeping sensitive information in the same database as non-sensitive information. 3) The age-old chestnut of the uses of passwords. A BT spokesman, speaking on the "Today" programme on BBC Radio 4 confirmed that a "top level" investigation had been launched, but refused to confirm or deny that the hack had taken place. Mathew Lodge, Software Engineer, Schlumberger Technologies, Ferndown, Dorset, UK, BH21 7PP lodge@ferndown.ate.slb.com (+44) (0)202 893535 x404 [The *Independent* items are in their entirety (28K) in RISKS-16.58BT, courtesy of Brian Randell. PGN] ------------------------------ Date: Fri, 25 Nov 94 0:31:28 MST From: "Tom Keenan" Subject: Automated Weather Reports for Pilots According to a piece on the CBC Alberta News on Nov 24: Pilots are complaining about the inaccurate weather forecasts being provided by new automated weather briefing equipment installed at an Edmonton airport (and soon to be operational at the Calgary airport.) The system apparently cannot keep up with changing weather conditions and, in one specific case, a Canadian Airlines plane landed in snow although the forecast did not mention any snow. The airline has complained, and union members are arguing for a return to human delivery of weather info to pilots. Dr. Tom Keenan, I.S.P., Dean, Faculty of Continuing Education, Univ. Calgary 2500 University Dr. NW Calgary, AB T2N 1N4 CANADA (403) 220-5429 ------------------------------ Date: 23 Nov 1994 04:08:25 GMT From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740) Subject: Extended Phone Failure in Iowa City On Saturday, Nov 19, Iowa City's telephone system, run by US West, shut down at about 3:30 PM, local time, and service was not restored until between 7:30 and 9:30 PM (service was brought up a bit at a time). As phone outages go, this was fairly severe! The population of the effected community is over 60,000. The Iowa City Press Citizen, on Tuesday, Nov 22, reported that the cause of the failure has finally been determined. In July, a new telephone switching system was installed, and in the past week, the old system was removed from the building. As part of the removal process, the paper reports that an electrical grounding cable was inadvertently removed, leaving the new switch improperly grounded. Apparently some customers noticed intermittent problems with their phone service earlier in the day, and US West had technicians working on the problem before the failure, but they were unable to diagnose the problem until some time after the failure had occurred. Once the failure was diagnosed, the paper's description makes it sound as if the missing cable must have been easy to replace, but the 2 hour delay between the fix and the complete restoration of service is disturbing. They had to cold-start the ESS system or systems involved (can you put over 20,000 phones on one system?), but this can't account for 2 hours, can it? My alternate hypothesis is that the improper grounding connection blew large numbers of fuses in alternate ground paths that weren't supposed to carry current, leading to a very time consuming job putting things right. 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. People who do such analysis or design other fault tolerant systems may need to look at this failure as an example. I'm eager to see more technical detail than the newspaper provided! Doug Jones jones@cs.uiowa.edu ------------------------------ Date: Wed, 23 Nov 1994 09:47:02 -0800 (PST) From: "James M. Politte" Subject: Enormous water bills - gigo strikes again. In the quiet western-Missouri town of Warrensburg, a small house with two occupants recently received a water bill amounting to $4,704.88. The water meter had been replaced with a new one, and being new, it read "000000". The previous reading from the last month, was "017060". The computer assumes that numbers on a water meter only go up, of course. So it was perfectly logical for the computer to assume that "000000" was caused by the meter rolling-over after reaching "999999". Subtracting 017060 from 1000000 yields 982940 - and I was in fact billed for using 982940 cubic feet of water. (That's a column of water with a base the size of my house and 495 feet tall.) The water company was quick to correct this problem upon hearing about it - but imagine if I had enrolled in the automatic payment program which subtracts bills directly from my bank account... J.Politte - oprime@netcom.com [A previous case due to the same cause, resulting in a water bill of $22,000, appeared in RISKS-12.16, Software Engineering Notes, vol 16, no 4, October 1991, and page 191 of my RISKS book. PGN] ------------------------------ Date: Wed, 23 Nov 94 16:48:10 PST From: "Peter G. Neumann" Subject: Computer-generated bridge-tournament hands Mark Brader (msb@sq.com) forwarded a note from ggates@Starbase.NeoSoft.COM (Georgiana Gates) from rec.games.bridge. Georgiana played in the recent Minneapolis Women's board-a-match Nationals bridge tournament, and she and others noted that the computer-generated hands were IDENTICAL to those from the first half of the semifinals of the Women's Knockout in San Diego (in which they had also played). This is not the first time for such an occurrence. RISKS-7.62, 7 Oct 1988 included an item from a New York Times column by Alan Truscott, contributed by Paul Abrahams, which I entitled "Bridge over troubled pseudo-random generation". I presume that the initialization values for the pseudorandom generator were duplicates. It certainly gives a new meaning to the term "duplicate bridge". ------------------------------ Date: Thu, 24 Nov 94 08:43:43 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson, Information Security) Subject: The PC as a RISC (how could I resist 8)* Just in time for the holiday season comes a new feature for the PC - self-executing and playing Christmas Cards you can send to people with only E-Mail reception. Did you know that it is possible to write a complex program on the PC using only ASCII printing characters ? XOR, AND, branching JMPs, PUSH, POP, SUB, INC, and DEC all exist within the range of 40h-7Eh. True, not all register and memory combinations can be used but enough. After seeing an example done, I set out to make a few tests of my own and have determined that is possible to write a program using only ASCII characters that can decode and transfer execution to a "normal" .COM file that has been ASCII-encoded something like UUENCODE. Of course with UUENCODE the problem is that first you needed to have the UUDECODE program. With an ASCII-executable program, the medium is the message. This is just what the world needs: self-extracting and executing E-Mail. Padgett ------------------------------ Date: Fri, 25 Nov 1994 15:20:24 -0500 (EST) From: Paul Robinson Subject: Problem with 911 service in Philadelphia CNN Reported that more than a dozen calls went into the Philadelphia 911 center to report a riot and fighting. Reports from callers ranged from civil to frantic as they called to report a serious incident occurring, while the 911 dispatch operators ranged from uninterested to downright rude. A sample of one of the calls reported was something like this: Caller: We need the police at 7100 Ridgeway, there's a group of people in a fight... Dispatch: (Bored) Is that all? Caller: (Incredulous) IS THAT ALL? There's a caravan of cars coming down here to participate in a damn riot, that's all! Another caller returned a call reporting a fight verging on a riot in their area. The 911 Dispatcher replied that she didn't know where they were. It's that response that I wonder about; aren't most large city 911 systems equipped with name and ID for calls that come in? Smaller Cities, I can understand may simply use 911 as a substitute for dialing their emergency number and may not have name/phone lookup capability. What got people upset was that, despite over a dozen 911 calls, police still took 40 minutes to show up, at which point they called the coroner to handle one dead 14-year-old, killed by some other teenagers armed with nothing stronger than baseball bats. (So much for the claims that gun control would make the streets safer.) You can have all the high technology in the world and all the latest equipment, but if you either don't have the people on hand, or the people you have don't care, the technology can make things worse. Paul Robinson - Paul@TDR.COM ------------------------------ Date: Tue, 22 Nov 1994 12:55:30 +0000 From: davidh@harlequin.co.uk (David Hembrow) Subject: Department store security cameras linked to computer Electronic Snap (UK "PC Week" magazine, 22 November 1994) Not-so saintly shoppers in Marks and Spencer's will soon find themselves matched up in an electronic version of Snap! if they dare try beating the latest security move. The company will use ceiling mounted video cameras fitted to computers to compare pictures of known shoplifters in a trial in one of its stores. Watch out, Beadle's about, and the police aren't far away. [Obvious risk of false positives ( which shoplifter do I look like? ), false data being in the computer in the first place etc.] Jeremy Beadle is a much hated/loved TV presenter in the UK who presents a show a little like Candid Camera. Snap! is a card game played (predominantly) by children. The objective is to match two identical playing cards. David Hembrow, Harlequin Ltd ------------------------------ Date: Tue, 22 Nov 94 22:38:04 PST From: bks@s27w007.pswfs.gov (Bradley K. Sherman) Subject: Children on the Infobahn I'm the father of a 9-year-old girl and a 4-year-old boy. I live in a major metropolitan area --Oakland, California. As far as I'm concerned they can read anything they want. They're not going to find anything on the USENET that comes close to the real horror that exists on the streets of our cities. I'm just happy that they have the desire and ability to read (well, this is stretching it for the four-year-old). I wonder what newsgroups the kids in Sarajevo are reading? Bradley K. Sherman, Dendrome Project, Institute of Forest Genetics, PO Box 245 Berkeley, CA 94701 bks@s27w007.pswfs.gov 510-559-6437 ------------------------------ Date: Wed, 23 Nov 1994 01:34:11 -0800 From: carlton@ISI.EDU (Mike Carlton) Subject: Re: Pentium FDIV bug It would be nice to know just how bad the bug is. Intel certainly isn't being very helpful. I ran a set of experiments this last weekend and found 819 divide cases with less than single-precision accuracy on the pentium. I found 66 cases with just 14 bits accuracy (as in the first 4195835/3145727 example). BTW, that example was originally posted to comp.sys.intel by Tim Coe of Vitesse Semiconductor. More info on my experiments is at: ftp://www.isi.edu/pub/carlton/pentium For another simple example (the smallest my searching found), try the following in a spreadsheet or calculator program running on a pentium: 5505001/294911 = 18.66600093 on a buggy pentium = 18.66665197 the correct answer The original reports of the bug mentioned double precision cases which returned 29 or so bits of accuracy, instead of the expected 52. At that point I wasn't very concerned by the bug (we had just taken delivery of a pentium workstation and I convinced the machine's user that it wasn't necessary to ask for a replacement processor). I've since changed my mind. People have correctly pointed out that there are bugs in the OS, the compiler, your application program, etc. How many programs really need need more than 29 bits accuracy? But Tim Coe's post showed that the error could get much worse than that. Tim also pointed out that the bug can occur in both single and double precision divides. Drawing upon his information, I was able to come up with a small set of divisors likely to cause the bug and write a search program that takes just 30 minutes to find the 800 cases. The risk? How about the way Intel marketing has handled this situation? They have not (yet) publicly described the extent of the bug. I've heard numbers like a 1 in 10^10 chance of hitting it and my back-of-the-envelope calculations tend to agree with this. It could be higher though, we have no way of knowing yet. However, Intel hasn't described the magnitude of the errors. Could it be less than 14-bit accuracy? My experiments lead me to believe that it won't get any worse, but until Intel comes forward with a description of the cause of the bug we won't know. Until then, can people really rely on pentium calculations for critical work? If you can't trust any result there is no point in using the pentium. What I really don't understand is why Intel didn't set up a PC doing random testing with one of the first pentiums off the fab line. Doing so would have exposed this bug in short order. It looks like that failure may turn out to be quite expensive. --mike carlton@isi.edu USC/Information Sciences Institute (310) 822-1511 ------------------------------ Date: Sat, 26 Nov 1994 12:09:02 -0500 From: wgi@aplcomm.jhuapl.edu (Bill Innanen) Subject: Re: Cell-phone ergonomics side-effect (Stanley, RISKS-16.57) Robert Stanley (rstanley@sybase.com) wrote in RISKS-16.57 about a mishap with a Nokia pocket sized cellular telephone. In this instance the one touch re-dial feature of the phone was inadvertently activated while in the owner's pocket, resulting in a supposedly private meeting being recorded on an answering machine. As a (very satisfied) owner of a Nokia cell phone I would add a couple more RISKS. Namely, failure to become acquainted with the features of one's high tech widgets, and/or the failure to use same. On my model 2120 Nokia there are two features either one of which would have prevented this mishap. As Mr. Stanley notes, the Nokia does not have a flip cover to protect the buttons from inadvertent presses. I personally think this lack is a Good Idea. The fewer moving breakable parts the better. However there is definitely a need to protect the keyboard. Nokia handles this electronically rather than mechanically. On my phone the "Keyguard" function is activated by the key sequence -*. This this puts a notice on the screen that the keyboard is protected until the same key sequence is entered again. One can still answer the phone with the Keyguard active, however. I habitually keep the Keyguard active since I also carry my phone in my pocket. (Pants pocket in my case -- my shirt pocket is occupied by my "nerd protector" full of pens and pencils.) The other Nokia feature that could have averted this problem is that the "one touch re-dial" can be turned off via the configuration menu. Personally I find it convenient and use it, relying on the Keyguard to protect me from unwanted redials. Bill Innanen wgi@aplcomm.jhuapl.edu ------------------------------ Date: Wed, 23 Nov 1994 15:35:54 -0500 (EST) From: Paul Robinson Subject: Re: Cell-phone ergonomics (Stanley, RISKS-16.57) > ... it is an extraordinarily sobering experience to hear > a sensitive work discussion issuing hours later from the > speaker of your home voice messaging system. Question: is this real or are you just repeating the plot of Michael Crichton's {Disclosure}? :) In {Disclosure}, the main character claims his boss - who is female - sexually harassed him by placing him in a compromising situation and trying to force him to have sex with her (he is married). He is able to show that she forced herself on him because he was testing a shirt-pocket sized cellular phone, had called a friend on it, and had not hit the "END" key, and his friend ended up with a recording of this "sensitive work discussion" on HIS answering machine... Life imitates fiction. Paul Robinson - Paul@TDR.COM [Also noted by padgett@tccslr.dnet.mmc.com (A. Padgett Peterson), wolit@library.att.com (Jan I. Wolitzky), minow@apple.com (Martin Minow).] ------------------------------ Date: Wed, 23 Nov 1994 17:43:33 -0800 From: marks@bierce.latimes.com (Mark Seecof PSD x77605) Subject: Re: Anon. on "TEN Q's" (RISKS-16.57) I agree with anonymized but urge: when giving "polite false" telephone numbers to salespeople, give NULL numbers, dammit, not random ones. I don't want calls from your sales contacts. (I find the TOD number (locally 853-1212) works well.) Mark Seecof ------------------------------ 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.58 ************************