precedence: bulk Subject: Risks Digest 20.12 RISKS-LIST: Risks-Forum Digest Weds 9 December 1998 Volume 20 : Issue 12 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at and at ftp.sri.com/risks/ . Contents: San Francisco power outage and Y2K (Cathy Horiuchi) Air-traffic control comments (Paul Cox) TCAS stories - 1 good, 1 bad (David Wittenberg) Security risks of laptops in airline cockpits (Jim Wolper) NW Frequent Flyer Miles subject to fraud (Sandy Antunes in PRIVACY Forum) Another monster water bill (Brian Clapper) Trusting non-redundant info about your RAID system (G.J. Dekker) Export exemptions (Padgett Peterson) Re: MS Outlook's calendar shifts with time zone (Stuart Lamble, Clive D.W. Feather) Re: Spamming to Spy (Kevin Connolly) Re: A risk ... of JavaScript (Steven M. Bellovin, Mathew) Interesting effect of PG&E power outage (Greg Marriott) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 09 Dec 1998 11:15:59 -0800 From: horiuchi Subject: San Francisco power outage and Y2K (RISKS-20.11) The 8 Dec 1998 SF outage (RISKS-20.11) may be subject to as much scrutiny as the 10 Aug 1996 western states blackout (RISKS-18.32). Electric system deregulation has caused numerous changes in priorities. This outage is attributed to human error, a construction crew not knowing a pipe was acting as a ground. It could be considered an information error, if no sign, tag or other label were present and this sort of pipe is not routinely used (e.g., noted in standards and training manuals) as substation ground. www.euy2k.com today quotes PGN on this outage as a sample of the type of scenario problems which might result from Y2K remediation failures. Is it a Y2K problem if utility executives decide it is preferable to spend $50-100 million on a new customer billing system rather than spend that amount on tree-trimming, line-crew training, supervision, buyout of excess staff, or labeling of equipment in substations? Study of major outages suggests among key issues faced in electric system reliability are aging infrastructure and loss of the knowledge base on details of transmission and distribution systems when staff retires or is downsized out as part of deregulation. Starting a project to catalog and label every wire in every city has no glitz and few major consulting firm requirements. Yet this simple course of action will prevent many problems with the energy infrastructure, and could be included in the national infrastructure protection project (http://www.ciao.gov). The writings on complexity and system accidents of Charles Perrow are highly recommended. Cathy Horiuchi, University of Southern California, formerly at the Sacramento Municipal Utility District, "Your Electric Service" ------------------------------ Date: Wed, 9 Dec 1998 00:48:39 -0800 From: "Paul Cox" Subject: Air-traffic control comments Hi. I'm an air-traffic controller at Seattle Center, located in Auburn, Washington. I am particularly drawn to RISKS reports of problems with the ATC system. I notice many times that, while generally accurate, there are some small but crucial errors in the general assumptions and conclusions drawn and made. For example, in RISKS-20.11, there is a response to the Dulles radar failure issue. Steve Peterson says, in part: > While radar failures are certainly important, it's wrong to say that radar > failures deprive controllers of this information. In this situation, > pilots report all three items (plus their position) to ATC via radio. ATC > procedures provide for increased separation between aircraft to compensate > for the lack of radar data. > In the US (and presumably elsewhere), there are many places where reports > by the pilot are the _only_ source of information on the location of > aircraft." While fairly reassuring, this isn't exactly true. First of all, "radar" technically refers to the physical radar antenna; what we think of as ATC "radar" display scopes are typically mosaics of multiple radar sites. The physical radars themselves don't fail frequently at all; in fact, I've been working as a controller for almost 8 years now and have never had it happen. What I HAVE had happen, numerous times, is failures of the various radar mosaic display systems, failures of the various communications systems, and power failures to the entire facility (which, of course, take absolutely everything. Except the cell phones in controller's cars.) Getting back to what Steve Peterson said above, display system failures most certainly DO deprive controllers of data such as heading, speed, and altitude of aircraft. These three things are the most important, most crucial components to data controllers need to do their jobs. In essentially all ATC facilities, printed or hand-written strips are required to be kept on each and every aircraft with needed data. In practice, however, controllers (particularly in busy terminal facilities) cannot keep those strips up to date. In practice, when working a busy "final" or "arrival" sector in a terminal facility, controllers are keeping the info on each plane in their head (which brings up some interesting single-point-of-failure questions.) Controllers are indeed perfectly capable of controlling traffic through radio position reports, pencils, and their flight strips, as Mr Peterson suggests; however, the bad news is that it is much, much slower and inefficient. When the radar display unit fails, the controller scrambles to his strips, tries to recall which of them were actively being worked by him at the time, and re-establishes the "picture" in his head. Good technique includes up-to-date strip marking; however, again, this is an area where practice often falls behind idealism. Staffing shortages might mean where, ideally, a controller working the radar will have an assistant handling all the strip-marking and landline calls (to other controllers to coordinate data); a controller might be normally capable of working a position alone, but be "down the tubes" temporarily and have fallen behind on his strip-marking; or he could simply be having a bad day. What all this comes down to is that most of the time, there's not much problem if the radar and/or radar displays fail. However, when they do (not if; history shows us they fail again and again and again, and shows no sign of abating) there is most definitely a temporarily greatly reduced safety factor. The transition times immediately following a failure can be complete and utter chaos, and quite frankly would be quite terrifying to most pilots if they could see what's happening on the other end of that radio link. Paul Cox, Enumclaw, Washington ------------------------------ Date: Wed, 9 Dec 1998 10:20:18 -0500 (EST) From: David Wittenberg Subject: TCAS stories - 1 good, 1 bad In *The Boston Globe* on 8 Dec. and *The New York Times* on 9 Dec. (see RISKS-20.11) there is a story about two planes getting within 1.1 miles horizontally and 900 ft. vertically when they were supposed to be separated by at least 2 miles horizontally or 2000 ft. vertically. The planes were warned by their TCAS systems and avoided each other. The controller's union says they got too close in the first place because of a series of computer failures, the FAA says the incident is under investigation. Both planes were bound from the US to Europe and were talking to the Boston center. [The *Globe* noted that there were 3 planes, and that when 2 of the planes changed course to avoid collision, one was then heading into the third plane.] About a week earlier, there was a case where the TCAS told a Air Ontario Dash 8 to climb to avoid a US air 737. The Dash 8 came within 300 ft. of a Northwest A-320 whose TCAS told it to descend. In this case a controller noticed the "erratic" flight paths and intervened. Neither the Times nor the Globe explained why the A-320 was told to descend. So the controllers got one pair of planes into a bad situation, and TCAS bailed them out; and TCAS got another set of planes into a bad situation and the controllers bailed them out. How are the pilots to know which one to trust when they must make decisions quickly? David Wittenberg ------------------------------ Date: Tue, 08 Dec 1998 06:49:02 +0000 From: Jim Wolper Subject: Security risks of laptops in airline cockpits The problem of laptop computer interference with flight and navigation equipment has been discussed in several issues of RISKS, notably R-16.23 to 25, -18.46, and -18.52. Here is a new twist on that theme: pilots wanting to use laptops to interface with installed avionics. There are several new RISKS involved here. INTRODUCTION Pilots of transport-category and certain larger corporate aircraft use a system called ACARS to exchange text messages with designated receivers on the ground, usually a company dispatch office. ACARS can also be used to report maintenance anomalies, routine data on performance, and the like. The interface is awkward: I've observed experienced pilots swirl an index finger over the keyboard looking for a letter. And, ACARS messages are generally sent in clear text, that is, there is no encryption or other encoding. (ACARS is short for ARINC Aircraft Communications Addressing and Reporting System; ARINC is a company providing voice and data services to the air transport industry.) *Aviation Week and Space Technology* now reports that Lufthansa German Airlines is now investigating the possibility of using "pilot laptop computers" and a dataport to ease the composition of ACARS messages. Such a course of action must be taken wtih extreme care: it opens a door to most of the known computer security problems. Pfleeger's "Security in Computing" lists four security threats: interception, interruption, modification, and fabrication. The laptop-ACARS connection is vulnerable to all four, unless certain precautions are taken. These will be discussed at the end of the essay. INTERCEPTION As mentioned above, ACARS messages are transmitted in clear text, and are subject to interception; in fact, there is a group of hobbyists who disseminate information about ACARS interception through a web site. Some argue that there is no value to intercepting ACARS messages (publicly owned airlines publish the economic data such as load factor, routes are standard, etc). Granting that this may be true for the airline, there are other parties which may be hurt by this information, primarily passengers. Here is a true story. I was riding in the jumpseat of a major airline's Airbus A320 (one of my prerogatives as a professional pilot). A flight attendant came into the cockpit to report that a passenger had had a problem with his colostomy bag and wanted to stay in his seat after landing and have his luggage brought to him so he could change his clothes. The cockpit crew, quite sympathetic, sent an ACARS message to the dispatch office, which necessarily included the passenger's name. But ACARS messages are easy to intercept; I wonder if the passenger really wanted his name and the nature of his medical problem broadcast in the clear? Ordinarily, there are no physical security problems with these messages but this is not the case with a pilot's laptop because presumably the composition of the message will be done on the laptop and the message will remain in the laptop. If the pilot then takes the computer home and allows his family to play with it, the size of the set of potential interceptors grows substantially. INTERRUPTION Once the laptop-ACARS connection is established as industry practice, any denial-of-service attack on the pilot's laptop becomes a denial-of-service attack on the airline. Such attacks include viruses and worms. Similarly, power supply, disk controller, or battery problems have the potential to disable the system at the laptop interface. MODIFICATION One modification issue involves the physical security of the laptop. Again, a virus or worm could be introduced which would alter the program encoding ACARS messages. Other modifications include changes to company manuals stored on the laptop. Modification becomes a more crucial issue when the laptop is actually connected to the airplane's avionics; one needs to be sure that this connection can't modify other aspects of the on-board avionics. FABRICATION The ACARS data link, since it is cleartext, is subject to bogus messages transmitted in either direction. Some airlines use ACARS to transmit weight-and-balance data to the aircraft, and the aircraft's trim is set before takeoff based on this information. If the crew receives false weight-and-balance data, the trim might be set incorrectly. This has caused many accidents, most recently the Fine Air DC-8 freighter which crashed leaving Miami. AVOIDING PROBLEMS Pilots are frustrated with the ACARS interface and are correctly looking for ways to improve it. The laptop connection could be secure if the following precautions are taken: 1. Ensure physical security of the laptop. It is not the pilot's laptop, it is the company's laptop, and does not go home with the pilot. It stays on the airplane or in the dispatch office. This reduces the RISK of all four threats. 2. Ensure communications security by using a simple cryptography scheme. The RISKS are short-lived, so even a simple crypto scheme that can be broken in a few hours is a major improvement. It should be noted that Scandinavian Air Systems is already implementing crypto in its ACARS messages, by adding hardware and software to the unit on the airplane. For verification purposes, a checksum such as MD5 or a public-key digital signature would provide more than adequate security. CONCLUSIONS The SAS example makes something more clear, namely, that there are two problems with the system: the interface and the plaintext transmission of the data. SAS's crypto addresses the latter but not the former. The laptops address the former but not the latter. The ACARS interface problem is a real one, but trying to solve it by adding yet another level of technology does not seem to be the best way to solve. Jim Wolper ATP/PhD/CFI, Department of Mathematics, Idaho State University Pocatello, ID 83209-8085 +1 208 236 2453 [Jim Wolper requested that a note be added to the archive copy: The source for this information on SAS was a copyrighted story in "Air Transport Intelligence", an on-line journal. PGN] ------------------------------ Date: Sat, 5 Dec 98 12:58 PST From: privacy@vortex.com (Sandy Antunes in PRIVACY Forum) Subject: NW Frequent Flyer Miles subject to fraud From the PRIVACY Forum Digest V07 #19 5 Dec 1998 Date: Tue, 27 Oct 1998 16:32:59 -0500 >From: antunes@xeno.gsfc.nasa.gov (Sandy Antunes) Subject: NW Frequent Flyer Miles are publically accessible-- and usable Flyers beware-- I've run into a severe privacy/security hole in Northwest's frequently flyer program, "WorldPerks"-- one that NW is not interested in changing. The short summary is, it seems anyone who knows your phone number can use your Northwest "WorldPerks" frequent flier miles to get an E-ticket issued in their name with your miles (or can simply find out your mileage balance). This is intentional, by design. I found this out when my mother was able to upgrade a "gift" ticket I gave her to First Class-- using my miles-- without my authorization. It turns out that it doesn't even have to be a relative or someone you got a ticket for-- just someone who knows your phone number. The record of this transaction (a receipt) is provided as the only notification of the transactions. Tickets issued can be for travel as soon as 4 days in the future (at which point the receipt is FedExed or faxed) or over 14 days in the future (receipt is just sent postal mail). In my case, 3 weeks passed between the ticket request and arrival of a receipt. The privacy concerns are this: - anyone can get your frequent flyer mileage balance knowing only your phone number, - anyone can deplete your mileage balance with malicious intent, knowing only your phone number, and - the only sign that a ticket was issued is a receipt mailed by post, so people with open mailboxes, people changing addresses, people on vacation, bosses with secretaries, and people with housemates are easy prey to having their miles stolen without knowing. Unlike credit card fraud, NW does not consider banked miles as currency, and it is the account holder's responsibility to find and file fraud charges against the ticketholder. 1st line managers have the option of waiving the $35 'rebank' fee if you wish to cancel such a ticket, if the flight has not already occurred. The most likely safeguard-- that only the person who ownes the frequent flyer account can request a ticket be issued-- is not something NW will consider. Quothe Jay (with permission), "The system is a great system, and it works, and we don't have problems with it. You're taking a situation that happened to you, and trying to completely blame it on Northwest, and I don't appreciate it." So, your account information is available to anyone who has access to a phone book (a privacy concern), the actual balance can be tampered with by same (an authorization risk), and catching such deeds is the responsibility of the account holder (verification after the fact). "Some People Just Know How to Fly", indeed. Sandy Antunes [For subscription information for the PRIVACY Forum Digest, see RISKS-20.00 . PGN] ------------------------------ Date: Tue, 8 Dec 1998 13:51:12 -0500 (EST) From: Brian Clapper Subject: Another monster water bill Courtesy of a friend of mine who lives near Seattle: > Earlier, I wrote: > >> We just received our monthly water bill... >> and it was for $18121.85 !!! The water company says it's >> switching to a new computer system and to ignore the bill. > > Well, we just received a Past Due notice, threatening to turn off our > water if we don't pay the above amount plus a 10% late-payment penalty > of $1812.19; this brings the total to $19934.04! As before, when we > phoned the water company, they said to ignore the bill ... we'll see > what happens! History just continues to repeat itself. Brian Clapper, bmc@WillsCreek.COM, http://WWW.WillsCreek.COM/ ------------------------------ Date: Wed, 09 Dec 1998 09:03:10 +0100 From: "G.J. Dekker" Subject: Trusting non-redundant info about your RAID system A few weeks ago one of the 8 disks in a RAID-5 cabinet on our PC server failed. The only indication of the identity of the defunct disk was in the graphical interface software on the operators console, which was a perfect look-alike of the physical cabinet. The console indicated that the third disk of the upper row of four was faulty. However, after replacing this disk, the system crashed. After reboot, it appeared that now the third disk of the upper row still was defunct, and that in addition the third disk of the lower row did not contain information. It took quite some amount of effort and luck to find that the graphical interface software had interchanged the two rows, such that in effect one of the functional disks was replaced, while there was no redundancy left due to the other failed disk. The whole process of finding the cause of the problem an solving it led to an outage of the server of about 6 hours. The risk: even in a properly designed redundant system there can be non-redundant pieces. Trusting non-redundant info on your system can be dangerous. G.J. Dekker -- National Aerospace Laboratory (NLR), Informatics Division P.O.Box 153,8300 AD Emmeloord, The Netherlands +31 527 248435 (operator 248444) ------------------------------ Date: Wed, 09 Dec 1998 08:37:23 -0500 From: "Peterson, Padgett" Subject: Export exemptions >The Norwegian developer Eivind Eklund wrote on slashdot.org: > I just got information on how Norway (where I live) implement this > (ie, how the regulations are changed). The new rules prohibit export > of crypto-software, but with a deliberate exception for open source > software. This is quite interesting since the implementation of the crypto algorithms is really the boring part of programs like PGP. While people once did not mind comand line interfaces and "pgp -sea " was meaningful, today the crypto is a minuscule piece of programmes. In 1994 when the "Enclyptor" was introduced, I told Dave that this was the future. Today we have key servers, tray icons, and Eudora/Exchange plugins, none of which contain "crypto" yet are what will make or break a product commercially. Sounds like all that is necessary to make public is an API that contain the various crypto modules while the wrappers that provide the GUIs and automatic execution (the moneymakers) remain proprietary. Padgett ------------------------------ Date: Wed, 9 Dec 1998 14:05:22 +1000 From: slamble@csc.com Subject: Re: MS Outlook's calendar shifts with time zone (Marriott, R-20.11) Been there, done that, got the T-shirt. It happens with just about everything you care to name under Outlook's calendar, including recurring appointments -- that's where I first noticed it. I'd enter an appointment for (say) 8:30pm to 9:30pm on a Tuesday, recurring every week until the end of time. Surprise -- daylight saving finishes, and all of a sudden, the appointments are for 7:30pm to 8:30pm. Even "events" (full-day happenings -- e.g., birthdays) aren't immune, so I was mildly amused to notice that a number of events started at 1am some days, midnight others... Maybe they were just taking a leaf out of Lotus' book? Lotus Notes does something similar; it has been demonstrated for e-mail (date sent is displayed relative to your timezone rather than the timezone it was sent), and it wouldn't surprise me if the calendar aspect of it does something similar. It's one of those things that, in my opinion, should be configurable. I'm not familiar with American time zones, so I'll give an Australian example: Perth is three hours behind Melbourne, two and a half hours behind Adelaide. Suppose somebody in Perth wants to set up a telephone meeting with somebody in Melbourne and somebody in Adelaide. They might say "10 am". Do they mean 10 am Perth time, Adelaide time, or Melbourne time? With a feature like this, the Perth guy can say "10 am", and it gets translated to "1 pm" for the Melbourne guy behind the scenes (12:30pm for the Adelaide chap.) I'm not saying it's always a Good Thing(tm) -- just that sometimes it's appropriate, sometimes it isn't. Of course, this is just another recurrence of the perennial question: how far should software go in trying to second-guess the person operating the keyboard? Stuart Lamble ------------------------------ Date: Wed, 9 Dec 1998 11:31:17 +0000 From: "Clive D.W. Feather" Subject: Re: MS Outlook's calendar shifts with time zone I've used systems that do the opposite - store all appointments in the local time for the system. You get to meetings in New York on time, but the alarm for the urgent phone call to someone in London is 5 hours late because it went off at 1500 EST instead of 1500 GMT. There's no easy way to win here, other than having an explicit "not this time zone" flag on diary systems. Clive D.W. Feather, Director of Software Development, Demon Internet Ltd. Tel: +44 181 371 1138 Web: [Other comments on this subject from eight others! The bottom line is specify your frame of reference. PGN] ------------------------------ Date: Wed, 09 Dec 1998 11:38:59 +0000 From: Kevin Connolly Subject: Re: Spamming to Spy (Mills, RISKS-20.11) In RISKS-20.11 Dick Mills wrote of the possibility of audio/video Trojans. It has already been done. "Back Orifice" from the "Cult Of The Dead Cow" http://www.cultdeadcow.com/ is a trojan that includes the feature to find your PC attached camera and take a picture (still or video). http://www.cultdeadcow.com/tools/bo.html Kevin Connolly, EI4ANB ------------------------------ Date: Wed, 09 Dec 1998 08:44:23 -0500 From: "Steven M. Bellovin" Subject: Re: A risk ... of JavaScript (Thompson, RISKS-20.11) There are many sins that can be ascribed to JavaScript, but this flaw is ubiquitous on the Web. There are very many ways for Web sites to send you to other places, ranging from JavaScript to embedded images (including those from "adult" sites) to http-level redirects. The real question, one that is asked by the browsers to the Web sites, is "where do I want to go today?" ------------------------------ Date: Wed, 9 Dec 1998 14:53:49 -0500 From: mathew Subject: Re: A risk ... of JavaScript (Thompson, RISKS-20.11) Of course, a survey which only samples opinions from readers who happen to have JavaScript enabled is so obviously statistically flawed that it's a bit pointless doing it in the first place. ------------------------------ Date: Tue, 8 Dec 1998 13:18:39 -0800 From: Greg Marriott Subject: Interesting effect of PG&E power outage (RISKS-20.11) San Francisco and San Mateo counties in California suffered a massive power loss on the morning of 12/8/98. I live in nearby Palo Alto, a community not directly affected by the outage. My Mitsubishi television equipped with TV Guide+, however, forgot all of its stored programming information. TV Guide+ is an online television program guide. The television schedule is updated automatically several times a day by tuning to a local public broadcasting station and downloading the next few days worth of programming. In my case the PBS station is KQED channel 9 in San Francisco. I assume they lost power along with the rest of the peninsula and the Guide+ service was disrupted. Apparently when my television failed to connect to the information server it decided the best reaction was to dump everything. I find this failure mode a bit annoying because the television stores enough data for 2 or 3 days worth of viewing. I would have preferred that it wait for a few more update cycles before deciding the server was gone for good. Now I not only have to re-enable TV Guide+, but I have to wait for about a day for the full schedule to be downloaded. And then I have to go through all the available channels, again, and disable the ones I don't need. (this leaves more memory for program descriptions on the channels I *do* need) Greg Marriott ------------------------------ Date: 23 Sep 1998 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact (Dennis Rears). .UK users should contact . => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 19" for volume 19] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks . ------------------------------ End of RISKS-FORUM Digest 20.12 ************************