The RISKS Digest
Volume 25 Issue 89

Thursday, 7th January 2010

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…

Contents

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
Re: Another user interface fatal accident in Afghanistan
Curt Sampson
Re: LED Traffic Lights are efficient ...
Dick Mills
Jerry Leichter
Amos Shapir
Rob Seaman
Info on RISKS (comp.risks)

Y2K+10 problem 1. German contactless bank cards (3 messages)

Debora Weber-Wulff <weberwu@htw-berlin.de>
Tue, 05 Jan 2010 00:33:39 +0100

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.
  http://www.tagesschau.de/wirtschaft/eckarte102.html

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
2016.

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.
http://www.spiegel.de/wirtschaft/soziales/0,1518,670433,00.html

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
defeated.

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


Y2K+10 problem 2: Symantec

"Peter G. Neumann" <neumann@csl.sri.com>
Thu, 7 Jan 2010 11:44:54 PST

Symantec Y2K10 Date Stamp Bug Hits Endpoint Protection Manager
http://www.eweek.com/c/a/Security/Symantec-Y2K10-Date-Stamp-Bug-Hits-Endpoint-Protection-Manager-472518/?kc=EWKNLSTE01072010STR1

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


Y2K+10 problem 3: Bank of Queensland Eftpos system

jared gottlieb <jared@netspace.net.au>
Sun, 3 Jan 2010 11:22:18 -0700

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]


Y2K+10 problem 4: SpamAssassin tags "2010" e-mail as spammish

danny burstein <dannyb@panix.com>
Sat, 2 Jan 2010 10:28:38 -0500 (EST)

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.

Details:
http://wiki.apache.org/spamassassin/Rules/FH_DATE_PAST_20XX
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269

  [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."]
  https://secure.grepular.com/blog/index.php/2010/01/01/spamassassin-2010-bug/


Y2K+10 Bug, for those who thought that Y2K was a made up crisis

Bob Gezelter <gezelter@rlgsc.com>
Wed, 06 Jan 2010 16:52:14 -0500

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:
https://www.networkworld.com/news/2010/010510-date-change-problems.html
The New York Times Op Ed can be found at:
http://www.nytimes.com/2010/01/01/opinion/01dutton.html
The Letters relating to Op Ed can be found at:
http://www.nytimes.com/2010/01/06/opinion/l06climate.html

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


Verizon: I just don't know what to say

Geoff Kuenning <geoff@cs.hmc.edu>
Sat, 02 Jan 2010 14:23:51 -0800

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
Verizon."

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

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


Eurostar Risks

"anthony.thorn@bluewin.ch" <anthony.thorn@bluewin.ch>
Sun, 27 Dec 2009 10:09:44 +0000 (GMT)

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.

e.g.
http://www.independent.co.uk/news/uk/home-news/thousands-stranded-as-eurostar-service-is-suspended-1846350.html

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?


Display: none; visibility: hidden; overflow: hidden

<jidanni@jidanni.org>
Tue, 05 Jan 2010 06:37:57 +0800

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?"


Crumbling Crypto: RSA 768 modulus factored + security implications

"Peter G. Neumann" <neumann@csl.sri.com>
Thu, 7 Jan 2010 11:40:28 PST

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)


Couple Stuck in Oregon Snow for 3 Days After GPS Leads Them Astray

Richard Grady <richard@richbonnie.com>
Mon, 28 Dec 2009 13:52:20 -0800

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.
  http://www.foxnews.com/story/0,2933,581303,00.html


The Risks of Relying on Downstream Syndication

Bob Gezelter <gezelter@rlgsc.com>
Mon, 04 Jan 2010 19:20:31 -0500

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


Re: Teleportation via Skyhook

Gary Bliesener <gbliesener@comcast.net>
Tue, 29 Dec 2009 10:45:31 -0500

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


Toyota acceleration; is it just the gas pedal or not? (RISKS-28.85)

David Lesher <wb8foz@panix.com>
Sun, 27 Dec 2009 01:35:32 -0500

<http://www.latimes.com/business/la-fi-toyota-throttle29-2009nov29,0,5254584.story>

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.


Re: Another user interface fatal accident in Afghanistan

Curt Sampson <cjs@starling-software.com>
Sun, 27 Dec 2009 16:14:54 +0900

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
bomb.

Curt Sampson         <cjs@cynic.net>         +81 90 7737 2974


Re: LED Traffic Lights are efficient ... (R 25 88)

Dick Mills <dickandlibbymills@gmail.com>
Sun, 27 Dec 2009 09:47:25 -0500

  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?


Re: LED Traffic Lights are efficient ... (R 25 88)

Jerry Leichter <leichter@lrw.com>
Sun, 27 Dec 2009 05:38:43 -0500

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.


Re: LED Traffic Lights are efficient ... (R 25 88)

Amos Shapir <amos083@hotmail.com>
Sun, 27 Dec 2009 17:55:49 +0200

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
bulbs.


Re: LED Traffic Lights are efficient ... (R 25 88)

Rob Seaman <seaman@noao.edu>
Mon, 28 Dec 2009 00:07:47 -0700

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
snow.

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
address.

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@hanksville.org

Please report problems with the web pages to the maintainer

x
Top