The RISKS Digest
Volume 19 Issue 12

Friday, 2nd May 1997

Forum on Risks to the Public in Computers and Related Systems

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

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


Internet routing black hole
California child-support deadbeat database flawed
Levi Strauss personnel data stolen
Risks of credit fraud and identity theft, and PEBES
James Sander's Book on TWA 800
Peter Wayner
I see a new idea for 1-900 service: prescriptions by modem
Rob Bailey
Motorola may take legal action over health claims
Mich Kabay
Re: Reuters techie brings down trading
A Labour-ious spelling-checker story
Finn Poschmann
A spell-binding RISK
Mike Lee
On the naming of names
Adrian Robson
Risks of electronic thesauri
Steve Schafer
Re: More on GMT vs BST: RS6000
Dave Sparks
Re: YOMDSTCS: Yet One More DST-Change Story
Steve Work
Info on RISKS (comp.risks)

Internet routing black hole

"Peter G. Neumann" <>
Thu, 1 May 97 18:30:34 PDT
On 23 Apr 1997 at 11:14a.m. EDT, Internet service providers lost contact
with nearly all of the U.S. Internet backbone operators.  As a result, much
of the Internet was disconnected, some parts for 20 minutes, some for up to
3 hours.  The problem was attributed to MAI Network Services in McLean,
Virginia (, which provided Sprint and other backbone providers
with incorrect routing tables, the result of which was that MAI was flooded
with traffic.  In addition, the InterNIC directory incorrectly listed FL
Internet Exchange as the owner of the routing tables.  A "technical bug" was
also blamed for causing one of MAI's Bay Networks routers not to detect the
erroneous data.  Furthermore, the routing tables Sprint received were
designated as optimal, which gave them higher credibility than otherwise.
Something like 50,000 routing addresses all pointed to MAI [Missing in
Action on the Internet?].  [Source: Inter@ctive Week Online, 25 Apr 1997,
article by Randy Barrett, Steven Vonder Haar, and Randy Whitestone.]

Once again we are suffering from inadvertigo, illustrating how the effects
of a seemingly small inadvertence and other collateral factors can cause
widely propagating problems.

California child-support deadbeat database flawed

"Peter G. Neumann" <>
Fri, 2 May 97 08:08:43 PDT
California has already spent $300 million on its Statewide Automated Child
Support System (SACSS).  The projected costs have escalated from the 1991
estimate of $99M.  The Assembly Information Technology Committee, chaired by
Elaine Alquist (D-SantaClara) has just issued a report suggesting that the
system may have to be scrapped: ``Due to significant problems in the SACSS
application, many of which could go undetected until the project is fully
implemented, it is unclear whether the project will ever fulfill the mandate
of the federal government or the child support enforcement needs of
California's 58 counties.''  [Source: *San Francisco Chronicle*, 2 May 1997,

Some of you may recall Simson Garfinkel's report in RISKS-17.30 (28 August
1995) on the legislation that prompted the development of SACSS.

The federal government is paying 90% of the development costs.  If that
funding were cut off, would they be accused of being a Deadbeat?  On the
other hand, the rate of failures reported in RISKS on such system
developments is extraordinarily high, so we should not be at all surprised
if the system is never deployed.  Can you hear Grateful DeadBeat Dads singing?

Levi Strauss personnel data stolen

"Peter G. Neumann" <>
Fri, 2 May 97 12:05:17 PDT
A computer hard-drive was stolen containing personal records for about
20,000 current Levi Strauss employees and 20,000 more former employees.
Information included names, addresses, dates of birth, and Social Security
Numbers.  Bank-account numbers for direct-depositing retirees were also
present.  It is not clear whether this was a theft for the equipment or an
explicit precursor to planned identity theft and credit fraud.

Is there a risk?  L-S spokesman Gavin Power said, ``The information is
written in a complicated computer language that would be very difficult to
crack.''  [RISKS readers may chuckle quietly to themselves.  Nonreaders
might not understand anyway.]  Of course, he added the usual peremptory
remark, ``We are taking steps to make sure this kind of security breach will
not happen again.''  [I suppose they are going to use ``unbreakable'' crypto
with the keys stored on the new hard-drive!??]  [Source: *San Francisco
Chronicle*, 29 Apr 1997, A1, and 30 Apr 1997, B1.]

Please pardon my cynicism.  I guess in a virtual genetic sense,
Levi Strauss *blew genes* all over the place.

Risks of credit fraud and identity theft, and PEBES

"Peter G. Neumann" <>
Fri, 2 May 97 12:10:18 PDT
Observing the foregoing Levi Strauss case, I note that RISKS has frequently
illustrated computer-related risks involving credit fraud and identity
theft.  As a reminder to casual readers, we have recently reported on other
thefts of personal data — the Visa computer containing information on over
300,000 credit-card accounts (RISKS-18.62), and CalTrain's database of
ticket-by-mail commuters (RISKS-19.02).  We also had items on risks involved
in the use of Social Security Numbers and PEBES (Simson Garfinkel,
RISKS-19.05) and identity theft (PGN, RISKS-19.05).

To put this all in perspective, I have submitted written testimony to the
U.S. House Ways and Means Committee subcommittee overseeing the Social
Security Administration and its PEBES system, for a hearing on 6 May.  You
can find the statement on my Website:
  ``The Social Security Internet Website: Technology and Privacy Implications''

You might also check out Chris Hibbert's FAQ, ``What to do when they ask for
your Social Security Number,'' originally reproduced in full in RISKS-14.16
and 17, and updated periodically on various Websites:
  or by e-mail to with the sole content line
    send usenet-by-hierarchy/news/answers/privacy/ssn-faq

James Sander's Book on TWA 800

Peter Wayner <>
Fri, 2 May 1997 11:27:16 -0400
RISKS readers will want to check out James Sander's *The Downing of TWA
Flight 800* (Zebra Current Events, $6.99 in paperback, 10% off at  The book is one of the first serious accounts of the
crash, albeit one written by someone convinced that the U.S. Navy was
directly responsible for the accident.  The strongest part of the narrative
is the detailed discussion of the tests the Navy was apparently conducting
off of Long Island that evening.  The weakest parts may be the analysis of
the debris found on the ocean floor and the jump to the conclusion that any
missile may have come from the US Navy.

The details of the Navy's tests of the Cooperative Engagement Capability
(CEC) may be of most interest to RISKS readers.  This system is apparently
part of the technology used to link several warships together and coordinate
their knowledge of all of the targets in the theatre.  One of its jobs is to
keep track of all of the civilian flights operating and this may be why it
was tested so close to civilization.  While I know nothing about the Navy's
development and can't comment on the accuracy of the description in the
book, I can easily imagine that the Navy would be actively interested in
developing this capability especially after the Vincennes incident in the
Gulf [e.g., see many issues from RISKS-7.16 to 67, and Matt Jaffe in 8.74].

The book goes on to suggest that the Navy was testing the system with a
drone equipped with jamming electronics.  Its job was supposedly to try and
neutralize the system's radar and escape detection.  The warship, on the
other hand, was trying to shoot down the drone, and it fired a missile to do
so.  The book says that as the missile was expecting to receive final
targeting information from the warship in midflight, but that the jamming
prevented this from happening.  The missile thus went looking for the target
on its own and locked on TWA 800 instead.

Again, I know nothing about what the Navy does, but such tests seem quite
prudent to me especially after the damage that Exocet missiles did in the
Gulf and in the Falklands.  In fact, I would insist on such real-world tests
to ensure that the system was truly combat ready.  The book suggests that
there was no real warhead on the missile, which sounds prudent.  It also
photographically reproduces the Navy's warning to the FAA about the military
activity in the region, so perhaps the TWA 800 pilot should have known

The book goes into greater detail about the pattern of debris on the ocean
floor and offers strong theories about what this says about the calamity.
While I have no reason to disbelieve anything that is said, I think a
disintegrating plane would be very random.  But my mind may be prejudiced by
the fact that there are no exact solutions for n-body differential

The book also discusses the red residue left on seats in rows 17,18 and 19
and concludes that they are a trail left by the missile as it passed through
the plane.  The author was able to obtain samples of the seat fabric from
sources inside the investigation and had them analyzed.  He says that
they're consistent with a missile.  Others say it's just melted adhesive.
I'll leave that for the chemists to argue about.

The greatest challenge to RISKS readers may be analyzing the evidence
themselves.  The author gave the seat-cover sample to CBS News, who
apparently returned it to the FBI.  The FBI also served the author with a
subpoena for the radar tape and other data related to their criminal
investigation.  They even subpoenaed the publisher, who was forced to turn
over copies of the book contract and check stubs.  These are all now kept
secret by the FBI's criminal investigation.  This book may be all we have to
discuss for some time.

I see a new idea for 1-900 service: prescriptions by modem

Rob Bailey <>
Fri, 2 May 1997 16:43:54 -0400
An item from Reuters (1 May 1007) entitled "Drugs Dispensed by Modem" tells
about a "telepharmacy system" which consists of "combining computer, modem,
and drug-dispensing unit" (yes... you can see it coming, can't you) so
patients can have pharmacists in the big city phone them prescriptions - not
the paper but the drug itself. The article does say that these machines
would presumably be in physician's offices, so I suppose the chance of
serious abuse would have at least a filter. The system's safety mechanism
consists of a bar-code that will "ensure that the correct drug has been
dispensed". The president of the company (called ADDS, Inc.), Brian Hart,

  "Basically, it's a fail-safe mechanism. By using the bar coding,
  we can be absolutely sure the right item is handed out."

Did he say "fail-safe"? Did he say "absolutely sure"? Ouch.

He does comment that you wouldn't put one in a bus station, but isn't having
them at all a step in that direction? Apparently, Mr. Hart's father was
killed by a goofed prescription. At least in the states, doctors'
handwriting on prescriptions is notoriously poor and I'm sure has led to the
mis-prescription of who knows how much medicine, no doubt occasionally
resulting in death. But I can't help but wonder what precautions will be
taken against hacking this little gem. 1-900-MORPHINE, anybody? $2.99 for
the first minute and after that you won't care any more.

Motorola may take legal action over health claims

"Mich Kabay [NCSA]" <>
Thu, 1 May 1997 07:14:23 -0400
In Australia, there's been quite a fuss over claims that cellular phones
cause all manner of disease.  Motorola responds:

        Phone giant may take legal action over health claims
        Australian Associated Press 29 Apr 1997

  SYDNEY, April 29 AAP - In the wake of growing fears over mobile
  phone safety, industry giant Motorola has hinted it may take legal
  action over claims linking its products to brain cell damage,
  cancer, Alzheimer's and Parkinson's diseases.

  The company's managing director Ron Nissan said today he had
  written to fledgling protection device manufacturer Microshield,
  seeking that it retract the claims made in its sales brochures.

Key points made in the article:

* Microshield announced its protective cell-phone shield in the third week
  of April.

* "The device consists of a woven polyester and nickel casing, a
  PVC phone screen ingrained with ultra fine protective mesh and an
  adjustable polyester-coated aerial guard."

* Device is described as blocking 90% of harmful emissions from the phones.

* Advertising pamphlet claims that cell phones have been shown to cause
  "permanent brain cell damage, cancer cell growth
  acceleration and possible promotion of asthma conditions following
  exposure to microwave radiation at cellular phone frequencies".

* Also claims that cell phones may cause Alzheimer's and Parkinson's diseases.

* Executive Director of the Australian Mobile Telecommunications
  Association (AMTA), Peter Russell, has written to the
  Australian Competition and Consumer Commission (ACCC) to demand
  removal of this brochure.

* ACCC will test Microshield claims using independent investigators.

* Australian researchers announced yesterday that lab mice show higher
  incidence of lymphoma after exposure to cell phone radiation.

M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education
National Computer Security Association (Carlisle, PA)

Re: Reuters techie brings down trading (SteveL, RISKS-18.65)

"Peter G. Neumann" <>
Thu, 1 May 97 18:26:12 PDT
Wilson Chan Chi-kong, 29, the former employee of Reuters financial
information agency who had sabotaged the dealing-room systems, was
apparently motivated by revenge after a dispute with his superior.  The
damage control took more than 1,700 man-hours, and the estimated cost was
HK$1.3 million.  He has been jailed.  [Source: Reuters Computer Engineer
Jailed For Destroying Files, South China Morning Post via Newsbytes News
Network, 1 May 1997]

A Labour-ious spelling-checker story

Finn Poschmann <>
Fri, 02 May 1997 09:27:25 -0400
> Mr. Blair, who will become the youngest prime minister since 1812, has
> said in recent interviews that he will be "a radical prime minister."
> While he hasn't eLabourated, there are indications that he may seek to
> address welfare reform, much as President Clinton and the U.S. Congress
> are trying to do.  [*Wall Street Journal*, 2 May 1997]

The *paper* edition used "Labor" throughout; in going to the *electronic*
edition, the editor — aware of inappropriate americanisation — apparently
ran search-and-replace "Labour" for "labor", which of course the software
duly accomplished, with a somewhat Freudian result.

The usual risks.

  [I'll have to add that one to my 1 April 1996 list of e-items for
  the next chapter in The Hyphenater's Handbook (see RISKS-17.95 for
  the chapter excerpt ``e is for electronic'').  PGN]

A spell-binding RISK

Mike Lee <>
Mon, 28 Apr 1997 18:35:13 -0700
I've just noticed on my Solaris machine a file called /var/adm/spellhist.
It is a log of all spelling errors found by the Unix spell program.  The
user, tty, and date are included in the report. The point of the log seems
to be that the local organization's "dialect" could be integrated into the
system dictionary to make the spell program more accurate, over time.  As
far as I can tell, the spellhist file is present by default and globally
read/write-able under Solaris(es) 2.3 and 2.4.

The spell program reports as misspellings any word it doesn't recognize:
this includes things like many last names and project code-words.  Depending
on the skills of the author, there can be enough genuine misspellings in
many documents that one can get some idea about the spell-checked document.
Also, each spell "session" is logged separately so an interested party could
follow the development of the document over time.

For example, the spell program distilled this message into:

> mikey      pts/1        Apr 28 09:34
> Solaris
> adm
> es
> spellhist
> trojan
> tty
> var
> writeable

The primary RISK is that data meant to be secret could be compromised.  The
secondary RISK is that any Unix filter program could be modified to behave
as a quiet trojan horse in this manner.

A quick fix (for Solaris at least) is to set the H_SPELL environment
variable to /dev/null in whatever startup file is appropriate for your

On the naming of names

Adrian Robson <>
Wed, 30 Apr 1997 12:51:36 +0100
In RISKS-19.07, Danny House correctly states the importance of good naming
conventions for software identifiers, and the risks of poor identifier names
in legacy software.

He rightly identifies global name spaces as the cause. They force the
invention of contrived naming conventions to avoid name clashes.  However,
there have been some attempts to help with this problem. For example, three
features of C++ reduce name space clutter.

The first, shared by all object oriented languages is the class.  A class
has its own name space, so the same name can be used for member functions in
different classes. If this is done carefully then ad hock polymorphism
results, where the same operation can be applied to different objects.

C++ extends its global and class name space with function overloading.  This
allows functions of the same name to be distinguished by their parameter
lists. So the same function name can be applied to objects of different
types without ambiguity.

Finally, the latest versions of C++, implementing the draft ANSI standard,
also have namespaces. These provide a way of preventing name clashes in
larger programs composed of several components.

Adrian P Robson

Risks of electronic thesauri

Steve Schafer <>
Wed, 30 Apr 1997 08:47:43 -0500
Marc Salverson's note about the interpretation of "zzzz" provided by MS
Word's spelling checker reminded me of the behavior of the thesaurus in
Lotus Ami Pro 3.0. If you enter the word "secrets" in a document and invoke
the thesaurus on that word, the first choice presented in the list of
alternatives is "genitalia."

  [Lotus est Mon Ami?]

Re: More on GMT vs BST: RS6000 (Yeomans, RISKS-19.09)

Dave Sparks <>
Fri, Apr 25 19:34:48 1997 +0100 (BST)
The trouble with our legislators isn't so much that they change the rules,
but that the changes they make are often subtle enough to go unnoticed until
several years afterwards.

Some years ago the rule for the end of DST in the UK was changed from "the
Sunday after the fourth Saturday in October" to "the fourth Sunday in
October".  This makes a difference only in years when the first of October
is a Sunday, and since this wasn't going to happen until several years after
the rule change, no-one bothered to reconfigure their computers.  In 1995
many computers changed their clocks a week late.  (The risk here is that an
inexperienced and harassed Unix system administrator would be tempted to fix
the problem on Monday morning by adjusting the system clock - which could
have disastrous consequences.)

Last year the rule changed from "the fourth Sunday in October" to "the
last Sunday in October".  Once again, the change has no immediate effect.
UK computer users using TZ to program their DST clock changes should
change the setting to


if they don't want to be caught out in 1999.

Re: YOMDSTCS: Yet One More DST-Change Story (Bruhin, RISKS-19.11)

Steve Work <>
Tue, 29 Apr 1997 13:50:10 -0700 (PDT)
I have an even stranger story about a double DST adjustment.  On my
computer, I also run multiple OS's.  Last year, I feared what was described
above was going to happen, so what I did was wait until the day after the
time change and boot each OS in succession.  I figured I'd let each one of
them set the clock, then I'd set it to the correct time afterwards, and
there'd be no surprises waiting later on.  Turns out that only Windows 95
adjusted the clock, the others (Linux, OS/2 Warp) didn't.  Apparently Linux
is smart enough to not adjust the clock unless the changeover happens *while
it's running*, the way it should happen.

So this year, I had 95 running the day before the changeover.  What my plan
was to set all the clocks ahead except the computer, and it'd just take care
of itself.  I also have since installed the After Dark screensaver, and have
it set up to display a large digital clock when the PC is not active.

Imagine my surprise when I come out at 4am (daylight time) and the computer
screen shows it's 2am.  The computer had set itself back, not forwards,
apparently.  Then I go over, press a key to deactivate the screen saver, and
Win95 had popped up an window saying it had set the clock ahead and asked me
to confirm it.  The clock in the corner of the screen read the correct time,
4am.  And the next time After Dark came up it, too had the right time.

What happened here?  Was After Dark trying to be a little too smart and set
the clock itself?  And got confused?  Or is this just another weird bug?

Please report problems with the web pages to the maintainer