Subject: RISKS DIGEST 16.10 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 31 May 1994 Volume 16 : Issue 10 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) ***** Contents: Closed Doors in Glasgow Human.risks-- Scapegoats and Puddlejumpers... (Peter Wayner) Man charged with E-mail stalking (John C. Rivard) Police BBS in Silver Spring, MD (Mich Kabay) Re: alt fan karla homolka (Phil Overy) Eavesdropping hits NSA (Peter Wayner) Risks of too-simple responses (Jerry Leichter) "Zap!" by Sellers (Rob Slade) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Wed, 25 May 94 21:12:10 BST From: kh@dcs.gla.ac.uk Subject: Closed Doors in Glasgow GUARD DIED AFTER DOORS FAILED IN COURT FIRE. The Glasgow Herald, Glasgow, Scotland, 25 May 1994 A failsafe system on security doors at Edinburgh's new sheriff courthouse did not work on the night of a fire in which a security guard died, a fatal accident inquiry heard yesterday. Graham Scott, 39, managing director of computer firm System 4, told the inquiry at Edinburgh Sheriff Court that security doors which should have opened automatically in the event of fire had remained locked. Security guard George Campbell, 57, of Claremont Grove, Edinburgh died when he was trapped in a lift by the fire on November 19 last year. Mr Scott said that a programmable computer chip in the system had its information wiped accidentally and did not signal the doors to open. The doors normally worked by having a security card "swiped" through a device which identified the card and allowed them to open. The inquiry heard that efforts by another security guard to reach Mr. Campbell failed when his card would not open a door on to the sixth level where Mr. Campbell was trapped. Mr. Scott said that because the fire had burned for some time before being discovered, it had probably burned through the cable connecting the door to the main control computer, but a push button on the inside should still have opened it. He said that under the new system any door which was cut off from the main control for more than 10 seconds would automatically unlock itself. [This tragedy seems to have been the result of a combination of problems: no escape route from the lift (elevator); no way of opening doors from the outside without the door computer working (sounds familiar!); and a specified but untested exceptional case. The new failure mode is interesting too: they'd better keep that computer working if they don't want thieves to break into the courthouse! KH] ------------------------------ Date: Thu, 26 May 1994 09:03:58 -0400 From: pcw@access.digex.net (Peter Wayner) Subject: Human.risks-- Scapegoats and Puddlejumpers... The May 25th edition of the Wall Street Journal has a long story by Daniel Pearl about a crash of a small commuter airplane. The company seems to be blaming the pilot and the story goes to long lengths to document his bad attitude. His anger, the theory proposes, lead him to screw up in the bad weather and misjudge the position of the ground by 300 ft. The story is well-written and essentially balanced, but I wonder if the author really thought about the spin he was putting on the story. For instance, the author "documents" the pilot's anger and abrasive behavior as such: "Always a meticulous person, Mr. Falitz became even more of a stickler. He filed 14 anonymous (sic) air-safety reports, including one about a flight attendant who didn't have up-to-date paperwork." (I hope their anti-terrorist security is better then their protections for anonymity.) (Before the Flight) "Mr. Falitz had an angry argument with a gate agent over his paperwork, and a ramp worker in Minneapolis told the safety board that he saw Mr. Falitz chew out Mr. Erickson (the co-pilot) for not checking the landing light from outside the plane. After the Hibbing-bound passengers were aboard, Mr. Falitz insisted on bumping one passenger to meet the weight limit; a woman travelling with her family volunteered to get off." To be fair, the writer also documents a time when Falitz slapped the headset of a co-pilot after the co-pilot set it to the wrong channel. There are a few other quotes that make Falitz seem a bit too disgruntled. For instance, Falitz was annoyed because the airline was forcing him to make the doomed flight and he would have to fly home on his day off. But, I still was rather disturbed by the fact that the writer seemed to be building an argument about Falitz's abrasiveness by citing Falitz's desire to abide by the rules. The second paragraph I quoted ran directly under the sub-heading "Quarrels with Colleagues." I wonder if the woman who was bumped by the flight believes that the doomed plane should have taken off with too much weight as well? The best "fact" that proves Falitz was an abrasive pilot with an attitude was that "On one sweaty flight, he announced to passengers that 'the company is too cheap to fix the air conditioner.'" Incidentally, the co-pilot on this flight that crashed made $18,000 a year. At the time, small commuter planes were not required to have low altitude warning devices that would have alerted the pilots to the fact that they were too low. Big jets had them, but the companies didn't have to spend the money on the little planes. They became required last month. The article also mentions that the altimeters often stick. The most dangerous subtext hidden in the article is the fact that the Federal Aviation Administration is funding a program to develop personality tests for pilots. I just hope that they can find a way to tame the anger without turning the pilots into lemmings that accept low pay and badly maintained planes that are overloaded with passengers and luggage. ------------------------------ Date: Thu, 26 May 1994 12:27:36 -0400 From: jcr@garnet.msen.com (John C. Rivard) Subject: Man charged with E-mail stalking A front-page story (!) in the May 26, 1994 _Detroit Free Press_ tells the tale of a 31-year-old suburban Dearborn Heights man who has been arrested and charged under Michigan's new anti-stalking law for alleged harassment of a 29-year-old Farmington Hills (another Detroit suburb) woman via E-mail. The article refers to this as "one of the first cases of stalking based primarily on E-mail. Under a large color photo of Mr. Archambeau with his arm draped casually over his computer, the story tells of how he was jilted five days into an E-mail relationship carried out over America Online. After the woman (anonymous in the article per her request) sent the "Dear John" E-mail message, he has been sending her E-mail trying to win her back. The two met via a video dating service. The woman states that received a total of "about 20 E-mail letters" from Archambeau since the day she met him, hardly mail-bombing by most RISKS readers' standards. She has saved and printed the messages for her lawyers. Archambeau claims that E-mail, by its nature, is non-harassing, because she can refuse to read the message after seeing the sender: "I was courting her in a way that she could easily ignore." The recipient of his unwanted advances points out that her system won't delete unread mail for 37 days, so she has to look at it for that long, "which is more harassing than postal mail." After being contacted by a Farmington Hills detective, Archambeau sent several more messages to the woman, as well as one to the detective explaining his side of the story. The detective said that the woman wasn't "terribly concerned" about the E-mail until she received a phone message from Archambeau in which he apologized for watching her leave her workplace, which is a block away from where he lives. The woman seems to be claiming that E-mail itself is harassing by its very nature. She does not claim that the content of any of the messages were in any way threatening, although the Farmington Hills detective said after he had initially contacted Archambeau, later messages contained "other methods of harassment if she carried through with a police complaint." The Michigan "stalker" law makes it a misdemeanor to maliciously and relentlessly harass and pursue someone, punishable by up to a year in jail and a $1,000 fine. This is the charge against Archambeau. The offense becomes a felony if threats are made or the person is under court order to stay away from the alleged victim. Then the perpetrator faces five years and $10,000. Women's rights groups who helped draft the law say they are certain that it covers E-mail harassment, but the ACLU, which has expressed concern over the law being able to withstand constitutional challenge, is not so sure. There is a strange and extreme dichotomy in this story. On the one hand, we have the alleged perpetrator is claiming that E-mail by its nature *cannot* be threatening, and on the other hand, the alleged victim is claiming the opposite, that unsolicited E-mail is *harassing* by it's nature. Both positions don't consider about the *content* of the message at all! This case brings the all the RISKS of treating the medium of E-mail differently than other channels of communication to the forefront in what may be a precedent-setting court case. A second RISK is in the news media's overemphasis on E-mail as a stalking tool. In fact, the text of the article indicates that the only blatantly threatening act (watching the victim leave work) was related over the phone. Nonetheless, the media spin on this issue is solely the ground-breaking act of stalking by E-mail. Denyability/accountability of E-mail is a RISK that is not dealt with in this article, mostly because Archambeau openly admits sending the E-mail in question. John C. Rivard jcr@mail.msen.com JCR Design and Consulting ------------------------------ Date: 26 May 94 06:11:46 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@CompuServe.COM> Subject: Police BBS in Silver Spring, MD >From the Washington Post newswire (94.05.23) via Executive News Service (GO ENS) on CompuServe: "In Silver Spring, the Public Can Log On to the Police Log" By Veronica T. Jennings Washington Post Staff Writer "In the corner of a second-floor office in the Silver Spring district police station sits a computer terminal that may launch Washington area police agencies onto the information superhighway. "The computer contains information on crimes and suspects and, as of last week, it's available to the public on a pilot basis." The author makes the following key points: <> o The Police BBS makes local crime information, updated twice weekly, available at all times. o Statistics include crime reports per block and county-wide. o The BBS also supplies "carjacking prevention tips and information on new laws." o Neighbourhood Watch groups communicate with each other and with the police. o The BBS supplies no new information beyond what is already available on Police central computers. o The BBS is run by James Hockenberry, who removes sensitive information before transferring files from the district computer into the BBS. He also translates code numbers into ordinary language. o The experiment is being closely watched by academics and by other police forces around the U.S. o Access port: 301-565-5737 N/8/1. o "Several safeguards have been built in for privacy and security, Hockenberry said. For example, it is not connected to the Maryland or national criminal information networks that provide data to law enforcement officials on vehicle registration or suspect information." o No disclosure of "exact street addresses of reported crimes or the names of victims." o Authorities hope that improved availability of timely, accurate, detailed crime statistics will lead to a more realistic appraisal of crime and crime prevention. <> [Comments by MK: The manual transfer of data will eventually lead to a screw-up. Confidential information will leak into the public domain and all hell will break loose, including lawsuits (O, Horror!). The initiative sounds positive; I hope that the authorities will arrange for automated processing of information to help the human supervisor prevent errors.] Michel E. Kabay, Ph.D. / Dir Education / Natl Computer Security Assn ------------------------------ Date: Thu, 26 May 94 15:07:40 BST From: phil overy Subject: re alt fan karla homolka The newsgroup and offending details of this list also made their way to our machine; I suppose the Ontario police object to details being published in a case which is "sub judice". I have read (this may be wrong information) that the details are being published by people who object to a plea bargain by the (equally guilty?) Karla Homolka. This is not the way in which sub judice is dealt with in Austria (I have recently moved back to the UK); often papers will carry details from major court cases, but not name the defendants and not quote any prosecution allegations. Many VERDICTS do not contain the convicted man's name, so a "family" murder might be reported: "Dragan K. stabbed his father to death after an argument over the war in Yugoslavia" - the report will continue to expand on what took place, but the name is not given (anyone who thinks "Dragan" is a good clue has not met many (Yugoslav)s..). The biggest advantage I can see to this approach is presented in minor crimes- in the UK many minor crimes are wiped from the record 3 years after the end of the sentence, but local newspapers indefatigably pillory the local fast drivers, petty thieves etc by name - the only way to genuinely lose that conviction 3 years after leaving prison is to move away, because someone may dig up the newspaper report (indeed they WILL do so in Hicksville/ Nempnett Thrubwell). "sub judice" publication of details of a case does of course cast doubt on fair trials; I am sure that the individuals named as Lt. Starbuck etc in the Homolka case do not want either of the accused to go free for lack of a fair trial, but their actions could well cause a mistrial to be declared. The Risk? The Internet is providing a sort of international newspaper; at the moment it doesn't display a great deal of commitment to that role. If The Internet is "the new press", it's a pretty flabby alternative to the old one. Phil Overy, Rutherford-Appleton Laboratory ------------------------------ Date: Sat, 28 May 1994 10:43:18 -0400 From: pcw@access.digex.net (Peter Wayner) Subject: Eavesdropping hits NSA The Baltimore Sun ran an AP wire story (5/27/94, pg1) reporting that Dunkin Donuts owners routinely places audio mikes in their stores for "security." The story notes that the DD near Fort Meade, MD (the home of the NSA) contains the equipment. The story notes that the main corporate headquarters says that these hidden microphones would be wrong. But it also cites Security systems dealer Jeff Meuse who "told the Concord Monitor he has installed systems in 500 Dunkin' Donuts in Massachusetts in the last five years; of those, 300 had audio monitoring." [No telling what might be hidden in the donut holes! PGN] ------------------------------ Date: Fri, 20 May 94 21:13:58 EDT From: Jerry Leichter Subject: Risks of too-simple responses Several articles in a recent RISKS caught my eye in their common style of taking too simple-minded an approach to a risk, thus missing important issues. 1. Editor functionality mutates code Kevin Lentin reports on an "extended vi" editor that has a CTRL/S command which, if the cursor happens to be sitting on a number, decrements the number by 1. In a particular communication setup, CTRL/S was being used as XOFF and also passed through to the editor, resulting in random mutations of code being edited. Mr. Lentin suggests that the fix is to be more careful about terminal settings. While this fixes the immediate problem, it ignores the underlying issue of adaptation to the real world. CTRL/Q and CTRL/S have been used for in-band signalling as XON and XOFF for many years. Using them as editing commands is simply *very* poor design. It's very poor because it's inherently dangerous: There are too many ways to accidentally misconfigure an asynchronous terminal connection so that XON and XOFF end up being passed to programs. Further, in the case of dial-up or network connections, the "proper" settings often have to be made at so many intermediate systems, often systems with wildly different interfaces, that errors are certain. EMACS has always been the primary focus of this particular problem. Its designer has made it a point to bitch and moan about and generally refuse to come to terms with any system that has the audacity not to deliver CTRL/Q and CTRL/S. Well, OK; that's fine for after-dinner conversation. Safe software, however, must adjust to the realities - and the realities for CTRL/Q and CTRL/S are long established. 2. UK ATM Spoof Mich Kabay reports on an incident in London in which thieves stole an ATM machine, repainted it, set it up in a shop, used it to gather card info and PIN's, and eventually used those to steal some 240,000 pounds. Mr. Kabay comments that had the banks used smart cards and a challenge/response system, this crime could not have occurred. He's right, but for a different reason: Had banks waited for smart cards to be practical before setting up ATM's, there would probably still be few if any ATM's. ATM's date back about 20 years by now, and it took a good ten of those years from ATM's to become really widespread. Smart cards are only just becoming practical for mass use now. They are still considerably more expensive and fragile than the well-proven magnetic stripe card technology. Meanwhile, the cost of conversion has inevitably mounted. There's a huge installed base of magnetic card readers, and a huge number of magnetic cards in customer hands. Conversion would be a very non-trivial task. Should we as a society have waited before putting our trust in a technology that has proved to be so easily abused? A difficult question in general - among technologists, there's always a push to just go ahead a build the thing and see what happens. In this particular case, I think you'd be hard put to argue that waiting was called for. What's ignored in just going ahead, however, is that it inevitably raises the future costs of fixing the problems. In practice, my bet is that we will *never* see the replacement of magnetic stripe cards by smart cards. Instead, we'll see improvements in stripe card technology. I saw a report not long ago about a technique that samples the random noise on the magnetic stripe. This noise is unique to a particular card, is not changed by recording information on the stripe, and cannot be set in a particular way by any known technique. If, indeed, this technique is practical - and the principle certainly appears sound - it would eliminate the class of crime described here equally well. (Curiously, a similar thing is happening in the cellular phone arena, where the same kind of crime - the theft of identification information for the purpose of faking a valid access token - is being combated by analysis of the details of a phone's transmission characteristics, which again appear to be unique to each unit, and not forgeable. There's a significant commonality here: These crimes are made possible because in the digital world, "bits is bits". Those of us who deal with higher-level abstractions, where circuits really are binary - much less those of us to whom the lowest level of abstraction is the software architecture - easily lose sight of the fact that underlying our abstractions is a physical world in which parts are not exactly interchangeable. My prediction: We'll see many more techniques based on looking "below" the digital level in the years to come.) 3. FIPS to be tied... [hashing, Capstone] Peter Wayner notes that the recently discovered flaw in, and modification to, the Secure Hash Algorithm "...proves the RISK of using a hardware based standard." It proves nothing of the sort. a. Software isn't nearly as "soft" as people like to think. There are still many systems out there running MSDOS Version 3. Security bugs reported and patched years ago are still live in many Unix systems. It's widely acknowledged that no fundamental change can be made in the UUCP algorithms or protocols, since many sites either would not, or simply could not, upgrade. The world of the individual programmer, ever ready to replace his copy of gcc with the latest and greatest release of yesterday morning, has little to do with the way most of the world works. b. Hardware may be easier to change than software, if appropriately designed. ROM updates are a common thing. c. A ROM update blurs the line between software and hardware, but in practice any low-end implementation will have more of the characteristics of hardware than of software, simply because the economics favor something that can be duplicated very quickly and cheaply - and that's either a specialized chip, or a general purpose CPU plus ROM. d. In any case, the Secure Hash Algorithm isn't a hardware-based standard - whatever that means - to begin with! If, as Mr. Wayner worries, SHA were found to have a significant problem after it was in wide use - it really would make little difference *how* it had been realized. Software, ROM, custom hardware - updating a million instances of *anything* is an immense problem. -- Jerry ------------------------------ Date: Tue, 31 May 1994 15:46:51 -0600 (MDT) From: "Rob Slade, Ed. DECrypt & ComNet, VARUG rep, 604-984-4067" Subject: "Zap!" by Sellers BKZAP.RVW 940311 Peachpit Press, Inc. 2414 Sixth Street Berkeley, CA 94710 800/283-9444 or 510/548-4393 Fax: 510/548-5991 tbooth@peachpit.mhs.compuserve.com "Zap!", Sellers, 1994, 1-56609-021-0, U$12.95/C$17.95 dsellers@hebron.connected.com The industrial first aid class that I was in had come to problems associated with bones and joints. The instructor was discussing bursitis, and was using the example of carpet layers. The tool used to stretch carpet is designed to be "kicked" with the knee while the worker is kneeling and tacking the carpet in place. Because of the repeated blows to the knee joint, bursitis is a fairly common result. Once it sets in, the worker can only hope to get a new job before the pain gets too bad. Someone in the class wouldn't accept this, and kept asking what could be done. The instructor patiently kept explaining that nothing could be done. Finally, the student pulled out what she thought was her trump card: what if the worker's whole *life* was carpet laying? "Well," replied the long-suffering teacher, "I guess he'd die, then." This was immediately recalled to me by the anecdote used to open this book. Some conditions are tragic and some are preventable. The prevention, however, may not always be within the control of the worker. Still, this is an important book. When you consider the possibly painful and costly alternatives, "Zap" is probably well worth the price for any and every computer user. Home users may cavil, but they are the ones who probably have the worst work setups and the most control over their environment. Certainly every large office should have a copy, although I suspect it will be used more by staff than management, alas. Given that the book's chapters cover not only body systems but also external and environmental factors, it tends to seem a bit disjointed. The jumps from subject to subject are sometimes difficult. It is, however, undoubtedly useful in bringing together all manner of factors and problems into one place. The suggestions tend to be along the lines of common sense; relax; if something is uncomfortable at first, it will get worse with repetition; keep moving, etc.; but it is not to be despised on that account. When the subject gets more technical, as in the chapter on radiation, Sellers tends to waffle more. (He recommends a commercial monitor retrofit which can be accomplished more effectively and for less money at home with a roll of tin foil.) The resources at the end of almost every chapter are helpful for further study in specific areas. There are, however, some odd gaps (such as the chapter on back pain). Hopefully, future editions of the book will add more contacts and information. The book is written to the user. This might seem an obvious audience, but it is probably management who need more prodding here. It is a pity that more information is not directed towards the solid business advantages of an "ergonomic" workplace. In discussing chairs, for example, one could note that the cheapest steno chair might be available for sixty dollars, whereas the most expensive is ten times that much. This might appear to be a substantial price difference--until you consider that the cheapest receptionist costs twenty times as much, per year, as the most costly chair. If you get only five percent more work out of someone with a better chair, you pay for the chair in a year. While there are gaps in this work, it is significant for bringing together a number of health issues in one place. For this reason, I highly recommend it and look forward to improved editions in the future. Give it to your computer novice friend and it might just save his or her neck. Or eyes. Or hands ... copyright Robert M. Slade, 1994 BKZAP.RVW 940311 Vancouver Institute for Research into User Security, Canada V7K 2G6 ROBERTS@decus.ca Robert_Slade@sfu.ca rslade@cue.bc.ca p1@CyberStore.ca ------------------------------ Date: 31 May 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. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: 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.10 ************************