The RISKS Digest
Volume 25 Issue 58

Sunday, 22nd February 2009

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…


Buffer overflows in SHA-3 submissions
Joy Marie Forsythe
Re: Train brake failure - broken valve
Al Stangenberger
Due Diligence or is that "Don't..."? Citibank fraud
David Lesher
Digital Archivists, Now in Demand
Conrad De Aenlle via Monty Solomon
Re: Wikipedia prankster dupes German media
Debora Weber-Wulff
Re: Control-Alt-Eject? French Navy grounded
Capital One Phishing Warning is dangerous
Marc Auslander
Re: The mystery of 'Ireland's worst driver'
Bernard Lyons
Re: Hiding in plain sight
Phil Smith III
Bounds checking in C
Andrew Koenig
The risks of Silver Bullets
Michael Smith
Re: Tony Hoare: "Null References"
Steven M. Bellovin
Dimitri Maziuk
Randy Saunders
Related to blacklists for antispam
De Vries Duane
Re: Dates of birth are not unique identifiers
David E. Ross
Re: USAA Web site follies
Jonathan Kamens
Alert TA09-051A — Adobe Acrobat and Reader Vulnerability
US-CERT via Monty Solomon
Info on RISKS (comp.risks)

Buffer overflows in SHA-3 submissions

Joy Marie Forsythe <>
Sat, 21 Feb 2009 11:19:27 -0800

NIST is currently holding a competition to choose a design for the SHA-3
algorithm. The reference implementations of a few of the contestants have
bugs in them that could cause crashes, performance problems, or security
problems if they are used in their current state. Based on our bug reports,
some of those bugs have already been fixed.

Two of the projects (Blender and MD6) contained buffer overflows. The rest
of the issues found were out-of-bounds reads, memory leaks and null
dereferences. The code was good overall, but it's important to get these
implementations right. They end up being the basis for future
implementations, or used as is, and can be a factor is the outcome of the
SHA-3 competition.

More details about the issues:

Joy Marie Forsythe, Security Researcher, Fortify Software  1-650-358-5621

Re: Train brake failure - broken valve (Lesher, RISKS-25.56)

Al Stangenberger <>
Fri, 20 Feb 2009 12:19:44 -0800

The lack of an emergency brake exhaust valve in a locomotive must be a
British peculiarity.  Every American locomotive built within the past
century has an emergency dump valve in the locomotive cab (and these are the
Westinghouse brake design).  When locomotives had firemen, the valve was
located by the fireman's seat in case the engineer was incapacitated.

Also, every American railroad passenger car has an emergency dump valve (aka
the conductor's valve).  In older cars this valve was connected to a cord
which ran above the windows for the full length of the car.  Modern cars
eliminated the emergency cord, and now the handle for the conductor's valve
is often found near the vestibule at the end of the car.  It is often not
very obvious, but the crew knows where it is.

AL Stangenberger, Western Railway Museum

  [Added: Fri, 20 Feb 2009 19:43:15 -0800]

I learned a lot more about railroad locomotive emergency brake valve

Emergency brake valves are now only required by U.S. Federal law (49 CFR
Ch. II, sec. 229.47) if the locomotive cab is designed for occupancy by more
than one person.  The requirement is actually for the valve to be accessible
to a member of the crew other than the engineer.

In the British case in RISKS, the US-built locomotive was designed for only
one person in the cab, so the emergency brake pipe valve was not required.
Possibly this policy should be reconsidered.

In any case, though, it is not the case that nobody ever thought about
having emergency valves in Westinghouse-design air brake systems.

Due Diligence or is that "Don't..."? Citibank fraud

"David Lesher" <>
Sat, 21 Feb 2009 15:10:59 -0500 (EST)


"A Nigerian citizen duped Citibank into wiring $27 million to accounts that
he and others controlled, prosecutors said."  Citibank accepted a package
changing contact data for the National Bank of Ethiopia; and only months
later noticed it came not from Ethiopia but Lagos, Nigeria.  When they
finally started looking into it; they also found the new contact numbers
were cell phones in Nigeria, UK and South Africa.

I'm reminded of the ex-President who'd never seen a grocery store
scanner. An enormous international bank has never connected Nigeria and
identity fraud?

The Risk? Reliance on easily forged documents with no verification.

Sometimes, a fraud too simple to ever work, shall...

Digital Archivists, Now in Demand (Conrad De Aenlle)

Monty Solomon <>
Sat, 21 Feb 2009 15:53:29 -0500

Conrad De Aenlle, Fresh Starts: Digital Archivists, Now in Demand, *The New
York Times*, 8 Feb 2009

When the world entered the digital age, a great majority of human historical
records did not immediately make the trip.

Literature, film, scientific journals, newspapers, court records, corporate
documents and other material, accumulated over centuries, needed to be
adapted for computer databases. Once there, it had to be arranged - along
with newer, born-digital material - in a way that would let people find what
they needed and keep finding it well into the future.

The people entrusted to find a place for this wealth of information are
known as digital asset managers, or sometimes as digital archivists and
digital preservation officers. Whatever they are called, demand for them is

One of them is Jacob Nadal, the preservation officer at the University of
California, Los Angeles. He does not use the "digital" modifier because his
duties include safeguarding analog materials in U.C.L.A.'s collection, not
just preparing them to cross the digital divide.

"I don't think there's any day where I would say I'm the digital guy," he
said. But he concedes that he's not really an analog, ink-on-paper guy,
either, and that is increasingly the case in his field. These days, he
noted, "if you want to work in a library, you have to deal in electronic

Mr. Nadal and 10 or so colleagues at U.C.L.A. devote much of their effort to
organizing and protecting material in digital form. Their duties include
licensing and buying digital content from vendors, assigning identification
markers called meta-tags so that material can be found easily, researching
copyright matters and ensuring that files remain intact whenever new
iterations of relevant software or hardware come along. ...

Re: Wikipedia prankster dupes German media (RISKS-25.57)

Debora Weber-Wulff <>
Sat, 21 Feb 2009 14:00:06 +0100

Actually, the prank goes deeper.

An anonymous IP (shorthand for non-registered editors on the Wikipedia),, a broadband user from Cologne, added the additional given
name "Wilhelm" on 8 Feb 2009 at 9.40 pm for the newly designated German
Minister of Commerce [1]. As a true blue-blood, he has more than the average
number of them.

On 9 Feb at 12.23 pm the administrator Arudaki complained that there was no
source for this name, and removed all of the additional given names [2]. But
by then the damage had been done, and the newspapers who had done a quick
Wikipedia "fact"-check were already online and included the name "Wilhelm".

A rage ensued, as people "fixed" the Wilhelm back in, quoting the now online
sources that had used the faked Wikipedia entry. As is usual in a vandalism
war, the page was removed from editing mode until people could cool down and
get out a copy of the German peerage book [3] and discover that there was no
"Wilhelm" listed there. The page is back being editable (and of course the
pranksters keep putting in new names such as "Marcus", but they get quickly
reverted (and the prankster given an hour in the corner, unable to edit).

Anonymous then bragged about his or her heroic feat in [4], and it became
clear that the German media relies heavily on the Wikipedia, without
citation, of course. And this is not just the more yellow press, many
newspapers printed the name.

The risks? Don't rely on Wikipedia information for current events. And find
a second, preferably offline, source for your information if you are doing
serious journalism. Especially if you are doing print.

Genealogischen Handbuch des in Bayern immatrikulierten Adels, Band 17.
Neustadt, Aisch, 1988
with picture document of the Bild front page

Prof. Dr. Debora Weber-Wulff,FHTW Berlin, FB 4, Internationale Medieninformatik
(from 1.4.2009 HTW Berlin), Treskowallee 8, 10313 Berlin +49-30-5019-2320
weberwu@(f) http://www.f4.(f)

Re: Control-Alt-Eject? French Navy grounded (Lesher, RISKS-25.56)

CBFalconer <>
Fri, 20 Feb 2009 23:26:21 -0500

... From this I conclude that France is using Windows in its military.  I
thought nobody other than the US (and possibly the UK) were so foolish.

Capital One Phishing Warning is dangerous

"Marc Auslander" <>
Sat, 21 Feb 2009 16:00:53 -0500

I got an e-mail alert from Capital One that a new message was in my account.
The messages was a boilerplate warning that a phishing attach on Capital One
was in progress.  Unfortunately, the email alert was sent by a third party
which Capital One uses for this purpose.  Capital One does not have an SPF
record for the sender, but is using SPF.  GMAIL correctly marks this as a
phishing letter and throws it into SPAM.  If you try to read it you get the
big bright GMAIL phishing warning!

So I try to tell Capital One they have a problem.  Their response is advice
on how to turn the warning off!  So much for their anti-phishing campaign.

Re: The mystery of `Ireland's worst driver' (Cantrell, RISKS-25.57)

Bernard Lyons <>
Sat, 21 Feb 2009 00:25:16 +0000

Ireland doesn't yet have credit-card style licenses (they've been coming
Real Soon Now for several years), but we've had the tri-fold licenses with
standardised numbered fields for well over a decade.  Mine is one.

It defies belief that any Garda doesn't know how to figure out a driving
license - no matter what it looks like - or establish someone's name from
other documentation. Their internal performance rating depends on it,
amongst other things.

Further, Polish people have been working in Ireland since at least the late
1970's to my personal knowledge. They just didn't suddenly appear from
nowhere. So 50 members of An Garda Siochana making the same mistake
stretches credulity.

It's far more likely to be a problem with their PULSE system, perhaps to do
with data entry. It's known to be inflexible, and there were several
expensive investigations into poor design and cost overruns before it went

Something about this story doesn't add up.

Re: Hiding in plain sight

"Phil Smith III" <>
Sat, 21 Feb 2009 09:38:59 -0500

Jeremy Epstein <> wrote about a product with an
asterisk in the middle between two common words, making it almost impossible
to find using search engines.

IBM has done something similar: the hardware line once known as AS/400, then
iSeries, then System i, is now known simply as "i", making it beyond
impossible to find. I can't imagine what their marketroids were thinking.

Bounds checking in C

"Andrew Koenig" <>
Sat, 21 Feb 2009 12:36:14 -0500

There have been a number of claims in RISKS recently that bounds checking is
impossible in C.  These claims are false.  In fact, there was a software
product (Centerline) available for a number of years that checked bounds in
C programs at run time.

However, out-of-bounds array references are far from the only run-time
transgressions in C programs that are both common and difficult to check.
Another such is referring to memory after it has been freed.

Such problems are exacerbated by the fact that at one time (before
approximately 1980), freeing memory was guaranteed not to affect its
contents--it was not until the next time you tried to allocate memory that
any values would be changed.  This phenomenon led to code such as this:

  struct node *p = listhead;
  while (p) {
        p = p->next;

Even worse, the original definition of realloc *required* the memory being
reallocated to be freed first; if you tried to call realloc with memory that
had not been freed, it would *always* allocate new space and copy the
contents of the old memory block into the new space, relying on you to free
the old block in the fullness of time.

Thus the original definition of malloc and free encouraged, and sometimes
required, programmers to use pointers to unallocated memory.  This
requirement made checking for legitimacy very difficult indeed.

The definition of free and realloc were eventually changed to say that free
was permitted to destroy the contents of the memory being freed, and that
realloc could (and should) accept the address of a block that was already
allocated, and would free the block after copying its contents elsewhere.
That change at least made it plausible to check the legitimacy of pointers.

The risks of Silver Bullets (was Tony Hoare: "Null References")

Michael Smith <>
Sun, 22 Feb 2009 18:34:29 +1100

Ah!  If only we had the right programming language, then we could write
robust software.

I have heard that refrain since the early eighties as I developed software
in FORTRAN, BASIC, COBOL, C, C++ Pascal, Prolog and various assemblers,
4GLs, 5GLs and more.  It remains, as it has always been, garbage.

You can write robust code in almost any language and can write garbage just
as easily.

We have known for many years how to write robust software.  We do not do so
for one reason: cost.  We can write junk software much more cheaply than the
good stuff and nobody wants to pay the extra cost.

1. We skimp on training our programmers and architects.  Maybe you can
  teach yourself <$PROGRAMMING_LANGUAGE> in 30 days (or whatever) but it
  takes many years to learn quality software engineering.

2. We rush through the specification phase.  Stakeholders are too busy to
  give time to nailing down requirements.  Sometimes we skip this stage

3. We skimp on the design phase.  Frequently we just start coding with no
  thought of a proper architecture.  Even when we do a design phase it is
  with mobile requirements and a short deadline.

4. We skimp on testing.  We don't have adequate test specs.  We don't have
  well trained testers.  And the pressure to ship, so that we can book some
  revenue, is overwhelming.

We chose not to produce quality software because all those things cost money
and we'd rather make do with the cheap alternative.

If we produced a word processor with almost zero bugs, an intuitive user
interface and excellent performance, but it cost $50,000 per copy, we would
not have a top seller.

Though if every company summed all the cost of crashed and buggy software,
bad products and training to manage poor interfaces, I wonder if it is still
a bargain.

Michael J Smith <>

Re: Tony Hoare: "Null References" (Franklin, RISKS-25.56)

"Steven M. Bellovin" <>
Sat, 21 Feb 2009 14:29:35 -0500

If we're going to take Hoare's name in vain, let me point people to his
Turing Award lecture from 1980:

  The first principle was security: ... A consequence of this principle is
  that every occurrence of every subscript of every subscripted variable was
  on every occasion checked at run time against both the upper and the lower
  declared bounds of the array. ... I note with fear and horror that even in
  1980, language designers and users have not learned this lesson. In any
  respectable branch of engineering, failure to observe such elementary
  precautions would have long been against the law.

And novelty?  Circa 1966, I knew a magic incantation (in Fortran II, using
some platform-specific subroutines) to interfere with the ability to do a
soft reboot.  (The machine in question was an SDS 920; as I recall, it
didn't even have any disk drives.)

Re: Tony Hoare: "Null References" (Ables, RISKS-25.57)

Dimitri Maziuk <>
Sat, 21 Feb 2009 13:01:01 -0600

In this particular case I have to disagree: I believe with C it's not so
much "hysterical raisins" as "nails and screwdrivers".

What gets lost in advocacy hype is that creators of a programming language
usually have a specific set of problems (real, perceived, transient or
fundamental) in mind and are thinking of ways to solve them. The programmers
get to choose what language to write in and it's their job to understand
available tools and choose the right one for the task at hand. For some
definition of "right".

C was created to write portable operating systems in, not end-user
applications. "Portable" is the big plus when you consider potential
customers and all the different computing platforms they may have been
using. The lack of proper high-level facilities is a minus, but what choice
do we have — the language that has std:string and std::vector?  Up until
recently those weren't portable, and judging from past experience there's a
good chance they'll revert to that state again when the next version of C++
standard comes out.

Of course nowadays 99.9% of the target user base is using an x86-based
platform with mice and graphical user interfaces, so one would expect the
focus to shift to the tool that built-in GUI and runs on all x86 computers:
Java virtual machine. Which has a whole lot of its own shortcomings and I'm
sure 20 years down the track we'll read all about them in RISKS.

Re: Tony Hoare: "Null References" (Ables, RISKS-25.57)

Randy Saunders <>
Sat, 21 Feb 2009 16:19:45 -0500

Not everyone in the "olden days" was as trusting as King Ables in
RISKS-25-57.  In the 1970's the Multics implementors at MIT and Honeywell
were developing a time-sharing system.  The language was PL/1, though that's
a minor difference.  Pointers that pointed to segments had bounds, and you
got a hardware exception if you violated them.  In PL/1 this was reflected
as part of a higher level construct called the refer extent of a structure.

The problem programmers happened alone the scene later on, with
microprocessors and "personal" computers.  The professional computer
scientist was displaced by hordes of self-taught C coders.

I hope to live to see today's programming paradigms replaced, I'm on my
third round of "what where those idiots thinking?"

Randy Saunders, JHU Applied Physics Lab +

Related to blacklists for antispam

De Vries Duane <>
Sun, 22 Feb 2009 12:10:25 -0500

This may be pure coincidence but it struck me as very odd. I use Earthlink
as my E-mail provider. I have the 'spam' setting set to put all suspicious
things into a 'spam folder' which I look at every few days (as opposed to
them automatically being deleted). During the U.S.  presidential campaign, I
would frequently find E-mail from 'Democratic' candidates AND conservation
groups in this folder. Not once did I find any E-mail from Republican
candidates in this folder.  I flagged the Democrat and conservation E-mails
as 'not spam' which supposedly sent copies to Earthlink to figure out why
they were improperly marked as spam. However, this kept up until AFTER the
election was over. Then all my mail was delivered correctly.  I'm not
accusing Earthlink of anything duplicitous but I did find it curious.

Duane De Vries, Retired, ex-computer geek, practicing curmudgeon

Re: Dates of birth are not unique identifiers

"David E. Ross" <>
Sun, 22 Feb 2009 11:08:09 -0800

> Steven J Klein asked, "Why not use the social security number, which
  is guaranteed to be unique?"

In California, Civil Code Section 1798.85 generally prohibits the use of
Social Security numbers as identifiers, especially for Internet services.
This law is the result of numerous instances where Social Security numbers
were not adequately protected from improper disclosure, resulting in
identity theft.  Of course, this law cannot be enforced against services
based outside of California.

David E. Ross <>.

Re: USAA Web site follies (Klein, RISKS-25.57)

"Jonathan Kamens" <>
Sat, 21 Feb 2009 18:47:57 -0500

Preventing siblings with the same birthdate from being entered via the Web
site seems like a reasonable precaution, especially given that there is an
easy fallback, i.e., calling and giving the information over the phone.  On
the other hand, I acknowledge that I might see it differently if I had been
thus inconvenienced.

Steven Klein's story about his problem with the USAA Web site brings to mind
a problem I had with the site last week which might be of interest to RISKS

I was entering the information on the Web site for myself and my wife, when
I found listed in my wife's profile a "parent" whose name most certainly was
not the name of one of my wife's parents.  I sent USAA a message about this
through their Web site, and they confirmed that the "parent" had been added
to my wife's profile in error and they had removed it (I was not able to
remove it myself through the Web site).

I don't know what precautions USAA has in place to prevent such "errors"
(e.g., do their member numbers have a checksum digit to detect mistyping?),
but something definitely seems wrong with the fact that someone was able to
attach a complete stranger to my wife's record in their database.

Re: The Trouble with Trusting Trend Micro (RISKS-25.57)

"Jonathan Kamens" <>
Sat, 21 Feb 2009 18:39:18 -0500

Kevin Way's description of the absurd hoops demanded by Trend Micro before
removing static IP ranges from their DNS blocklists reminded me of an
incident which occurred during the 2008 U.S. Presidential Campaign.

I was an active volunteer for one of the candidates and thus regularly
received bulk emailings and email list messages from his campaign.  At some
point during the campaign, the flow of email petered out to nothing.
Eventually I realized that this was because one of the blocklists my mail
server was configured to use, NJABL, had the candidate's mail servers listed
as spam sources.

Only registered users of the candidate's site and donors to his campaign
were added to his mailing lists, and every single message sent by the
candidate had a working unsubscribe link at the bottom of it, so the
candidate could not reasonably be categorized as a spammer.  I contacted
both the maintainers of NJABL and the webmasters of the candidate's site,
pointing out that the site was listed in the blocklist and suggesting that
perhaps one or more people who opposed the candidate had falsely reported
his site as a spam source as a political dirty trick.

I received no response from either NJABL or the webmasters, and after
waiting in vain for several days for the problem to be fixed, I threw up my
hands and removed NJABL from the set of blocklists my server was using.  I'm
now using only the Spamhaus ZEN blocklist, which apparently has somewhat
more rigorous procedures than NJABL.

The implications of being able to use DNS blocklists as weapons in political
campaigns are quite frightening.

Alert TA09-051A — Adobe Acrobat and Reader Vulnerability

Monty Solomon <>
Fri, 20 Feb 2009 21:56:43 -0500

                    National Cyber Alert System
              Technical Cyber Security Alert TA09-051A
     [PGN-excerpted: Please see the cited item in case of updates.]

Adobe Acrobat and Reader Vulnerability

   Original release date: February 20, 2009
   Last revised: --
   Source: US-CERT

Systems Affected

     * Adobe Reader version 9 and earlier
     * Adobe Acrobat (Professional, 3D, and Standard) version 9 and earlier


   Adobe has released Security Bulletin APSB09-01, which describes a
   vulnerability that affects Adobe Reader and Acrobat. This vulnerability
   could allow a remote attacker to execute arbitrary code.

I. Description

   Adobe Security Bulletin APSB09-01 describes a memory-corruption
   vulnerability that affects Adobe Reader and Acrobat. Further details are
   available in Vulnerability Note VU#905281.  An attacker could exploit
   these vulnerabilities by convincing a user to load a specially crafted
   Adobe Portable Document Format (PDF) file.  Acrobat integrates with
   popular web browsers, and visiting a website is usually sufficient to
   cause Acrobat to load PDF content.

II. Impact

   An attacker may be able to execute arbitrary code.

III. Solution

   Disable JavaScript in Adobe Reader and Acrobat [...]
   Prevent Internet Explorer from automatically opening PDF documents [...]

IV. References

 * Adobe Security Bulletin apsa09-01 -

 * Securing Your Web Browser -

 * Vulnerability Note VU#905281 -

   The most recent version of this document can be found at:


   Feedback can be directed to US-CERT Technical Staff. Please send email to
   <> with "TA09-051A Feedback VU#905281" in the subject.

   For instructions on subscribing to or unsubscribing from this
   mailing list, visit <>.
   Produced 2009 by US-CERT, a government organization.

Terms of use:
Revision History
  February 20, 2009: Initial release

Please report problems with the web pages to the maintainer