Subject: RISKS DIGEST 12.53 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 21 October 1991 Volume 12 : Issue 53 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Inappropriate ATM error codes (Sean Eric Fagan) Blood Donor Cards (Robert E. Van Cleef) RISKs of new E911 system (Paul Robichaux) Unusual risks of frequent flying (Rob Aitken) Review of THE GLASS COCKPIT (Robert Dorsett) Yet another journalistic cock-up (cracker activity) (Simon E Spero) Assurance of High-Integrity Software - Report (Rick Kuhn) Video stores losing videos... (Chris A. Anderson) Re: Blockbuster (Brian Boutel, Matt Crawford, Kevin Hughes, Patricia Shanahan) 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. REQUESTS please to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 12, 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. 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: Sun, 20 Oct 91 22:22:17 PDT From: Sean Eric Fagan Subject: Inappropriate error codes After a longish day yesterday, I was on my way home, and decided to pick up some stuff for both dinner and breakfast at Lucky's. For those not acquainted with it, Lucky's allows customers to use an ATM card to pay for the purchases (and they pay for the transaction fee, which makes it attractive to me). This was at about 3:30AM or so. After getting everything I wanted, and standing at the register and shouting for someone to come take my money, I tried to pay with my ATM. Slid it through the machine, entered my PIN, said I wanted $20 extra in cash, approved it, etc. Wait. Error code 60. No approval. I go, "Huh?!" Cashier takes out a little card, and shows me where it says "Error Code 60" is "incorrect PIN." So I tried again, making sure I had the right card, making sure I had the right PIN. Same result. I tried it with a smaller amount. Same thing. Paid with my reserve cash, and proceeded to drive down to a branch of my bank so I could make sure I hadn't gone broke. Well, it turns out that it was the one hour a week when Bank of America takes down their network for (I assume) routine maintainance. Normally, when this happens, and I'm at a bank ATM (my own or a different bank), it says that it is unable to conduct the transaction, which is a different message than an incorrect PIN entry. If Lucky's had had a correct error code (ETIMEDOUT would do 8-)), I would have driven home a bit slower, and not had the near-corronary when I passed the cop... ------------------------------ Date: Thu, 17 Oct 91 11:32:51 -0700 From: vancleef@nas.nasa.gov (Robert E. Van Cleef) Subject: Blood Donor Cards Last June I donated blood at a local blood drive. I was told that I would receive my blood donor's card in the mail in a couple of weeks. I just got off the phone with a representative of the local Red Cross organization. A new computer system was installed last January, and the "card printing" portion of the software "didn't work out". I can expect to receive my card in two to three months.... Bob Van Cleef, NASA Ames Research Center (415) 604-4366 ------------------------------ Date: Thu, 17 Oct 1991 13:00:34 GMT From: robichau@freedom.msfc.nasa.gov (Paul Robichaux) Subject: RISKs of new E911 system [_The Huntsville Times_, Huntsville AL, 1991Oct15. My comments in braces.] "Enhanced 911 put on hold until early '92" [Julie T. Schultz, _Times_ Staff Writer] Enhanced 911 officials [how are they enhanced?] Monday announced yet another delay in the operations of the new emergency communications system. Emergency Communications Board Chairman Richard Holloway said that the system will be operational sometime in early 1992 rather than at the end of this month or early November. The agencies that will use the system, Huntsville's police and fire departments, the city's ambulance service, and the county Sheriff's Department have requested a delay, Holloway said today. The agencies feel their dispatchers and other workers need more training on the system, he said. [Concerns of this new system's impact on personnel, staffing levels, etc. deleted.] If agencies had to switch to the new system during the next few weeks, [E911 Committee Chairman Philip] Arnold said workers would have to run a "parallel operation to the computer-aided dispatch system." "Anytime you convert over to something new you continue the current process for awhile and then compare them for glitches," he said. "We would have to staff the old and new systems simultaneously if we started" late this month or early November. Several months will give workers time to train on and test the system at the same time, he said. Despite the fact that Mr. Arnold appears to be aware of some of the RISKs of abruptly switching over to a new system, the article seems to say that Huntsville's E911 will abruptly replace the current system *with no parallel system in operation at startup.* The RISKs here should be evident to readers of the Digest. -Paul Robichaux ------------------------------ Date: Thu, 17 Oct 91 13:02:36 pdt From: Rob Aitken Subject: Unusual risks of frequent flying Recently, when I opened the monthly statement for a frequent flyer program to which I belong, I discovered that someone else's statement had been stuffed into the envelope with mine. I was thus able to see which flights this person had taken that month. A potentially RISKier piece of information I was also able to obtain, however, was the amount of her airline Mastercard bill, which had been credited as miles to her account. I think the biggest risk of the entire episode, though, comes from the sorting technique used to print the mileage statements: In order to get discount mail rates, the airline presorts the statements by 9 digit zip code. As a result, the person whose report I received lives in my neighborhood. While I can't speak for the person involved, if information about me was to be accidentally released, I would prefer that it be to someone with a similarly spelled name in another city or state (as would occur in an alphabetic sort) than to someone down the street (although it was admittedly easier in this case to send the report to the correct destination). Rob Aitken, HP Santa Clara aitken@dtl.hp.com ------------------------------ Date: Sun, 20 Oct 91 09:04:32 CDT From: rdd@cactus.org (Robert Dorsett) Subject: REVIEW of THE GLASS COCKPIT [ This may be of interest to RISKS readers. The tape described would definitely go a long way toward clearing up a lot of misconceptions which keep on popping up. ] THE GLASS COCKPIT. 80 min. $49 + $3 S&H. Aviation & Space Videos, 316 N. 12th St., Sacramento, CA 95814. 800-348-9933. "The Glass Cockpit" is an introduction to the Flight Management System (FMS) concept, using the 757/767 cockpit environment as a practical example. FMS's comprise the backbone of the operation of modern jet aircraft, and were introduced beginning in the early 1980's. The setting is that of an operational United Airlines 767 flight simulator. The tape follows this approximate format: - Introduction to displays: - electronic attitude director indicator (EADI). - Nav display (EHSI). - upper Engine Indication and Crew Alerting System (EICAS). - lower EICAS. - Intro to autopilot mode control panel. - Detailed coverage of the Control Data Unit (longest segment). The tape finishes with an event-oriented flight from LAX to SFO, including a demonstration of how to use the FMS to accomodate two changed clearances: one at departure, and one inbound. It finishes with a CAT IIIA landing. It's exclusively demonstrated on the instruments: the only "out the window" view is when the airplane crosses decision height (and even that's overlayed on what we'd be seeing on the EADI). The narrator/emcee sits in the captain's seat, showing us around the cockpit and systems. A split-screen format is frequently used, as is a screen pointer. The coordination of the presentation of systems is good: changes made through the CDU or autopilot mode panel are shown on the EADI or EHSI. Overall, the quality of the tape comes across as somewhat amateurish: there's a lot of background noise from the simulator, for instance, so the narrator has to speak up, which in turn sounds kind of stiltish--rather like those 50's and 60's-era documentaries we all had to sit through in grade school. :-) A major failing is that we *see* changes to the CDU through the *right* CDU. However, the majority of the changes are *made* through the *left* CDU. Thus, we don't see EXACTLY how items are "put into the scratchpad" or assigned to other items (an operation which, surprisingly, looks a lot like Mac- style Cut & Paste). The narration usually goes "Now, we'll put line L# in the scratchpad, then put it in over line R#..." But we don't really see the mechanics involved. The strong point is the quality of the amount of data on the subject matter itself: it's an excellent introduction to the systems. The narrator is clearly a proponent of FMS systems, but one has got to wonder whether his basic points (smarter, more economical, faster) are presented effectively: there's a LOT of heads-down workload in that simple run from LAX from SFO. It's an unrealistic example for a 767, but we know that 737s (and MD-80s, and, eventually, A320s) have to do this all the time. And the CDU comes across as the User Interface from Hell: slow, and with a hodgepodge of text sizes and styles. It's very difficult to tell what the "active" fields are, and what the labels are (it's bad enough that I started to suspect parallax between the selector buttons and fields from the camera angle, but when we actually see what the fingers are doing, it turns out that it really is that bad). Even the narrator gets "lost" a couple of times. But I digress. Again. :-) Overall, the tape's worth having, for those interested in glass cockpits. Glossary: CAT IIIA An ILS landing, with no decision height, and RVR of 700'. CDU Control Data Unit. Primitive, keyboard-driven interface between pilot & FMC. EADI Electronic Attitude Director Indicator. EHSI Electronic Horizontal Situation Indicator. Shows A/C plan view relative to navaids and waypoints. EICAS Engine Indication and Crew Alerting System. For engine and systems monitoring, systems messages, and checklists Replaces F/E and traditional center instruments. F/E Flight Engineer. FMC Flight Management Computer. Central aspect of the FMS. FMS Flight Management System. The sum total: FMC, CDU, IRS, displays, etc. ILS Instrument Landing System. A way of landing airplanes in low visibility. IRS Inertial Reference System. Black box that tells pilots where the plane is. LAX Los Angeles International Airport. RVR Runway Visual Range. Visibility down the runway, measured by mechanical instruments. SFO San Francisco International Airport Disclaimer: I have no personal or business connection whatsoever with Aviation & Space Videos, Inc, or any of its products. ------------------------------ Date: Fri, 18 Oct 91 00:51:05 -0200 From: ses@ccgr.technion.ac.il (Simon E Spero) Subject: Yet another journalistic cock-up There's an double page spread in "Ha'aretz" today (17/10/91) based on an interview with an ex-cracker who for the past four years has run a computer security firm. When he was a teenager, he took his revenge on a hated maths teacher by breaking into computer of the American bureau of an Israeli paper, and inserting a false story reporting on how the said teacher had been arrested on a drugs charge. The story was duly transmitted back to Israel, and printed in the next edition. [See Risks:???? Internet link's down, and I can't reach the WAIS risks archive (meta-risk?)] Now it seems he's found an even easier way to get bogus articles into a newspaper - just talk to a journalist. He decided to demonstrate his prowess to the journalist by breaking in to one our VM machine. The account he chose was that of the head of the Computer Centre advisory centre. The owner of this account isn't the most technical of people- her passwords are chosen from a quite small, related set of words. Four years ago, he broke into her account - he claims that by chance, her password happened to be the same at the time of the demonstration. I have no evidence to contradict this,although it seems more likely that he guessed her current password using the information he had from the old one. Up until this point, the article is mostly accurate - but now, the bogometer needle starts going off the scale. ------ Claim #1: He claimed that the account be broke was privileged. Lie: The account was an ordinary user account, with *no* system priviledges. ------ Claim #2: He stated that the account name had a prefix which indicated that the account was special, and that this showed how naive the system managers were. Lie: See #1. Even if his claim were valid, the risk is exactly the same as being able to cat /etc/groups on a UN*X box to see who's in wheel. ------ Claim #3: He claimed that from this account he count enter the accounts of all employees and researchers, and change their files. Lie: See #1. ------ Claim #4: He claimed that from this account, he could change information on the administration computer. He offered to wager the journalist that he could make him a Technion employee, give him a professorship, pay him a bonus, and then erase everything without leaving a trace. Lie: See #1. Also, the administration computer is completely separate from VM machine. The only connection is that both have the same three letters written on them. This machine can only be connected to from special terminals. ------ Claim #5: He claimed he could shutdown the computer and destroy all the data on the machine. Lie: See #1. ------ Claim #6: He claimed he could destroy all the back-ups. Lie: Maybe if he stuck magnets on a few SCUD-C's and lobbed them at the various tape archives. It's a lot harder to spoof a human being, especially when you're a 24 year old male, and the spoofee is a 50ish woman. He also makes other false statements, including a claim that before he hired a salesman, he never approached anyone to offer his services. Four years ago, he came to the Technion, and offered his services to a member of computer centre staff. This offer was not taken up. What made things worse was the slightly inept performance of the Technion spokesbeing. After a quick telephone call to the head of the centre, who gave him the usual spiel about how theoretically, all systems are breakable if you can connect to them, and that without more details, he couldn't say what the cracker could or could not do. The spokesbeing took this message, and then garbled so completely that he acknowledged almost all the allegations in the article. The risks? 1: Technologicaly naive journalists can easily be taken for a ride by experts with something to sell. The best computer reports in the press come from papers like "{\em The} {\sf Guardian}", where the computer editor has a technical background as well as a journalistic one. 2: Technologicaly naive spokebeings can be taken for a ride by journalists with something to sell. Maybe Spaf or Cliff Stoll could give pointers on how to handle the media when statements can only come from the talking suits. 3: The boy who called "wolf!" effect. We know that our computers aren't secure (here in the UNIX group, doubly so). In an academic environment, there's really nothing you can do about it, except for blocking the more obvious holes, and keeping good backups. But when an article like the Ha'aretz one appears, it throws a bad light upon the institution, and lessens the impact when you really do have a serious break in. Simon ses@techunix.technion.ac.il ses@techunix.bitnet Tel +972-4-292658 ------------------------------ Date: Fri, 18 Oct 91 08:34:00 EDT From: Rick Kuhn Subject: Assurance of High-Integrity Software - Report Assurance of High Integrity Software - report available The need for dependable software has resulted in the production of a variety of standards: the Trusted Computer Security Evaluation Criteria ("Orange Book"), the British MoD 00-55, the DO-178A standard for civil aviation, the IEC 880 standard for the nuclear industry, and others. Because of technical, economic, and political considerations, these standards approach the question of assurance from a variety of viewpoints. There is much disagreement over how dependable software can be produced. The controversy over MoD 00-55, with its requirement for formal methods and deprecated programming practices, is a recent example. To address the question of assuring the trustworthiness and integrity of software, and what assurances should be required in standards, the National Institute of Standards and Technology brought together experts from industry, academia, and government in a Workshop on the Assurance of High Integrity Software in January. The report is now available for electronic distribution. (It will soon be available from the Govt. Printing Office in paper form.) The report can be obtained from our mail server. Both Postscript and troff formats are available. Send a message containing ONE of the following requests to posix@nist.gov: send ahisrptp /* for Postscript */ send ahisrptt /* for troff */ The report will be delivered as three (troff) or 16 (postscript) email messages. Remove the headers and concatenate the files, then unpack them using either 'unshar' or the UNIX shell 'sh'. (Instructions included in the files.) ------------------------------ Date: Thu, 17 Oct 91 10:00:27 pdt From: caa@unify.com (Chris A. Anderson) Subject: Video stores losing videos... Mowgli Assor mentions an occurrence that happened to him at Blockbuster Video recently. I also had something like this happen to me and it's worth sharing with others... Our local video store (not Blockbuster, by the way) also has a very nice computer system that keeps track of what's checked in and out, as well as a history of recent transactions. At one point, I had a video out for longer than the rental period and was required to pay for the extra time. I paid with a check and went my way without a thought. Several weeks later, I was renting another video from the same store when the attendant told me that I owed money on a late rental. I couldn't remember being late with anything, so I asked him for the title (hoping to jog my memory). It turned out to be the video that I had payed for previously. I told him that I had already payed for it. He replied that their system had no record of it. I asked if there was any other audit trail and of course there wasn't. At that point I said that I had the cancelled check at home and that I would go and get it for him. He told me that a cancelled check didn't prove anything, since it wouldn't have what it was for on it (the store sells other things as well as renting videos). By this point, I was upset and asked to speak to the manager. The attendant replied that he was at home and they were not allowed to call him there. Deciding that I had had enough, I asked for my drivers license back (the store uses the DL number to identify the renter). He refused to give it to me until I payed for the late video. I blew up at that point and asked for him to call the manager at home again. He refused. I asked for the manager's name. He gave it to me and I went to a pay phone to look him up in the phone book and call him. The manager agreed that this was an unfortunate occurrence and asked me to pay the late fee "just for now" and then bring him the cancelled check in the morning. I wasn't available to bring him the check in the morning since it was a workday, and he wasn't available any other time. He kept repeating that his computer system always kept "perfect" track of all of the accounts, and that it couldn't be wrong. In the end, I payed the video late fee, got my drivers license back, took my cancelled check to the manager's home (it was conveniently listed in the phone book) and had him write me a personal check to cover the late fee. He didn't really believe the cancelled check, but I had already proved myself to be a dangerously unbalanced person just by driving to his home at 10:00pm to recover a $3.00 late fee. To the end, he kept repeating that his computer systems didn't make mistakes. Like most people, he didn't realize that it took *humans* to enter the data into the system and that they *did* make mistakes. Needless to say, I do business elsewhere now. And the video store that I use has a paper trail to back up the computer system. Just another risk. Chris Anderson, Unify Corp. ------------------------------ Date: Thu, 17 Oct 91 10:12:46 EDT From: Brian Boutel Subject: Re: Blockbuster `Loses' Returned Video This is a problem that can occur in any library. It arises for two reasons. First, in almost all modern circulation control systems, the discharge transaction is not done at the time of return - the books/videos are left on the counter for later processing, and human failure can then intrude. Second, there is no physical evidence residing with the borrower (a receipt?) that provides proof of the return. The antique (Brown?) system solved these problems. Borrowers had a collection of tickets, and could borrow one item per ticket. Books also had tickets, and the loan record was the physical pairing of a borrower ticket and a book ticket, usually one fitted inside the other, filed in chronological order of due date. When returning items, borrowers had to wait for the loans to be discharged in order to have their tickets returned. Being able to account for all your tickets was proof of not having lost or stolen a book. Alas, computerised systems have cost us this piece of security. Actually, some library systems go to the other extreme. One library I used microfilmed each issue transation. An 80-column card with a transaction number both punched and printed on it was inserted into the book, and the open book, card, and borrower's ID were photographed together. Presumably the control on non-returned books was based on sorting returned cards and looking for gaps in the sequence, which could then be looked up on the film record. The risk here was for the library, since the primary record of the loan was with the borrower. As long as the card was returned, the library assumed that the book with which the card was issued had been returned, which did not follow at all. On the subject of risks associated with video libraries, last year (at home in New Zealand) I went to borrow a video, and was told that my card had been reported lost, and was no longer valid. I had not made that report, and had been out of town on the day it was recorded. I said "But it's not lost. I'm here, I have the card, and ID to prove who I am." They said "Sorry, but there is no way we can reactivate that card. The computer won't let us. You will have to go to head office for that." "But I want to take out this movie now." Silence, then: "Oh, I know what we can do. We can issue you a new card." Which they then did, using the same ID previously offered. It turned out that one of my children, looking for my card in the drawer where it is usually kept, failed to find it - it happened to be in my wallet that day - decided to apply for their own card, and reported mine missing at the same time. This report was accepted, and prevented the legitimate owner (me) from using t! he card, even though it was made by someone else, not even obviously a family member since they have a different address and surname. --Brian Boutel ------------------------------ Date: Thu, 17 Oct 91 11:16:55 CDT From: "Matt Crawford" Subject: Re: Blockbuster `Loses' Returned Video (v12n51) When I first got a VCR, not so awfully long ago, I used to always ask for a receipt when I returned a rented movie. They would *never* give me one. I kept asking, figuring if they lost a movie I'd at least be memorable as the guy who always asked for a receipt. ------------------------------ Date: Fri, 18 Oct 1991 11:07:53 EDT From: hughes@gpx1.square-d.com Subject: Re: Blockbuster 'Loses' Returned Video I have experienced a similar situation at another video store and have found at least a temporary manual solution to the problem (until they make the bar code readers available and print receipts). Whenever I check a video (or any valuable media) out now, whether from a store or the library, I physically make sure that they check it in as I stand there. This avoids problems of the nature Mr. Assor has described. This may seem like a bit of a nuisance at times, especially when you are in a hurry, but believe me, it is a small price compared to what one video company wanted when they claimed that *five* videos (3 childrens movies and two comedies for those of you who keep track of these things) had not been returned. Sometimes the employees give me problems when asked to do this but if I forcefully explain that an incompetent employee was the reason for this and perhaps I should explain this to their manager, I usually have no more problems. It seems a bit redundant in this ultra-efficient computer age to have to manually force this condition but as long as there is a human link in the chain of events, there needs to be a check on that link. Kevin Hughes ------------------------------ Date: Fri, 18 Oct 91 08:34:39 PDT From: ps@dreamit.fps.com (Patricia Shanahan) Subject: Re: Blockbuster `Loses' Returned Video [Rented video tape actually returned, but the return not recorded in the stores computer system, and the tape is not on the shelf where it should be.] > At this time, Blockbuster thinks I stole the tape (even though the manager >doesn't ;) & since I gave them the proof I didn't on Monday & they lost it, I >of course have no proof anymore. The risk of relying on employees to know their >jobs, I guess. There are both technological and social fixes for this type of problem. The best technical fix that I can think of would be for the store to have a barcode reading receipt printer. It would take only a moment to scan each tape as it is returned, and hand the customer a printed receipt proving that the tape was returned. There are currently a large number of transactions that do not have satisfactory systems for verifying what happened. ATM transactions have similar problems. The social fix that I think should be applied is to force the cost of such disputes onto the person who has the power to determine how the transaction is done. There is already in at least some states a rule that resolves ambiguity in a contract against the person who wrote the contract. The equivalent rule would say that any issue of fact that is inherently unresolvable because of how the transaction is organized is to be decided against the person who designed the transaction. The application in this case would be that if the customer claims to have returned the tape, and the store designed a tape return system that leaves both the customer without any proof of return, and the store without any proof of non-return, then the store should carry the cost. If the store always issues a receipt for returned tapes, than it becomes reasonable for the store to demand that the customer either return the tape or produce a receipt. The store would have to judge whether the cost of issuing receipts exceeds the cost of lost tapes due to customers lying about having returned them. Patricia Shanahan ps@fps.com uucp : ucsd!celerity!ps (619) 271-9940 [Time to blow the whistle on this subject... But there are a lot of lessons to be learned by the unwary customer. Asking for a receipt sounds like a great idea. If enough customers did ask, the video outfits might do something intelligent! You might bring in a piece of paper with the name of the film and the date, and INSIST that the clerk sign it. PGN] ------------------------------ End of RISKS-FORUM Digest 12.53 ************************