The RISKS Digest
Volume 23 Issue 5

Wednesday, 3rd December 2003

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…


Two loose screws killed Disneyland rider
US railroad uses Wi-Fi to run 'driverless' trains
Lars Kongshem
Nuclear plan shut down by lightning strike
Fuzzy Gorilla
Tanker Truck Shutdown Via Satellite
Fuzzy Gorilla
Microsoft Windows, Auto Edition
Andrew Whitby
What Bill Gates Says About Security (from InformIT)
Dawn Cohen
Another large gas bill
Amos Shapir
UK MoD scraps 120-million-pound computer project
Fuzzy Gorilla
How Much Is Privacy Worth?
Monty Solomon
Government e-mails apparently sent to hairdresser
Neil Youngman
'Master' and 'slave' computer labels unacceptable, LA officials say
Henry Baker
Security subtleties
identity withheld by request
Man trapped for hours by payphone
Mark Brader
Debian security breach and forensic analysis
Gerrit Muller
Re: Security patching: a story from the trenches
Walter Dnes
Dangerous looking e-mail from quickbooks
Kyle York
Re: In-Security clearance
Peter H. Coffin
Re: Amber Alert, Coming to the Inbox Nearest You
Timothy Knox
Re: Cehck tihs out!
Rodney Hoffman
ANNOUNCE: New mailing list for secure application development, SC-L
Kenneth R. van Wyk
Info on RISKS (comp.risks)

Two loose screws killed Disneyland rider

<Peter G Neumann <>>
Wed, 26 Nov 2003 15:17:15 -0800 (PST)

Improper maintenance and inadequate operator training are being blamed for
the death of the rider of the Big Thunder Mountain Railroad roller coaster
at Disneyland on 5 Sep 2003.  The lead car lost its rear-wheel assembly and
hit the tunnel roof, causing the following passenger car to go underneath
it.  The train had just been returned to service after routine maintenance
three days earlier.  Unusual noises were noted on the first 12 trips of the
day, and operators had planned to take the train off line after the 13th
ride — which never finished.  Subsequent analysis showed that two screws
had not been properly tightened.  [PGN-ed from]

US railroad uses Wi-Fi to run 'driverless' trains

<Lars Kongshem <>>
Fri, 21 Nov 2003 11:52:30 -0800

"The Burlington Northern and Santa Fe Railway Company (BNSF) has found a
novel use for Wi-Fi.  It has started using the wireless networking
technology to control trains remotely. BNSF locomotives carry freight across
the continental US.  However, it is using wireless technology to move units
around its rail yards....  (Drivers) operate a control panel that mirrors
what they'd see if they were sitting in the cab.  Their instructions are
relayed to each loco via the 'industrial strength' WLAN."

Given Wi-Fi's security problems, this novel use of 802.11 certainly gives a
new meaning to the word "loco"!

[Source: *The Register*, Nov 20 2003]

Lars Kongshem, 2220 Taylor St. Suite D, San Francisco, CA 94133
1-415.606.5277 +

  [Of course, if they were carrying fruit, it would be PLUM LOCO.  PGN]

Nuclear plan shut down by lightning strike

<Fuzzy Gorilla <>>
Sun, 16 Nov 2003 21:30:42 -0500

A 15 Sep 2003 lightning strike in Chester County, Pennsylvania, shut down a
pair of nuclear reactors 36 miles away at the Peach Bottom Atomic Power
Station.  Early that morning, lightning struck a PECO power line in East
Bradford Township, near West Chester.  A circuit breaker failed to isolate
the damaged power line, cutting off electricity to more than 100,000 PECO
customers and three PECO/Exelon plants — Peach Bottom, Conowingo (Md.)
Hydroelectric Station and Muddy Run Pumped Storage Facility in Holtwood.
...  At least two complications occurred at Peach Bottom as the reactors
were shutting down, according to a preliminary report issued by the NRC.
One of four emergency generators failed, and a safety relief valve used to
control steam pressure initially stuck open.  The NRC has decided to
penalize Exelon because the September shutdown was the fourth at Unit 2 in
less than a year.

The reactor tripped off unexpectedly 21 Dec 2002, when a computer failure
caused steam isolation valves to close. On 21 Apr, the valves closed and
shut the reactor again because of instrument problems on an air line.  The
unit also was down from 22 Jul to 1 Aug because of generator problems.
[Source: Article by Rebecca J. Ritzel, (Lancaster) *Intelligencer Journal*,
date not available, but prior to 19 Nov, anticipating a public meeting of
Nuclear Regulatory Commission officials; PGN-ed, but URL no longer valid.]

Tanker Truck Shutdown Via Satellite

<Fuzzy Gorilla <>>
Sun, 16 Nov 2003 21:05:12 -0500

[The obvious RISKS — when mandated by law, that a terrorist would be
unaware of the need to disable the system; and that no cracker would ever
find out the needed signal and shut down a truck for 'fun'; and that no GPS
or other systems failure might cause a truck to be shut down incorrectly by
law enforcement — are probably obvious to any RISKS reader.]

Satellite Security Systems (S3), in cooperation with the California Highway
Patrol (CHP) and InterState Oil Company, dramatically demonstrated the first
wireless remote shutdown of a fully loaded moving petrochemical tanker
truck.  From S3's headquarters in San Diego (530 miles away), "satellite
communications were used to disable the truck in seconds, proving S3's
GlobalGuard and FleetGuard a viable solution to the challenge of controlling
rogue hazardous waste vehicles that could pose a threat to homeland

While the California state government may be voting as early as January on
Assembly Bill (AB) 575 (requiring truck disabling devices, global
positioning or other "location reporting systems" on hazardous material
haulers), the CHP has been tasked with researching various technologies to
support these regulatory initiatives.  [PGN-ed from *SpaceDaily*, 4 Nov 2003]

Microsoft Windows, Auto Edition

<Andrew Whitby <>>
Tue, 2 Dec 2003 12:44:07 +1000 (GMT+1000)

The Associated Press reports:

  First Microsoft set out to put a computer in every home. Now the software
  giant hopes to put one in every vehicle, too.  "We'd like to have one of
  our operating systems in every car on Earth," said Dick Brass, the
  vice-president of Microsoft's automotive business unit. "It's a lofty
  goal."  Cars with the Microsoft software will speak up when it's time for
  an oil change. They'll warn drivers about wrecks on the road ahead and
  scout alternative routes. They will pay freeway tolls automatically. The
  software running their brakes will upgrade itself wirelessly.

I can see it now. "A security update is available for your braking system.
Press okay to begin installation."

Apparently the RISKS are not obvious to everyone.

What Bill Gates Says About Security (from InformIT)

<"Dawn Cohen" <>>
Mon, 17 Nov 2003 11:48:34 -0500

InformIT, 13 Nov 2003: What Bill Gates Says About Security

"You don't need perfect code to avoid security problems. There are things
we're doing that are making code closer to perfect, in terms of tools and
security audits and things like that. But there are two other techniques:
one is called firewalling, and the other is called keeping the software up
to date. None of these problems (viruses and worms) happened to people who
did either one of those things. If you had your firewall set up the right
way * when I say firewall I include scanning E-mail and scanning file
transfer — you wouldn't have had a problem.

"But did we have the tools that made that easy and automatic and that you
could really audit that you had done it? No. Microsoft in particular and the
industry in general didn't have it.  "The second is just the updating
thing. Anybody who kept their software up to date didn't run into any of
those problems, because the fixes preceded the exploit. Now the times
between when the vulnerability was published and when somebody has exploited
it, those have been going down, but in every case at this stage we've had
the fix out before the exploit."....  "Actually, all the forms of Unix (as
well as Linux) have had more vulnerabilities per line of code. They don't
propagate as much because they're not as dense as our system is, so the
things that prevent the propagation are particularly important for our

Another large gas bill

Mon, 1 Dec 2003 13:31:32 +0200

Commenting on a complaint from a Mr Arthur Purdey about a large gas bill,
a spokesman for North Westgas said, "We agree it was rather high for the
time of year. It's possible Mr Purdey has been charged for the gas used up
during the explosion that destroyed his house."  (*The Daily Telegraph*)

UK MoD scraps 120-million-pound computer project

<Fuzzy Gorilla <>>
Sun, 16 Nov 2003 20:46:03 -0500

Sources: John Leyden, 6 Nov 2003, The Register,
Sara Arnott, 5 Nov 2003,

Britain's Ministry of Defence squandered 118 million pounds on a computer
system that was axed before ever being used.  The Defence Stores Management
Solution was designed to modernise the MoD's inventories of equipment.
(Hardware valued at 12.2 million pounds was salvaged and not included in the
118M figure.)  The system had been expected to save 650 million pounds in
its first ten years.  A report on the collapse of the project (begun in
1999) was released in mid-November.  Reasons given included "developments in
defence logistics" had rendered the project obsolete, but also indicated
management weaknesses at every level: "The MoD had no framework to assess
and manage deliverability once projects were launched; the DLO lacked
effective change management support and co-ordination; and the BCP suffered
from poor financial governance, weak benefits management, poor
communications and a failure to establish an effective programme management
organisation.  ... The review also noted weaknesses in the scrutiny and
approvals process.  Although BCP projects, including the DSMS, did not meet
the Department's requirements in important areas — especially on
affordability and benefits management — the projects were not rejected,"

How Much Is Privacy Worth?

<Monty Solomon <>>
Wed, 3 Dec 2003 09:01:22 -0500

The Supreme Court will hear oral arguments today over whether the federal
government should reimburse individuals whose sensitive data was disclosed
illegally, even if no harm can be proven.  The Privacy Act of 1974 prohibits
the government from disclosing private information intentionally, without
the individual's consent, and provides for a $1,000 minimum fine if the
individual is "adversely affected."  In the case, known as Doe v. Chao, the
Department of Labor distributed the Social Security number of a coal miner
who was appealing for black lung benefits.  Since 1969, the Labor Department
has used miners' Social Security numbers as their case numbers on documents
shared with coal companies, insurance companies and lawyers for all
sides. Those documents also were published in court filings that later ended
up in legal databases.  [Ryan Singel,, 3 Dec 2003; PGN-ed],1848,61439,00.html

Government e-mails apparently sent to hairdresser

<Neil Youngman <>>
Sun, 16 Nov 2003 21:21:40 +0000

According to this BBC article, a hairdresser called Ronnie Campbell received
e-mails apparently intended for a Member of Parliament (MP), called Ronnie
Campbell. Usual RISKS apply.

'Master' and 'slave' computer labels unacceptable, LA officials say

<Henry Baker <>>
Thu, 27 Nov 2003 23:09:22 -0800

FYI — In Tinseltown, bus 'slaves' must go to the end of the line...  This
gives a whole new meaning to 'PC' language.  Please update your cable labels.

Los Angeles officials have asked that manufacturers, suppliers, and
contractors stop using the terms "master" and "slave" on computer equipment,
saying such terms are unacceptable and offensive — after someone had filed
a discrimination complaint with LA County's Office of Affirmative Action
Compliance.  "Based on the cultural diversity and sensitivity of Los Angeles
County, this is not an acceptable identification label," Joe Sandoval,
division manager of purchasing and contract services, said in a memo sent to
County vendors.  [PGN-ed from Reuters item]

Security subtleties

<[identity withheld by request]>
Thu, 9 Jan 2003

I work at a large institution which shall remain nameless.  I was recently
involved in the evaluation of a product from a company which I will call
Company X.  The product consists of a Linux server that is sealed in a way
that it is impossible to open the box without leaving evidence of tampering.
During the course of the normal operation of the product it was installed
behind our firewall, and it made copies of sensitive data accessible on our

The loan agreement stipulated that before the box could be returned, our
sensitive data had to be deleted from the disks.  The box had a built-in
"self-destruct" feature that was supposed to accomplish this.
Unfortunately, self-destruct was a little too thorough: it not only erased
all the data, but it erased the operating system as well, leaving the box

The problem with this is no doubt immediately obvious to long-time Risks
readers: if the box is unbootable then we have no way of verifying that the
data is in fact gone.  For all we know, self-destruct only erases the boot

I raised this objection with representatives of Company X.  They suggested
that instead of running self-destruct that I use the standard Web-based
control interface to erase the data.  No, this wouldn't work either, I
explained, because again there is no way to verify that the data has
actually been erased.  For all we know, the only thing that is actually
erased is a symlink.

They suggested "running a big magnet over the box."  Same problem of course.

I pointed out that the only way for us to verify that the data was in fact
gone would be to examine the disk, which meant one way or another obtaining
either root or physical access.  They refused to allow this because (they
said) they were concerned about us stealing the software.

We went back and forth about this literally for months, and I was astonished
how hard it was for people to grasp the concept that just because you can't
see the data through an HTTP interface doesn't mean it's not there. We
finally arrived at the following compromise: Company X would send a
representative to our site where the rep would witness the invocation of the
self-destruct feature, after which we would open the box, remove the disks,
and install them on another machine where they could be examined and/or
further wiped.

The big day finally arrived, and we ran self-destruct according to the
directions.  Oddly, there was no indication when the process was finished.
We waited five minutes (the prescribed amount of time).  At that point the
company rep said he wanted to log in to the machine to make sure that it had
worked properly.  I was shocked, shocked! to discover that in fact
self-destruct seemed to have done absolutely nothing.  All the files were
still there, both our data and those of Company X.

At that point the rep typed "rm -rf /".  He then proceeded to open the box,
take out the disk (turned out there was only one), and give it to me.  He
then took the box (sans disk) with him and left.

This story is fraught with subtle ironies, not least of which is the amount
of trouble Company X went through to prevent us from stealing their
software, only to leave it with us in a pretty easily recoverable form (to
say nothing of the fact that in the interim we had actually purchased the
product, so if we wanted to open it up and steal their software nothing
would have prevented us from doing so).

But the most worrisome aspect of this story is that apparently, among many
dozens of customers who evaluated the product, I was the only one to raise
any security concerns.  Company X's attitude throughout the whole affair
was, essentially, "Gee, we never thought of that.  No one else ever
complained."  (And Company X has a reputation for technical savvy.)

So I'm off to go through Company X's dumpsters.  I expect to be able to
retire off what I find there.

Man trapped for hours by payphone

< (Mark Brader)>
Tue, 18 Nov 2003 14:36:33 -0500 (EST)

A man in East St. Louis got his middle finger stuck in a payphone's
coin-return slot.  Fortunately, this also meant that when he realized
he needed to call 911, there was a payphone conveniently... *at hand*.
Eventually the phone was removed and taken, with the victim, to a
hospital emergency room where doctors managed to pry them apart.

See e.g. <,1282,-3402400,00.html>.

  [This is known as giving him the finger back.  An overzealous knee-jerk
  response to this episode might be to get rid of the few payphones that
  remain.  PGN]

Debian security breach and forensic analysis

<Gerrit Muller <>>
Wed, 03 Dec 2003 12:41:24 +0100

The text below was send to me by Auke Jilderda. The original e-mail is
from the debian mailing list.

This is a very readable and interesting case description of an intrusion
of a software repository.

The Debian Project                      
Debian Investigation Report                   
December 2nd, 2003

Debian Investigation Report after Server Compromises

The Debian administration team and security experts are finally able to
pinpoint the method used to break-in into four project machines.  However,
the person who did this has not yet been uncovered.  The package archives
were not altered by the intruder.

The Debian administration and security teams have checked these archives
(security, us, non-us) quite early on in the investigation and
re-installation process.  That's why the project was able to open up the
security archive again and confirm that the stable update (3.0r2) wasn't

 [Truncated for RISKS.  See <> for the complete
 report.  PGN]

Re: Security patching: a story from the trenches (Rex Black, R-23.03)

<Walter Dnes <>>
Sat, 15 Nov 2003 16:49:17 -0500

A more accurate subject would be "Risks of updating Internet-insecure
computers via the Internet".  Rex Black had a computer that was not secure
to connect to the Internet.  So he connected to the Internet in order to
download patches secure the computer; what's wrong with this picture ?
Browsing through my router logs, I see approximately 3 hits per minute on
port 135 today, i.e. approximately one every 20 seconds.  The Blaster patch
is 918576 bytes, which would take 3 minutes to download on a v90 dialup.  A
33.6 dialup will take approximately 4 minutes.  During this timespan he
would get 9 to 12 hits on port 135, and be COM-promised (sorry) long before
the download was complete.

This is prime example of why he needed yet another computer, preferably with
a different enough OS that it is not vulnerable at the same moment.  I
downloaded the Blaster patch from Microsoft's website using Mozilla Firebird
on a linux Machine.  A Mac running Safari would probably have worked just as
well.  The patch is small enough to fit on a floppy and could have been
moved to the laptop that way.

Even if the patch was too large for a floppy, he could've used another
computer to check Norton's and/or Microsoft's website, and find out which
ports to block to temporarily protect himself whilst downloading the patch.

So much for criticism, what solution do I offer?  I suggest a "safe mode"
Internet connection option be available for these situations.  It would
require stateful firewalling that would, by default, reject *ANY* packets
from IP addresses and ports that the machine had not initiated a connection
with.  Actually, it wouldn't be a bad idea for the average home user 100% of
the time.  The only holes normally necessary to allow in the firewall would
be for...

 * NETBEUI for other *LOCAL* machines; *NOT* including machines on the
   Internet side of the connection
 * Active-mode mode FTP initiates a second connection back to the
   client.  Stateful firewalling can handle this.

Other exceptions would be to allow file-sharing over a VPN.  If the
user feels *REALLY* confident and adventurous, allow external
connections for P2P applications.

Dangerous looking e-mail from quickbooks

<Kyle York <>>
Wed, 19 Nov 2003 16:00:46 -0800

I just received an e-mail from quickbooks that my credit card information
was soon to expire and I should immediately call a toll-free number to
renew it. A quick look at the headers made me immediatly suspicious:

  Received: from ([])
     by **my machine** with esmtp (Exim 3.35 #1 (Debian))
     id 1ALnfP-0005xu-00
     for <**me**>; Mon, 17 Nov 2003 10:00:03 -0800
  X-MID: <>
  Date: Mon, 17 Nov 2003 13:01:21 -0500 (EST)
  Message-Id: <>
  From: QuickBooks Payroll Services
  To: **me**
  Subject: QuickBooks Critical Notice - Credit Card Expiration Reminder

Note the two relays, and how the From: line doesn't match the Message-Id.
Both an are aliases for which
made me even more suspicious. In the body of the e-mail was a toll-free
number that doesn't appear anywhere on

It turns out this was legitimate e-mail, but given the number of scams how
many people would really pay attention if it wasn't?  And how many spam
filters would have kicked it out due to the problems noted?

Re: In-Security clearance (RISKS-23.04)

< (Peter H. Coffin)>
Fri, 28 Nov 2003 19:50:32 -0600

I would be greatly interested to learn if this installer referenced by the
unknown submitter is the same "Netopsystems FEAD Recomposer" which is used
to package Adobe Acrobat Reader version 6. There are a nontrivial number of
reports (both on the web and on USENET) of the installer failing to work on
many Windows 2000 machines, usually with the same "hourglass then nothing
apparently has happened" symptoms, but has also various other reported
issues, such as leaking memory and creating CPU loops sufficient to require
hardware resets of the computers running the installer, in addition to more
trivial assumptions like listing Windows 2000 as supported but only actually
supporting Service Pack 2 of Windows 2000.

If it is this same installer, this would be extremely interesting for use as
an installer for a security clearance application submitter for the US. The
FEAD system is published by Netopsystems AG, Berlin, Germany.

  [Added in archive:  The program in question is reportedly called the
  Electronic Personnel Security Questionnaire (EPSQ).  PGN]

Re: Amber Alert, Coming to the Inbox Nearest You (Mercuri, R-23.04)

<Timothy Knox <>>
Fri, 28 Nov 2003 15:55:54 -0800

One other response, that I have used to some good effect, is to find the
hoax details on an urban legends website (I personally recommend
<>) and reply-to-all with the URL. It may not stop
them all (there are none so blind as those who will not see), but it does
help some. At least one person wrote me back, thanking me for pointing them
to the site.

Re: Cehck tihs out! (RISKS-22.91)

<"Rodney Hoffman" <>>
Fri, 28 Nov 2003 14:59:16 -0800

Matt Davis at Cambridge has posted a response to this:
   "Aoccdrnig to a rscheearch at Cmabrigde Uinervtisy, it deosn't
    mttaer in waht oredr the ltteers in a wrod are, ..."

where Davis says, "I've written this page, to try to explain the science
behind this meme. There are elements of truth in this, but also some things
which scientists studying the psychology of language (psycholinguists) know
to be incorrect. ... To my knowledge, there's no-one in Cambridge UK who is
currently doing research on this topic."

The page also includes samples in many other languages.

ANNOUNCE: New mailing list for secure application development, SC-L

<"Kenneth R. van Wyk" <>>
Sun, 30 Nov 2003 16:22:57 -0500

I would like to announce the availability of a new and free resource to the
software security community, the SC-L e-mail discussion forum.  The moderated
forum is open to the public.  The group's purpose is, "to further the state
of the practice of developing secure software, by providing a free and open,
objectively moderated, forum for the discussion of issues related to secure
coding practices throughout a software development lifecycle process
(including architecture, requirements and specifications, design,
implementation, deployment, and operations)."  (The complete text of the
group's charter, including its acceptable and unacceptable usage policies,
can be found at

To subscribe to the list, simply connect to
and follow the directions on the form.  Submissions should be sent (by
subscribers only) to

Ken van Wyk, Moderator, SC-L mailing list

Please report problems with the web pages to the maintainer