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 25 Issue 3

Tuesday 29 January 2008


Data entry error leads to incompatible transplant
Mark Brader
London Heathrow plane crash
Colin Stamp
"Butterfly Award": French Bank Says Trader Hacked Computers
Henry Baker
Henhouses, guarding of, by foxes: Kerviel Kerfuffle
Steve Summit
Problems with the German tax software "Magpie"
Debora Weber-Wulff
Florida computer problems halt early voting
The risks of upgrading software
Clive D. W. Feather
Charter Cable deletes 14,000 e-mail accounts. No backups.
Danny Burstein
IRS: Kansas City lost our tapes. Lots of personal info....
Danny Burstein
Automated parking garage reopens
Rich Mintz
Blue Screened Asphalt Jungle...
David Lesher
Windows virus protection on NASA Linux machines
David Lesher
Authors, pseudonyms, and software
Steven M. Bellovin
Re: Metal structure beneath runway affects aircraft instruments
Roderick A Rees
Re: Boeing 787 networking issues
Mark Siegel
Re: Coffee Grounds Qantas
Brian Hayes
Re: More GPS mishaps
Joel Maslak
Dag-Erling Smørgrav
Paul Saffo
REVIEW: "Fuzzing", Michael Sutton/Adam Greene/Pedram Amini
Rob Slade
Info on RISKS (comp.risks)

Data entry error leads to incompatible transplant

Mark Brader
Thu, 24 Jan 2008 17:11:43 -0500 (EST)
It was revealed recently that in 2005 a kidney was transplanted in
Liverpool, England, into a patient with the wrong blood type, due to an
erroneous entry in the UK Transplant database.  The error was noticed a few
hours after surgery and the kidney was removed.  The patient recovered
successfully from the double surgery, but they're not saying what happened
to the patient after that.

The error was apparently made at the Royal Liverpool and Broadgreen
University Hospitals Trust, with UK Transplant merely recording the
information.  A spokesperson for the trust says that "A thorough
investigation was concluded in 2006 and a series of improvements have been
made" and there have been no more such incidents.

London Heathrow plane crash

Colin Stamp <>
Fri, 18 Jan 2008 12:22:32 +0000
All 136 passengers and 16 crew escaped from the British Airways flight BA038
from Beijing.  Eighteen people were taken to the hospital with minor
injuries.  An airport worker told the BBC the Boeing 777 pilot (Peter
Burkill, 43) said he had lost all power and had to glide the plane in to
land.  The worker also said the pilot had told him all the electronics had
also failed.  "He said he had no warning - it just went," the worker added.
"It's a miracle. The man deserves a medal as big as a frying pan."

See the BBC Web Article:

Colin Stamp, IBM United Kingdom Limited PO Box 41, North Harbour,
Portsmouth, Hampshire PO6 3AU

"Butterfly Award": French Bank Says Trader Hacked Computers

Henry Baker <>
Sun, 27 Jan 2008 18:05:51 -0800
FYI—If all else fails, blame it on the computer...  Since this one trader
may have singlehandedly upset the world's markets last week, I'd like to
nominate him for the "Butterfly Award", which should be given to those whose
actions are amplified by the nonlinearities in the world's systems in truly
stupendous ways...

  Societe Generale said Sunday that a trader who evaded all its controls to
  bet $73.5 billion—more than the French bank's market worth—on
  European markets hacked computers and "combined several fraudulent
  methods" to cover his tracks, causing billions in losses.  The bank says
  the trader, Jerome Kerviel, did not appear to have profited personally
  from the transactions and seemingly worked alone—a version reiterated
  Sunday by Jean-Pierre Mustier, chief executive of the bank's corporate and
  investment banking arm.  But, in a conference call with reporters, Mustier
  added: "I cannot guarantee to you 100 percent that there was no
  complicity."  [Source: Jenny Barchfield and John Leicester, French Bank
  Says Trader Hacked Computers, Associated Press, 27 Jan 2008; PGN-ed, with
  memories of Nick Leeson and Barings Bank, RISKS-16.87.]

Henhouses, guarding of, by foxes: Kerviel Kerfuffle

Steve Summit <>
Sun, 27 Jan 2008 18:45:23 -0500
Jérome Kerviel is being blamed for a $7 billion loss at Société
Générale in France.  Evidently, before he became a trader, Kervail
worked in the bank's own internal fraud-prevention department, designing
controls to catch suspicious trading activity.  Allegations are emerging
that he hacked the bank's computer systems—i.e., those same controls --
as part of his alleged coverup.

Take the guy who designed the system to prevent questionable trades, then
let him make trades.  "What could possibly go wrong?",8599,1706661,00.html

  [Later Update: A considerably more detailed account of Kerviel's alleged
  fraud, including the extent to which computers were involved:] .

Problems with the German tax software "Magpie"

Debora Weber-Wulff <>
Thu, 17 Jan 2008 22:14:51 +0100
The Berliner Zeitung reports on 17 Jan 2008 on a problem with the German tax
office's tax filing program "ELSTER" (Why on earth they call their software
"magpie", especially when there is a German saying about the "thieving
magpie" is anybody's guess).

Seems the German tax system wasn't complicated enough, so they made a new
rule that you can't take a deduction for travel to work unless you have to
travel 21 kilometers or more each direction.

If you put in the true value when using ELSTER to submit your taxes online -
such as 18 - the program returns an error and refuses to continue. If you
put in a higher value than 21 (the journalist tested it with 30) then the
program continues working on your taxes, but you just committed tax evasion
by reporting more km than you really have.

The problem? If you just say "forget it" and skip this line, then you will
have no chance to get money back from the government if this passage in tax
law is struck down, which is quite probable, as many have submitted lawsuits
against it.

The solution: file your taxes on paper again, make them type in all your
values. Maybe then they will see that making such complicated rules
confounds even their own software.

Prof. Dr. Debora Weber-Wulff, FHTW Berlin, FB 4, Treskowallee 8, 10313 Berlin

Florida computer problems halt early voting

"Peter G. Neumann" <>
Sat, 26 Jan 2008 13:32:41 PST
What appears to have been a "total network failure" affected all Palm Beach
County early-voting sites on 25 Jan 2008, four days before Florida's
presidential primary election.  Voter registration lists could not be
accessed, which meant party affiliations and ballot choices could not be
verified.  [Source: UPI item, 25 Jan 2008]

The risks of upgrading

"Clive D. W. Feather" <>
Tue, 29 Jan 2008 15:22:01 +0000
As a result of an upgrade to Vista in Ohio's Marietta High School computer
systems, previously protected student information and photos were able to be
accessed by unauthorized people.  "It appears the students were interested
in making changes to their photos in the school cafeteria system."  The
photos and a student ID are used to verify charges for lunches, and
officials suspected some students were manipulating the system to avoid
paying for lunches.  [Source: Marietta Times <>,

Clive D.W. Feather  +44 20 8495 6138

Charter Cable deletes 14,000 e-mail accounts. No backups.

Danny Burstein <>
Thu, 24 Jan 2008 18:46:06 -0500 (EST)
(Note: there wasn't anything in either my Charter e-mail account or on
their web page.)

Charter Communications officials believe a software error during routine
maintenance caused the company to delete the contents of 14,000 customer
e-mail accounts.  There is no way to retrieve the messages, photos, and
other attachments that were erased from inboxes and archive folders across
the country on 21 Jan 2008.  The company apparently deletes inactive
accounts every three months.  [Source: Jim Salter, Cable Co. Empties 14,000
E-Mail Accounts, Associated Press item, 24 Jan 2008; PGN-ed],0,4378708.story

IRS: Kansas City lost our tapes. Lots of personal info....

Danny Burstein <>
Sat, 19 Jan 2008 22:16:30 -0500 (EST)
[Source: Lynn Horsley, KC faulted after probe of IRS tapes missing from City
Hall, *The Kansas City Star*; PGN-ed]

A federal investigation of missing Internal Revenue Service tapes from City
Hall in Kansas City has concluded that the city failed to follow 'proper
safeguards for protecting federal tax return information.'  That conclusion
is contained in a heavily redacted report obtained recently by *The Kansas
City Star* under a Freedom of Information Act request to the Treasury
Department's inspector general for tax administration.

The inspector general's investigation stemmed from the disappearance of 26
IRS computer tapes containing taxpayer information. The tapes, which have
never been found, are normally used by the city to help enforce collection
of the 1 percent city earnings tax paid by people who live or work in Kansas
City. ... The IRS has never said what information was on the tapes, how
many taxpayers were affected, or whether those taxpayers would ever be
notified about the missing information.

Automated parking garage reopens

Rich Mintz <>
Fri, 25 Jan 2008 09:26:30 -0500
The 314-space automated parking garage in Hoboken, New Jersey, near New York
City, officially opened yesterday to local fanfare, in a ceremony marking
the transfer of ownership from Unitronics (the garage's designer) to the
City of Hoboken.

The garage actually opened in 2002, and there were numerous problems in the
first two years, with three cars "dropped" in three years and vehicles
trapped for hours or days at a time.

Video of the garage in action (courtesy of the Jersey Journal):
Story from the Bergen Record, 25 Jan 2008:
Story from the Jersey Journal, 25 Jan 2008:

Rich Mintz - 201-217-8245 (desk), 646-708-5998 (cell)

Blue Screened Asphalt Jungle...

"David Lesher" <>
Mon, 14 Jan 2008 11:43:30 -0500 (EST)

Those NYC Taxi & Limousine Commission mandated GPS+credit card+TV systems?
Well, seems they run Windows, and [surprise!] they are, well.... hackable...

Will the warez community start awarding medallions soon?  Does the open road
bring new vistas of opportunity?

Windows virus protection on NASA Linux machines

"David Lesher" <>
Fri, 25 Jan 2008 19:54:45 -0500 (EST)
  [I was told this story by an unSenior unAdminstration unOfficial; but I've
  already forgotten who it was..]

NASA Langley Research Center [LaRC] is now requiring all desktop Linux
machines to be equipped with an antivirus program that detects and
eliminates Windows viruses. Why? Apparently it is because there is an
uncited NIST recommendation suggesting all desktop machines have virus

Of course, since some Linux machines may operate as mail servers or as
file servers for Windows users, there may be causes for a virus scanner
on the Linux server may be a good idea; it may be more efficient and
easier to maintain a scanner there than on the client machines. But the
average Linux machine does not do this, so detecting Windows viruses on
them is superfluous.

The RISK?  Why, anything you run on a computer can have security flaws,
and anything that runs as root is that much more hazardous.  A program
which downloads virus signatures from a remote location then has
the needed permissions to alter files based upon that data.

Now, on a Windows machine where viruses run rampant and where hourly
patching seems the order of the day, that is a perfectly reasonable risk
to take.  On a Unix machine which does not suffer from those problems;
running an antivirus program only adds risk but does not solve any actual

Also, of course, we have the risk of people taking reasonable security
guidelines and treating them as absolute mandates.  Sadly, a lot of
Federal agencies are prone to that activity.

  [I wonder what LaRC is saying about OSX machines...? Further, I can see a
  dandy DoS attack scenario.  Break into, or just buy the low bidder virus
  definition server company, and merely declare lots-a-files as:
    Dangerous—Must Destroy NOW
  Or, use the root permissions you enjoy to zombify the machines.  Sit back
  and enjoy the fun.]

Authors, pseudonyms, and software

"Steven M. Bellovin" <>
Thu, 24 Jan 2008 03:39:49 +0000
I recently stumbled on this quote on a web page

  In an e-mail exchange, Hemry explained to me the reasons for using a
  pseudonym for his newest opus. In addition to wanting to get away from the
  pigeonholing authors endure when they're known for writing one type of
  book, e.g. military science fiction, there's this: "The pen name was
  primarily driven by bookstore buying software. I've been caught (like so
  many others) in the decreasing orders death spiral. Based on prior sales,
  the chains order fewer copies, so they sell fewer, so they order even
  fewer, so they sell even fewer . . . The pen name short-circuits that
  because the software just sees the pen name and doesn't assign any sales
  history to it."

  I'm not sure if there's a word for how infuriating and depressing this is,
  that the fate of a writer's career is determined by software. Surely there
  have been armed insurrections over less. Okay, perhaps not, but there
  ought to be. After all, the notion of being consigned to oblivion by a
  computer seems a little too close to some of the bleaker visions of
  dystopian SF to me.

I think that latter paragraph sums it up nicely.

Steve Bellovin,

Re: Metal structure beneath runway affects aircraft instruments (Re: Dixon, RISKS-25.02)

"Rees, Roderick A" <>
Mon, 21 Jan 2008 07:52:55 -0800
The source of this problem was 13 locomotives provided to Britain by the USA
under the Lease-Lend scheme.  At the end of the Second World War, the U.S.
did not want to have the locomotives returned, but under the legal terms of
Lease-Lend, they could not be used after the war, nor could they be salvaged
for scrap.  They were therefore tipped into a water-filled hole at the end
of a stub line in the Hounslow area of London, and buried.  Years later (in
the sixties, I believe) Heathrow was expanded, and came to include this
forgotten railway graveyard.  It was discovered by historical research when
Heathrow wanted to put a new compass base there, and found that there was a
significant magnetic anomaly.

Re: Boeing 787 networking issues (RISKS-25.01)

Mark Siegel <>
Tue, 08 Jan 2008 09:21:40 -0800
  [Also Re: Malware and Auto Electronics (Klashinsky, Risks 23.70/72)]

There is a wonderful cartoon from the German computer magazine *c't*
pinned to my group's noticeboard. A passenger is sitting in an airliner
using his laptop, and on the screen appears:

  Bluetooth: new device found: Airbus A310

Re: Coffee Grounds Qantas (Wood, Re: RISKS-25.02)

Brian Hayes <>
Tue, 15 Jan 2008 11:14:41 -0500
> 5. The galley drains in first class on OJM at BKK were blocked by coffee
>    grounds.

Senior RISKS readers may remember the 1964 film "Fate Is the Hunter," based
on an earlier book by Ernest K. Gann (who had been a pilot for American
Airlines). It's the story of an aircraft crash investigation, where the
cause turns out to be a cup of coffee spilled into a control console. Life
imitates art. Fortunately, it's not death imitates art.

Re: More GPS mishaps (Saffo, RISKS-25.02)

Joel Maslak <>
Mon, 14 Jan 2008 17:53:02 -0700
I can relate a personal experience, towing an RV trailer across the US with
the help of satnav.  Besides for some simply bad routing (it's idea of the
quickest route between Amarillo, TX and Dallas, TX - both of which are in
Texas - is via Oklahoma City, Oklahoma, which requires leaving and
re-entering Texas.  This route is several hours longer than the more direct
route.  But, that itself, is not particularly dangerous, except perhaps if
CO2 emissions are considered.  Rather, in Philadelphia, I saw first hand the
result of the GPS routing my vehicle down a particularly unsuitable road in
the Philadelphia suburbs.  In the middle of this road was a one-lane iron
bridge with a 3 ton (US) weight limit.  My complete rig is about twice that
weight, and the truck itself (a 3/4 ton Chevy diesel) is over 3 tons by
itself - as I imagine many large SUVs are as well.  I ended up backing up a
long hill for about 3/4 of a mile, to reach a larger, more suitable road,
rather than risk traveling over the bridge weighing twice as much as the
bridge's capacity.  The lesson?  Check the maps and stick to major roads
whenever possible - and when in doubt, talk to a local.

Re: More GPS mishaps (Saffo, RISKS-25.02)

=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <>
Wed, 16 Jan 2008 15:46:17 +0100
> "It's also worth saying that improved satnavs won't themselves solve all the
> problems," says Geoff Dossetter ...

Dossetter is being too generous.  It is *always* the driver's fault.  I am
not aware of any provision in the Vienna Convention on Road Traffic, nor in
the traffic rules in force in the UK or any other country, which absolves
the driver of responsibility for errors arising from the use of a faulty
satellite navigation system (or a faulty paper map for that matter).
Furthermore, there is no excuse for the driver not realizing that the road
is too narrow or too poorly paved for his vehicle.

As far as I know, all automobile satnav systems, whether integrated or
third-party, offer a disclaimer to that effect upon first use, sometimes
even on every use.

[In Norway, foreign long-haul truckers, especially from Southern or Eastern
Europe, are regularly involved in fatal accidents due to their ignorance -
willful or otherwise - of Norwegian regulations and / or over-reliance on
satellite navigation.  Of course, said accidents are rarely fatal to the
truckers, which may explain why they don't seem to care.]

Re: More GPS mishaps (RISKS-25.02)

Paul Saffo <>
Fri, 18 Jan 2008 09:54:21 -0800
Well stated!  It is so immensely practical that I doubt it has ever occurred
to the local officials!

On Jan 18, at , Peter D. wrote:

> The article from the *Christian Science Monitor* about large trucks and
> narrow lanes was was appalling and funny (like much of comp.risks) but the
> problem is a solved one.
> What happens around here (Victoria, Australia) is that we don't like
> having trucks wedged tight under low bridges.  So, we have a large sign
> that warns, "LOW CLEARANCE" and advises a maximum vehicle height.  And
> soon after that a bright yellow steel girder hung by chains at the advised
> height.  Most drivers are alert enough to stop when they hit the steel
> girder.  It saves the bridge and does comparatively little damage to the
> truck.
> Vertical girders at the start of a narrow lane could easily do the
> analogous job.

REVIEW: "Fuzzing", Michael Sutton/Adam Greene/Pedram Amini

Rob Slade <>
Mon, 14 Jan 2008 15:42:32 -0800
BKFUZZNG.RVW   20071005

"Fuzzing", Michael Sutton/Adam Greene/Pedram Amini, 2007,
0-321-44611-9, U$54.99/C$68.99
%A   Michael Sutton
%A   Adam Greene
%A   Pedram Amini
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   2007
%G   0-321-44611-9 978-0-321-44611-4
%I   Addison-Wesley Publishing Co.
%O   U$54.99/C$68.99 416-447-5101 fax: 416-443-0948
%O   Audience a+ Tech 2 Writing 1 (see revfaq.htm for explanation)
%P   543 p.
%T   "Fuzzing: Brute Force Vulnerability Discovery"

In the foreword, H. D. Moore states that fuzzing is the submission, to a
system, of miscellaneous inputs in order to find vulnerabilities, and that
it is more art than science.

In the preface, the authors assert that, since it is important to have as
many people as possible finding vulnerabilities in our applications, the
book is written not only for researchers, but for the general public and
those with no background in the idea and activity of fuzzing.

Part one provides background information and concepts.  Chapter one outlines
the three basic types of vulnerability discovery: white box, utilizing
source code and other developer materials; black box, submitting inputs and
observing the results; and gray box, using tools such as disassemblers and
debuggers.  A definition of fuzzing is attempted in chapter two, discussing
boundary values analysis (submission of inputs that straddle the line
between acceptable and improper), but notes that fuzzing goes beyond this
level of activity.  There is brief mention of mutation-basing (modification
of input described as acceptable) and generation-basing (creation of test
data from the specification of the format).  Fuzzing methods are supposed to
be the topic of chapter three, but it generally lists different types of
programs (based on the types of applications they test).  Different types of
data representation are mentioned in chapter four.  The requirements for
successful fuzzing, discussed in chapter five, are basically the best
possible understanding of the system under test, the ability to determine
when an effect has been created, and care in recording attempts and results.

Part two examines a variety of application target types, and the automation
of fuzzing activities.  Chapter six lists some tools, and notes some factors
in programming test generation programs.  Subsequently, chapters follow a
pattern of an initial discussion of a specific category of intended quarry
(environment variables and arguments in chapter seven) and then automation
of fuzzing for that purpose (environment parameters in chapter eight).  The
targets are Web applications (nine and ten), file formats (eleven, with
automation for UNIX in twelve, and Windows in thirteen), network protocols
(fourteen, fifteen, and sixteen), Web browsers (seventeen and eighteen), and
in-memory fuzzing (nineteen and twenty).

Part three introduces advanced fuzzing technologies.  Fuzzing frameworks,
described in chapter twenty-one, are applications for specifying formats and
generating ranges of test and probe input data to be used for submission to
programs.  It is difficult to find a consistent thread for chapter
twenty-two, but the topic seems to have something to do with general
programmatic approaches that may have promise for the automation of fuzzing.
While fuzzing can create failures, and therefore note the existence of
faults, in a program, it cannot help us to identify vulnerabilities to be
addressed unless we can distinguish the part of the application that is
responsible for the malfunction.  Chapter twenty-three explores this idea
under the title of fuzzer tracking, or code coverage, and notes some of the
utilities that can be of assistance, but doesn't do a good job of explaining
the necessary functions and concepts.  Intelligent fault detection, in
chapter twenty four, is related to the material in twenty-two, although on a
more generic level.

Part four is a kind of summary, with "Lessons Learned" (and the potential
for the use of fuzzing in software development) in chapter twenty-five.  The
title "Looking Forward," in twenty-six, would normally lead the reader to
expect some examination of future directions, but instead there is a list of
some advanced fuzzing programs to close off the book.

This work does delineate the concepts involved in probing and testing of
software through random or semi-random input submission.  For those managing
the software development process, these ideas are helpful, although the book
may seem a trifle long to that audience.  For those more directly involved
in testing, the text may seem frustrating at times: either simplistic, for
experienced testers, or not detailed enough, for quality assurance people
just getting started in technical explorations.  Still, this is the most
complete volume in the field so far, easily exceeding Beaver's "Hacking for
Dummies" (cf.  BKHACKDM.RVW), Chirillo's "Hack Attacks Testing"
(cf. BKHKATTS.RVW), or "The Software Vulnerability Guide"
(cf. BKSWVLGD.RVW).  Andrews' and Whittaker's "How to Break Web Software"
(cf. BKHTBWSW.RVW) has a higher level of writing, but is more specialized,
so Sutton, Greene, and Amini have provided a useful and more general guide.

copyright Robert M. Slade, 2007   BKFUZZNG.RVW   20071005

Please report problems with the web pages to the maintainer