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 22

Thursday 12 June 1997

Contents

o Washington D.C. air traffic slowed
PGN
o Poorly designed train signal nearly causes crash
Martin Minow
o Computer glitch slows trains
Jeremy Epstein
o Cut cockpit wiring found on airliner
Matt Welsh
o Company blackmails Netscape for details of browser bug
Jim Griffith
o Censorship from half way around the world
Jeremy Freeman
o Smith Barney customers become momentary millionaires
Jim Griffith
o Texas Drivers in the Privacy Pothole
Lauren Weinstein
o Largest Database Companies to Restrict Use of Personal Data
Edupage
o Risks of being a spammer
Jim Griffith
o Major corporation's misconfigured FTP server
John P. Wilson
o 3001: Improving A Classic
Scot E. Wilcoxon
o Geez Pleez Sloueez
Mark E. Ingram via Peter Ladkin
o Re: When is 0 not 0? The wonderful world of the Web
Mathew Lodge
David Jones
o IFIP WG 11.3 Working Conference - August 11-13, 1997
David Spooner
o CFP: 1998 Symposium on Network and Distributed System Security
Matt Bishop
o CFP: The Impact of the Internet on Communications Policy
Nora O'Neil
o Info on RISKS (comp.risks)

Washington D.C. air traffic slowed

"Peter G. Neumann" <neumann@chiron.csl.sri.com>
Thu, 12 Jun 1997 18:22:08 PDT
Air-traffic control around the eastern United States was seriously slowed
down for nearly eight hours on 11 Jun 1997 because of a wiring error that
occurred two months ago when new communications equipment was being
installed.  The main system at National Airport for communication with
aircraft in flight broke down.

Another aggravating episode occurred at Dulles International on the same
day, when a man with a briefcase ran through a security checkpoint.  80
flights were delayed when police made 2,000 passengers go through metal
detectors for a second time.  That is a really nasty kind of
denial-of-service attack, even if computer-unrelated.


Poorly designed train signal nearly causes crash

Martin Minow <minow@apple.com>
Wed, 11 Jun 1997 20:24:41 -0700
An article in the Swedish newspaper, *Svenska Dagbladet* (12 Jun 1997)
describes a potentially-catastrophic train collision that was avoided
by a train engineer with "good local knowledge." See
<http://www.svd.se/svd/ettan/dagens/tagsignal.html>
with a graphic on <http://www.svd.se/svd/ettan/dagens/tag_grafik.html>
(Note: these URL's are only valid 12 June, but the articles can be
retrieved for a week by following "previous day" links.)

[Translator's note: this is a very quick summary of a complex article.
There are a few technical terms that I don't understand in the Swedish, and
I apologize for any errors.]

The main train line from the South and West of Sweden enters Stockholm on a
bridge over Lake Malar that is, as I recall, at least 50 meters over the
water. At the entrance, five tracks merge into the two tracks that cross the
bridge. On a dark January night, a local train had previously stopped on a
parallel track due to an engine failure.  Another locomotive was then
coupled onto that train to take it into the station. That train's engineer
did not observe a lit "stop signal" before the switch leading onto the
bridge, but was concentrating on the green "main signal" on the bridge
itself.

However, the "main signal" was lit for an oncoming express train proceeding
from the South. Fortunately, the express train engineer "had good local
knowledge" and realized, when he saw the local train moving, that it would
merge onto his track. He warned the passengers and brought the train to an
emergency stop without colliding with the local train. [The X2000 is the
Swedish high-speed train, and can attain over 150 miles/hour. I would
imagine that it was going at least 80 miles/hour (130 km/hr) at the time.]

The incident report provides a critical assessment of the "stop signal"
system, noting that rules for its placement and marking are unclear and
incomplete, as well as noting that train engineers are not always
knowledgeable about its function.

The article's graphic notes that, while the "main signal" always shows
either red (stop) or green (go), the "stop signal" is off for "go" and red
for stop. Also, the "main signal" is replicated on the train engineer's
console, while the "stop signal" is not replicated.

>From the article: "We have discovered a basic system [design] error.  The
track control system [this may be an incorrect translation of "regelverket"]
has not been modernized and adapted to the newer technology. The people and
the technology did not work well together." said Anders Lundstrom, the lead
incident investigator.  The investigators also noted that the "stop signal"
is only used in a few heavily-trafficked parts of Sweden and is not lit in
normal traffic, which results in engineers forgetting that it is
there. Also, in other contexts, an unlit signal would be an error condition
that means "stop." [The article also noted that, unlike "main signals," the
"stop signal" is not replicated on the train's control console, making it
easier to overlook.]

The graphic gave me a clearer understanding of what happened.  In case you
want to attack it, here is a brief glossary:

"rod"         red
"gron"        green
"hjaplok"     assisting locomotive (pulling the local train).
"X2000"       express train
"huvudsignal" main signal: shows either red or green, replicated in the train.
"stopplykta"  stop light. Shows red or nothing. Not replicated.

Martin Minow  minow@apple.com


Computer glitch slows trains

JEREMY EPSTEIN <JEPSTEIN@cordant.com>
Fri, 06 Jun 1997 08:35:45 -0400
Trains on the Washington D.C. Metro system's Blue line are running 20-30
minutes behind schedule this morning, due to a "computer glitch".  The
computer that schedules the trains is malfunctioning, as is its backup.  No
word on whether the glitch is hardware or software, how often the backup
computer is tested, etc.  (Source: WAMU-FM)

  [Actually, this is becoming so common it may not even be RISKS-newsworthy
  any more.  BART had several more bad days this week, with computer outages
  causing manual operation and the usual delays.  PGN


Cut cockpit wiring found on airliner

Matt Welsh <mdw24@cl.cam.ac.uk>
12 Jun 1997 09:04:10 GMT
AP via CNN's web site (www.cnn.com) reports on June 11, 1997 that "Cut
wires were found underneath the cockpit of a Pan Am plane undergoing
routine maintenance checks at Kennedy International Airport Wednesday,
but the safety of the plane was not compromised, officials said."

The remainder of the article is at
http://www.cnn.com/US/9706/11/plane.wires.cut.ap/index.html (CNN
Interactive URLs are almost always valid indefinitely) although as
one expects from such a report there are little technical details
and a lot of hot air from 'officials' trying to cool the situation down.

M. Welsh, Vrije Universiteit Amsterdam.


Company blackmails Netscape for details of browser bug

Jim Griffith <griffith@netcom.com>
Thu, 12 Jun 1997 18:05:53 -0700
In an article today, CNN reports that a Danish company has found a bug in
Netscape's Communicator Suite which allows remote users to read any file
stored on the hard drive of a PC web server.  CNNfn reports that they and PC
Magazine have verified the existence and nature of the bug.  The Danish
company in question, Cabocomm, stated that they will not release details of
the bug until Netscape has fixed it, so I can't provide specifics.

While this is nothing new, one aspect struck me as unusual.  The Danish
company further stated that Netscape's reward of $1000 and a t-shirt is
"insultingly low" considering the severity of the bug.  They have stated
that they will provide Netscape with the specifics of the bug if and only if
1) Netscape provides "reasonable compensation", or 2) Netscape sends a
representative to Denmark to collect the bug details.  In other words, until
Netscape pays up, they don't get their bug.

http://cnnfn.com/digitaljam/9706/12/netscape_pkg

Jim


Censorship from half way around the world

Jeremy Freeman <jeremy@vip.net>
Thu, 12 Jun 1997 13:47:31 -0700
Recently, I was checking out the latest news on Hotwired. I came across a
story of how a controversial, previously unpublished report called the JET
Report found its way on to the Internet. The report detailed how many child
abuse cases that occurred in Britain's Nottinghamshire County some time ago
were incorrectly identified as 'satanic child abuse'. For some reason the
Nottinghamshire County Council did not want this report in the open, so they
threatened the British reporter who posted the report to the Internet with
court action. Not only did they threaten to sue him if he did not
 remove the report, they threatened to sue if he did not remove the Links
to mirror sites of the report around the world.

This bothered me. I believe that any information concerning the public
should be made available for the public to read. Further, I despise the fact
that they made the reporter take down Links to mirror sites. A link is not
infringement of copyright. They used big government intimidation and scare
tactics to force the burial of the report.

So in protest, I mirrored the JET Report on my server and registered the
page with the search engines.

Not long after, I received an e-mail from Nottinghamshire County's barrister
instructing me to remove the "JET Report" or face legal action on the
grounds I was infringing on their copyright. Fearing a long drawn out case
in British court, I removed the report and in its place put a hyperlink to
another mirror site in the United States. About 5 hours later I received
another e-mail explaining to me that a hyperlink to a mirror site was
in-effect the same thing as putting the report on my page. The e-mail went
on to say that if I did not remove the link, court action would commence
without further notice.

Now, my page that formerly contained the JET Report contains a detailed
report of the events surrounding this incident, but not the report or any
links to it.

The RISKs are: Assuming one is immune from prosecution even though they
reside in another country and that a judge will understand that providing a
link to another site is not the same as hosting it.

The site detailing these events is: http://www.jeremy.bc.ca/jetrep.htm

Jeremy Freeman, Penticton, BC, Canada


Smith Barney customers become momentary millionaires

Jim Griffith <griffith@netcom.com>
Thu, 5 Jun 1997 11:59:44 -0700
CNNfn reports that a computer glitch at Smith Barney caused half a million
customer accounts to be credited with $19 million each for a brief period
Wednesday night.  Company representatives claim that customers did not have
access to the money, and that the balances were only visible to Smith Barney
brokers and any customers who happened to look at their account balances via
the Internet during the brief period that the problem exists.  The problem
was reportedly quickly noticed and fixed.

$19 million x 525,000 accounts = 9,975,000,000,000.  That's $9.975 trillion,
folks.  Methinks someone misplaced the national debt by mistake...

http://cnnfn.com/hotstories/bizbuzz/970605/smith_barney

Jim


Texas Drivers in the Privacy Pothole (PRIVACY Forum Digest V06 #08)

Lauren Weinstein; PRIVACY Forum Moderator <lauren@vortex.com>
Wed, 11 Jun 97 14:39 PDT
PRIVACY Forum Digest      Thursday, 12 June 1997      Volume 06 : Issue 08
            Moderated by Lauren Weinstein (lauren@vortex.com)
              Vortex Technology, Woodland Hills, CA, U.S.A.
           From the PRIVACY Forum Five-Year Anniversary Issue
   [For the most recent issue, see http://www.vortex.com and click on
   "Current Edition of the PRIVACY Forum Digest".]

In yet another example of "public record" data running amok, drivers in
Texas will no doubt be pleased to learn that their names, addresses,
birthdays, license plate numbers, and a variety of other data, is now
publicly available on the Internet.  And of course, broad searching
capabilities based on a variety of criteria are included!

No longer need the potential thief follow that luxury vehicle all the way
back to a residence.  No need for the sickie who harasses young women to
follow his next lovely target all the way home.  And that guy you
accidentally cut off on the freeway?  He may not have bothered you at the
time, but he can come by to "visit" you later, perhaps in the middle of the
night while you're sleeping.  Use your imagination for more interesting
scenarios.  Yes, thanks to database lookups, all of these folks could
apparently just copy down your license number, then look up the address and
other info at their leisure.  Now, that's progress!

It's not clear who bears the most blame regarding the availability of this
data: the state of Texas, for considering this information to be public
record, or Public Link Corp. of Dallas (www.publiclink.com), for putting it
on the net as a "public service" (with more to come, we're promised).

While theoretically Public Link restricts access to this database to persons
with a Texas driver's license (a license number is needed to establish an
access "account"), procedures for reading the information directly via web
URLs, bypassing the login procedures, have already been widely disseminated
around the net, along with suggested "famous Texans" for lookup.  And of
course, account information for accessing the database via normal login is
also circulating widely.

When public record data just sat on index cards in the back room of the
Hooterville courthouse, it represented a minimal threat to personal privacy.
But as municipalities now try to convert their databases into profit
centers, that same data is becoming one of the most potent threats to
individual privacy, and in some cases personal safety as well.

Lauren, Moderator, PRIVACY Forum


Largest Database Companies to Restrict Use of Personal Data

Edupage Editors <educom@educom.unc.edu>
Wed, 11 Jun 1997 09:15:14 -0400 (EDT)
Eight of the largest database companies in the U.S., including the
Lexis-Nexis on-line search service, have agreed to restrict the kinds of
personal information they maintain about individuals, and to refrain from
augmenting their own records with data from private marketing databases
containing such information as individual's magazine subscriptions, shopping
habits, and personal income.  Privacy advocates have endorsed the agreement
but have expressed concern that smaller database companies that did not sign
on, and will continue to sell such marketing information; they also
criticized the agreement for failing to provide an enforcement mechanism.
(*Washington Post*, 10 Jun 1997; Edupage, 10 June 1997)


Risks of being a spammer

Jim Griffith <griffith@netcom.com>
Thu, 12 Jun 1997 17:50:11 -0700
CNN reports that the Federal Trade Commission will crack down on spammers
who advertise false claims or fraudulent offers.  The FTC may fine such
spammers, it may seek injunctions to bar spamming, or it may do both,
depending on the offender.  It is further asking industry groups for lists
of known spammers, so as to better identify fraud cases.  The FTC is
specifically targeting two types of fraud:

    - Spammers who forge headers or otherwise provide false e-mail
      return addresses (yay!).

    - Spammers who make false claims or fraudulent offers.

If CNN's wording is to be believed, the FTC's goal seem to be to reduce
Internet traffic, rather than to prosecute fraud.

The full text of the article is available at
    http://www.cnn.com/TECH/9706/12/junk.email.ap/index.html

Jim


Major corporation's misconfigured FTP server

"John P. Wilson" <jowilson@mtu.edu>
Wed, 11 Jun 1997 20:14:12 -0400 (EDT)
I set out to download some software from a major corporation's FTP server
(name not given for reasons that will soon be obvious) and rather than go
through the hassle of navigating through their complex web page, I fired up
ftp.  I assumed that the address for their ftp server was ftp.foo_corp.com,
and connected as an anonymous user with no difficulty.  After getting a
directory listing, I noted the fact that there was about eight or so
directories which looked suspiciously like usernames.  A directory listing
of one of these contained a .login, .cshrc, and a .rhosts file.  In addition
to the username directories, there was a directory labeled "research".
Permissions were set so that I could have downloaded anything I liked.

Risks?

1.  There was probably a misconfigured DNS server which sent me to the
computer I connected to rather then the actual FTP server; even if this
was the correct server, there appears to have been a a fairly serious FTP
configuration error and/or failure to change the FTP server from a default
value.

2.  Incorrect permissions were set on a directory obviously labelled
"research".

3.  I question the wisdom of placing any computer which contains company
sensitive/proprietary information on a network which is connected to the
outside world.

4.  People could download saved e-mail from the user's accounts who were
on this machine.

These are the few that I came up with off the top of my head.  The rest,
"should be obvious".

--John Wilson, sysadmin, Department of Education, Michigan Tech.


3001: Improving A Classic

<sewilco@fieldday.mn.org>
Sun, 8 Jun 1997 11:49:41 -0500 (CDT)
In reading "3001: The Final Odyssey", I found that Clarke has used the
current proximity to 2001 to update the background of "2001".  There are a
number of references to our society of the 1990s that had not existed when
"2001" was written.  Clarke gets a chance to make improvements in his
thirty-year-old story, using our history to improve the history in his
story.  (The main story line is separate from these references, and this is
not a review of the book)

There also is a reference to the existence of many computing devices that
are not able to deal with some date calculations.  I'm not sure if Clarke is
suggesting that computer programmers won't solve all date calculations even
after the year 2000, or if Clarke is showing that not all date calculation
problems have obvious solutions.

Clarke has been noting problems with dates and researchers for a while.
In 1975's "Imperial Earth" he included a speech given to the USA Congress
three hundred years in the future, and reported that the speech has been
added to the official Congressional Record with that future date.

Scot E. Wilcoxon   sewilco@fieldday.mn.org


Geez Pleez Sloueez (Mark E. Ingram via Peter Ladkin)

"Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>
Fri, 06 Jun 1997 19:37:57 +0200
Have you ever had a nightmare in which you're flying into an airport in bad
weather, and you see the purser open the cockpit door and hear her say to
the captain, "Try Control-Alt-Delete"? Then you wake up, right?  Well, read
on.

Glossary: GPS = Global Positioning System; ATC = Air Traffic Control;
approach = a strictly defined and certified plan by which an aircraft
approaches an airport runway and lands, even when the runway cannot be seen
until the aircraft has almost landed; GPS approach = an approach based
primarily on use of navigation signals from GPS.  Peter Ladkin

  [begin message From: "Mark E. Ingram" <markt@mickey.mo-net.com>,
  forwarded and mildly edited with permission. PBL]

[The abstract for the report `A Human Factors Approach to Use of
GPS Receivers', by Ruth M. Heron, Waldemar Krolak and Shawn Coyle,
available from http://bluecoat.eurocontrol.fr/reports/
            or http://www.neosoft.com/~sky/BLUECOAT
says in part:]

> Imagine you are about to pilot an aircraft on a GPS approach into a
> busy airport surrounded by high mountains.  You are being buffeted by
> high winds, rain and turbulence.
>
> Then ATC calls for a different approach and you must re-program.  Time
> is of the essence, but somehow your receiver inputs are getting
> scrambled and you can't figure out why.
>
> Finally, as you perform a critical keyboard entry to the GPS receiver,
> all navigation capability is lost because the unit's operating system
> crashes with the message, "Contact Factory, Contact Factory, Contact
> Factory...."  (This message was real, but the problem that invoked it
> has long since been resolved.)

[..] this problem *may* have been resolved, depending on
the circumstances.  It seems that the "Contact Factory" issue has only
been solved *if* the unit has had its software updated during a visit to
the factory.

Since the manufacturer didn't issue a recall (that anybody seems to know
about, anyway) and the FAA did not issue an AD, there are probably still a
lot of boxes out there which haven't been fixed.  Since the point of
emphasizing this issue was *not* to embarrass or otherwise single out any
one manufacturer, suffice it to say that if your GPS unit has a startup
screen showing that its software is level 236 or lower (you know who you
are), it can be prone to the "Address Error 02 Contact Factory" message.

Solution - send it back to the factory.  The upgrade is free.

[end message from Mark Ingram]


Re: When is 0 not 0? The wonderful world of the Web (Turrall, R-19.21)

<Mathew Lodge [...]>
Fri, 06 Jun 1997 13:42:42 -0700
> Netscape (and MSIE) insists however that 020 is actually equal to 16.

This is actually a feature of Netscape's JavaScript parseInt() function. I
originally considered that Netscape meant well when it implemented this
behavior. Then I wondered why, in this day and age, anyone cares enough
about input of octal numbers to code it into an integer parsing function of
a relatively recent language such as JavaScript.

I don't have source code to Netscape's JavaScript interpreter to check, but
I expect that the implementation of parseInt() eventually ends up in some C
code where something like the following takes place:

int error, num;

error = sscanf(line, "%i", &num);

My copy of K&R "The C programming language (2nd Edition)" defines this to
mean that an integer conversion of 'line' will take place; "the integer may
be octal (leading 0) or hexadecimal (leading 0x or 0X)". Hence the same
behavior in the I/O functions of a 90's programming language.

I guess this is the old chestnut of a RISK that code will be used in a
manner that the designers never envisaged. Or perhaps it is the risk of
basing a new language (Java) on the less-than-solid foundations of an older
one (C) ;-)

The final irony is that the page in question,
http://www.halifax.co.uk/mortgage/pay.html, contains JavaScript code to
"validate" the user's input...

Mathew

Mathew Lodge, Product Manager, Cisco Systems   +1 408 527 4908


Re: When is 0 not 0? The wonderful world of the Web (Turrall, R-19.21)

David Jones <dej@inode.org>
Fri, 6 Jun 1997 08:13:04 -0400 (EDT)
The real problem lies in the script that runs the mortgage calculator
itself.  Web browsers do not interpret any of the values typed into forms
they display; all information is sent as-is, in encoded string form, to the
server, where it is up to the CGI script to process it.

It's highly likely that the mortgage CGI was written in Perl, or a C program
that uses strtol().  This just goes to show how important it is to validate
all input data, for both security and correctness reasons.


IFIP WG 11.3 Working Conference - August 11-13, 1997

David Spooner <spoonerd@cs.rpi.edu>
Sun, 8 Jun 1997 11:17:34 -0400 (EDT)
IFIP WG 11.3 Database Security 11th Working Conference on Database Security
11--13 August 1997, Lake Tahoe, California

This conference provides a forum for presenting original unpublished
research results, practical experiences, and innovative ideas in database
security. The conference is limited to about forty participants so that
ample time for discussion and interaction may occur.

For more information on registration and updates on the advance program, see
the IFIP WG 11.3 home page at web address http://www.cs.rpi.edu/ifip/.
Registration information will be posted there in a few days.  If you do not
have web access, please contact David Spooner (spoonerd@cs.rpi.edu) for an
e-mail version of the detailed information.


CFP: 1998 Symposium on Network and Distributed System Security

Matt Bishop <bishop@cs.ucdavis.edu>
Fri, 6 Jun 1997 15:05:45 -0700
The Internet Society Symposium on Network and Distributed System Security,
San Diego, California, March 1998

The symposium will foster information exchange between hardware and software
developers of network and distributed system security services.  The
intended audience is those who are interested in the practical aspects of
network and distributed system security, focusing on actual system design
and implementation, rather than theory.  Encouraging and enabling the
Internet community to apply, deploy, and advance the state of available
security technology is the major focus of symposium.  Symposium proceedings
will be published by the Internet Society.  Topics for the symposium
include, but are not limited to, the following:

GENERAL CHAIR:
        David Balenson, Trusted Information Systems

PROGRAM CHAIRS:
        Matt Bishop, University of California at Davis
        Steve Kent, BBN

Dates, final call for papers, advance program, and registration
information will be available at the URL:
  http://www.isoc.org/conferences/ndss98.
Matt Bishop, Department of Computer Science, University of California at
  Davis, Davis CA 95616-8562, sndss98-submissions@cs.ucdavis.edu
  Phone: +1 (916) 752-8060, FAX: +1 (916) 752-4767,
The Internet Society, 12020 Sunrise Valley Drive, Suite 210 Reston, Virgina
20191-3429 USA  voice 703.648.9888      fax 703.648.9887


CFP: The Impact of the Internet on Communications Policy

<Nora_O'Neil/FS/KSG@ksg.harvard.edu>
Mon, 9 Jun 1997 17:06:05 -0400
HARVARD INFORMATION INFRASTRUCTURE PROJECT
THE IMPACT OF THE INTERNET ON COMMUNICATIONS POLICY
First Announcement and Call for Papers

Co-Sponsors: International Telecommunication Union and
the Center for Law and Information Technology, Harvard Law School
Cambridge, Massachusetts, December 4-5, 1997

Ms. Nora O'Neil, Project Coordinator, Information Infrastructure Project
Harvard University, John F. Kennedy School of Government
79 John F. Kennedy St., Cambridge, Massachusetts  02138 USA
Tel. +1 617-496-1389  Fax:    +1 617-495-5776    nora_o'neil@harvard.edu

Please report problems with the web pages to the maintainer

Top