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 19 Issue 84

Tuesday 7 July 1998


o Computer glitch snags airline travel
Doneel Edelson
o Coffee spill affects air traffic
Doneel Edelson
o Yet another baggage-system problem
Peter B. Ladkin
o PacBell PCS outage
Tony Lima
o Vendors unite against bad applets
o "The world's largest online database!"
Lindsay F. Marshall
o House hears about encoded circuit board missing from Chinese rocket
Doneel Edelson
o Lucent cracks e-commerce encryption code
o FIPS-Flop: Reuters on failed NIST key-recovery effort (Alan Davidson0
o NSA declassifies encryption code
o Woman cracker gets five-month prison sentence
o Defining the line between hacking and web surfing...
Eli Goldberg
o Y2K problem worries CIA
o Galaxy IV, 600 days and Y2K
Dennis Elenburg via Ben Torrey
o Galaxy IV muzak withdrawal
Philip Edmonds
o No manual switching for railroads; result, famine
Doneel Edelson
o A new wrinkle in address harvesting?
George Swan
o Re: More on @#$%& Software
Michael A. Nelson
o REVIEW: "The Year 2000 Software Problem", Capers Jones
Rob Slade
o Info on RISKS (comp.risks)

Computer glitch snags airline travel

"Edelson, Doneel" <>
Thu, 2 Jul 1998 10:01:48 -0500
Hundreds of American Airlines flights were delayed Tuesday evening after its
Sabre Group computer stopped functioning at 5:18 p.m. CT and was out of
service for at least four hours.  An American Airlines spokesman said the
delays ranged from 8 minutes to a few hours on domestic and international
flights, due to a software problem.  This was the second Sabre
central-system outage in a week.  The outages affected about 50 airlines
that use Sabre for reservations, seat assignments, baggage info, etc.
[Source:  Sara Nathan, *USA Today*, 1 Jul 1998, PGN Abstracting]

Coffee spill affects air traffic

"Edelson, Doneel" <>
Mon, 29 Jun 1998 09:01:43 -0500
A coffee spill in a control tower distracted controllers long enough to
delay instructions to a passenger jet, causing two planes to pass within 20
feet of each other over New York's LaGuardia Airport, the Daily News
reported yesterday.  The incident happened on April 3 as a US Airways plane
was preparing to land on one runway and an Air Canada plane was taking off
on an intersecting runway.

[Reuters - from The Baltimore Sun, 6/29/98.

Yet another baggage-system problem

"Peter B. Ladkin" <>
Sun, 05 Jul 1998 19:13:22 +0200
This time it's at Kuala Lumpur's new airport which opened Tuesday 30 Jun
1998. The check-in systems were also fouled up. The problems were still
persisting Friday, July 3, the fourth day of operation. Looks as though
Denver was a pioneer in more ways than one.

Peter Ladkin

  [Things reportedly got better after that, however.  PGN]

Re: PacBell PCS outage

Tony Lima <>
Fri, 03 Jul 1998 00:14:00 GMT
On Friday 26 Jun 1998, PacBell managed to upload a corrupted database that
disabled their digital "PCS" telephone service to all subscribers.  The
database was the central authentication database that ensures that the user
of a particular phone has the rights to use that phone.  The service is the
new, non-cellular, digital service; you now know as much about the
technology as I do.  We are subscribers.  Our telephone came back on-line at
about 3 p.m. Saturday.

Details should be available at or  Have a nice Fourth. - Tony

Vendors unite against bad applets

Edupage Editors <>
Thu, 2 Jul 1998 14:35:19 -0400
A group of vendors has teamed up with the International Computer Security
Association (ICSA) to form a Malicious Mobile Code Consortium, aimed at
combating the threat of malicious or corrupt Java applets and ActiveX
controls.  Malicious applets are capable of freezing a user's screen,
slowing PC performance to a crawl, or even scrambling a hard drive.  Charter
members include Advanced Computer Research, Computer Associates, Cybermedia,
Digitivity, Dr Solomon's Software International, eSafe Technologies, Finjan,
Internet Security Systems, Quarterdeck, Security-7, Symantec and Trend
Micro.  The consortium will focus on educating companies and consumers,
developing product-certification standards and testing, and providing a
venue for information exchange.  "The threat by mobile malicious code has
been established," says ICSA's malicious mobile code program manager.  "We
have the benefit of anticipating these attacks and preventing them."
(*Information Week*, 1 Jul 1998; Edupage 2 July 1998)

"The world's largest online database!"

"Lindsay F. Marshall" <>
Wed, 24 Jun 1998 11:36:50 +0100 (BST)
This was posted recently to a mailing list of which I am a member :


"Microsoft TerraServer serves up some fascinating images. But it does a lot
more. It demonstrates how off-the-shelf components from Microsoft, Compaq,
Legato, and StorageTek can be used to design, to deploy, and manage a
massive digital image database that has to be available 24 hours a day,
seven days a week."

    [clickety-click through the tedious map interface to SE England]

"We're sorry, the TerraServer Database is temporarily unavailable.  Please
check back again soon, this should only be a temporary delay."

House hears about encoded circuit board missing from Chinese rocket

"Edelson, Doneel" <>
Wed, 24 Jun 1998 16:02:36 -0500
A secret encoded circuit board containing sensitive technology was missing
from the wreckage of an American satellite aboard a Chinese rocket that
exploded in 1996, and American officials said Tuesday at a joint hearing of
two House committees, National Security and International Relations, that
they suspected that Chinese authorities took the board.
[Source: *The New York Times*, 24 Jun 1998, try]

Lucent cracks e-commerce encryption code

Edupage Editors <>
Sun, 28 Jun 1998 14:56:16 -0400
A researcher at Lucent Technologies' Bell Labs has broken the standard
encryption code used for electronic commerce, called secure sockets layer,
or SSL.  Using a physical connection to a server computer operated by an
Internet service provider, a hacker could send about a million carefully
crafted messages to an e-commerce Web site operator, and analyze the
responses to those messages to decode the original message.  Following
Lucent's announcement, Netscape, Microsoft and Security Dynamics' RSA Data
Security unit issued patches to fix the problem.  SSL relies on technology
developed by RSA.  (Reuters 26 Jun 1998; Edupage, June 28 1998)

FIPS-Flop: Reuters on failed NIST key-recovery effort

Alan Davidson <>
Fri, 26 Jun 1998 14:46:39 -0500
The 22-member U.S. Government Technical Advisory Committee to Develop a
Federal Information Processing Standard for the Federal Key Management
Infrastructure (TACDFIPSFKMI) has failed in a two-year effort to design a
federal computer security system that includes "back doors," a feature that
would enable snooping by law enforcement agencies.  Addressing Commerce
Secretary William Daley, the panel wrote that it "encountered some
significant technical problems that, without resolution, prevent the
development of a useful FIPS. ... Because the focus of this work is
security, we feel that it is critically important that we produce a document
that is complete, coherent, and comprehensive in addressing the many facets
of this complex security technology.. The attached document does not satisfy
these criteria."

The failure casts further doubt on the Clinton
administration policy -- required for government agencies and strongly
encouraged for the private sector -- of including such back doors in
computer encryption technology used to protect computer data and
communications, according to outside experts.  But administration officials
said the panel, which is set to expire in July, simply needed more time.
[Source: U.S. effort on encryption "backdoors" ends in failure, By Aaron
Pressman, Reuters, 25 Jun 1998, PGN Stark Abstracting]

[Pressman's article also included this quote from Alan Davidson: "The
administration keeps spending taxpayer money to pursue a ...  strategy
that's wrong-headed and won't protect security.  Its own advisory committee
can't answer basic questions about how to make it work for the government,
yet they continue to push for its adoption by everyone, worldwide."  PGN]

Alan Davidson, Staff Counsel, Center for Democracy and Technology, 1634 Eye
St. NW, Suite, 1100 Washington, DC 20006  202.637.9800  <>

NSA declassifies encryption code

Edupage Editors <>
Thu, 25 Jun 1998 16:22:04 -0400
The National Security Agency has declassified its 80-bit-length Skipjack
encryption algorithm and its 1,024-bit-length key exchange algorithm, and
made them publicly available.  "This declassification is an essential part
of the Department of Defense's efforts to work with commercial industry in
developing reasonably priced computer-protection products," says the
Pentagon.  "This declassification decision will enable industry to develop
software- and smart card-based security products, which are interoperable
with Fortezza."  The Skipjack algorithm is used in the Fortezza PC smart
card, which controls access to computers in the Defense Message System and
other DoD applications.  (*EE Times*, 24 Jun 1998; Edupage, 25 June 1998)

Woman cracker gets five-month prison sentence (Edupage)

Edupage Editors <>
Tue, 30 Jun 1998 14:06:42 -0400
A former U.S. Coast Guard employee was sentenced to five months in prison
for a July 1997 incident, in which she deleted crucial information from the
Coast Guard personnel database and caused the computer system to crash.
Shakuntla Devi Singla was also ordered to serve five additional months of
home detention and three years supervised release, and to pay $35,000 in
restitution to the Coast Guard.  It took 115 Coast Guard employees 1,800
hours to restore the data, which included information on personnel
promotions, transfers, assignments and disability claim reviews.  Singla's
attorney says her action was the result of frustration after her attempts to
report the illegal behavior of a computer contractor were ignored.
(*The Washington Post*, 20 Jun 1998; Edupage, 30 June 1998)

Defining the line between hacking and web surfing...

Eli Goldberg <>
Wed, 1 Jul 1998 19:49:14 -0700
I've recently been faced with a very curious intellectual dilemma: at what
point is the web browsing that we do potentially --- and unknowingly ---
crossing the line into illegal hacking?

RISKS has explored this topic before (such as with alternate uses of
robots.txt files, such as for finding interesting stuff like

Here are two recent encounters that have left me rather perplexed:

Case #1: A lot of AFS directories (a network file system popularized by
CMU in the 1980s) have been starting to appear in recent months as
publically viewable HTTP directories, without the knowledge of their
owners. (In many cases, the directory owners have since graduated or
moved to a staff position, leaving countless long-forgotten files and
E-mail archives in their home directory.)

On two occasions in the past month (one at MIT, and one at CMU),
I've performed ordinary web searches using ordinary search engines, and
ended up finding private documents belonging to friends, with personal
and confidential information.

In each case, I immediately alerted the friend, and they had the
permissions changed immediately, and the offending material removed.
(Now, removing the summaries from a dozen search engines for hundreds of
pages will be another matter. ;)

Could perhaps a tenuous argument be constructed that an individual
reading these private documents --- after realizing that they were not
meant to be publically posted --- was hacking?

Case #2: A *lot* of webmasters omit index.html files in critical
directories, or perhaps forget to configure their servers to deny access
to directory listings to HTTP directories that lack index.html files.
This renders any casual web surfer trivially able to surf the actual
directory tree of their web site --- including their CGI directory ---
and associated private data files.

I've encountered this twice tonight --- once while attempting to
post a housing vacancy at a local University's housing list (system was
down, and I was curious why ;), and a second time while browsing a web
site of a music publisher whose works I have enjoyed in the past.

In the latter case, I immediately stumbled upon full archives of
this company's (unprotected) customer orders, web logs, & associated
information, and other information that I believe any company should
reasonably consider private. Ouch!

Let's say I went ahead and read those files.

Say, I was curious about more information about the company's
customers buying habits, and had no malicious or criminal intent. Would
this be breaking the law?

On one hand, the webmaster *probably* didn't intend for the
information to be public. Does a difference truly exist between
exploiting known configuration errors in web sites, and exploiting known
configuration errors in networked UNIX systems to access information not
meant to be public?

On the other hand, it doesn't matter what they intend. They *have*
made it public, and they've just placed it on a server where any bozo
with a web browser can get to it just by typing a regular URL; how could
one be breaking the law by viewing what they've already placed in a
public area for viewing?

(Certainly, I never signed an agreement to limit my use of the web site to
merely clicking on links, and have every right to type whatever I'd like
into the URL field!)

Now, let's say a competitor to the company in question happened to stumble
upon the same URL and data. What, then?

Y2K problem worries CIA

Edupage Editors <>
Thu, 25 Jun 1998 16:22:04 -0400
Central Intelligence Agency director George Tennant is warning that the Year
2000 computer bug (found when programs are unable to correctly interpret
dates past 1999) "provides all kinds of opportunities for someone with
hostile intent" to gain information or plant viruses.  "We are building an
information infrastructure, the most complex the world has ever known, on an
insecure foundation."  (*USA Today*, 25 Jun 1998; Edupage, 25 June 1998)

Galaxy IV, 600 days and Y2K

"Ben Torrey" <>
Wed, 1 Jul 1998 11:17:36 -0400
The following item is from Dennis Elenburg, "The Y2K Weatherman",,, 1 July 1998,
re: the Galaxy IV failure, RISKS-19.75-77]

"Well, yesterday in talking to an engineer, I heard that the source of the
problem was a 600-day date window.  Bottom line, according to this
particular engineer, is that Galaxy IV was taken out by a Y2k-like glitch.
The recovery from the loss of this (single) satellite was pretty impressive,
but what happens when we lose several satellites at the same time?  Will we
be able to recover communications then?"

[The list he refers to is his own Y2K Weatherman Report.  I imagine that
readers of RISKS would also be very interested in more information on this.
Ben Torrey,]

Galaxy IV muzak withdrawal

Philip Edmonds <>
Wed, 24 Jun 1998 10:45:57 -0400
The loss of transmission from the Galaxy IV satellite last month made some
customers realize how much they depended on Muzak. In Lafayette, Indiana,
one upset and elderly Burger King customer told the manager: "Now I just
have to sit here and hear myself think."  [Source: *The Globe and Mail*, 24
Jun 1998]

Phil Edmonds

No manual switching for railroads; result, famine

"Edelson, Doneel" <>
Wed, 1 Jul 1998 15:48:38 -0500
This is an excerpt from the CSIS Y2K conference.

Gary North's Y2K Links and Forums   Summary and Comments
Category:   Shipping_and_Transportation
Date:   1998-06-24 19:34:02
Subject:    No Manual Switching for Railroads; Result, Famine

At a June 2 conference on y2k sponsored by the Center for Strategic and
International Studies, Alan Simpson confirmed what I have been saying for
over a year: the trains will go down. He said that the railroads have
abandoned manual controls.  "Going back to the rail system, they've taken
out manual points. I talked to some of the major rail companies a few days
back and said, 'Go to manual.' And they said, 'All our manual points are in
the warehouse up in New York State waiting to be disposed of. We cannot
switch manually anymore. We have taken out manual reversion systems on most
of our key communication, power, and switching systems.' " Conclusion: * * *
* * * * * * * And a few weeks ago he started looking at this, and it was
Bruce Webster here who mentioned about, in one of his presentations, the
could-be famine in the United States in 2000. And like most of you here I
thought rubbish, rubbish, until we started looking at the infrastructure and
started the wildfire scenarios on what if.  And looking at New York and
California, I walk into a supermarket and I get lettuce, fresh vegetables,
any day of the year. Seven days ago they were in a field in California. Now
they're in a supermarket just outside New York. We know the switches on the
railroads are faulty. We know because of mergers, even today, many of the
major corporations in the railroad business don't know where the railway
stop is.  When you move this way through, come 2000 you could have a
scenario -- and when you look at this, it's the Soviet Union in the '80s --
where there's plentiful supply of food in the fields, but you can't get it
from the fields to the towns to feed the population. This is not a way-out,
whacko scenario. This is for real.

A new wrinkle in address harvesting?

George Swan <>
Mon, 29 Jun 1998 19:45:00 -0400 (EDT)
I received a copy of a chain letter recently.  This chain letter claimed
that a dying child's last wish was to have a chain letter sent out across
the internet, to raise the public's level of awareness of the dangers of
"cerebral carcinoma".  A corporate sponsor was going to donate three cents
to the American Cancer Society for every copy of the letter that went out.
Readers were asked to add the e-mail address of the American Cancer Society,, to their carbon copy list when forwarding it to their friends.

Most chain-letter frauds seem aimed at the reader's greed.  The new wrinkle
in this one was that it was aimed at the reader's generosity and altruism.
I believe the perpetrator's real intent was to harvest live e-mail addresses.
I suspect that they intended to build two lists.  I suspect that all those
who actually responded to the campaign have marked themselves as both
generous and trusting, and will be sent a second, more pushy, campaign for

Re: More on @#$%& Software (Agre, RISKS 19.83)

Wed, 01 Jul 1998 8:46 -0500
Mr. Agre's observation raises a disturbing issue regarding the languages of
choice in computer science courses.  I have grown increasingly concerned
that a sizable number of colleges and universities have chosen C or C++ as
their language of choice based almost solely on its prevalence in the
marketplace.  While I agree that both are excellent, capable languages, they
must be evaluated in the context of their original application.  C (and by
extension C++) was designed as a system software programming tool, to be
used by experienced programmers to develop operating system and related
software; it allows the programmer wide latitude and great flexibility,
assuming in almost every case that the programmer knows what he/she is
doing.  On the other hand, this laissez-faire approach can lead to
extraordinary, and sometimes destructive, program behavior under other
circumstances, particularly those involving inexperienced programmers.
Framed another way, it's a matter of choosing the right tool for the job at
hand.  C/C++ is probably the right tool if you're developing system
software; I maintain that is not always the case for general application
software development.

Having taught both Pascal and C++ for over 10 years I've seen the situation
Mr. Agre's describes almost every semester: student programs inadvertently
walking off the end of an array.  With Pascal the language's run-time bounds
checking caught this every time; the lack of these checks in C++ has been
the source for countless hours of debugging baffling program behavior.  Time
and again, I have cautioned my students to treat C++ as an exquisitely
capable power tool with few, if any, safety features: in the right hands it
can do wonders, allowing a craftsman to fashion a work of art, knowing all
the while that a minor slip-up could cost him a finger, arm, or leg.  While
languages such as Pascal and Ada have taken a beating over the years from
various constituencies within the programming community for a wide variety
of alleged sins, in the final analysis the safeguards built into these
languages offer significant value-added to project managers in terms of the
avoidance of this type of common logical errors within their program

Michael A. Nelson, ARINC, Incorporated

REVIEW: "The Year 2000 Software Problem", Capers Jones

"Rob Slade" <>
Wed, 24 Jun 1998 12:31:54 -0800
BKY2KSWP.RVW   980410

"The Year 2000 Software Problem", Capers Jones, 1998, 0-201-30964-5,
%A   Capers Jones
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D   1998
%G   0-201-30964-5
%I   Addison-Wesley Publishing Co.
%O   U$29.95/C$41.95 416-447-5101 fax: 416-443-0948
%P   335 p.
%T   "The Year 2000 Software Problem: Quantifying the Costs and
       Assessing the Consequences"

    "When the twentieth century ends, many software applications
    will either stop working or produce erroneous results since
    their logic cannot accept the transition from 1999 to 2000,
    when the dates change from 99 to 00 ... The costs of defending
    against litigation and lawsuits can approximate half a year's
    software budget, but damages and penalties from suits that are
    lost can reach multiples of annual software budgets and lead
    to bankruptcy ... Unfortunately, current data indicates that
    at least 15% or software applications will not be repaired in
    time."  - from the Introduction

This book is a warning.  By its own admission, however, it comes too
late.  Is this book simply an insightful and focused locking of the
barn door after the horse has left the building?

Chapter one provides an executive overview of the situation.  It shows that
year 2000 repairs should have started some time ago.  However, it does also
demonstrate that it is barely possible to start such repairs now, provided
heroic measures are undertaken.  It also proves that such repairs then would
have been much less costly than the same repairs now, and furnishes rough,
but well supported, estimates of costs for the repair of applications, and
for the failure to repair.  A historical review in chapter two also notes
that there is a benefit to the year 2000 problem: it will force companies to
pay attention to their software inventory.  Chapter three is rather odd,
defining a handful of terms associated with applications development.  The
common metric for year 2000 work is the number of lines of code to be
checked.  Jones prefers the function point, and chapter four looks at
conversion factors plus a glance at the size of the problem as a whole.
However, it also starts to deal with direct and indirect costs, particularly
in regard to litigation, and loses some focus thereby.  Chapter five is a
very thorough (perhaps at times overly thorough) assessment of the total
impact of the Y2K problem on the United States, looking at the total cost,
and cost by state, industry, programming language, and so forth.

Advice on the actual fixing of the problem starts with program testing
in chapter six.  Chapter seven looks very briefly at database repair.
Litigation and liability is reviewed in chapter eight.  The analysis
of business failure risks, in chapter nine, seems to lean heavily on
litigation as well.  Chapter ten discusses the rise of the year 2000
repair industry.  Retrofitting applications by the use of masking or
windowing is mentioned in chapter eleven.  The heavy United States
emphasis of the book is partially rectified in chapter twelve.  The
analysis of the scope of the project by country is somewhat flawed by
assumptions that figures per line of code can be directly converted
from US surveys.  However, the chapter also looks at the impact of
conversion to the Euro (the new European currency) and the diverse
impact this may have on the problem as a whole.  Chapter thirteen
looks at factors that modify costs for various industries.

Chapter fourteen examines a number of problems that may arise in
various sectors if the problem is not fixed in time.  A review of
general defensive tactics is contained in chapter fifteen.  Appendices
B, C, and E contain additional sources of information.

In general terms, the book does not give much in the way of advice for
dealing with the crisis except for the suggestion to use masking in
preference to date field expansion.  However, it does provide you with
some lovely frightening figures to use next time the CEO asks you if
this Y2K thing is really of any importance.

copyright Robert M. Slade, 1998   BKY2KSWP.RVW   980410

Please report problems with the web pages to the maintainer