Subject: RISKS DIGEST 13.73 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 17 August 1992 Volume 13 : Issue 73 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Microwave oven autonomously turning on (A E Eckberg) Outdated sports news recurs (Geoff Kuenning) Fire department to get computer dispatching (Robert Allen) Electronic payment takes 2 weeks! (D. Langford) Security breach cited as class schedule erased (UBC) (Thomas Dzubin) A true tale of terror in the making: AUTOPAY (Steve VanDevender) Another saga of long-distance carrier confusion (Brian Holt Hawthorne) Intolerance and human differences (Rob Horn) Re: Bug or Fraud (A. Padgett Peterson) Re: Voting (Karen Frenkel) 1993 Research in Security & Privacy, Call for Papers (Teresa Lunt) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 13, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. For information regarding delivery of RISKS by FAX, phone 310-455-9300 (or send FAX to RISKS at 310-455-2364, or EMail to risks-fax@cv.vortex.com). ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Mon, 17 Aug 92 05:57:44 EDT From: ted@buckaroo.att.com (A E Eckberg) Subject: microwave oven autonomously turning on This article was originally posted in 'misc.consumers' and 'misc.consumers.house', and a responder suggested also posting in 'comp.risks'. I'm looking for information from anyone who has experienced an electronic-control appliance "autonomously" turning itself on or otherwise doing something that it was not explicitly "commanded" to do by a user. Also, if anyone has not experienced this first-hand, but knows of such incidents, I'd like to know. Here's why I'm looking for this information. Recently, while we were out of the house, our electronic-control microwave oven turned itself on. While this oven has a timer, it had not been activated, and there was no "logical" reason for the microwave to turn on. There had been, however, an electrical storm in the area that was severe enough to have affected many of the computer systems where I work (about a mile from our home), and the only logical explanation for the microwave coming on was that its microprocessor control had received just the right impulses from the storm to set it running. We don't know how long the oven had been running when we came back, but when we entered the house the microwave was running and had burned/melted a plastic trim piece inside, and had filled the house with burned-plastic fumes. In my opinion, electronic controls for appliances should be designed with more fail-safe capabilities than seem to be the case here, and it appears to me that our oven has a fundamental safety design flaw. Very likely ALL electronic-control appliances share this flaw, and there are likely to be severe consequences, although probably quite rare. In our case our house would probably have burned if we had not come back and turned the microwave off. Because occurrences like this are probably very rare, and maybe even unbelievable, I'd like to hear from anyone else who could relate incidents similar to this that could add to the believability of what happened. Please send relevant information to me at a.e.eckberg@att.com ------------------------------ Date: Mon, 17 Aug 92 00:50:43 PDT From: desint!geoff@uunet.UU.NET (Geoff Kuenning) Subject: Outdated sports news recurs About a year ago, Hennessey's, a local bar, replaced the usual ESPN programming on one of their four TV monitors with an obviously computer-generated display giving the day's sports scores, standings, and miscellaneous news, as well as showing advertising and some simple graphics. I found it to be a nice addition, since ten minutes or so of watching would give me the results on my favorite teams. This summer, the system has developed a rather troubling memory problem. There seems to be a flaw in the deletion of outdated information. In July, for example, it reported on the outcome of a Stanley Cup hockey game played in April, complete with a coach's comments on the (supposedly) next-scheduled game. This evening (August 16), it displayed baseball standings showing the Dodgers in fourth place, 6.5 games out of first. (As of this morning, they were in last place, 22 games behind. I guess today's loss to San Francisco really helped their standings!) Even more interesting, the out-of-date results are mixed with up-to-date information. The incorrect baseball standings were followed by a Las Vegas odds display gaving information on the correct National League baseball schedule for Monday. I have no idea how the system works (except that the immediacy of the results and the speed of the display update together indicate a local computer which receives information from a service via a modem), so I can't speculate on where the problem lies. But it's clear that somebody needs to erase the disk! Geoff Kuenning geoff@ITcorp.com uunet!desint!geoff [Sounds as if there is a selective three month lag for certain results. OR, could it be that some of the data entry is done by people who write dates such as 7/4/92 to mean 7 April rather than July 4? PGN] ------------------------------ Date: Thu, 13 Aug 92 21:06:02 GMT From: Robert.Allen@eng.sun.com (rja@sun.com) Subject: Fire department to get computer dispatching From a scanner hobbiest newsletter: Hayward [California] Fire department is going to be going to all MDT dispatch in the future. According to Hayward Fire, they will never, ever, have to use voice traffic again. Even the Battalion Chief won't hear the calls since there will be no voice traffic calls. The Chief will have to be near a computer terminal to see the calls. This according to an anonymous source. The risks should be obvious... ------------------------------ Date: Fri, 14 Aug 92 17:22:36 BST From: "D.Langford" Subject: Electronic payment takes 2 weeks! I bank with one of the UK's largest building societies, the Nationwide. I was attracted by their advertising, which offered 'electronic payments' via their cashpoint machines. You notify details of the accounts you'll want to pay, and can then send money to pay the bills from any machine. It looked neat and fast, and I liked the idea of a paperless payment. I'd used it to pay my credit card bills for about a year, when in May I needed to settle a Visa account of 600 pounds or so ($1100). It was twelve days before the due date... Yes, that's right. Although they debited my account immediately, they did not pay the credit card company for two weeks - and I incurred interest charges for not making a payment when I'd made it 2 weeks before. This was NOT an accident, it wasn't a mistake - Nationwide told me that their terms and conditions permitted them to take up to TWO WEEKS to make an ELECTRONIC payment! The small print, which talks of 'working days' rather than 'real' days, bore this out. I'd - foolishly - always assumed payment would be made faster if I used an electronic cashpoint; this was several times slower than a paper transaction! The RISKs are obvious; your money goes, but bills are not paid, and the bank doesn't tell you. I asked for a technical explanation - writing a system which takes two weeks to process a payment sounded tricky to me. The eventual answer was so depressing it had to be true - mag tapes are moved physically around the UK, until they eventually arrive at the right location. ------------------------------ Date: Thu, 13 Aug 92 18:43:37 PDT From: tdzubin@cue.bc.ca (Thomas Dzubin) Subject: Security breach cited as class schedule erased (UBC) (From _The Vancouver Sun_ August 13, 1992. Article by Lynn Moore) University of B.C. student Tamiko Musgrove thought the worst had happened when she checked on her class schedule for September and found she didn't have one. Only two weeks earlier, Musgrove had used UBC's telephone registration system and managed to get all nine courses she needed for her second year of study, including those hard-to-get labs. Someone, Musgrove concluded after a brief investigation, had breached the security of the Telereg system and wiped out her courses. A Telereg hotline operator told her someone using her student number and birth date entered the system one week after she chose her courses and dropped them one by one. And seven of the nine courses she wanted had filled up since then. Although Musgrove was quickly reinstated into her courses after assuring UBC it wasn't she who dropped them, she still wonders if Telereg security is up to snuff. UBC registration coordinator Sham Pendleton says it is and what happened to Musgrove is rare. "One or two students each year" claim their registration files have been tampered with through the Telereg System, Pendleton said. And Martin Ertl of the Alma Mater Society said Telereg security breaches have not been reported to the student association. Students should keep their eight-digit identification number to themselves, Pendleton said. That and their birth date combine to make the Telereg access code. "Chances of someone knowing that combination of numbers is very, very slim," she said. Student identification numbers have to be used on every assignment and lab that is handed in to be marked, countered Musgrove, and it would not difficult for a determined classmate to learn a student's number. Birth dates are a little more difficult to figure out but not impossible, said Musgrove, who believes that a male classmate who was harassing her last year erased her courses. Pendleton said that when cases like Musgrove's arise, students are put back into their original courses and given a new _and fictitious_ birthday. Students can also request that a new birth date be assigned to them if they fear their numbers are known to others, she said. Thomas Dzubin, tdzubin@cue.bc.ca ------------------------------ Date: Wed, 12 Aug 92 23:30:22 PDT From: stevev@miser.uoregon.edu (Steve VanDevender) Subject: A true tale of terror in the making: AUTOPAY I work for a game software company in Eugene, Oregon. It has grown tremendously over the past year as a result of a successful series of products and a merger with another, larger company, going from 35 to 135 employees in about a year. Traditionally, employees have been asked to hand in signed timesheet forms to report vacation and sick leave days taken and information on projects we were working on. During the last pay period the accounting department announced they were going to introduce a program called AUTOPAY that would run on the company-wide LAN to gather this information, and that eventually paper timesheets would be phased out. Someone soon noticed that since you only needed to provide your LAN login name to AUTOPAY for identification, it was possible for anyone to view and modify anyone else's timesheet data. When I brought up my concerns to our chief financial officer while handing in my paper timesheet, I was assured that data from AUTOPAY would be checked before being entered into the payroll system. Later this person also responded to a public e-mail message noting that AUTOPAY had no security, saying that "the only reason someone would modify another person's timesheet would be to be mean or ornery." By now I had become concerned, and wrote an e-mail reply of my own saying that with that kind of attitude and no security, we were just waiting to be stung. I also noted that computer-gathered data of this type is all too often used without any verification. Even with verification it would still be possible to do subtle things like add vacation days a few at a time to someone else's timesheet until they were used up, resulting in at best confusion and at worst loss of pay when the person claimed real vacation time. Since then we've gone through another pay period where password protection was hacked into the program. I promptly requested a password in person (the announcement asked people to send password requests in e-mail!), then discovered on returning to my office that I couldn't get it to work. I then tried something that I hoped wouldn't work, but suspected would -- I grepped the directory tree containing the AUTOPAY files for the first few characters of my password, and found it in one of the files. To my horror this file was publicly readable _and writable_; I could see other people's passwords and modify them if I had wanted to. All six characters (the maximum allowed!) were entered correctly in the password file but if I typed them into the program they would never match, although typing the first five would work. After I complained about the lack of access protection for the password file it was made read-only, which means that although now people can't change other's passwords, they can still find out what they are. Unfortunately the head-in-the-sand approach to security exhibited by the accounting staff and some other participants in a small public e-mail discussion has been rewarded so far because no one has been malicious enough to try screwing up the AUTOPAY data. I have gotten a bit frustrated that the attitude towards security for data that affects everyone's pay is so lax. Another less drastic problem with this AUTOPAY system is that it has an unusually poor user interface, particularly when it comes to saving timesheet data and exiting the program--I usually have to run through it twice to make sure that my data has been entered properly because the method for exiting and the prompts given by the program are obscure. The individual author (whose name appears in a garish and pointless title screen) appears to know as little about user interface design as he does about security. Although nothing has yet gone terribly wrong with AUTOPAY, it has all the ingredients of a minor computer security fiasco in the making. I hope that any sequels I write will be happier ones. ------------------------------ Date: Mon, 10 Aug 92 09:53:41 EDT From: praxsys!moon!rowan@uunet.UU.NET (Brian Holt Hawthorne) Subject: Another saga of long-distance carrier confusion Kraig Meyer reported on being switched from MCI to AT&T without any action on his part. We has something similar happen to us recently, but with an additional twist. In February, MCI called our home and convinced my wife to sign us up for the MCI Friends & Family program, promising her $20 of free long distance and that they would switch us back free to AT&T if we didn't like it. She asked them explicitly how the $20 would be paid ("a credit on your first month's bill") and generally made sure they weren't trying to pull any tricks. I was surprised that several days later, we were on MCI, since I have a password on my New England Telephone account that they assured me would prevent anyone from making any changes without it. Risk number one: a supposedly secure system that allows unauthorized transactions if they come from certain sources that NET trusts, but I don't. In early March, we received an envelope from MCI containing a $5 certificate good only for our March bill, a $5 certificate good only for April and a $10 certificate good only on our May bill. I immediately called MCI and explained that this was unacceptable, and that I wasn't going to do business with a company that lied to us. I told them to switch us back to AT&T free like they had promised. I was told that I would have to call my local phone company for that change, that they could only switch people to MCI, not to other carriers. I asked them how they were going to pay for it, and they said "a credit on your bill". Risk number two: MCI claims to be unable to reverse their transactions. I called NET and they agreed to switch me back to AT&T. Several days later, the 700 number that tells you your LD carrier told me I was on AT&T. When our March bill arrived, it had all LD calls billed by MCI. I called the 700 number, and sure enough, we were back on MCI. NET looked up the change and told me that apparently MCI frequently puts through changes a couple of months in a row, to make sure that people really get switched. They agreed to switch me back to AT&T immediately at no cost. They also told me not to pay for any of the calls billed by MCI after the date was supposed to have been switched to AT&T. Risk number three: Transactions are not verifiable, and are repeated. A month later, our April bill arrived, and all of the LD charges were billed by...you guessed...MCI. We called NET who informed us MCI had pulled the same trick: apparently not many people take them up on their offer to switch back after a month. NET told us not to pay the LD charges (so we ended up getting the free LD service after all :-) and switched us BACK to AT&T. About this time I started getting entreating letters and phone calls from BOTH AT&T and MCI begging me to get back on their service. I was very short with MCI, and had to try very hard to convince that AT&T telemarketers that I really was on AT&T and they weren't going to pick up a commission on me. Risk number four: telemarketing databases that seem out-of-date with customer records. When our May bill arrived, our LD calls were billed by MCI. This time NET assured us that we really were on AT&T and they would look into it. They told us to pay the bill (over my protestations). The 700 number told us we were on AT&T. Our June bill was also billed by MCI, and this time we managed to talk to someone at NET who took an intellectual interest in what was happening, and tracked things down. Apparently, NET had us correctly connected to AT&T's LD network, and everytime we called, the technicians would check the configuration on our number and see that we had already been changed to AT&T and do nothing. The billing system, however, had failed to notify AT&T that we were back on their network, and had also failed to notify MCI that we were off of their network. Moreover, NET's billing system actually thought we were on MCI. Our July bill correctly showed us on AT&T for the latter part of the month. Question: does this mean that NET generates the billing data for LD calls dialed, rather than the company that is actually carrying those calls?? rowan@praxsys.com +1.617.255.9600x132 ------------------------------ Date: Wed, 12 Aug 1992 15:39 EST From: HORN%athena@leia.polaroid.com Subject: Intolerance and human differences System designers will need much more understanding of diversity (not the PC kind) as computer based systems go into widespread use. The somewhat intolerant comments regarding user inability to understand obvious systems are indications of design flaws. There are some people who are stupid, and others who have learned to use feigned stupidity as a negotiating mechanism, but most of these problems are related to different personality traits. As a basic, I recommend that anyone working with such systems really learn about how different people can be. The Hermann Brain dominance profile (left-right brain) and the Myers-Briggs profiles are two important ways to discuss some aspects of differences. There are also many other more discipline specific analyses of such things as human behavior under stress, etc. Reading the literature is a start, but the organized training courses are very important. Take one if possible. You may learn a lot about how differently react and how differently they want to be treated. One of the classic examples is between the analytic left-brained engineer who insisted on a detailed theoretical training method. His customers were physically oriented lower-left brain sensor types. They wanted someone to take them to the machine, literally hold their hands, have them push the buttons, and directly experience the machine. The engineer felt that this would be a very demeaning experience, while they thought the lecturing was worthless and insulting. A simple personality difference. Also, don't forget the impact of age, illness, stress, and the like on behavior. Now that more of us have grey hairs you see more computers that are usable by bifocal wearers. Rob Horn [For more on the left-brain / right-brain differentiation, see my chapter, Psychosocial Implications of Computer Software Development and Use: Zen and the Art of Computing, in Theory and Practice of Software Technology, edited by Ferrari, Bolognani, and Goguen, North-Holland, pp. 221-232, 1983. PGN] ------------------------------ Date: Wed, 12 Aug 92 15:29:49 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Re: Bug or Fraud (RISKS-13.72) > [Once again this brings up the concern of people thinking that anything that > happens in a computer system that wasn't expected by the end users is a bug. > I'd like a job where I got paid $7000 to remove a "conditional statement." Back before the flood there used to be a joke about the computer repairman (person?) that , when called to fix a problem, disappeared inside the computer with a little silver hammer. Shortly there can a musical *tonk* from inside and all of the lights began to blink. Emerging, the repairman presented the owner with a bill for US$ 25000.25. The owner protested and requested an itemized bill. The repairman complied with the following: Striking computer: US$ .25 Knowing where to strike computer: US$ 25000.00 I have yet to have anyone complain about my prices to cure a virus. Padgett ------------------------------ Date: Wed, 12 Aug 92 16:27:42 EDT From: KARENF@acmvm.bitnet Subject: Re: Voting (Mercuri, RISKS-13.72) Rebecca Mercuri has given the wrong address for the hearing on voting machines that is to take place on Aug. 20. The correct address is: 42 Broadway, which is downtown near Battery Park City. This hearing is for the press and is a contract briefing. The second hearing, on Sept. 10, is open to the public. ------------------------------ Date: Fri, 14 Aug 92 11:39:27 -0700 From: Teresa Lunt Subject: 1993 Research in Security & Privacy, Call for Papers CALL FOR PAPERS 1993 IEEE Symposium on May 24-26, 1993 Research in Security and Privacy Oakland, California sponsored by IEEE Computer Society Technical Committee on Security and Privacy in cooperation with The International Association for Cryptologic Research (IACR) The purpose of this symposium is to bring together researchers and developers who work on secure computer systems. The symposium will address advances in the theory, design, implementation, evaluation, and application of secure computer systems. Papers and panel session proposals are solicited in the following areas: Secure Systems Privacy Issues Information Flow Network Security Formal Models Viruses and Worms Database Security Access Controls Security Verification Authentication Data Integrity Auditing and INSTRUCTIONS TO AUTHORS: Send six copies of your paper and/or panel session proposal to Richard Kemmerer, Program Co-Chair, at the address given below. Put names and affiliations of authors on a separate cover page only, as a ``blind'' refereeing process is used. Abstracts, electronic submissions, late submissions, and papers that cannot be published in the proceedings will not be accepted. Papers must be received by November 15, 1992 and must not exceed 7500 words; papers that exceed this length will be rejected without review. Authors will be required to certify prior to December 25, 1992 that any and all necessary clearances for publication have been obtained. Authors will be notified of acceptance by February 1, 1993. Camera-ready copies are due not later than March 15, 1993. The Symposium will also include informal poster sessions. Send one copy of your poster session paper to Teresa Lunt, at the address given below, by January 31, 1993. Electronic submission of the latex source for poster session papers is strongly encouraged. Poster session authors must send a certification with their submittal that any and all necessary clearances for publication have been obtained. PROGRAM COMMITTEE Tom Berson Paul Karger Jon Millen Anagram Laboratories OSF MITRE Deborah Cooper Tanya Korelsky Jeff Picciotto Paramax Systems Corporation ORA MITRE George Dinolt Sue Landauer Phillip Porras Loral Labs TIS Aerospace Virgil Gligor Teresa Lunt Ravi Sandhu University of Maryland SRI George Mason Univ. Deborah Hamilton Doug McIlroy Marv Schaefer Hewlett-Packard Laboratories AT\&T Bell Labs CTA Jeremy Jacob John McLean Brian Snow Oxford University NRL NSA Sushil Jajodia Catherine Meadows Yacov Yacobi George Mason University NRL Bellcore For further information concerning the symposium, contact: Teresa Lunt, General Chair Cristi E. Garvey, Vice Chair SRI International, EL245 TRW, MS R2-2104 333 Ravenswood Avenue One Space Park Menlo Park, CA 94025 Redondo Beach, CA 90278 Tel: (415)859-6106 Tel: (310)812-0566 FAX: (415)859-2844 FAX: (310)812-7147 lunt@csl.sri.com Richard Kemmerer, Program Co-Chair John Rushby, Program Co-Chair Computer Science Department SRI International, EL254 University of California 333 Ravenswood Avenue Santa Barbara, CA 93106 Menlo Park, CA 94025 Tel: (805)893-4232 Tel: (415)859-5456 FAX: (805)893-8553 FAX: (415)859-2844 kemm@cs.ucsb.edu rushby@csl.sri.com Jeremy Jacob, European Contact Oxford Univ. Computing Laboratory 11 Keble Road Oxford, England OX1 3QD Tel: +44 865 272562 FAX: +44 865 273839 jeremy.jacob@prg.oxford.ac.uk ------------------------------ End of RISKS-FORUM Digest 13.73 ************************