The RISKS Digest
Volume 24 Issue 05

Friday, 30th September 2005

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…


Software hijacks jet airliner ... again?
Charles Wright
Airbus, Whistleblower Dispute A380 Pressurization Controls
Metra Rail accident in Chicago
Andy Steingruebl
Katrina victims required to use Microsoft IE
Douglas W. Jones
Travelers Continue to Struggle with Wrongful Watch List Matches
Scots Jail hi-tech door locking system broke
George Michaelson
Risks of keyboard shortcuts
Andrew Koenig
Designing "safe software"...: A 4-star article!
Michael Radow
Sorcerer's Apprentice in the Driver's Seat??
David Lesher
Mea culpa: How we got it wrong on Calling-Number ID
Geoff Kuenning
Open letter: Why "dot-xxx" is for Chumps
Lauren Weinstein
Router worms and International Infrastructure
Gadi Evron
Wolf Blitzer repeats Rudy in questioning governors
Fred Cohen
Info on RISKS (comp.risks)

Software hijacks jet airliner ... again?

<"Charles Wright" <>>
Sat, 17 Sep 2005 11:26:11 +1000

*The Australian* (17 Sep 2005) has a chilling story about the pilots of a
Malaysian Airlines 777 flying from Perth to Kuala Lumpur last month battling
to regain control after an "unknown computer error" caused the aircraft to
pitch violently, and brought it close to stalling.

An Australian Transport Safety Bureau report
( released
yesterday reveals the pilot in command disconnected the autopilot and
lowered the plane's nose to prevent a stall, after incorrect data from a
supposedly fail-safe device caused the plane to pitch up and climb 3000ft,
cutting its indicated air speed from 500kmh to 292kmh, activating a stall
warning and a "stickshaker". [A stickshaker vibrates the aircraft's controls
to warn the piot when he is approaching stall speed ... which, you know,
means the plane is about to fall out of the air.]

The system refused to give up control, however. It increased the power on
the automatic throttle, forcing the pilot to counter by pushing the thrust
levers to the idle position. The aircraft immediately pitched up again, and
climbed 2000ft.

The pilot turned back to Perth under manual control. When he kicked in the
two autopilot systems, the plane banked to the right, and the nose pitched

On its landing approach, at 3000ft, the flight display gave a low airspeed
warning and the auto-throttle increased thrust. The warning system also
indicated a dangerous windshear, but the crew landed the jet safely.

According to the report, "investigations are focusing on faulty acceleration
figures supplied by a device called the Air Data Inertial Reference
Unit". The ADIRU collates aircraft navigation and performance data from
other systems and passes the information to the primary flight computer.

What's potentially more disturbing, however - and neither the Transport
Safety Bureau nor The Australian appear to have picked this up - is that a
US FAA directive <a
in June this year highlighted other problems with the Boeing 777's ADIRU.

Boeing has told operators of the jet — which by the way has the best safety
record of any aircraft (
-- to load a previous software version.

   [The article at
   was also noted by Mickey Coggins and Ian Chard.
   was cited by Richard Weir.  PGN]

Airbus, Whistleblower Dispute A380 Pressurization Controls

<"Peter G. Neumann" <>>
Tue, 27 Sep 2005 11:13:19 PDT

James Paul (U.S. House Science Committee professional staffer) called my
attention to an item in the 27 Sep 2005 *Los Angeles Times*.  A
whistleblower alleges that the chips controlling cabin pressurization valves
in Airbus's new Flying Whale aren't behaving properly and may lead to
decompression incidents.,1,2186118.story

Metra Rail accident in Chicago

<Andy Steingruebl <>>
Tue, 20 Sep 2005 09:40:22 -0500

As you are no doubt aware, there was a Metra Rail train accident in Chicago
this last weekend that caused the death of two people and injured
approximately 80.  The issue has gotten national news coverage, and lots of
local coverage.  The Metra spokeperson has been rather forthcoming in
analysing the situation.

Because the train was speeding at the time of the accident and the accident
is similar to previous train accidents, there have been a lot of calls for

 - Put a second person back in the train to help the engineer. There was a
   second person until 1995.

 - Implement automated train controls to brake the train in case of an
   engineer missing a signal.

The second option has received a lot of attention because Metra currently
has computer controls on several of its train lines, but the controls are

This situation presents a great opportunity to get the issue of the
reliability of human and computer controls in the media.  As the ideas are
being widely discussed, its a perfect opportunity to discuss failure rates
for the different technologies, the humans, etc.

I'd contact Metra Rail myself, but I don't have the requisite engineering
background to act as a truly knowledgeable source.

Perhaps you or someone from RISKS (perhaps someone in the Chicago area) can
contact local news media and Metra to get this issue discussed in public as
it should be.

[Added note: I believe it was going about 60 and the speed limit for that
section of track was 10.  Recent news is the the engineer either missed the
signal, or the signal was green indicating he could keep his speed and not
slow down.  In either case since its a big news story.  AS]

Katrina victims required to use Microsoft IE

<"Douglas W. Jones" <jones@CS.UIOWA.EDU>>
Thu, 22 Sep 2005 10:02:21 -0500

  [In a USACM newsgroup, Barbara Simons noted that FEMA requires Katrina
  evacuees to use Microsoft IE 6.0 for access to its website:
  The following message by Doug Jones discusses that issue.  PGN]

The FEMA web portal violates a number of good web usage guidelines.  The
first page at is fixed-width, not conforming to the user's
browser window.  Things get worse from there.

The web page is a mess when viewed under
iCab, my preferred web browser, the browser spent what seemed an eternity
blinking from grey to white and back again before stabilizing with content.
When I clicked on Register for Assistance, it went back to blinking and kept
it up for so long that I gave up.

When I repeated the exercise under Safari, Clicking on Register for
Assistance, which takes me to
I got the following error message:
    500 Internal Server Error
    Servlet error: java.lang.ClassNotFoundException:

When I tried it under IE, it got farther, letting me through an
automated test to distinguish humans from bots, but then it gave me
the message:

  Integrated Security Access and Control (ISAAC) Unavailable
    Your request cannot be processed because the ISAAC system is unavailable.
  Please try again later or contact the FEMA Helpline at the number
    listed below.

So, it's clear to me that they've engineered a web system that is:
  a) Extraordinarily over-engineered to work under only one browser,
  b) Nonfunctional under that browser,

This, I conclude, is simply another example of FEMA incompetence.

Travelers Continue to Struggle with Wrongful Watch List Matches

<EPIC FOIA Notes <>>
Tue, 27 Sep 2005 11:47:44 -0400

EPIC FOIA Notes #8:
Travelers Continue to Struggle with Wrongful Watch List Matches

Documents obtained by EPIC from the Transportation Security Administration
under the Freedom of Information Act reveal nearly a hundred complaints from
airline passengers between November 2003 and May 2004.  The most common
complaint from passengers is that they have been wrongly placed on a
government watch list.  Numerous complaints show passengers' frustration
with the agency's failure to resolve their misidentification problems.

More information:
FOIA_Notes mailing list

Scots Jail hi-tech door locking system broke

<George Michaelson <>>
Tue, 20 Sep 2005 11:18:59 +1000

This one begs a few questions: How can the inmates have had over a *month*
of using the hackaround without other non-linked security systems (e.g.,a
video cameras) not noticing?

This suggests that an integrated solution has replaced multiple discrete
lines of protection, with predictable outcomes.  George

Prison officers have been forced to abandon a new security system and return
to the use of keys after the cutting-edge technology repeatedly failed.  The
system, which is thought to have cost over 3 million, used fingerprint
recognition to activate the locking system at the high-security Glenochil
Prison near Tullibody, Clackmannanshire.  ...  For more than a month, the
420 inmates - including some murderers and other high-risk inmates - had
been able to wander around the high-security jail. Staff claim that the
unlimited access to all parts of the prison had allowed some prisoners to
settle old scores with rivals.

George Michaelson, APNIC, PO Box 2131 Milton, QLD 4064 Australia   +61 7 3858 3150

Risks of keyboard shortcuts

<"Andrew Koenig" <>>
Wed, 28 Sep 2005 10:44:32 -0400

Background: Microsoft Windows can support only 10 USB MIDI devices.  This
may sound like a lot until you realize that when you move a device to a
different USB port, it counts as a new device.  The list of devices is
stored in the registry, using keys named "midi", "midi1", ... "midi9".  I
was running regedit to try to understand the degree to which these keys had
become filled, and to delete some of the duplicates.

I turned away from the keyboard for a moment.  When I turned back, on the
screen was a dialog box saying "Do you want to permanently delete this key
and all of its components?  Yes/No", and one of my five-month-old kittens
was ambling away from the keyboard.

I'm not usually a fan of such dialog boxes, but this time I'll make an
exception--especially as regedit does not have an undo function.  Yes, I
know about system restore points, but still...

Designing "safe software"...: A 4-star article!

<Michael Radow <>>
Thu, 15 Sep 2005 19:36:33 -0700 (PDT)

  David Kalinsky, Architecture of safety-critical systems
  September issue of "Embedded Systems Programming" magazine
  "compressed" URL

Sorcerer's Apprentice in the Driver's Seat??

<"David Lesher" <>>
Sat, 17 Sep 2005 09:51:21 -0400 (EDT)

  The driver of a runaway [21 ton] truck that locked at 60 mph for 140 miles
  on highways in northern France and Belgium is planning to sue the truck
  manufacturer.  The crisis happened Monday when the driver, who refused to
  give his name, used his mobile phone to raise the alarm when he realized
  he could not brake or change gears.  ... {no good scheme to stop it;
  finally skidded out} ...  Iveco, the truck manufacturer, sent technicians
  to examine the vehicle. The driver denies he was at fault and he was
  taking legal action.  [UPI item, abstracted]

A slew of Risks, here. First the obvious, did it go down as reported; i.e.,
the driver really had no way to stop it? (Or had he been to see
<> recently.)

If so, why? Diesel vehicles usually have an emergency shutoff that blocks
the air intake. Was it NOT manually operable, or did it fail as well? And
were the brakes out, or insufficient to overcome the engine power?

It will be interesting to see the followup analysis.

Mea culpa: How we got it wrong on Calling-Number ID

<Geoff Kuenning <>>
25 Sep 2005 23:37:03 -0700

Back in the early 90's, U.S. phone companies began rolling out the service
known as "Caller ID" (really Calling Number ID, or CNID).  Early adopters
were very pleased with the feature; it helped them to avoid telemarketers
and occasionally to dodge inconvenient friends.

Then a few privacy advocates noticed that there was a dark side: if
you called a local business, it could capture your number with CNID
and add you to a telemarketing list.  Suddenly CNID changed from a
beneficial service to a nefarious plot.

An anti-CNID campaign ensued, culminating in California's decision to
require telephone companies to offer free CNID blocking as a condition of
rolling out the service.  At the same time, privacy advocates (including me
and many other RISKS subscribers) publicized the downsides of CNID:
unintentionally revealing your (possibly unlisted) phone number, confusing
the concept of calling number with the identity of the calling person, etc.
The campaign was successful: when CNID was rolled out, something like 50% of
Californians chose to block their number by default.

Fast forward approximately a decade.  I recently switched local phone
providers (finally freeing myself from the clutches of Verizon, ne GTE,
after a 25-year quest) and got rid of my CNID blocking in the process.
Rather than advocating against CNID, I've now changed my tune and am trying
to convince my blocked friends to unblock.

What happened?  The answer is simply that I was wrong about the evils of
CNID, and wrong about the (perceived lack of) benefits.  That error arose
primarily from an inability to correctly predict the future.  In particular,
the following forces have reduced the evils and increased the benefits:

1. The predicted data collection by small businesses never happened.  It
   wasn't worth the effort.  Businesses didn't get much benefit from knowing
   that somebody at 555-1234 had called to inquire about mattress prices;
   their telemarketing money was better spent on buying phone lists that
   included names and demographic data.

2. Larger businesses had 800 numbers that included Automatic Number
   Identification (ANI), which wasn't bothered by caller ID blocking anyway,
   so the people with lots of funds were never stopped from telemarketing.

3. The unforeseen Federal Do-Not-Call List has become an effective defense
   against telemarketing, so revealing your telephone number isn't much of a
   problem anyway.

4. The rise of cellphones means that we are starting to see a true
   one-to-one association between phone numbers and people, so CNID is
   becoming the caller ID it was once billed as being.

5. Most cellphone plans include CNID as part of the package, and some local
   plans are also offering it as a no-cost option, increasing the number of
   people who depend on CNID working.

6. A new generation of CNID signaling allows short text information to be
   transmitted along with the calling number, so that the recipient can
   identify the caller even if they have never seen the number before.

In addition, in 20-20 hindsight many of our criticisms seem overstated.  For
example, we argued that since CNID doesn't identify the individual, you
never really knew who was calling.  That's true enough, but do my family and
friends care whether it is I or my wife calling to arrange a visit?  We
argued that a stranded teenager calling from a pay phone might have his call
rejected, but would a parent with a teen out on a date really turn down
calls from an unknown number?

I think the lesson here is that we need to remember to be humble, and to
avoid crying wolf about the RISKS we perceive.  Overall, CNID's benefits far
outweigh its drawbacks, and we have done society a disservice by encouraging
people to block it.  We were right to point out the potential weaknesses and
incorrect marketing claims, but we erred in encouraging so many people to
unnecessarily block their phone numbers, inconveniencing their friends and
family while gaining almost no real benefit.

Geoff Kuenning

Open letter: Why "dot-xxx" is for Chumps

<Lauren Weinstein <>>
Mon, 19 Sep 2005 09:55:28 -0700

This is an open letter addressed to that segment of the Internet community
where the *real* money is made — the "adult entertainment" industry.  For
that matter, the operators of the ubiquitous non-commercial
sexually-oriented Web sites can join in as well.

I have some free advice that may save you a great deal of grief.

Now, in all honesty, I don't have any particular love for your operations or
your products.  I'm not a prude (well, not much of one, anyway), but by
continuing to push the envelope you folks have engendered a great deal of
negative reaction that's approaching a fever pitch.

That reaction is what I'm really concerned about, since it's likely to
splatter collateral damage broadly across a wide range of free speech and
civil liberties arenas.

So, in my desire to protect them, I'll try to protect you as well.

My advice?  Don't fall into the "dot-xxx" trap that's being set for you by

As you no doubt are aware, ICANN appears to be preparing for the deployment
-- despite broad protests across the political spectrum and a couple of
delays — of a "dot-xxx" top-level domain (TLD).

I've explained elsewhere ( ) and ( ), why dot-xxx is an absolutely atrocious

ICANN claims that participation in the domain will be voluntary, and that
will indeed be the case — at first.

But as I discussed back in a 2001 PFIR position paper on "domain
ghettoization" ( ), such
efforts are a slippery slope likely leading to widespread filtering and
censoring by ISPs, governments, plus a broad range of other entities,
affecting a *lot more* than merely pornographic materials.  A glance at the
current Supreme Court situation is not particularly encouraging in this

ICANN apparently doesn't view their dot-xxx plan as a trap.  They seem to
consider themselves courageous by pushing on with that TLD despite the broad
public and private consensus that it's a terrible concept.  Unfortunately,
this is the sort of "forge ahead over the cliff" behavior that we've come to
expect from ICANN as an organization.

So if dot-xxx arrives, my strong recommendation is that *you ignore it*.
Pretend that it doesn't exist.  Allow it to be an empty database.  Joining
that domain won't provide you with any cover — what you'll actually be
doing is painting a giant bulls-eye on yourselves — and on a vast array of
worthy and important groups and materials that have nothing whatever to do
with adult entertainment.

Dot-xxx is for chumps.

By the way, I originally considered titling this entry with a domain-related
variation on the old "Suppose They Gave a War and Nobody Came" line, but
while the situation with dot-xxx is indeed dangerous — and an example of so
much that's wrong with Internet Governance in general and ICANN in
particular — this matter is anything but a dirty joke.

Lauren Weinstein, 1-818-225-2800
Moderator, PRIVACY Forum -

Router worms and International Infrastructure

<Gadi Evron <>>
Fri, 30 Sep 2005 23:29:29 +0200 wrote:
> Reading through the original Russian posting here
> It seems that someone has built an IOS worm that
> follows an EIGRP vector from router to router.

A while back I emailed the following text to a closed mailing list. I figure
now that quite a few cats are out of the bag it is time to get more public
attention to these issues, as the Bad Guys will very soon start doing just

Ciscogate by itself ALONE, and now even just a story about worms for Routers
is enough for us to be CLEAR that worms will start coming out.  We do learn
from history.

So.. as much as people don't like to talk much on the issues involving the
so-called "cooler" stuff that can be done with routers, now is the time to

Here is one possible and simple vector of attack that I see happening in
the future. It goes down-hill from there.

I wrote this after the release of "the three vulnerabilities", a few months
back. Now we know one wasn't even just a DDoS, and that changes the picture
a bit.

Begin quoted text ----->>>

More on router worms - let's take down the Internet with three public POCs
and some open spybot source code.

  - - -

People, I have given this some more thought.

Let's forget for a second the fact that these vulnerabilities are dangerous
on their own (although it's a DoS), and consider what a worm, could cause.

If the worm used the vulnerability, it would shoot itself in the leg as when
network is down, it can't spread.

Now, imagine if a VX-er will use an ancient trick and release the worm,
waiting for it to propagate for 2 or 3 days. Then, after that seeding time
when the say.. not very successful worm infected only about 30K machines
around the world, each infected host will send out 3 "One Packet Killers" as
I like to call them to the world.

Even if the packet won't pass one router, that one router, along with
thousands of others, will die.

Further, the latest vulnerabilities are not just for Cisco, there is a "One
Packer Killer" for Juniper as well.

So, say this isn't a 0-day. Tier-1 and tier-2 ISP's are patched (great
mechanism to pass through as these won't filter the packet out if it is
headed somewhere else), how many of the rest will be up to date?

Let's give the Internet a lot of credit and say.. 60% (yeah right).

That leaves us with 30% of the Internet dead, and that's really a bad
scenario as someone I know would say.

Make each infected system send the one packet spoofed (potentially, not
necessarily these vulnerabilities) and it's hell. Make them send it every
day, once! And the net will keep dying every day for a while.

As a friend suggested, maybe even fragment the packet, and have it
re-assembled at the destination, far-away routers (not sure if that will

These are all basic, actually very basic, techniques, and with the source to
exploits and worms freely available....  We keep seeing network equipment
vulnerabilities coming out, and it is a lot "cooler" to bring down an ISP
with one packet rather than with 1,000,000,000,000,000.

I am sure the guys at Cisco gave this some thought, but I don't believe this
is getting enough attention generally, and especially not with AV-ers. It

This may seem like I am hyping the situation, which is well-known. Still
well-known or not, secret or not, it's time we prepared better in a broader



----->>> End quoted text.

I would really like to hear some thoughts from the NANOG community on
threats such as the one described above. Let us not get into an argument
about 0-days and consider how many routers are actually patched the
first... day.. week, month? after a vulnerability is released.

Also, let us consider the ever decreasing vulnerability-2-exploit time of

I don't want the above to sound as FUD. My point is not to yell "death of
the Internet" but rather to get some people moving on what I believe to be a
threat, and considering it on a broader scale is LONG over-due.

The cat is out of the bag, as as much as I avoided using "potentially" and
"possibly" above to pass my point.. this is just one possible scenario and I
believe we need to start getting prepared to better defending the Internet
as an International Infrastructure.

As I am sure that this will be an interesting discussion, I am also sure
this will eventually derail to a pointless argument over an un-related
matter, here on NANOG.  I'd appreciate if people who are interested would
also email me off-list so that we can see how we can perhaps proceed with
some activity.

My blog:

Wolf Blitzer repeats Rudy in questioning governors (Re: RISKS-24.04)

<Fred Cohen <>>
Sun, 18 Sep 2005 09:30:59 -0700

This morning I watched as Wolf Blitzer on CNN questioned governors about
preparedness, and the single frequency question came up again - in that
form. It just shows how the power of ideas can take on its own
life. Fortunately the mayors of Miami and Boston were more clued in than
Rudy. Florida indicated that the he believed that the problem was solved
there without referring to a single frequency in his response. Boston
indicated the use of a system by Raytheon that allows interconnections
between different frequency bands for specific emergency communications
requirements. Hopefully Wolf will start to ask the right question after he
finds out that the notion he is spreading is flawed.

Thanks also to the many people who have responded to me personally with
their views — all reasoned views — are as always welcomed.

Security Posture <>, Fred Cohen & Associates <>
572 Leona Drive, Livermore, CA 94550 1-925-454-0171, University of New Haven

Please report problems with the web pages to the maintainer