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 71

Friday 1 May 1998


o Washington Metro Stops Payments on Troubled Computer
D. Scott Lucero
o Euro phone network collapse: France'98 Cup tickets
Cris Pedregal Martin
o A case of GPS jamming by a computer-test failure
Peter B. Ladkin
o Software clandestinely uploading: Intuit TurboTax?
Mike Williams
o British ATMs authenticate with iris-scanning
Tim Pierce
o Re: A new kind of "sin attack"
Reuben G. Torrey
o Re: Yes, Virginia, no classified information is leaked...
Michael Hogsett
o Outrunning Bears
Adam Shostack
o Risks of assumptions
Leonard Erickson
o Y2K Testing Bugs
Name withheld
o Y2K bug and public health concerns
Chris Kuan
o Re: Going to jail innocently over a speeding ticket
John Carr
o Re: Y2K on the road
A. Padgett Peterson
o Passwords
Kevin 'Bob' Fu
o IEEE newsletter on Security & Privacy
Avi Rubin
o CFP: "Software Practice & Experience" on security
Gene Spafford
o REVIEW: "Intranet Security", John Vacca
Rob Slade
o "Beyond Calculation" - seeing the forest for the trees
Mike Martin
o Info on RISKS (comp.risks)

Washington Metro Stops Payments on Troubled Computer

"D. Scott Lucero" <>
Wed, 29 Apr 1998 19:13:44 -0400
*The Washington Post* (29 April 1998) reports that Washington DC's Metrorail
is stopping payment on a system which pinpoints the position and operation
of every train in the 92-mile system and controls 470 switches and 500
signals.  Metro officials say that the system has crashed 50 times in the
last 15 months.  Screens go black, images jiggle, duplicate train numbers
and slow response occur frequently according to officials.  According to the
Metro General Manager, "First we couldn't get the source code from [the
contractor].  Then when we got it, it was in foreign language because they
had a contractor work on it overseas... They've had people come and go.
There has not been total continuity."  A familiar RISK, not having
developers close to the system.  I used to think that not having the
escalators work was a big deal - it appears they've got bigger problems.

Scott Lucero

Euro phone network collapse: France'98 Cup tickets

Cris Pedregal Martin <>
Fri, 24 Apr 1998 13:42:26 -0400 (EDT)
[A well known denial-of-service RISK, reported to remind everyone that these
things keep happening.]

In a news item about the European Union's intention to fine the organizers
of the soccer world cup France'98 (in non-US English: the organisers of the
football world cup...), the leading Spanish daily _El Pais_
(, in Spanish),
reports that (translated loosely):

  [After complaints by the EU that almost all tickets were sold to French
  citizens, the organizers agreed to put 110,000 tickets on sale for
  non-French, through a single telephone number.]  Almost 20 million people
  tried to reach to buy tickets [...] with the result of
  blocking the phone system of several countries especially Netherlands,
  Belgium and the United Kingdom [...] only 15,000 tickets of the
  110,000 available were sold because of the slowness of the system...

  As a consequence of the ill-will generated, the EU may impose a fine of up
  to 10% of the world cup's gross income.

I did not find other reports of this; perhaps the European readers can
report on the extent of the denial of service which must have affected
traffic unrelated to the world cup ...

Cris Pedregal Martin - - Comp. Sci. UMass

A case of GPS jamming by a computer-test failure

"Peter B. Ladkin" <>
Mon, 27 Apr 1998 13:58:11 +0200
A colleague has pointed out to me that a confirmed case of significant GPS
jamming is related at

A 30 Dec 1997 Continental trans-Atlantic flight lost all GPS signals as it
descended south from Albany NY to Newark NJ for landing.  Continental
originally believed that the flight had been subject to intentional military
jamming exercises. The FAA declared an `interference zone' of 300km,
although they believed the jamming was localised around the Albany VOR
navigation radio beacon.

It turns out that the US Air Force Research Lab Information Directorate has
a facility in Newport, NY, that tests antenna emission patterns.  On 30 Dec
1997, they started a test of a GPS antenna with a 5-watt signal, stepping
through frequencies. The tests are computer- controlled, and it wasn't
noticed that at the end of the testing period the transmitter had not turned
itself off. The lab discovered the problem through reading message traffic
reporting a GPS outage in mid-January. The jamming period ran from 30 Dec to
12 Jan 1998.

Peter Ladkin

  [Typo fixed in archive copy.  PGN]

Software clandestinely uploading: Intuit TurboTax?

Mike <>
Wed, 29 Apr 1998 11:50:05 -0400
One of the most widely used consumer programs is Intuit's TurboTax for
Windows 95.  In '98 ('97 tax year) I reluctantly started using it, because
Intuit had bought out Parson's Personal Tax Edge, my preferred package, and
discontinued it.  I also use Quicken Special Edition (bundled with my Compaq
tower), TurboTax For Partnership Returns (necessary for my consulting
business), and Quicken Financial Planner, all promptly registered with
Intuit, by postcard mostly.  The TurboTax splash screens strongly warn to
update the release with late forms and patches, automatically, by clicking
on a button that takes one to their website on the Net.  I have done this
perhaps 3 or 4 times in the '97 tax season, twice getting significant (long)
updates applied automatically.

I was disturbed to discover my summary tax information, not only in the
TurboTax directories where it belonged, but in my Windows directory,
partially encrypted in a file called INTUPROF.INI, along with registration
information.  Among the highly sensitive and demographically valuable fields
shown there are: dependents' names, total exemptions, wages, taxable income,
dividend income, business income, etc.  I have attached a copy of my
INTUPROF.INI for the editor to use as space permits.  [The editor has
removed it.  It leaks too much information.]

I have not been able to reach Intuit on this or other matters: its website
( has no feedback provision, it will not release any e-mail
address for either feedback or Tech Support, and has interminable waits on
phone calls to its HQ.

Do RISKS readers (and fellow TurboTax users) also wonder why this
information is stored encrypted outside its designated area, and whether
this information is being transmitted to Intuit during registration or at
updates, without their consent?  Do they wonder why a firm that sells its
software on the net, and updates it that way, has no e-mail address?

If this is innocent, as I'd guess they claim, why do they make it so
difficult to reach them to ask questions like this?

Mike Williams

British ATMs authenticate with iris-scanning

Tim Pierce <>
23 Apr 1998 13:15:27 -0400
A Reuters piece of 22 Apr 1998 announced the introduction of automated
teller machines that authenticate users by scanning the customer's iris.
Some details:

  The manufacturers said the system, which they described as the first
  of its kind in the world, would be totally secure.

  Customers will have a digital picture of their iris taken the first
  time they go to the bank.

  A camera mounted on the cash machine will then scan their eye every
  time they want to withdraw money. Only if the iris matches the details
  stored in a central database will the transaction proceed.

  "The system is foolproof because each person's iris is unique and
  above all the iris doesn't change throughout life, so it's safer than
  fingerprints," said Richard Lander, a spokesman for Britain's NCR
  Financial Solutions Group, a subsidiary of NCR Corp in the United States.

Some risks: does the iris really not change at all throughout life?  [No.
It can change considerably in color and blemishes. PGN] Are there
circumstances under which the pattern of the iris cannot reliably be read?
For example, would a customer who developed cataracts or glaucoma be able to
authenticate themselves consistently, or would the condition of the eye
confuse the scanning technology?

What happens to customers who lose one or both eyes, due to physical injury
or illness?  If a bank customer with a glass eye comes in to be scanned,
could the bank mistakenly "scan" the artificial eye, and what would happen
under those circumstances?  Could the scanning technology injure such a

Perhaps these concerns are not well founded.  The point, of course, is that
they need to be considered and examined, and it's not clear from this piece
whether that happened.  (A quick scan of some of the other wire services
turned up no other reports of this item.)

This isn't the first time that biometrics have been introduced in
bank-machine technology: a 1995 piece in the CNN archives reported a
technology called `Fingerscan' that was being used experimentally to
identify customers.  That apparently went nowhere; why not?  (Could NCR and
Sensar, Inc. learn something from that lesson?)

  "I think the new system can become popular especially when bigger sums
  are involved and people don't want to bother with their PIN (personal
  identification number)." [Richard Lander]

This may be a more troubling idea, for all the usual reasons.  Is the motive
for this new authentication system one of security, or one of convenience?
If a deeper sense of security motivates people into using ATMs for huge
transactions, it will surely provide a greater motivation to people to find
a way to subvert the technology.

Tim Pierce <>

Re: A new kind of "sin attack" (Bostic, RISKS-19.70)

Wed, 29 Apr 1998 14:45:09 -0400
There is a distinct theological issue with the archive!  The theology behind
the secrecy of the confessional (which has subsequently made its way into
client/attorney and patient/doctor confidentiality) is that the sins cannot
be revealed because they no longer exist. Absolution not only forgives the
action but, from God's not-confined-to-time perspective, makes it as if it
never occurred (living/dealing with the real consequences of sin--dead
bodies, destroyed lives, etc.-- is a separate issue, the reality of which is
never denied).  So, to maintain an archive of sins is, in a sense, to
contradict God who has deleted the archive which did exist in His
mind. Somehow, I don't think this is a smart thing for the penitent to do.

Re: Yes, Virginia, no classified information is leaked...

Michael Hogsett <>
Tue, 28 Apr 1998 13:11:14 -0700
I have to wonder why they simply do not use a public-key encryption system
such as PGP to encrypt their messages before transmission.  It is trivial to
set up, and fairly time consuming to crack.

I set up PGP on my system at home and at work in a number of minutes.  My
mailer (EXMH) integrates PGP when it is available.  It will sign and encrypt
my outgoing messages and decrypt and verify signatures on incoming messages

Michael Hogsett <>
System Administrator, SRI Computer Science Lab

Outrunning Bears (Cohen, 19.70)

Adam Shostack <>
Wed, 29 Apr 1998 03:45:59 -0400 (EDT)
Fred Cohen comments on the popularity of the "run-faster approach" to
computer security.  Unfortunately, run faster is only useful when running
from bears.  It doesn't do a lot of good when worried about a fellow with a
machine gun.  Many people are not aware of tools like Internet Probe Droid,
which is an optimized scanner to find specific security problems by testing
each of thousands of hosts for them.  This is much closer to a machine gun
than a bear.

The popularity of the run faster approach is based on faulty thinking about
the problems that are out there.  (I'm not accusing Fred of this thinking.)

Risks of assumptions (talon-owner, RISKS-19.69)

Leonard Erickson <>
Thu, 23 Apr 1998 01:30:16 PST
Actually, I know of *no* _personal_ computer that stores date/time info as
the number of seconds from a baseline. They tend to store it in bit mapped
fields. A few have already run into trouble. TRS-DOS version 6.2 will not
accept a year greater than 1987, as they kept stealing "spare" bits from the
datestamp field until they only had 3 left! They had to fix this by
eliminating a password hash field.

MSDOS datestamps store the month day of month and year as bit mapped fields
in a 16 bit variable. 7 bits are allocated to the year, which is stored as
an offset from 1980. That is, 0 = 1980, 127 would equal 2107 *if* the date
handling routines allowed a date past 2099, which they don't.

The risk is assuming that because the OS you are familiar with does
something a certain way, so do all other OSes.

Again, the personal computers I am familiar with (mostly TRS-80, and the
more recent PC compatibles) *don't* have OS or even hardware Date storage
based on a count of *anything*.

The PC *does* count "timer ticks" since midnight to determine the time of
day. But that's reset once a day, and is secondary to the real time clock
chips in all PCs since the AT.

Leonard Erickson (aka Shadow)

Y2K Testing Bugs

Name withheld <>
Thu, 23 Apr 1998
There's a whole new class of problem that's been introduced with the Y2K
panic: Y2K testing bugs, which are caused by people screwing around with the
dates on their machines to see if anything will break when the year passes
2000.  Things are breaking, not because programs can't handle the year 2000,
but because they can't handle the dates on the machines jumping around.

I've seen two related cases now.  In one, somebody set some machines forward
to 2000, ran a program that collected data, everything worked, so they reset
the clocks.  Unfortunately, they forgot to get rid of the data they'd
collected while the clocks were set forward, so everything ended up out of
order, with the "year 2000" data showing up as the latest data collected.
In the other, the machine was set to the year 2000, and then rebooted to
make sure it would boot OK.  After it did, the date was reset to 1998.
Unfortunately, this leaves the year 2000 as the latest date in the boot log,
and anything that checks to see if something has happened since the last
time the machine was booted returns a false negative.  Both these problems
are easily fixed, but might not be easily detected.  With Y2K testing being
done on a large scale, I'm wondering how many stupid little problems are
going to be introduced that persist until 2000.

Y2K bug and public health concerns

"Kuan, Chris CH" <>
Thu, 30 Apr 1998 08:44:27 +1000
A report based on simulation tests of Y2K effects includes these items:

* ``Enough toxic chemicals would have been released into Coffs Harbour's
water supply to kill its entire population.''  The entire chemical holdings
were dumped into the water in a single shot.

* The Reserve Bank's vaults flew open.

* The Federal Government is allocating $126 million for federal agencies.  The
national electricity industry is spending close to $100 million, fearing
widespread power blackouts and the failure of protective coats around live
cables as a "worst case scenario".

* Telstra is spending almost $600 million on Australia's telecommunications.

Chris Kuan, BHP Information Technology

  [Source: Y2K 'Could Kill a Town', by Darren Goodsir and Martin Chulov,
  *Sun-Herald*, Australia, 26 Apr 1998, p. 33.  PGN Stark Abstracting]

Re: Going to jail innocently over a speeding ticket (RISKS-19.69)

John Carr <>
Thu, 23 Apr 1998 19:29:44 -0400
The national driver database and interstate agreements have been mentioned
before, in RISKS-14.26 and 14.27.  Many states, but not all, have laws like
the New Jersey law mentioned in 14.27: knowledge that one's license is
invalid is not an element of the crime of driving without a license.

In this case (16.69) they found the right man.  The old articles described
problems caused by the database using name (or partial name) and birthdate
as keys.

Mistaken identity is apparently not rare.  A Boston _Globe_ article last
year described a similar case.  A man had his Massachusetts license
suspended because Pennsylvania put a name and birthdate matching his in the
national driver database.  He didn't find out until he tried to renew his
license.  The article pointed out a bug in the system: when Massachusetts
checked the national database and detected a match based on name, it filled
in an empty field based on information from its own database: the Social
Security Number.  Now the other person's national record has his SSN.

The author of the RISKS-14.27 article said he had to convince his home state
of the mistake.  That was apparently too easy and the system seems to have
closed the loophole.  According to the _Globe_ article, the driver had to
convince Pennsylvania to admit that it made a mistake.

I know a man who got into trouble because his name and birthdate matched
that of someone in the database.  His case proves that the database doesn't
depend on gender: he got stuck with the driving record of a woman with the
same name.  Fortunately the judge was lenient.

I consider this primarily a social and political problem.  The technology
is working more or less as intended.  There are minor bugs like the SSN
leaking from one database to another, but the use of the SSN as a universal
identifier is a choice approved by politicians who knew or should have
known of the risks.

Here are the two fundamental principles of driving laws.

1: Driving is not a right so the government can take away one's "privilege"
   to drive essentially at will.

2: The people who make and enforce traffic laws are generally not subject
   to them.

The government wanted a system where any state could suspend the license or
right to drive of any person in any other state (see item 1).  They got it.
The states designed laws based on the principle that it is better to convict
an innocent man than let a traffic law violator escape "justice" (see item
2).  The national database merely continues that tradition.

In other words, this is another case of bad requirements leading to bad

Re: Y2K on the road (McLain, RISKS-19.69)

"A. Padgett Peterson" <>
Thu, 23 Apr 1998 14:44:10 -0400 (EDT)
Computer ? 1979 Toyota ? Right. - P

  [Several folks doubted that story.  PGN]


"Kevin 'Bob' Fu" <>
Wed, 29 Apr 1998 08:45:19 EDT
Lecturers often give computer demos during large lectures.  One lecturer
recently muttered this while logging in to our campus-wide system:

Lecturer: "Wrong password? ... Hm, oh!  Wrong daughter."

Kevin E. Fu (

IEEE newsletter on Security & Privacy

Avi Rubin <>
Tue, 28 Apr 1998 00:38:57 GMT
This is to inform people who are interested in the IEEE Computer Society's
Technical Committee on Security and Privacy's newsletter, CIPHER. The URL
for the online version can be found at

CFP: "Software Practice & Experience" on security

Gene Spafford <>
Mon, 27 Apr 1998 09:52:48 -0500
Call for Papers, Special issue of "Software Practice & Experience"
Experiences with Computer and Network Security,
Contact me (the guest editor) for details on submissions (by 1 July 1998),
or to volunteer as a referee.

  SP&E Special Issue Submissions
  c/o Prof. Eugene Spafford
  Department of Computer Sciences
  Purdue University
  West Lafayette, IN 47907-1398

Spaf <>

REVIEW: "Intranet Security", John Vacca

Rob Slade <>
Tue, 28 Apr 1998 08:23:33 -0800

"Intranet Security", John Vacca, 1997, 1-886801-56-8, U$49.95
%A   John Vacca
%C   403 VFW Drive, PO Box 417, Rockland, MA   02370
%D   1997
%G   1-886801-56-8
%I   Charles River Media
%O   U$49.95 800-382-8505 617-871-4184 fax 617-871-4376
%P   506 p. + CD-ROM
%T   "Intranet Security"

While the author seems to be sincerely motivated by a concern for security,
this book badly needs more discipline, more material, and more fact
checking.  Not to mention a closer alignment with the stated topic.

Part one is a general guide to data security.  Chapter one, although titled
"Intranet Security Trends," provides an overview of vulnerabilities, means
to address them, and security policies.  Security policies are covered in
more depth in chapter two, and then really again in chapter three, although
there are slight variations in emphasis.  Chapter four introduces Internet
(TCP/IP) specific topics, but still is dealing at the level of policy.  Part
one closes with a look at hiring or being hired (it's a bit difficult to
tell) for a security position.

Part two is said to address intranet security threats, but starts out with a
look at security protection tools in chapter six.  (More specifically,
chapter six presents a kind of extended case study of the work at Portland
State University.)  Chapter seven discusses security applications again, in
part more generally, and in part mentioning specific proprietary programs.
Chapter eight does the same thing.  Finally, chapter nine does look at a
variety of risks associated with Internet use, although it seems to keep
lapsing into a discussion of encryption as a security tool.  (There is also
a rather odd statement about using antiviral software to protect
confidential documents.)  Identification of computer viruses, in chapter
ten, contains generally good advice, but some extremely suspect assertions
in the background discussion.  Chapter eleven is supposed to talk about
antivirus software, but after a nonsensical description of an almost
unknown "type" of antiviral software, the rest of the chapter meanders
around oddball virus related topics without divulging too much useful
information.  (This emphasis on viruses is, of course, rather gratifying
from my perspective, but doesn't seem to have much to do with the stated
topic of intranets.  In terms of intranets, the gravest viral danger is
probably that of the MS Word macro viruses, which get some space, but don't
seem to be a priority.)

Disaster avoidance, in part three, would seem to be what computer security
is all about.  The recovery part seems to be primarily physical, since
chapter twelve stresses redundant hardware and hot sites.

Part four discusses development, implementation, and management of security.
Chapter thirteen reprises some of the information from part one in reference
to workstations.  Database security is important, but chapter fourteen does
not provide enough coverage to really get down to work on it.  Chapter
fifteen looks briefly, but not in much detail, at security for remote users.
Policy is revisited in chapter sixteen.

Part five is supposed to look to the future, but chapter seventeen is little
more than a collection of computer crime war stories.  Chapter eighteen
proposes that the Year 2000 problem might raise security issues, but is
short on specifics.  Internet security related issues are once again
discussed briefly in chapter nineteen.  Chapter twenty is supposed to be a
summary and recommendations, but seems to be simply a rather random
assortment of additional security related bits.

Although there is some general security related material in this book,
almost nothing relates directly or particularly to intranets.  The security
content is not too bad as far as generic advice is concerned, but isn't
anything too significant, either.  Overall the book is woefully short in
some areas, redundant in others, and badly disorganized.  For standard
security advice the reader can easily do better.

copyright Robert M. Slade, 1998   BKINTRAS.RVW   980206

"Beyond Calculation" - seeing the forest for the trees

"Martin, Mike" <>
Thu, 30 Apr 1998 12:07:15 +1000
What will be the impact of computer and communication technology on society
in 25 years? In 50 years? Rob Slade's review of this book (Risks 19.70)
raises the interesting issue of how to see the forest for the trees.

I don't have the answer.

However I'd like to make some suggestions as to what the question means.

A paper by Peter Drucker that appeared in the Harvard Business Review a few
years ago began:

"Every few hundred years, throughout Western history, a sharp transformation
has occurred. In a matter of decades, society altogether rearranges itself.
Its world view, its basic values, its social and political structures, its
arts and institutions. Fifty years later, a new world exists. And the people
born into that world cannot even imagine the world in which their
grandparents lived and into which their own parents were born.

"Our age is such a period of transition."

From memory, Drucker suggested that the current transition can be dated from
around 1950 and that, in fact it may take 75 or 100 years before the full
implications become apparent.

Typically, technology inventions are used at first to provide new solutions
to existing problems. The horseless carriage was exactly that.

Typically also, a major technology invention fails to reach its potential
until other, enabling inventions have occurred. The steam railway had only
limited usefulness, until the invention of wrought iron permitted rivers and
gorges to be affordably bridged.

Gutenberg invented the European version of the movable type printing press
about 1450, but it was another 400 years before an industrial process was
invented for making cheap paper from wood pulp.

The impact of computer and communication technology 25 or 50 years from now
might turn out to be further refinement and spread of existing uses. Then
again, other enabling inventions may open directions that we cannot guess
at. And they won't necessarily be benign.

Suppose the advent of quantum computing allows rapid factoring of extremely
large numbers. Much of today's security technology would be in immediate
disarray. Or suppose widespread deployment of a secure Internet payment
system puts control of the world money supply into the hands of a few
maverick bankers in hitherto obscure nations.

Tomorrow may be like today, only more so. Then again, it may herald another
"Druckeresque" transformation. Any suggestions about already emerging
technologies that may signal the latter?

Mike Martin, Sydney, Australia

Please report problems with the web pages to the maintainer