Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
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"
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
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 <dkw@cs.brandeis.edu>
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 <http://math.isu.edu:80/~wolperj>
[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]
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 <antunes@xeno.gsfc.nasa.gov>
[For subscription information for the PRIVACY Forum Digest,
see RISKS-20.00 <URL:http://catless.ncl.ac.uk/Risks/20.00.html>. PGN]
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/
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)
>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 <file>" 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
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
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: <http://www.davros.org> [Other comments on this subject from eight others! The bottom line is specify your frame of reference. PGN]
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
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?"
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.
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
Please report problems with the web pages to the maintainer