The RISKS Digest
Volume 25 Issue 31

Wednesday, 10th September 2008

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…


FAA redundancy — or the lack thereof
Tessler and Robertson via PGN
Corrupt File Brought Down Flight Planning System
Gabe Goldberg
UK software upgrade issues
John Sawyer
JPMorgan Chase: The Bank Account That Sprang a Leak
Monty Solomon
Software problems affect the bottom line at J. Crew
Steven M. Bellovin
Google ads and language
Erling Kristiansen
Rob Slade
Control-C vs. Bourne-Again SHell
Control-C Control-C vs. gnus
Risks of better security and "smarter" users
Ron Garret
BNY Mellon Data Breach Potentially Massive
George Hulme via Monty Solomon
Student hacker exposes Carleton U cash, ID card security holes
Sergei Patchkovski
Whit Diffie and Susan Landau: Internet Eavesdropping
Randall Webmail
US .gov website asks for personal info without https protection
Jonathan Thornburg
Re: Germany's New Unified Tax Identification Codes
Kevin Pfeiffer
Re: Firefox 3's Step Backwards ...
Dimitri Maziuk
Info on RISKS (comp.risks)

FAA redundancy — or the lack thereof

<"Peter G. Neumann" <>>
Sat, 30 Aug 2008 15:12:08 PDT

The FAA computer problem on 26 Aug 2008 (RISKS-25.30) "served as a reminder
that the U.S. flight system is waiting for a modernizing overhaul."  The FAA
is apparently using "computing practices that would be considered poor in
credit card networks or power plant operators — relying on only the Atlanta
and Salt Lake City centers for flight planning.  For example, power and
water utilities can be find a million dollars a day if they are willfully
negligent.  [Source: Joelle Tessler and Jordan Robertson, FAA outage reveals
odd computing practices, AP item, 29 Aug 2008; PNG-ed]

Corrupt File Brought Down Flight Planning System

<Gabe Goldberg <>>
Fri, 29 Aug 2008 14:17:58 -0400

Strike 1: A corrupt file wasn't caught by validation?

Strike 2: It took 2 1/2 hours to restart after the failure?

Strike 3: The "backup" computer couldn't handle the failover load?

Strike 4: The restored-to-service computer couldn't clear the accumulated
backlog until new transactions were suppressed?

 - - - - -

Corrupt File Brought Down Flight Planning System A corrupt file contained in
a normal software upload brought down the FAA's main flight planning
computer on Tuesday, delaying hundreds of flights and prompting questions
about the inevitability of it happening again. FAA spokesman Paul Takemoto
told eWeek the corrupt file stopped flight plans from being filed at the
FAA's Hampton, Ga. facility, which is the principal flight planning
computer. "Basically, all the flight plans that were in the system were
kicked out," Takemoto said. "For aircraft already in the air, or had just
been pushed back form the gate, they had no problems. But for all other
aircraft, it meant delays."

The system switched to the FAA's backup flight planning computer in Salt
Lake City, which was quickly overwhelmed by airlines trying in vain to enter
flight plans. "They just kept hitting the 'Enter' button. So the queues
immediately became huge," Takemoto said. "On top of that, it happened right
during a peak time as traffic was building. Salt Lake City just couldn't
keep up." The Georgia computer was fixed in two-and-a-half hours but it
wasn't until the FAA asked airlines to stop filing flight plans that the
backlogs started to clear. All was reported normal on Wednesday but eWeek is
openly wondering how much longer the "a creaky old IT system" can
continue. They system is more than 20 years old and the company that built
it has been out of business most of that time, eWeek reported.

UK software upgrade issues

<John Sawyer <>>
Sat, 30 Aug 2008 01:33:07 +0100

Yet another example of UK government not testing software properly
before upgrading!

They want us to trust them with more information?

Dr John Sawyer, Wiltshire England.

JPMorgan Chase: The Bank Account That Sprang a Leak

<Monty Solomon <>>
Sun, 31 Aug 2008 10:04:21 -0400

Surely customers of the elite private banking operation at JPMorgan Chase,
serving only the bank's wealthiest clients, are safe from such problems,
right?  Wrong, says Guy Wyser-Pratte, an activist investor on Wall Street
for more than 40 years who uses his hedge fund's war chest of roughly $500
million to wage takeover fights and proxy battles in the United States and
Europe.  In May, he learned that someone had siphoned nearly $300,000 from
his personal account at the private bank through many small electronic
transfers over a 15-month period.  Then he was told by the bank that he
could stop the theft only by closing his account and opening a new one.  And
then JPMorgan Chase told him that the bank would cover only $50,000 of his
losses. ...  [Source: Diana B. Henriques, *The New York Times*, 30 Aug 2008;

Software problems affect the bottom line at J. Crew

<"Steven M. Bellovin" <>>
Sat, 30 Aug 2008 10:31:22 -0400

According to the Wall Street Journal's Business Technology blog, software
problems from a "botched system upgrade" caused earnings for the third
quarter to drop by 12% from a year earlier.  Problems included outages,
performance, botched orders, return problems, call center issues, and more.

Steve Bellovin,

Google ads and language

<Erling Kristiansen <>>
Wed, 03 Sep 2008 20:09:26 +0200

Googling something in one language while accessing from another language
environment can give rather amusing ads.

I looked for "SOA SWIM" (SOA = Service oriented architecture; SWIM = System
wide information management. Both terms are related to network
architecture).  The first half-dozen hits were spot on, and gave me what I
was looking for.

But the ads somehow caught my eye: Cures for chlamydia.
Explanation: SOA is the Dutch abbreviation for sexually transmitted disease.

So it seems that, while the search engine tries to match as many search
terms as possible, the ads go for single words.

At first, I had a good laugh. But, thinking a bit more about what happened,
what if somebody was trying to make a profile of me based on single words?

Some time ago (actually, quite a longtime ago), I was googling for "EROS
data centre", a professional repository of Earth resource imagery.

Put EROS and SOA together, and you might get the wrong idea of what I had
been up to, and what were the consequences.


<Rob Slade <>>
Thu, 4 Sep 2008 18:25:35 -0800

Go look up the term rootkit on Wikipedia.  (Go ahead, I'll wait.)  Lovely
entry, isn't it?  Lots of information.  Trouble is, there's lots of
misinformation, too.

A rootkit is *not* "a program ... designed to take fundamental [or] ...
`root' access" for a system.  It's designed to *keep* that access, once you
broken into the system and grabbed it.  (And rootkits were around before
1990, etc, but we'll let that go for the moment.)

Or, at least, it used to be defined that way.  Recently, all kinds of people
have been redefining what rootkit means, to the point that it may no longer
mean anything.

Wikipedia is a wonderful tool, and the English encyclopedia made with it is
a wonderful resource.  For the most part.  But when you get to the real
specialty areas you start running into problems.  As John Lawton has pointed
out, the irony of the information age is that it has given new
respectability to uninformed opinion.  And Wikipedia is susceptible to that

Now the Wikipedia people are aware of the problem, and have provided ways to
address it.  There is the fact that anyone can correct errors, when errors
have been made.  There are technical controls in terms of limits on changes.
There are administrative controls in the granting of elevated privileges to
editors.  But occasionally you get a breakdown, such as the fact that an
editor can be, him or herself, in error.  And then you get entries like the
one for rootkit.

But Wikipedia is not what I really want to talk about.  I want to talk about
words.  Specifically, the jargon that we use, and create, in technical
fields, and in the field of information security in particular.  Because
language is kind of like a giant Wikipedia, where anyone at all can make an
entry.  And anyone at all can try and modify that entry.

Lots of people like to talk about computer security.  It's quite likely that
more people like to talk about security than actually *do* anything about
security.  So it's not hard to see that a lot of the people who are talking,
and writing, about security often talk about things that, well, they are not
quite certain about.

If I say that Alan Turing was a homosexual, I might be right, or I might be
wrong.  But it would be fairly easy to check whether I was right or wrong.
However, if I say that a Turing Machine is a universal computer because it
can be implemented on any computer, I am making a different kind of
assertion, and one that it harder to check.  Someone who hears me say that,
and knows that I'm wrong, might not challenge it immediately, because it's
partly right, and the error I've made may not be important to the point that
I'm making.  But the people who hear me make that statement, and who do not
know why the statement is in error, are probably going to assume and
generate various kinds of mistaken ideas about Turing machines.  And if I
make the statement frequently enough, and in enough different places, it
starts being taken as true.  And eventually we'll have people saying that a
universal computer is any entity that can be implemented on any platform.
Which had nothing at all to do with what Turing was doing and proving.

So it is with a number of the specialized terms that we have been using in
infosec.  A lot of people are getting hold of them, and using them in sloppy
ways.  Now, a great many people say that language is living, and you have to
make allowances for that growth.  Fair enough: much of the vocabulary that
we use every day in computer security didn't even exist fifty years ago, so
it would be hard to argue the point.  However, if the terms can be changed
by anyone, at any time, then they lose meaning.  If I use the word virus to
mean one thing, and you use it to mean something quite different, then we
aren't going to come to any agreement.  We can't communicate.  And, in all
of these rapidly changing technical fields, communication is vitally

So, in the blort, I just want to regrify you to smetnicate all forms of

Yelth you for your fesculiant.

Control-C vs. Bourne-Again SHell

Mon, 01 Sep 2008 02:04:01 +0800

Naturally I only use orthodox Free Software, like bash, the GNU
Bourne-Again SHell, to control my household projects.
$ sleep 55; launch_rocket
The problem is if one discovers a missing O-ring etc., then a
Control-C interrupt will not cancel the whole launch as it does in
other leading brand SHells, but instead just cancel the countdown --
VROOM. Next time use an && operator instead of a ;.

Control-C Control-C vs. gnus

Mon, 01 Sep 2008 02:52:22 +0800

We continue our Control-C adventures with gnus.
As you know I only use the highest pedigree Free Software,
Stallman->emacs->gnus, wherein lies
  C-c C-c runs the command message-send-and-exit
I told them 13 times this was too easy to hit by accident,
and rigged up my own Child Safety Cap macro.
Well, just the other day I was attempting to hit
  C-c C-f C-c runs the command message-goto-cc
to merely add somebody important to the CC: header,
but guess which key I pressed too lightly? Imagine me sending half
baked messages out the door before they are complet

Risks of better security and "smarter" users

<Ron Garret <>>
Tue, 19 Aug 2008 11:28:19 -0700

The other day I visited the site of a well known issuer of SSL certificates
to look up some information in my account.  I was shocked to realize that I
was able to access this information without going through a login procedure.
All I did was click the "login" button, and my account information came up.
This behavior persisted across a browser restart, and even a machine reboot.

I was shocked.  Here's a company whose business is security, but their site
(apparently) issues login cookies that don't expire!  Worse, there didn't
seem to be a "logout" button!

(Spoiler alert: it makes an interesting exercise to see if you can figure
out how this happened, other than that the web site designers were idiots.
Here's a hint: I use a Mac.)

Most "secure" (I've been reading RISKS far too long not to put that in scare
quotes) web sites follow a common motif: there's a login page where you type
your user name and password into an HTML form.  That information gets sent
to the server, which verifies your credentials and issues a session cookie.
After you've done your business you log out, which either removes the
session cookie from your browser or invalidates it at the server.  Usually
the session cookie expires after some period of inactivity.

But there is another method of authentication on the Web: HTTP
authentication.  This is the kind of authentication that makes a browser
dialog pop up to ask for your user name and password rather than entering it
into an HTML form.  There are different kinds of HTTP authentication.  The
most common one is "basic" authentication, because it's the easiest to set
up.  It is also fairly insecure because it sends passwords in the clear
(usually with an accompanying warning in the browser dialog).  Because of
this, HTTP authentication is generally frowned up for "serious" security,
despite the fact that there are variants that are more secure than "basic"

The site in question was using one of these more advanced HTTP
authentication schemes.  The first time I ever logged into the site, the
login dialog popped up and, without really thinking about it, I marked the
checkbox next to "remember this username and password in my keychain."

Now, this alone should not have produced the behavior that I saw because
normally in order to access the OS X keychain an application has to ask
permission, and my browser wasn't.  But it turns out that the OS X keychain
has a handy-dandy convenience "feature" that allows you to permanently grant
access to a particular keychain item to a particular application, and Safari
had "helpfully" added itself to this list when it created the keychain item.

So here we have a security risk that is a confluence of three circumstances,
two of which are the result, arguably, of too much knowledge.  They are:

1. The web site used a secure authentication scheme that behaves almost
   identically to a less secure scheme

2. I am familiar with the more common design of secure sites and

3. OS X and Safari conspire to subvert the security of HTTP authentication
   in a very subtle way in order to make things more convenient for the user

I find myself at a loss to suggest how this particular risk might have been

BNY Mellon Data Breach Potentially Massive (George Hulme)

<Monty Solomon <>>
Sat, 30 Aug 2008 01:24:54 -0400

BNY Mellon Data Breach Potentially Massive

Posted by George Hulme, Aug 29, 2008 10:09 PM

It was in May when we noted an investigation launched by the authorities in
the state of Connecticut into a backup tape lost by the Bank of New York
Mellon. The results of that investigation are in, and they don't look good.

First, some background (which is available in my earlier post, here).  A
backup 10 unencrypted backup tapes with millions of customers' information
had gone missing on Feb. 27, and the Connecticut authorities wanted to know
more, as there were up to half-million Connecticut residents private
information place at risk.

Here's what those (unencrypted) tapes contained, according to Attorney
General Blumenthal's letter:

BNY representatives informed my office that the information on the tapes
contained, at a minimum, Social Security numbers, names and addresses, and
possibly bank account numbers and balances.

That's just great, isn't it.

At first, we thought there were 4 million whose private financial
information was on those tapes; turns out now that there could be up to 10
million. Here's what Connecticut Gov. M. Jodi Rell has to say in a statement
released yesterday:

"It is simply outrageous that this mountain of information was not better
protected and it is equally outrageous that we are hearing about a possible
six million additional individuals and businesses six months after the
fact," Governor Rell said. "We fear a substantial number of Connecticut
residents are among this latest group."

I couldn't agree more. There is absolutely no acceptable excuse as to why
this information was not encrypted on these tapes. None.

The BNY Mellon has set up this Web site for those who may have been affected
by this incident.

Student hacker exposes Carleton U cash, ID card security holes

<Sergei Patchkovski <>>
Tue, 09 Sep 2008 12:09:33 +0000

On 9 Sep 2009, CBC News carried a report of a security breach of the
Carleton University student ID cards. The Ottawa-based university issues the
barcode and magnetic stripe-equipped cards to the students. The cards can be
used to access on-campus buildings (including some of the residences), pay
for services on-campus, and access university e-mail systems. According to
the news report, a student (it is not clear from the report whether this was
a student at Carleton, or at the Ottawa U - the other large university in
the area) has compromised the security of the card by writing a piece of
software "in a few hours" and installing it on a computer lab terminal. The
attacker was able to collect the e-mail login credentials of at least 32
Carleton students. He/she then proceeded to report the breach to the victims
and the university authorities, under an alias "Kasper Holmberg". In the
report, he/she suggested that the system in its present form lacks the most
basic safeguards against misuse, and should be suspended. University
authorities has issued new ID cards to the affected students, and assured
campus ID card users that "the campus e-mail system and campus card network
are safe". The university is further considering calling in the police and
charging "Karsper Holmberg" criminally for taking "a very odd way to draw
attention to the security of the system", according to the university
spokes-person, Christopher Walters.

The complete news story can be found at:

Whit Diffie and Susan Landau: Internet Eavesdropping

<Randall Webmail <>>
August 30, 2008 1:32:46 AM EDT

  [From several other groups that I see, including Dave Farber's IP.  PGN]

As telephone conversations have moved to the Internet, so have those who
want to listen in. But the technology needed to do so would entail a
dangerous expansion of the government's surveillance powers

By Whitfield Diffie and Susan Landau

As long as people have engaged in private conversations, eavesdroppers have
tried to listen in. When important matters were discussed in parlors, people
slipped in under the eaves — literally within the `eaves drop' — to hear
what was being said. When conversations moved to telephones, the wires were
tapped. And now that so much human activity takes place in cyberspace, spies
have infiltrated that realm as well.

Unlike earlier, physical frontiers, cyberspace is a human construct.  The
rules, designs and investments we make in cyberspace will shape the ways
espionage, privacy and security will interact. Today there is a clear
movement to give intelligence activities a privileged position, building in
the capacity of authorities to intercept cyberspace communications. The
advantages of this trend for fighting crime and terrorism are obvious.

The drawbacks may be less obvious. For one thing, adding such intercept
infrastructure would undermine the nimble, bottom-up structure of the
Internet that has been so congenial to business innovation: its costs would
drive many small U.S. Internet service providers (ISPs) out of business,
and the top-down control it would require would threaten the nation's role
as a leader and innovator in communications.

Furthermore, by putting too much emphasis on the capacity to intercept
Internet communications, we may be undermining civil liberties. We may also
damage the security of cyberspace and ultimately the security of the
nation. If the U.S. builds extensive wiretapping into our communications
system, how do we guarantee that the facilities we build will not be
misused? Our police and intelligence agencies, through corruption or merely
excessive zeal, may use them to spy on Americans in violation of the
U.S. Constitution. And, with any intercept capability, there is a risk that
it could fall into the wrong hands. Criminals, terrorists and foreign
intelligence services may gain access to our surveillance facilities and use
them against us. The architectures needed to protect against these two
threats are different.

Such issues are important enough to merit a broad national debate.
Unfortunately, though, the public's ability to participate in the discussion
is impeded by the fog of secrecy that surrounds all intelligence,
particularly message interception (`signals intelligence').  [...]
IP Archives:

  [Beware of the Adamant Eaves Drop.  PGN]

US .gov website asks for personal info without https protection

<Jonathan Thornburg <>>
Fri, 29 Aug 2008 08:34:40 +0100 (BST)

I recently used the US Immigration and Customs Enforcement Agency's
SEVIS (Student and Exchange Visitor Information System) to pay the fee
for a US visa.  The online version of this lives at
This process requires typing a variety of personal information into web
forms lined from the site, including full name, place/date of
birth, and passport number.  If one wants to pay online, credit card
information (including CVV2) is also required.

The index page for this system links to https urls for the actual form (as
javascript-activated popups), but disables browser titlebars on the popular
windows, so for most users there's little evidence of https security.  And
indeed, those https urls aren't even under a .gov domain, but rather
(outsourced?) under  I also saw no warnings about the dangers of
typing such sensitive information on a public computer.

The risks of identity theft, or even "just" credit-card fraud, seem very

Re: Germany's New Unified Tax Identification Codes (Fritzsch, R-25.29)

<Kevin Pfeiffer <>>
Fri, 05 Sep 2008 11:15:10 +0200

> It seems definite that obviously white spaces in the original data were
> misinterpreted during data transfer. Technical reasons remain until now
> unknown.

Empty fields, not "white space"

Ralf Fritzsch repeats the error from the original posting: the
German-language newspaper source quoted wrote "empty [data] fields", not
"white spaces". (Shades of the children's game "Stille Post" --

Re: Firefox 3's Step Backwards ... (Barrett, RISKS-25.29)

<Dimitri Maziuk <>>
Wed, 20 Aug 2008 12:52:47 -0500

> ... I believe that the criticism of Firefox 3.0 was simply misguided and
> ill-informed. This is not helpful.

Side note #1: the obvious self-contradiction. State that argument was
strictly about encryption, then list a bunch of things that have nothing to
do with encryption, then conclude that argument is misguided and

Side note #2: from day one SSL's been criticized for mixing two different
things: encryption and authentication in one protocol. This precisely why.
It's a design problem, most of the time you can't fix those in an

Aside from those, three problems with this argument are:

1. Why would I ever trust a certificate signed by someone called GoDaddy?
   Especially over the one I generated and signed myself?

2. Nobody expects browser developers to come up with a solution for design
   flaw in underlying protocol (see side note #2) that works well for every
   user. Yet,

> The general logic is that most users should never be presented with ... a
> choice and the browser should make the decision for them.  [sic]

3. The problem is not that firefox complains, it's that it previously
complained that *signature cannot be verified*.  Now it complains about
*invalid certificate*. Technically a properly self-signed cert — "criminal"
or not — is "invalid" only because firefox developers say so. And thy shalt
trust their judgment because they, like GoDaddy, Know Better(tm).

Side note #3: another annoying new feature is that you can't type or paste
into file upload field anymore.

Dimitri Maziuk, BioMagResBank, UW-Madison —

Please report problems with the web pages to the maintainer