Subject: RISKS DIGEST 16.09 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Weds 25 May 1994 Volume 16 : Issue 09 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: Call Your OPERATER! (Martin Minow) Bank goof creates millionaire (Andy Fuller) Two risk-related articles from Edupage 5/24/94 (Terry Alford) Dell monitors too hot to handle (Mich Kabay) Canada, The Internet, and the Homolka trial [anonymous] Risks of setting up awful puns (Aaron Barnhart) Re: China Airlines A300 Crash (John Yesberg) Re: Computer Crime on Wall Street (Mike Rosenberg, Marc Horowitz) Cable / Closed Circuit TV Info Display Risks and 911 (Bob Richardson) Re: Logging on as root is easy! (Dan Franklin, Eddy) Re: UK ATM Spoof (Gary Preckshot) Privacy Digests (reminder) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Tue, 24 May 94 13:08:26 -0700 From: Martin Minow Subject: Call Your OPERATER! From rec.humor.funny, but it belongs in Risks, too... (True) In an effort to snag more long distance telephone calls (charged to a credit card or a third number), AT&T reserved the toll-free number 1-800-OPERATOR. Not to be outdone, and perhaps knowing the public better, MCI reserved the number 1-800-OPERATER and has been scooping up calls intended for its arch-rival. Walter C. Daugherity Texas A&M University daugher@cs.tamu.edu [So now we need legislation on Truth in Mispelings and Mistouchtonings? PGN] ------------------------------ Date: Wed, 25 May 94 08:57:43 EDT From: acfa@callisto.eci-esyst.com (Andy Fuller) Subject: Bank goof creates millionaire >From the Tampa Tribune, Wednesday May 25, 1994 Howard Jenkins was a multimillionaire for about a half a day. About a week ago he lost his checkbook and called his bank to have a hold put on his account. "When he went to make a deposit Fiday morning, he was told to check the automated teller machine outside to make sure the account was working." He made a small withdrawal and the receipt told him his account balance was $889437.93. He went home and called the bank's automated telephone account inquiry system, and was informed that his balance was now more than $88 million. He went back to the bank and asked a teller for his balance, and was given an 8 digit number. She asked if he had received "an inheritance or something". He withdrew $4 million in cashier's checks and cash, requiring a bank manager's signature on each check, and they "didn't bat an eye". He returned later that day, accompanied by his lawyer, and returned the money. The bank attributes the erroneous balance to a computer error, probably linked to the hold transaction. Several things stand out to me: 1) He was told to check an ATM to see if his account was working. Whoever told him this should have been able to check directly using the bank's terminal. The bank (and reasonably so) puts a great deal of trust in the computer. 2) The balance shown on the ATM receipt was different than that given him by the automated telephone information system and the teller. Is this a user interface problem, or something more involved? 3) The computer error is likely to be the fault of inadequate testing or a user interface inadequacy (calling up a deposit transaction instead of an account hold transaction). Both topics have been discussed at length in this forum. 4) Nobody questioned this withdrawal or the large deposit. The teller who checked his balance was the only one mentioned in the story that even noticed his windfall. Proper software and human procedural checks would have caught this error. If a pre-computer bank teller had been handed a deposit of this size, the bank manager would have been notified. When the withdrawal was made, the manager would have known about the deposit and been confident that the request was legitimate. Are similar human checks and balances included in modern banking computers? Andrew C. Fuller, E-Systems, ECI Division, St. Petersburg, FL acfa@callisto.eci-esyst.com (813) 381-2000 x3194 72417.612@CompuServe.com ------------------------------ Date: 25 May 1994 15:51:31 GMT From: talford@mitre.org (Terry Alford) Subject: two risk-related articles from Edupage 5/24/94 ATTENTION LIBRARIANS -- FATAL BOOKSHELVES A union claims that Library of Congress employees are exposed to potentially fatal crushing hazards caused by sliding mechanical bookshelves, and asserts in a lawsuit that the bookshelves have occasionally started up unexpectedly, undeterred by safety sensors. The government insists the bookshelves have experienced "only three or four failures," none of which resulted in employee injury. (BNA Occupational Safety & Health Reporter 5/18/94 p.1787) RISK-TAKING Information technology visionary George Gilder calls Michael Milken a risk-taker, "who was willing to plunge $2 billion into a company with $100 million in assets and $200 million in revenues. He had a great eye and really did it brilliantly. The people who prosecuted him did not understand what he was doing at all. It was mysterious to them and he was making too much money to be legal [laughs]." (Upside, June 94, p.55) ------------------------------ Date: 25 May 94 07:45:30 EDT From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@CompuServe.COM> Subject: Dell monitors too hot to handle Dell has issued a recall of 63,000 monitors after receiving 32 reports of overheating or fires starting. The problem monitors bear the number DL-1460NI on the back. Owners of the monitors with that number should call 1-800-913-3355 to set up free pickup and repair. Arrangements also can be made through Dell forums on CompuServe and America Online or by dialing Dell Computer Corp.'s bulletin board at 512-728-3589. Dell will ship packing materials to owners of the monitors, who then will send them by Airborne Express to the company for repair within three to five working days. Michel E. Kabay, Ph.D. / Dir Education / Natl Computer Security Assn [Watch out for The Foamer in the Dell. PGN] ------------------------------ Date: Fri, 20 May 1994 22:00:16 -0400 (EDT) From: [anonymous] Subject: Canada, The Internet, and the Homolka trial As reported in Toronto's EYE Newspaper [eye@io.org] (similar to New York's Village Voice) dated 19 May 1994: The London Ontario detachment of the Ontario Provincial Police have begun a campaign of harassment against local University Internet users who are attempting to use the net to gain information on the Karla Homolka trial. A University of Western Ontario (London) student had his Internet account frozen by the university computer staff when requested by the Police. The reason for this lay in the student's name being left on the text of a FAQ of the details of the trial. Another student in Toronto had Faxed this material (which had been Emailed to him) to the Toronto media, and the offices of the Premier of Ontario and the Attorney-General as an act of provocation against the Ban (his regular anonymous forwarding site was not working). The problem was that he had forgotten to remove the other persons name and account number from the original E-mail that was sent out. The police action against the student's account was done without a warrant, and also involved the questioning of the student at the local police station. Likewise the students home computer was searched without a warrant by using the threat of criminal charges. The Student's computer account was reinstated, but he was required to turn over all incoming Email to the police under the threat of criminal charges if he did not cooperate. A list of about 50 people who had received Homolka FAQ's were passed on to the police. The important part of this entire situation is that no one, including the Ontario Attorney-General office is certain that the ban applies to the Internet. The ban states that details of the trial cannot be published in the print media but there is no ban on possession of information. There is no mention of the Internet, nor the use of computer systems in the ban. Further, there is no official investigation of the Internet on the part of the Ontario Provincial Police, except for this one detachment. One of the questions raised is the ethics of the University of Western Ontario's computer department. Their cooperation with the police was based on a fear of having their computer equipment confiscated (similar to the case of the University of Cambridge in England). If the situation had taken place with in the library system of the university, it would not have been tolerated by the library staff due to the long held tradition in that profession of the defence of freedom of speech. If the Internet is to remain open this set of values will have to become part of the professional commitment of the MIS staff of universities as well. ------------------------------ Date: Wed, 18 May 94 13:12 CDT From: barnhart@mcs.com (Aaron Barnhart) Subject: Risks of setting up awful puns If Schindler Elevator gets a black eye as a result of the Toronto controversy, at least they have an ace in the hole. They can just change their name to Schindler's Lifts. [Remarkably, this was also suggested in various contexts by Mark Bartelt , roedder@netcom.com (Spencer Roedder), jcook@epoch.com (Jim Cook), davis@ilog.ilog.fr (Harley Davis). I am absolutely delighted that I am not carrying the entire burden of elevating the level of discourse. PGN] ------------------------------ Date: Fri, 20 May 1994 10:14:31 --9-30 From: jdy@itd0.dsto.gov.au (John Yesberg) Subject: Re: China Airlines A300 Crash (Stalzer, RISKS-16.05) > ... This is a serious kind of failure, if an automatic system designed to > prevent a problem makes it worse, it should do nothing at all! This is probably true for conventional aircraft. For fly-by-wire aircraft, however, the computer systems can never "do nothing". I understand that the main computer system (in, e.g. A320) has six (approx) flight modes, and that it responds slightly differently to manual inputs depending on which mode it is in. Pilots are required to understand the differences between the modes. I imagine that, in non-emergency situations, the pilot would not need to worry about these differences: the aircraft would respond "intuitively" to command inputs. In very unusual situations, the required inputs to the machine may be counterintuitive. This can probably be overcome in two ways: (i) Give the flight computer more modes to be in, so that it could behave "properly" or "intuitively" in the various situations. (ii) Give the pilots enough simulator training so that the intuition takes into account the mode that the aircraft is in. In critical manoevres, like landing and go-around, pilot confusion is to be avoided at all costs. John Yesberg (jdy@itd.dsto.gov.au) ------------------------------ Date: Wed, 18 May 1994 14:48:51 -0400 From: mkr@fid.morgan.com (Mike Rosenberg) Subject: Re: Computer Crime on Wall Street (RISKS-16.08) re: joe jett's alleded fraud: > It seems to me that this manipulation could only have been accomplished > through extensive computer manipulation by Jett and possibly by others. I believe this is incorrect. It probably happened because the accounting system did not handle the trade properly. i would guess that no outright manipulation of data or code was necessary. also, his gross strips position was probably growing larger and larger as time went on. this should have raised some red flags. mike rosenberg mkr@fid.morgan.com ------------------------------ Date: Sat, 21 May 94 16:45:30 EDT From: Marc Horowitz Subject: Re: Computer Crime on Wall Street >> 76 total accidents, 3513 fatalities. (How do you have *1* mid-air? >> They must be counting accidents, not aircraft involved.) Although you are probably right, this is not impossible. Several months ago, several people were killed in a small airplane over Massachusetts when it collided with a skydiver (who survived with a broken leg). One plane, midair collision. Marc ------------------------------ Date: Tue, 17 May 1994 14:41:55 -0700 (PDT) From: Bob Richardson Subject: Cable / Closed Circuit TV Info Display Risks and 911 John Gersh writes regarding an information channel display that showed an incorrect floor number during a fire alarm. Other contributors have written regarding cable-TV channels reporting "Software Failure" for hours or days on-end. As a manufacturer of such equipment for the Cable Television Industry, I hope I can provide some insight. A very common computer used in systems for broadcast applications is the Amiga. This is because of it's relatively low cost for this application, as well as the fact that it generates clean video at standard NTSC/PAL rates. On older versions of the operating system, if a program crashed severely (the Amiga OS does not provide memory protection or resource tracking, yet is fully multitasking), a flashing red "guru" message would appear, requiring an acknowledgement from the user to reboot the machine. Unfortunately, due to the nature of cable transmission, these machines are usually located in very remote sites. Of course, many cable companies are too lax in even monitoring for crashed displays. Under newer versions of the OS, this problem is solved in that after a timeout (usually 30 seconds), these requesters go away and the reboot proceeds normally. Since the Amiga isn't a very widely supported or understood platform, most of these cable operators do not upgrade to newer OS's, and some machines cannot legally be upgraded (physically they can, but since ROMs are not available from Amiga, you have to make a copy of the OS and install it on the hard drive of the machine, which is technically illegal.) Our solution for our customers was to create a "watchdog" program that would reboot the machine in the event that our main task failed in any way. We then discovered something interesting: Most of the crashes occurring were not a result of our program (or our competitors), but of line spikes and brownouts trashing the machine. We now insist that our customers at least purchase a line conditioner or a UPS as a result. One contributor to this list asked what cable companies will do now that Commodore is out of business, regarding replacement parts. For quite some time now, it has been quite difficult to obtain support from Commodore anyway, so my company as well as others have been acquiring spare parts from used machines. One should note, however, that Commodore's death is being exaggerated on the net, and that there is indeed a buyer, but specifics have not been made public at this time. An interesting incident reported to me by a customer: During the March, 1993 earthquake in Klamath Falls, Oregon, cable service was not interrupted. The 911 emergency center was being swamped with calls, many of them for non-life-threatening situations. They called the cable company and requested that a message be posted on the air to tell people with minor emergencies to use an alternate number to reach the 911 center. Unfortunately, the number provided to the cable company was incorrect, and was for the main 911 center's outgoing lines (non-emergency). The administrative office was then swamped with calls, and could not obtain and outgoing line to call the cable company and tell them to change the number. As a result, the 911 center wants modem access to our software so that they can alter displays themselves. (I don't see how that could have prevented this particular situation.) We are currently evaluating how best to achieve this. There are several liability issues that open up when you allow third parties access to your airwaves. Not to mention the fact that while our software is password-protected at this time, anyone with a password also has access to the billing and setup functions. We now have to segment our security further so that outsiders can not mess with private or operation-critical information. Bob Richardson, Product Development Supervisor, Sound Concepts / MagicBox (503) 752-5542 bob@csos.orst.edu ------------------------------ Date: Wed, 18 May 94 14:40:16 -0400 From: dan@copernicus.bbn.com (Dan Franklin) Subject: Re: Logging on as root is easy! I am somewhat skeptical of the apparent failure in security described by in RISKS-16.08. I have been in the situation eddy describes many times, and the "NFS server ..." message always appeared AFTER I typed the password, if the password prompt appeared at all (sometimes it did not). In fact since the code in question queries you for the password and then waits to collect it, it is difficult to imagine what it could be doing in between those two operations that would involve NFS access. Also, if the included transcript is literally accurate eddy@eddy> su Password: NFS server mbfs.bio not responding still trying then, since the "Password:" prompt does not end in a newline, eddy must have at least typed a newline before getting the "NFS server ..." message, and the possibility that the entire password was typed before that newline cannot be ignored; after all, until that much-loathed message appeared, eddy was presumably expecting to "su" as usual so as to be able to unmount the soon-to-disappear filesystems. Of course, this is computer software, so I'm not saying it's impossible! But I'd like to see it duplicated before I believe it. Unfortunately eddy's message did not give the UNIX version involved in this scenario, so I cannot do it here. The _real_ risk is that once you've entered the password, you've got a nascent superuser shell that anyone can type at once the server comes back up. Yet one hardly wants to stick around and guard it... In a university environment, this seems risky indeed. Dan Franklin ------------------------------ Date: Thu, 19 May 94 13:35:12 BST From: eddy Subject: Re: Logging on as root is easy! (Franklin, RISKS-16.09) > The _real_ risk ... superuser shell that anyone ... In a university Interesting point. The risks of leaving the terminal unattended aren't the usual ones for a university; this is a lockable office which I share with folk that I trust not to abuse a root shell and who would have locked the office if they'd gone out in my absence -- ie, we don't get random undergraduates wondering in in our absence -- but I hadn't typed the password, so this wouldn't have been a problem (except that I'd feel shy of letting random UG's get at _my_ account, of course; which is one of our reasons for locking the door). > ... if ... literally accurate ... possibility ... cannot be ignored ... The transcript is literally accurate; I copied the text from the command-tool to the mail window by raw cut-and-paste. I had not typed anything at the password prompt when the NFS server message came up; what I did type (a tenth of a second later -- thus before I'd noticed the message) was only the first three letters of the password and I soon removed those with ^U because they were being echoed ! I followed that with a return and several ^Cs (a strategy which doesn't trick su normally -- the first experiment I tried on discovering what had happened) so that nothing should sensibly have been able to go wrong. > ... after all ... eddy was ... expecting to "su" [so as] to unmount ... Dead right there; but, as I say, I noticed what was happening _before_ I'd typed the whole password. > I am somewhat skeptical ... And all Dan's reasons for skepticism (which I respect as such given that he only has the information third hand) are exactly the reasons for my horror upon discovering that I'd managed to become root without having typed the magic words. > I'd like to see it duplicated before I believe it. ... UNIX version ... Yes, duplication under controlled conditions is the only way to confirm. The machine I'm running on is a Sun SPARCclassic running SunOS 4.1.3. Eddy [A similar correspondence occurred between Caveh.Jalali@eng.sun.com (Caveh Jalali) and Eddy, but it is not included here because of the overlap. PGN] ------------------------------ Date: 19 May 1994 11:22:34 U From: "Gary Preckshot" Subject: Re: UK ATM Spoof Subject: Time:10:57 AM OFFICE MEMO Re: UK ATM Spoof Date:5/19/94 Date: 19 May 1994 From: gary_preckshot@lccmail.ocf.llnl.gov Subject: Re: UK ATM Spoof >.....copies the one-time response from the card's LCD into the keypad). >The ATM or banking network validates the response and continues the >transactions. Results of setting up a spoof on a stolen ATM: zero.] Surely this is an example of the risk of becoming too enamoured of your own ideas. Regardless of the elaborate scheme proposed, all the fake ATM machine needs to do is look like it is responding correctly, and the user will enter his or her PIN. The issue isn't validation, it's getting information out of the user by deceit, and anything that fools the user will work. Only other information, not available easily either to the user or to the credit card thief, will fill this security hole. Instead, there probably has to be a piece of information possessed by the "smart" card which cannot be obtained without correct authorization. Only an ATM hooked up correctly to the bank could obtain the passwords to unlock the card, which then provides some internal code unrelated either to the PIN or to the card account number. However, this raises other issues, such as how could you use such a card for phone charges? Or how could charges be validated at the point of sale? Somehow the same challenge/response would have to occur at Macy's as it does at the ATM, or what good would the internal validation code do? Thus, the challenge would be available for analysis on the general telecommunications system, and a significant communications burden would be placed on the system due to wide spread usage. Somehow, I don't think it's quite so simple. Gary DRTOPE@delphi.com ------------------------------ Date: 18 May 94 Subject: Privacy Digests From: RISKS-request@csl.sri.com Periodically I will remind you of TWO useful digests related to privacy, both of which are siphoning off some of the material that would otherwise appear in RISKS, but which should be read by those of you vitally interested in privacy problems. RISKS will continue to carry general discussions in which risks to privacy are a concern. * The PRIVACY Forum Digest (PFD) is run by Lauren Weinstein. He manages it as a rather selectively moderated digest, somewhat akin to RISKS; it spans the full range of both technological and non-technological privacy-related issues (with an emphasis on the former). For information regarding the PRIVACY Forum, please send the exact line: information privacy as the BODY of a message to "privacy-request@vortex.com"; you will receive a response from an automated listserv system. To submit contributions, send to "privacy@vortex.com". * The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is run by Leonard P. Levine. It is gatewayed to the USENET newsgroup comp.society.privacy. It is a relatively open (i.e., less tightly moderated) forum, and was established to provide a forum for discussion on the effect of technology on privacy. All too often technology is way ahead of the law and society as it presents us with new devices and applications. Technology can enhance and detract from privacy. Submissions should go to comp-privacy@uwm.edu and administrative requests to comp-privacy-request@uwm.edu. There is clearly much potential for overlap between the two digests, although contributions tend not to appear in both places. If you are very short of time and can scan only one, you might want to try the former. If you are interested in ongoing detailed discussions, try the latter. Otherwise, it may well be appropriate for you to read both, depending on the strength of your interests and time available. PGN ------------------------------ Date: 17 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. 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.09 ************************