The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 20 Issue 12

Weds 9 December 1998

Contents

o San Francisco power outage and Y2K
Cathy Horiuchi
o Air-traffic control comments
Paul Cox
o TCAS stories - 1 good, 1 bad
David Wittenberg
o Security risks of laptops in airline cockpits
Jim Wolper
o NW Frequent Flyer Miles subject to fraud
Sandy Antunes in PRIVACY Forum
o Another monster water bill
Brian Clapper
o Trusting non-redundant info about your RAID system
G.J. Dekker
o Export exemptions
Padgett Peterson
o Re: MS Outlook's calendar shifts with time zone
Stuart Lamble
Clive D.W. Feather
o Re: Spamming to Spy
Kevin Connolly
o Re: A risk ... of JavaScript
Steven M. Bellovin
Mathew
o Interesting effect of PG&E power outage
Greg Marriott
o Info on RISKS (comp.risks)

San Francisco power outage and Y2K (RISKS-20.11)

horiuchi <horiuchi@ix.netcom.com>
Wed, 09 Dec 1998 11:15:59 -0800
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"


Air-traffic control comments

"Paul Cox" <pcox@eskimo.com>
Wed, 9 Dec 1998 00:48:39 -0800
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


TCAS stories - 1 good, 1 bad

David Wittenberg <dkw@cs.brandeis.edu>
Wed, 9 Dec 1998 10:20:18 -0500 (EST)
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>


Security risks of laptops in airline cockpits

Jim Wolper <wolpjame@cwis.isu.edu>
Tue, 08 Dec 1998 06:49:02 +0000
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]


NW Frequent Flyer Miles subject to fraud

Sandy Antunes in PRIVACY Forum <privacy@vortex.com>
Sat, 5 Dec 98 12:58 PST
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]


Another monster water bill

Brian Clapper <bmc@WillsCreek.COM>
Tue, 8 Dec 1998 13:51:12 -0500 (EST)
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/


Trusting non-redundant info about your RAID system

"G.J. Dekker" <gjdekker@nlr.nl>
Wed, 09 Dec 1998 09:03:10 +0100
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)


Export exemptions

"Peterson, Padgett" <padgett@gdi.net>
Wed, 09 Dec 1998 08:37:23 -0500
>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


Re: MS Outlook's calendar shifts with time zone (Marriott, R-20.11)

<slamble@csc.com>
Wed, 9 Dec 1998 14:05:22 +1000
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


Re: MS Outlook's calendar shifts with time zone

"Clive D.W. Feather" <clive@demon.net>
Wed, 9 Dec 1998 11:31:17 +0000
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]


Re: Spamming to Spy (Mills, RISKS-20.11)

Kevin Connolly <Kevin.Connolly@ansf.alcatel.fr>
Wed, 09 Dec 1998 11:38:59 +0000
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


Re: A risk ... of JavaScript (Thompson, RISKS-20.11)

"Steven M. Bellovin" <smb-lists@research.att.com>
Wed, 09 Dec 1998 08:44:23 -0500
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?"


Re: A risk ... of JavaScript (Thompson, RISKS-20.11)

mathew <meta@pobox.com>
Wed, 9 Dec 1998 14:53:49 -0500
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.


Interesting effect of PG&E power outage (RISKS-20.11)

Greg Marriott <greg@spies.com>
Tue, 8 Dec 1998 13:18:39 -0800
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

Top