Subject: RISKS DIGEST 16.48 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Friday 21 October 1994 Volume 16 : Issue 48 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: "The Mother of All Utility Bills." (F. Barry Mulligan) Observed Electro-Magnetic Interference (Henry Troup) Re: Computer risk that nearly proved deadly (Mark Thorson, Gary Koerzendorfer) Cellular Phone Fraud Operator Arrested (Paul Robinson, Chip Maguire) Not enough bytes bites again (Marc Auslander) Inadvertent postal forwarding (V. Michael Bove Jr.) Computer model of Haiti (Phil Agre) Re: Risks of not thinking about what you're stealing (Joel Finkle) Re: Risk of similar interfaces (Chris Norloff, Erann Gat, John Mainwaring) Re: Software reuse (David Honig) Re: Greyhound (Danny Burstein) CNID and Don Norman -- CNID can be private (Justin Wells) Re: CNID (Andrew Klossner, Phil Agre) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Fri, 21 Oct 1994 13:08:57 -0500 (CDT) From: "F. Barry Mulligan" Subject: "The Mother of All Utility Bills." From The Atlanta Constitution, Tues 18 Oct 1994, p.1, by Christopher C. Warren Imagine a single monthly statement listing all utility charges, including phone, cable, gas, electricity, water, garbage collection and sewerage charges. It could be the mother of all utility bills and would allow consumers to write only a single check for all their services. One Check, as the proposal is being touted, would ease consumer's household management by reducing utility bills to one monthly payment, said Maureen Bailey, vice president of public affairs with American Express, the company proposing the service. The article goes on to describe the pilot test being proposed for the Atlanta metro area. The cost of the service would be shared by the utilities and the consumer. Risks? A little late with one payment and you're instantly in arrears with every company in town. Billing disputes "still would be handled through the individual utility companies", but what if the utility says it didn't get a payment you sent to the service company? If your combined statement is mailed on the 15th and a utility transmits a new charge to the service bureau on the 16th, what happens to the payment grace period? If you've ever had to rob Peter to pay Paul, how do you deal with Peter & Paul, Amalgamated? Perhaps the real question is 'Do I want to give a complete, itemized description of all monthly utility consumption to American Express?' (and pay for the privilege). ------------------------------ Date: Fri, 21 Oct 1994 13:39:00 -0400 From: "henry (h.w.) troup" Subject: Observed Electro-Magnetic Interference On Thursday 20 October 1994, I attended an Emergency Response seminar held in the auditorium of a high-tech institute. There were a number of fire and ambulance personnel there "in-service" with two-way radios. A radio transmission inside the auditorium triggered all kinds of equipment - the video projector turned on, the slide projector turned on, and some unidentified motor noise started up. Nothing new, but an example of a widespread problem (still sometimes not accepted as real.) Henry Troup - H.Troup@BNR.CA (Canada) ------------------------------ Date: Fri, 21 Oct 1994 10:31:02 -0700 From: eee@netcom.com (Mark Thorson) Subject: Re: Computer risk that nearly proved deadly (Maniscalco, RISKS-16.47) The posting in RISKS-16.47 about reprogramming pacemakers through audio tones seems a bit alarming to me. Does that mean someone could have a tape player (i.e. "boom box") with a tape of pacemaker programming signals which would be deadly to certain members of the public? Imagine some guy walking around with that on a crowded train or bus. How about cutting into the SCA-encoded Muzak played in supermarkets? That's broadcast on the same frequencies used for ordinary FM radio. Often, wireless mikes are used at lectures and concerts. Care to find out how many Rolling Stones fans have pacemakers? The power level from the speakers at a concert hall ought to be much more than is needed for programming. Anyone know the name of the company that made the malfunctioning pacemaker? It might be interesting to do a patent search on them. Mark Thorson (was mmm@cup.portal.com, but now eee@netcom.com) ------------------------------ Date: Fri, 21 Oct 94 16:20:49 PDT From: Gary Koerzendorfer Subject: Re: cauterizer corrupts pacemaker I was surprised that a pacemaker would be susceptible to this interference, that it didn't figure it out, and apparently had no fallback mode. I'm not sure what EMI field strength the electrocauterizer created; should a patient be advised to avoid proximity to arc-welders and to 50KW broadcasting facilities like the one next to a bridge in San Francisco Bay? Secondly, a state-verification circuit (or even a "heartbeat"!) could have detected the malfunction, and regressed to a fallback fixed rate. Your own heart has a 30 beats/minute tertiary protective function - you're unable to engage in strenuous activity, but you remain alive until you can seek help. An incapacitated patient would be unable to inform ER staff that they had a pacemaker - perhaps if I had one I'd wear a MedicAlert tag. Gary Koerzendorfer, Hewlett-Packard Co., Systems Techn. Div., 19447 Pruneridge Ave. m/s 42L2, Cupertino Calif 95014 garyk@cup.hp.com (408) 447-4783 [For younger RISKS readers, TWO cases of deaths due to pacemakers being affected by interference are included in the RISKS archives. PGN] ------------------------------ Date: Thu, 20 Oct 1994 21:37:55 -0500 (EST) From: Paul Robinson Subject: Cellular Phone Fraud Operator Arrested (Summary and Comments) The following article summary is followed by some comments: In a Front Page article appearing in the Wed 19 Oct 1994 {Washington (DC) Times} entitled "High-Tech sleuthing busts cellular phone fraud ring" reporter Doug Abrahms tells us that Clinton Watson and two other persons were arrested Monday for selling cellular phones with altered serial numbers, causing the charges to be sent to legitimate cellular users. According to an Indictment in U.S. District Court in San Jose, when police raided Watson's house, they found 30 phones with counterfeit ID, 16 altered memory chips and 600 mobile phone numbers which could be used for fraudulent calls. Some of Mr. Watson's phones had as many as 12 different ID numbers, thus spreading usage patterns over a large area. Other phones were designed to allow the ID to be changed at will. Police and cellular companies have turned to using more sophisticated means to find illegal cellular phones, including helicopters, voice prints and traffic analysis. Mr. Watson is a Computer Programmer who designed his own software to program integrated circuits to include numbers read from scanners used on the cellular band. The phones so set up were referred to as "lifetime" phones since they never got a bill. They sold for $1,200 to $1,500 and have been found all over North America, according to Ron Nessen of the Cellular Telecommunications Industry Association (CTIA), which estimates that cellular fraud is a $1 million a day problem, with people stealing cellular IDs by waiting near tunnels, airports and parking lots to snatch the ID code transmitted. New York's NYNEX is introducing a PIN code on cellular calls. The Mayor and Police Commissioner of New York City have had the IDs for their cellular phones stolen six times this year. A division of TRW is developing a means to prevent calls unless the user's voice print matches the print on file. Comments: 1. Cellular Companies have been notorious for evading security problems in their phones. Rather than spend the money to add encryption in their switch software, they got a law passed to make it illegal to listen to cellular frequencies and to build equipment that can monitor cellular bands. 2. Cellular phones transmit call information in the clear, so a thief can just use someone else's number and steal a few minutes of airtime from them; if you bleed 10,000 customers of ten extra minutes a month, almost none of them individually will recognize that their bill is ten minutes too high. Unless customers complain, the Cellular Company won't care. 3. A typical practice of an aerospace/military contracting company like TRW is to try an implement and expensive complicated system such as voice print matching instead of something simple and cheap like a device to implement either Kerberos validation, S/Key style one-time passwords, or MD-4/MD-5 arithmetic checksum of some stored value. Putting such methods in as an inexpensive box like a Radio Shack tone dialer might cost users $20 and installing it in new phones might cost an extra $2 or $3. Persons having portable PCs could run a program to generate the code. Since everything is done without a secret being transferred, the software to do this can be public and nothing is compromised. 4. Does using a biometric validation system on a communications network scare anyone? I can think of a half-dozen reasons to dislike it, including: - use of the system to track and locate dissidents and anyone the people who run the government don't like; - my sister wants me to call someone for her and find out something without them knowing it's her asking; I don't match her car phone profile; - I borrow her car to do an errand; I can't call her back to let her know what I found out for her; - Bugs in the software might not recognize the owner with a cold, after an accident that damages their throat, or after some forms of surgery; - Checking voice prints will require very heavy processing capability, quite likely slowing down call connection times; - I bug someone's car and simply play back the recording to unlock their phone. I think that this is an attempt to "kill flies with nuclear weapons," e.g. excessive overkill. There are cheaper alternatives such as mathematical verification that will probably be quite effective without using a system that requires expensive and complicated subsystems such as voice print recognition. ------------------------------ Date: Sat, 22 Oct 94 01:00:54 +0100 From: maguire@it.kth.se Subject: Re: (mobile-ip) Cellular Phone Fraud Operator Arrested Actually - FBI/Cellular operators/... could just buy suitable equipment from a major electronics manufacturer in France - it reportedly even includes key-word spotting. Certainly why I look forward to widely available portable crypto for mobile voice and data. Chip ------------------------------ Date: Fri, 21 Oct 1994 13:41:16 -0400 From: marc@watson.ibm.com (Marc Auslander) Subject: Not enough bytes bites again ---222--- NOTICE ADVISORY TO NAVSTAR USERS (NANU) 222-94266 SUBJ: TIME TRANSFER DATA ANOMALY 1. CONDITION: USERS OF GPS TIME TRANSFER INFORMATION ARE ADVISED THAT THE DATA IS SUSPECT AS OF DAY 266 (23 SEP 94) BEGINNING AT 1500 UTC AND CONTINUING UNTIL FURTHER NOTICE. 2. GPS NAVIGATION POSITIONAL DATA ACCURACY IS UNAFFECTED. 3. POC: CPT JAMES AT COMMERCIAL (719) 550-6378 OR DSN 560-6378. ---223--- NOTICE ADVISORY TO NAVSTAR USERS (NANU) 223-94266 SUBJ: USERSET TIME TRANSFER ERRORS 1. CONDITION: INVESTIGATION HAS REVEALED THERE IS NO CURRENT OR PAST PROBLEM CONCERNING TIME TRANSFER INFORMATION. WE HAVE DETERMINED THAT SOME USERSETS MAY NOT ACCOUNT FOR ROLLOVER OF THE 8 BIT GPS UTC REFERENCE WEEK. IAW ICD GPS 200, PARAGRAPH 20.3.3.5.2.4, PAGE 18 OF SUBFRAME 4 INCLUDES THE PARAMETERS NEEDED TO RELATE GPS TIME TO UTC. THE USER MUST ACCOUNT FOR THE TRUNCATED NATURE OF THE UTC REFERENCE WEEK. THIS USERSET DISCREPANCY WILL OCCUR EVERY 255 WEEKS AND WILL LIKELY CLEAR AT END OF WEEK ROLLOVER. 2. POC: 1LT PETERSON AT COMMERCIAL (719) 550-6378 OR DSN 560-6378. Marc Auslander 914 784-6699 (Tieline 863 Fax x6306) ------------------------------ Date: Fri, 21 Oct 94 16:12:43 -0400 From: V. Michael Bove Jr. Subject: inadvertent postal forwarding The following concerns an acquaintance whom I'll call S, who works at the corporate headquarters of a large firm which I'll call FooCorp (the pseudonyms are used because none of what happened seems to be FooCorp's fault, but some of their clients might be a bit distressed to hear about it). Having recently changed residences, S filed a mail-forwarding order in her name at her former post office. A few days later, mail addressed to the offices of a number of FooCorp employees started showing up at her new house, complete with yellow computer-generated forwarding stickers. How this happened is partial conjecture on S's and my part, as the postmaster in S's former town of residence wasn't terribly helpful in unraveling the mystery. The trigger seems to be the fact that as part of her employment S has a commercial credit card in the name of FooCorp, and the bills were mailed to ``FooCorp, [S's old home address].'' Somehow, some combination of postal employees and postal software decided therefore to generate a forwarding order such that mail addressed to FooCorp passing through the postal sorting facility nearest to S's former home should be forwarded to S's new address. The outcome is that various important-looking pieces of FooCorp's mail were diverted to a rural mailbox in front of a horse barn in the middle of nowhere, and apparently no one in the Postal Service thought this at all odd. The postmaster thinks the forwarding order has now been eradicated, and S has contacted her credit card issuer to cause the bills to be mailed in her name, not FooCorp's. However, the misdelivered mail hasn't totally stopped, since while the order was in effect, the Postal Service dutifully notified anyone whose envelope said ``Address Correction Requested'' that FooCorp had moved; there are now at least a few mailing databases out there which think that FooCorp is located at S's house. The lesson, of course, is that procedures that try automatically to do the right thing without being asked sometimes need a reality check applied to the results. ------------------------------ Date: Thu, 20 Oct 1994 18:15:37 -0700 From: Phil Agre Subject: Computer model of Haiti In an article in The Nation, Allan Nairn asserts that the American military force occupying Haiti is more concerned about the popular movement that elected Jean-Bertrand Aristide than it is about the oligarchy that created the attaches. I don't know whether this assertion is fair, but Risks readers might be interested in one part of his evidence. The full citation is: Allan Nairn, The eagle is landing, The Nation 259(10), 3 October 1994, pages 344-348. Here's a quote: ... the Pentagon's Atlantic Command (ACOM) has commissioned Booz, Allen, Hamilton, a corporate consulting firm, to devise a computer model of Haitian society. A similar model was ordered for Iraq for Desert Storm. The model tries to predict "the effects of social, political and economic actions on various sectors of society". In an April 29 report Booz, Allen presented a "Power Relationship Matrix" which divides Haitian society into seven groups, including the "Lower Class Majority", and asks questions like "What would mobilize the masses to take action?" The crux of the Booz, Allen/ACOM planning theory is thus: "Whether political power is a direct function of popular support or based on the allegiance of key groups and coercion of the remainder of the populace, cohesion of support is a critical question in assessing political power". They place greatest emphasis on the importance of "Organized Civil Society" -- popular and professional groups, unions and associations, development workers -- seeking to identify the points at which mass cohesion will crack. This, they say, is the key to any program for "control of the populace". Their priority is to build an "organized information bank" and to run a systematic, ongoing "assessment of the relative strengths of opposition organizations", as well as of leading "political personalities". "The tracking of opposition organizations", they say, "should be limited to those which are known to have a basis of political action and some established capacity for taking political action". As the Washington Office on Haiti has documented in detailed reports, A.I.D. [the US Agency for International Development] is already exploring this divide-and-conquer strategy in Haiti, seeking to cultivate and fund, as on embassy memo put it, "responsible elements within the popular movement" along with "moderate Duvalierist factions". (pages 347-348) An exercise for the reader: if they implemented such a program for your home town, what would it look like? Phil Agre, UCSD ------------------------------ Date: Fri, 21 Oct 1994 12:55:34 -0500 From: jjfink@skcla.monsanto.com (Joel Finkle) Subject: re: Risks of not thinking about what you're stealing Tumbling a beeper's activation code is trivial. You can take your beeper to any beeper service company, ask to be switched to their line of service, and they'll recode and activate you, assuming (a) that you're using the same brands that they are and (b) you're *not* using the same service company they are (or they can't switch you). Presumably, a stolen beeper could be handled as if you owned it, then there's a high likelyhood that you'd get it reactivated. ------------------------------ Date: Thu, 20 Oct 94 22:48:41 EDT From: cnorloff@tecnet1.jcte.jcs.mil Subject: Re: Risk of seeming similar interfaces (Elkins, RISKS-16.47) ARRRRGGGHH!! And the risk of idiots designing switches! It does not take a rocket scientist to figure out that a critical switch should be put in a hard-to-access location or should have a protective cover over it. This kind of stuff is taught in very basic human engineering classes. There are certain errors designers are doomed to keep repeating, and switch design is one of them. Chris Norloff cnorloff@tecnet1.jcte.jcs.mil ------------------------------ Date: Fri, 21 Oct 94 11:09:00 PDT From: gat@aig.jpl.nasa.gov (Erann Gat) Subject: Re: Risk of seeming similar interfaces (Elkins, RISKS-16.47) Monta Elkins writes: >on the Power Mac this is the POWER button Geez! Will Apple never learn? The original Apple II was notorious for having its reset button on the keyboard immediately adjacent to the return key, with predictable results. If any company should know to put power and reset buttons far away from everything else on the machine you'd think it would be Apple. Sigh. Erann Gat gat@robotics.jpl.nasa.gov ------------------------------ Date: Fri, 21 Oct 1994 14:33:00 -0400 From: "john (j.g.) mainwaring" Subject: Re: Risk of seeming similar interfaces (Elkins, RISKS-16.47) The late lamented Commodore company did the same with the Amiga 3000, which has a push power switch in almost the same location as the disk eject button of the A1000. I don't suppose that was the only reason for the company's demise. Still, fond as I have been of the A3000 since the day I got it, that design feature led me to wish an even worse fate on the company on numerous occasions during my first several months of ownership. ------------------------------ Date: Fri, 21 Oct 1994 12:18:24 -0700 From: David Honig Subject: Re: Software reuse (Gonzales, RISKS-16.47) >Published reusable software should be as carefully designed and verified as >any other safety critical software, since its publishers will have no control >over what systems it gets reused in. I think this is wrong. Ensuring safety is the requirement of the human organization producing a potentially hazardous product. The *organization* must have adequate quality checks. One engineer's bad day, one alpha particle, or one bolt's failure, should not harm people. One wouldn't disallow the reuse of used power supply designs, for instance. Instead, if you were putting them into an important machine, you would not only test their published performance, but perhaps *add* additional safety-relevant tests. And then you would design in several of them if the application justified it. If you want to reuse some code (or other artifact) in a RISKy application, maybe you'll have to characterize it more than a less critical user. What else is new? Computer professionals should learn that (organizations of) people are responsible; technical professionals are responsible for making technical observations and their implications known to others in the organization. ------------------------------ Date: Thu, 20 Oct 1994 22:43:44 -0400 (EDT) From: danny burstein Subject: Re: Greyhound (RISKS-16.47) While I haven't seen the original piece, I would expect that it glossed over what may very well be a major, if not -the- major, cause of of the problems -- namely, the horrendous management-labor problems at the company that led to a strike/lockout/mass firing (take your choice....) of the vast majority of bus operators. The bosses, though, as well as the finance MBA types, stayed in office. And, as the article mentioned, cheerfully exercised their stock options to make huge profits. -dannyb@panix.com (or dburstein@mcimail.com) ------------------------------ Date: Fri, 21 Oct 1994 13:29:49 -0400 From: Justin Wells Subject: CNID and Don Norman -- CNID can be private In Don Norman, in his book "Things That Make Us Smart", makes some interesting points about Call Number ID. He writes that the emphasis on NUMBERS stems from a mechanistic view of the phone system -- a human view of the phone system wouldn't depend so heavily on numbers (which we have trouble remembering). He suggests that other information should be sent instead of a telephone number. Perhaps each telephone owner could set a string that accompanies their call instead of their phone number. It need not be more than a few characters -- maybe your first name, maybe the name of your company. His point is that the average person wants to know WHO is calling, and only businesses, etc., really care about the phone number. This solution should retain the value of CNID (knowing whether you want to answer the phone), but eliminate the privacy risks (including the need for call blocking, etc.) I found lots of excellent commentary on this and other sorts of RISKS in his book. I know he's posted here before, and I noticed he has a reference to RISKS in his book. I recommend it to everyone. Justin [Don also wrote a column for the April 1993 CACM Inside Risks, which has been adapted as a section in my COMPUTER-RELATED RISKS book. PGN] ------------------------------ Date: Fri, 21 Oct 94 11:54:46 PDT From: andrew@frip.wv.tek.com (Andrew Klossner) Subject: Re: CNID (Preece, RISKS-16.47) Require the phone company to assign a second unique number ... to each telephone... I don't think this represents a serious technological hurdle... It does. Almost all area codes in North America are more than half populated. In order to double the number of phone numbers, most area codes would have to be split. -=- Andrew Klossner (andrew@frip.wv.tek.com) ------------------------------ Date: Thu, 20 Oct 1994 19:09:09 -0700 From: Phil Agre Subject: Re: CNID In his comment (RISKS-16.47) on my message about CNID, Peter da Silva refers to me as an "Anti-CNID fella". But I am not opposed to CNID, only to bad implementations of it that make free choices about CNID difficult. At the same time, he is correct to criticize my generalizations about "CNID proponents". I didn't mean to refer to everyone who finds CNID useful, only the folks who wish to profit from bad implementations of CNID and can hire lobbyists for this purpose. Phil Agre ------------------------------ Date: 20 October 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 automated). 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.48 ************************