[RISKS] Risks Digest 25.89

From: RISKS List Owner <risko_at_private>
Date: Thu, 7 Jan 2010 15:17:41 PST
RISKS-LIST: Risks-Forum Digest  Thursday 7 January 2010  Volume 25 : Issue 89

Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy

***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <http://www.risks.org> as
The current issue can be found at

  Contents: "HAPPY NEW YEAR!!!"
Y2K+10 problem 1. German contactless bank cards (Debora Weber-Wulff)
Y2K+10 problem 2: Symantec (PGN)
Y2K+10 problem 3: Bank of Queensland Eftpos system (Jared Gottlieb)
Y2K+10 problem 4: SpamAssassin tags "2010" e-mail as spammish (Danny Burstein)
Y2K+10 Bug, for those who thought that Y2K was a made up crisis (Bob Gezelter)
Verizon: I just don't know what to say (Geoff Kuenning)
Eurostar Risks (Anthony Thorn)
Display: none; visibility: hidden; overflow: hidden (jidanni)
Crumbling Crypto: RSA 768 modulus factored + security implications (PGN)
Couple Stuck in Oregon Snow for 3 Days After GPS Leads Them Astray
  (Richard Grady)
Risks of Relying on Downstream Syndication (Bob Gezelter)
Re: Teleportation via Skyhook (Gary Bliesener)
Toyota acceleration; is it just the gas pedal or not? (David Lesher,
  Curt Sampson, Dick Mills, Jerry Leichter, Amos Shapir, Rob Seaman)
Abridged info on RISKS (comp.risks)


Date: Tue, 05 Jan 2010 00:33:39 +0100
From: Debora Weber-Wulff <weberwu_at_htw-berlin.de>
Subject: Y2K+10 problem 1. German contactless bank cards (3 messages)

Happy New Year!

Germans now have the answer as to why they came up short at the ATMs after
the New Year. Tagesschau reports online that people who were using newer
cash machine cards that had new-fangled golden chips in them were told at
the machine that their cards had an error because of a "software error". Not
only ATM machines were affected, supermarkets and such that check cards
online refused to accept the cards.

Since I have spent the first 4 days of the year writing "20010", anyone want
to speculate that this is the error?  No details on the exact nature of the
error as yet. It is scheduled to be fixed tonight (Jan. 4!).

Not all of the machines refused to work, only the newer ones with the
"EMV-Standard" (http://en.wikipedia.org/wiki/EMV) which are to keep the
cards from being duplicated illegally and "secure" the data.

Older cards, which store information on a magnetic strip, were not affected.

I'm glad I still have an old card and an ancient machine around the
corner. I got money after New Year's.

More: Wed, 06 Jan 2010 17:36:57 +0100

It is getting curiouser and curiouser! The Tagesschau reports in
http://www.tagesschau.de/wirtschaft/eckarte108.html and
http://www.tagesschau.de/wirtschaft/kreditkarten144.html, which
I translate and summarize here:

It turns out that even more cards are affected, and even more people are
unable to use either their EC cards or their credit cards to obtain cash or
to pay in stores.

The culprit has been named: The company that produces the cards,
Gemalto. Seems that the software thinks that it is the year 2016 and not
2010, so all of the cards are no longer valid. A friend pointed out to me
that 2016 is 11111100000 in binary. [*]

The problem is a program stored on the chip. The banks don't want to have to
exchange all of the cards (a really expensive solution), so they are looking
for a workaround. One was promised for Monday evening, but it has not yet
materialized. ATMs are generally now accepting the cards again [meaning they
probably don't do any checking now...], but the Point of Sale terminals
refuse to cooperate.

30 million cards are affected, and changing them would entail the owners all
having to learn a new code for their cards. Only German cards are
affected. Many hundred thousand cards were just exchanged in November
because of problems with the data of cards used in Spain having been
available after a security breach.

The company Gemalto was formed 2006 in the fusion of the French company
Gemplus International and the Dutch Axalto Group. The company has 10.000
employees and produces bank cards, telephone SIM cards and electronic
passports. The company reports a volume of 1,68 billion euros in 2008.

Consumer organizations and the consumer minister are blasting the banks for
informing the consumers only a little bit at a time.

* On a side note, customers of smartphones using Windows Mobile operating
system have been noticing that incoming SMS messages also have the date

Still More: Thu, 07 Jan 2010 08:58:34 +0100

Just a bit of scotch tape, sir!

The great Y2K+10 problem in Germany continues:

The chips were put on the cards to make them more difficult to
duplicate. But it turns out, they at least have a fail-safe mode.  If the
chip is found to be malfunctioning or not there, the card readers resort to
reading the magnetic stripe.

Spiegel and others report that all it takes is a little Scotch tape over the
contacts of the card, and the readers will switch to fail-safe mode.
Retailers now dispense tape at the cash registers.

It is great that they have this mode, but it kind of makes you wonder how
safe these expensive chips really make you, if they can so easily be

Prof. Dr. Debora Weber-Wulff, HTW Berlin, Treskowallee 8, 10313 Berlin
Tel: +49-30-5019-2320 http://www.f4.htw-berlin.de/people/weberwu/


Date: Thu, 7 Jan 2010 11:44:54 PST
From: "Peter G. Neumann" <neumann_at_private>
Subject: Y2K+10 problem 2: Symantec

Symantec Y2K10 Date Stamp Bug Hits Endpoint Protection Manager

Updates after 31 Dec 2009 11:59 p.m are being labeled as "out-of-date."


Date: Sun, 3 Jan 2010 11:22:18 -0700
From: jared gottlieb <jared_at_private>
Subject: Y2K+10 problem 3: Bank of Queensland Eftpos system

Retail businesses across the country have lost thousands of dollars over the
long weekend because a computer glitch left shoppers unable to use the Bank
of Queensland's Eftpos terminals.  BOQ's Eftpos machines skipped ahead six
years when the clock ticked over to January 1 and started date stamping
January 2016.  BOQ staff have not been able find what caused the problem,
but a temporary solution has been put in place to ease retailers'
frustrations.  The glitch cost businesses untold amounts as the Eftpos
terminals read customers' [debit] cards as having expired and refused their
transactions.  [Source: *Sydney Morning Herald* 3 Jan 2010, AAP news wire]


Date: Sat, 2 Jan 2010 10:28:38 -0500 (EST)
From: danny burstein <dannyb_at_private>
Subject: Y2K+10 problem 4: SpamAssassin tags "2010" e-mail as spammish

Spam Assassin is a pretty widely used e-mail filtering program.  One of the
rules it uses is checking the date on incoming e-mail. If it's wrong, then
some points are added to the "is this spam?" score.

It seems that up until a rushed update the afternoon of Jan. 1st, 2010, the
standard installations, using the default rule set, considered the year
"2010" to be way off in the future. Accordingly they gave e-mail with that
date an automatic 3.5 points. Five points gets you to the "spam threshold",
so lots of material coming through on the new year got clobbered.

It seems the "year date" was hard/hand coded, as opposed to making a
comparison to "today's" date.

The SpamAssassin folk have a new version which corrects this problem. Folk
running SA can also modify that one rule set and bypass the issue.


  [Also noted by Dave Horsfall:
    "To summarise, it blocks messages with dates set too far in the future
    (which apparently is a common spammer trick - I read my e-mail in forward
    order of delivery) and 2010 was inside the range of 2010-2099."]


Date: Wed, 06 Jan 2010 16:52:14 -0500
From: Bob Gezelter <gezelter_at_private>
Subject: Y2K+10 Bug, for those who thought that Y2K was a made up crisis

Recently, I have seen several letters questioning the whether Y2K was a real
hazard, or whether it was an invented crisis. Several of these letters have
appeared in *The New York Times* Letters page following the publication of
"It's Always the End of the World as We Know It" (Op Ed, 1 Jan 2010).

The coincidence is uncanny. Yesterday (5 Jan 2010), Network World published
"Y2K all over again in 2010?" on a series of outages related to this most
recent decade change.

The Network World article can be found at:
The New York Times Op Ed can be found at:
The Letters relating to Op Ed can be found at:

- Bob Gezelter, http://www.rlgsc.com


Date: Sat, 02 Jan 2010 14:23:51 -0800
From: Geoff Kuenning <geoff_at_private>
Subject: Verizon: I just don't know what to say

Recently, Verizon took over MCI, resulting in me getting them as my new
local telephone provider.  This afternoon, I used Verizon's online site
to change the billing address for my account.  About an hour later, I
got a nice automated phone call that was intended to verify that the
change was legitimate.

So far, so good.  But the automated voice informed me that if I hadn't
authorized the change, I should "contact us at [slight pause] between
the hours of [slight pause] and [slight pause].  Thank you for choosing

I guess I should be glad that "[slight pause]" didn't come out as "left
parenthesis null pointer right parenthesis."

Geoff Kuenning   geoff@private   http://www.cs.hmc.edu/~geoff/


Date: Sun, 27 Dec 2009 10:09:44 +0000 (GMT)
From: "anthony.thorn_at_private" <anthony.thorn_at_private>
Subject: Eurostar Risks

On December 18th, 5 Eurostar passenger trains failed, in the Channel tunnel
trapping 2000 passengers.  (Eurostar is the rail service through the tunnel
under the English channel) The service only resumed on Tuesday 22nd.

The failure was due to inadequately "winterised" trains encountering snow
and extremely cold weather: "The snow entered the locomotives' ventilation
system... When the trains entered the great warmth of the tunnel, the
electrical system short-circuited and the traction motors of the Eurostars
cut out and would not start again."

This problem was known.  It is NOT a "Black Swan" !

Apparently in contrast to the passenger trains, the car-transporter trains
are sufficiently winterised.

If the failure was not already a disaster, there is no doubt at all about
the evacuation.

Some passengers were trapped in the tunnel for up to 14 hours, and
complained about lack of/conflicting information, as well as the heat.

Thousands of passengers waited at the railway (train) stations for a service
that would not be available for days.

There was not much of an alternative: huge queues for ferries , and planes
delayed by the weather.


The risks:

1. (IMHO)  an inadequately tested contingency plan.

2. We passengers assume that a rail service will be reliable -because it
almost always is.  Perhaps we should not/cannot and need to take our own
"emergency equipment" along?


Date: Tue, 05 Jan 2010 06:37:57 +0800
From: jidanni_at_private
Subject: Display: none; visibility: hidden; overflow: hidden

I suppose it's fair game these days to hide anything you like within an
HTML div style="display: none; visibility: hidden; overflow: hidden;"
like they do on http://topics.cnn.com/topics/weather .
They even store a "404 Error The page you requested cannot be found"
inside that HTML div. "Who would ever browse without using (our) stylesheets?"


Date: Thu, 7 Jan 2010 11:40:28 PST
From: "Peter G. Neumann" <neumann_at_private>
Subject: Crumbling Crypto: RSA 768 modulus factored + security implications

After an extensive multiyear collaborative effort, the RSA 768-bit challenge
number has been factored, suggesting that 1024-bit prime products may be
somewhat closer to approaching the end of their practical lifetimes.

  http://bit.ly/8xXSgy  (International Association for Cryptologic Research)


Date: Mon, 28 Dec 2009 13:52:20 -0800
From: Richard Grady <richard_at_private>
Subject: Couple Stuck in Oregon Snow for 3 Days After GPS Leads Them Astray

KLAMATH FALLS, Ore.  A Nevada couple letting their SUV's navigation system
guide them through the high desert of Eastern Oregon got stuck in snow for
three days when the GPS unit sent them down a remote forest road.


Date: Mon, 04 Jan 2010 19:20:31 -0500
From: Bob Gezelter <gezelter_at_private>
Subject: The Risks of Relying on Downstream Syndication

It is common to rely on downstream syndication feeds (e.g., ATOM, RSS,
usenet news) for information. Unfortunately, sometimes there are "clogs" in
the pipeline that result in delayed, lost, or out of sequence messages.

Those who read RISKS using Google Groups have recently experienced just such
an episode. RISKS 25.85, 25.86, and 25.87 are out of sequence on the archive
at http://groups.google.com/group/comp.risks and RISKS 25.88 is completely
missing as of this date (4 January 2010), despite having been posted on
26 December.

Fortunately, the RISKS page at http://www.risks.org is up to date.

Bob Gezelter, http://www.rlgsc.com


Date: Tue, 29 Dec 2009 10:45:31 -0500
From: Gary Bliesener <gbliesener_at_private>
Subject: Re: Teleportation via Skyhook

The default browser, Polaris 6.0, on my Samsung Rant is nearly useless so I
installed the Opera Mini-Browser.  I ran into IP geolocation issues when
responding to e-mailed employment alerts, as many websites would reject my
application with a message informing me that one must be a United States
resident to apply for their position, even though I am an American using the
phone in the mid-Atlantic region of the United States.  The Opera
mini-browser evidently brings with it an IP address out of what IP
geolocation types would label a "Norwegian address pool".  I had to wait
until my return home to apply, rather defeating the purpose of purchasing a
web and e-mail enabled cellphone.

Gary Bliesener, Unix System Administrator


Date: Sun, 27 Dec 2009 01:35:32 -0500
From: David Lesher <wb8foz_at_private>
Subject: Toyota acceleration; is it just the gas pedal or not? (RISKS-28.85)


An *LA Times* item has lead the coverage of the issue, bringing up the
accusation that the problem is not just mechanical interference between the
mats and the pedals, but also more.

  Eric Weiss was stopped at a busy Long Beach intersection last month when
  he said his 2008 Toyota Tacoma pickup unexpectedly started accelerating,
  forcing him to stand on the brakes to keep the bucking truck from plowing
  into oncoming cars.  ..  But Weiss is convinced his incident wasn't caused
  by a floor mat. He said he removed the mats in his truck months earlier on
  the advice of his Toyota dealer after his truck suddenly accelerated and
  rear-ended a BMW.

Also, I saw a mention that a previous driver of the car that crashed had
complained to the dealer about the problem, but it was reissued to the
victim despite that. If true, THAT would not alter the cause, but would
likely change the legal liability issues.


Date: Sun, 27 Dec 2009 16:14:54 +0900
From: Curt Sampson <cjs_at_starling-software.com>
Subject: Re: Another user interface fatal accident in Afghanistan

Re: Mark Thorson, RISKS-25.88

> When the target position is cleared, it would probably be better to
> initialize it 100 meters to the east or something, rather than right on
> top of the observer position.

Where it might drop on your friends?

It seems to me one wants to expand the range of values to include "no target
position." It can't be all that unusual sometimes not to want to drop a

Curt Sampson         <cjs_at_private>         +81 90 7737 2974


Date: Sun, 27 Dec 2009 09:47:25 -0500
From: Dick Mills <dickandlibbymills_at_private>
Subject: Re: LED Traffic Lights are efficient ... (R 25 88)

  John Johnson (R 25 88): "The problem is also evident on motor vehicles
  with LED signal and stop lights.  Snow is not melted away by the signal
  and stop lights and accumulation blocks the lights."

Neither can incandescent stop and signal lights melt snow if they are not
used often; such as long stretches of driving on the open highway.  Nor
could they melt snow when there was a generous air gap between the bulb and
the lens cover.

I can't recall any mention of this risk in the pre LED era. What's new?


Date: Sun, 27 Dec 2009 05:38:43 -0500
From: Jerry Leichter <leichter_at_private>
Subject: Re: LED Traffic Lights are efficient ... (R 25 88)

John Johnson's mention (R 25 88) of a story that LED traffic lights can be a
problem if it snows because they don't generate enough heat to clear
themselves brings to mind a repeated story from the NY area.  Every fall, we
get delays in mass transit because of wet leaves on train tracks.  I never
recalled hearing of such problems years back, and indeed reports have
indicated that this is another side-effect (or lack of a side-effect!) of
new technology.

In the old days, trains stopped by apply brake pads to the wheels.  The
resulting friction heated the wheels and rails and rapidly dried and burned
off any leaves.  Today, the trains use regenerative braking: The wheel
motors are run as generators, recovering much of the kinetic energy of the
train as electricity.  Much more efficient - but as a result, the wheels and
rails no longer hot enough to perform a leaf-clearing function.


Date: Sun, 27 Dec 2009 17:55:49 +0200
From: Amos Shapir <amos083_at_private>
Subject: Re: LED Traffic Lights are efficient ... (R 25 88)

This is actually an old problem with a new twist: the designers of traffic
lights and headlights were -- probably unknowingly -- relying on an
undocumented feature of incandescent light bulbs, namely their ability to
generate enough heat to melt snow on cold days.  Obviously it did not occur
to anyone that light fixtures should be redesigned for a different type of


Date: Mon, 28 Dec 2009 00:07:47 -0700
From: Rob Seaman <seaman_at_private>
Subject: Re: LED Traffic Lights are efficient ... (R 25 88)

The general class of risk here is that of unintended consequences.  It may
be helpful to drill down into the specifics of what is going wrong.  In both
of these submissions (traffic or vehicle signals), LEDs are replacing
incandescent bulbs in outdoor applications subject to varying weather
conditions.  The notion appears to be that nobody could have predicted that
more efficient lamp technology would be subject to a failure mode in the

Such a notion is mired in confusion over the difference between describing a
problem and entertaining solutions to that problem.  "Unintended
consequences" is another way of saying "undiscovered requirements".  The
underlying problem is one of signaling, not of lighting technology.  After
all, before there were traffic lights, there were unlighted traffic
semaphores.  Drivers still use hand signals on occasion to supplement
lighted turn signals and brake lights.

The common goal is to communicate signals (of intent, permission, and
proscription) between a community of drivers, pedestrians, and other roadway
users.  In addition to numerous requirements relating to sequencing of
interlocking signals, there are - as a matter of course - various
requirements regarding weather and ambient visibility (and other sensory)
conditions.  For instance, presumably the LED manufacturers did not neglect
to consider the effect of rain on the operation of their signals.

A complete set of top level requirements for a roadway signaling system
might not even mention lighting technology at all.  More likely, constraints
on lighting will appear as non-functional requirements describing current
practices and standards (eg., the order of the colors on a traffic signal).
A statement that a signal device should continue to operate when it is
snowing (presumably up to some NNN-year blizzard threshold) is very much a
functional requirement inherent in the concept of operations.

A compliance audit/acceptance test should have caught this issue - almost by
inspection - before deployment.  LEDs are desirable because they inexpensive
to operate due to their high efficiency.  They are efficient because they
emit far less waste heat.  What happens to the snow accumulation when heat
is removed from the system?

Some possible solutions have already been mentioned: a heating element
(perhaps actively controlled), weather shielding, special coatings.  The
point is that there is one problem description ("signal must continue to
operate when it is snowing"), but many different options for solutions.  It
is impossible to evaluate the acceptability of any solution without matching
it point-by-point against the problem requirements the solution is meant to

Some risks are long and involved to describe.  It is precisely that this
issue can be characterized so succinctly that reveals a requirements
failure.  Whether the vendor or the customer bears a larger burden of the
responsibility for the failure is a separate question.

Rob Seaman, National Optical Astronomy Observatory seaman_at_private


Date: Thu, 29 May 2008 07:53:46 -0900
From: RISKS-request_at_private
Subject: Abridged info on RISKS (comp.risks)

 The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
 if possible and convenient for you.   The mailman Web interface can
 be used directly to subscribe and unsubscribe:
 Alternatively, to subscribe or unsubscribe via e-mail to mailman
 your FROM: address, send a message to
 containing only the one-word text subscribe or unsubscribe.  You may
 also specify a different receiving address: subscribe address= ... .
 You may short-circuit that process by sending directly to either
   risks-subscribe_at_private or risks-unsubscribe_at_private
 depending on which action is to be taken.

 Subscription and unsubscription requests require that you reply to a
 confirmation message sent to the subscribing mail address.  Instructions
 are included in the confirmation message.  Each issue of RISKS that you
 receive contains information on how to post, unsubscribe, etc.

=> The complete INFO file (submissions, default disclaimers, archive sites,
 copyright policy, etc.) is online.
 The full info file may appear now and then in RISKS issues.
 *** Contributors are assumed to have read the full info file for guidelines.

=> .UK users should contact <Lindsay.Marshall_at_private>.
=> SPAM challenge-responses will not be honored.  Instead, use an alternative
 address from which you NEVER send mail!
=> SUBMISSIONS: to risks_at_private with meaningful SUBJECT: line.
 *** NOTE: Including the string "notsp" at the beginning or end of the subject
 *** line will be very helpful in separating real contributions from spam.
 *** This attention-string may change, so watch this space now and then.
=> ARCHIVES: ftp://ftp.sri.com/risks for current volume
     or ftp://ftp.sri.com/VL/risks for previous VoLume
 <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive
 http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.
   Lindsay has also added to the Newcastle catless site a palmtop version
   of the most recent RISKS issue and a WAP version that works for many but
   not all telephones: http://catless.ncl.ac.uk/w/r
 <http://the.wiretapped.net/security/info/textfiles/risks-digest/> .
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
    <http://www.csl.sri.com/illustrative.html> for browsing,
    <http://www.csl.sri.com/illustrative.pdf> or .ps for printing
==> Special Offer to Join ACM for readers of the ACM RISKS Forum:


End of RISKS-FORUM Digest 25.89
Received on Thu Jan 07 2010 - 15:17:41 PST

This archive was generated by hypermail 2.2.0 : Thu Jan 07 2010 - 16:13:22 PST