[RISKS] Risks Digest 25.90

From: RISKS List Owner <risko_at_private>
Date: Fri, 8 Jan 2010 15:21:19 PST
RISKS-LIST: Risks-Forum Digest  Friday 8 January 2010  Volume 25 : Issue 90

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

NIST-certified USB Flash drives with hardware encryption cracked (PGN)
Skype: the case of disappearing telephone numbers (Chrisf J Brady)
Libel by Twitter? (Al Stangenberger)
Risks of USB chargers for cell phones (Paul Pomes)
Y2K+10: look at the Hex (Dave Hansen)
Y2K+10: what's underlying? (Chris Smith)
Y2K+10: The problems with sticky tape (Peter Houppermans)
Weight of a Land Rover incorrectly input into UK VCA database
  (Matthew Wilson)
Re: Eurostar RISKS (Richard Pennington)
Leaves on Tracks (Curt Sampson)
Re: LED Traffic Lights are efficient (Dick Mills, Terrence Enger)
Re: Silent Hybrid Nearly Causes Carbon Monoxide Poisoning
  (Walt Strickler)
NDSS Program (Internet Society)
Abridged info on RISKS (comp.risks)


Date: Fri, 8 Jan 2010 10:47:27 PST
From: "Peter G. Neumann" <neumann_at_private>
Subject: NIST-certified USB Flash drives with hardware encryption cracked

Certain USB drives using AES encryption have a major flaw that allows a way
to bypass the login rules: "The SySS experts wrote a small tool for the
active password entry program's RAM which always made sure that the
appropriate string was sent to the drive, irrespective of the password
entered and as a result gained immediate access to all the data on the
drive."  In essence, despite the use of AES 256-bit encryption, the password
checker program always put out the same bitwise-identical POSITIVE response
to a successful password check, which was trivially reproducible.  [Source:
The H Security, 4 Jan 2010; Thanks to John Curran; PGN-ed]

  [Misleading title; make sure you understand what is `certified' and what
  that means (or doesn't mean) with respect to systems in the large.  PGN]


Date: Thu, 7 Jan 2010 17:10:04 -0800 (PST)
From: Chris J Brady <chrisjbrady_at_private>
Subject: Skype: the case of disappearing telephone numbers

The latest version of Skype (partly owned by eBay) is causing major
irritations amongst web designers and users. By default when downloaded and
installed it also installs a small utility unbeknown to the user. This
utility effectively reformats any telephone &/or fax. nos. on a web page
including adding a little flag icon and also embeds a link behind these to
link to Skype. Theoretically clicking on the telephone no. then initiates a
Skype call to that no.

Unfortunately there are some side effects.

Web designers are especially upset that the reformating effectively destroys
the look of a web page, especially if a web site has been designed to a
corporate style when Skype then reformats parts of every page to suit

Secondly in many cases the telephone &/or fax nos. are simply deleted from
the web page displayed never to be seen again. Even more irritating is that
telephone nos. disappear when web-based emails are viewed such as when using
Yahoo Mail and/or Google Mail. That is until a cure is implemented.

And the cure is to remove the embedded utility - not easy. And/or remove
Skype entirely. Both are reported to be effective.

The risk of course is trusting Skype when the company (partly owned by eBay)
has deliberately chosen to allow this feature to be installed by default
without any user choice in the matter.


Date: Mon, 04 Jan 2010 19:31:53 -0800
From: Al Stangenberger <forags_at_private>
Subject: Libel by Twitter?

Interesting legal commentary on the problem of crafting a comment within
Twitter's 140-character limit for messages.  The forced brevity can cause
the unwary to make statements but not to qualify them as opinion due to the
maximum message length.


Date: Wed, 30 Dec 2009 20:40:54 -0800
From: Paul Pomes DVM <Dr.Pomes_at_private>
Subject: Risks of USB chargers for cell phones

My wife recently purchased a no-name third-party USB charger for her Droid
cell phone. When the included cable is connected to the USB port of her
laptop, the phone charges normally albeit somewhat slowly.  Connecting the
cable to the included voltage-sensing wall transformer starts a menagerie of
interesting effects: opening applications, creating garbled text messages,
changing settings, etc. No doubt this is due to floating signal lines with
induced voltages that is triggering this storm of activity.

It takes little imagination, however, to visualize more sinister
applications. A very small amount of logic, specific for each cell phone
model the charger is marketed for, could be embedded inside the plastic
transformer block. After a few minutes delay the phone could be probed for
sensitive information and the results sent to an electronic dead-drop. The
risk is a classic trade-off of security vs convenience. Having a single
charger for our Kindles, cell phones, PDAs simplifies the number of
ancillary chargers we need to tote around. Mixing the mission of power
supply and data conduit opens a covert channel.

Paul Pomes, DVM (formerly a network and computer security engineer until I
got tired of meetings) http://www.FurryFriendsVet.com
http://PaulPomes.livejournal.com http://www.facebook.com/Paul.Pomes


Date: Fri, 8 Jan 2010 12:14:15 -0500
From: Dave Hansen <iddw_at_private>
Subject: Y2K+10: look at the Hex

A lot of the problems seem to share a common characteristic -- instead of
2010, the date appears to be 2016.

Debora Weber-Wulff wrote:
> 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.

It's more interesting to look at both numbers in hexadecimal: 2009 is 0x7d9
while 2016 is 0x7e0.  A little BCD math, perhaps?


Date: Fri, 8 Jan 2010 11:12:28 -0500 (Eastern Standard Time)
From: Chris Smith <smith_at_private>
Subject: Y2K+10: what's underlying?

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

I - and I suspect many others - would be interested in knowing the
underlying error behind this problem. One the best reasons to read RISKS is
to expand your personal list of bugs to watch out for.

I can see at least one strong possibility. It relates to the point that chip
cards - and especially contactless chip cards - are very low power, low
resource, devices. The hardware and software developers optimize

Expressing the problem as though a two-digit year were in use, the problem
was that 9 was followed by 16, not 10. But in hexadecimal, $09 was followed
by $10 - but it should have been $0A.

Chip cards could reasonably use BCD (binary coded decimal), where a decimal
number is stored in a byte as two separate digits, one per nibble. At some
point, if the chip provides a current year value, it would provide it as 10
(hex $10, binary 0001000). But if a terminal thinks this is a *binary*
field, it will misinterpret it -- starting in the year 2010. Any conversion
from 10 to 2010 would have been done by the terminal.

It is also worth noting that card systems in general make heavy use of
BCD. The numbers on your magnetic card stripe, for example, are all BCD.

Note that this raises the possibility that the *terminal* is at fault for
misunderstanding the data format, not the card. But it also makes clear -
consistent with reports - that even if the card is the problem, the terminal
can correct the difficulty with a customized conversion routine, as long as
it can accurately identify which cards have the problem.

Note that BCD is sufficiently common in small processors that the 6502
processors actually had a 'decimal mode', where adding $01 to $09 resulted
in $10, and adding $01 to $99 both gave $00 and set the carry flag.


Date: Fri, 08 Jan 2010 09:56:19 +0100
From: Peter Houppermans <peter_at_private>
Subject: Y2K+10: The problems with sticky tape (RISKS-25.89)

The "German" credit card problem is interesting from a number of angles:

* Disaster Recovery: imaging you're abroad and your cash becomes
  inaccessible, but this time not because your bank fails.  At least the
  good news is that that's easier to solve, and a fallback was available.
  Uncomfortable idea when you're traveling.

* Technology migration risk: I guess it's now properly publicly known that
  the so-called safe chip is easy to defeat by simply avoiding it.  This
  presents an interesting issue with respect to card cloning as you actually
  do not need access the chip itself.  Copy the magnetic strip and make sure
  any chip on the target card malfunctions (expect a surge in nail varnish
  sales).  The fallback option has now reduced the level of trouble for the
  end user, but I suspect a surge in that method of old, magnetic strip
  cloning, is unavoidable.

* Think before you report: my immediate reaction was "uh oh" when I saw the
  sticky tape reporting, because I knew what would happen next: tight
  (anti-fraud) mechanical tolerances in ATMs resulting in transfer of sticky
  tape from card to mechanism, thus gumming up the works (and possibly
  retaining the card in the process).  Sure enough: in the evening those
  same sources reporting the "solution" were now labeling it a "problem"
  without the slightest hint of irony..


Date: Fri, 8 Jan 2010 10:25:25 -0000
From: "Matthew Wilson" <matthew_at_private>
Subject: Weight of a Land Rover incorrectly input into UK VCA database

It appears that the UK's Driver and Vehicle Licensing Agency - DVLA - have
routinely been giving older series Land Rovers a revenue weight of 3499 kgs,
which puts them in the commercial class 7 bracket of vehicle.  The Land
Rover (apart from some specialist version of the vehicle) should be a class

It seems this weight choice was done when the computer database was set up
and this 'random' value chosen.

Now that the garages where you submit your vehicle to gain a MOT certificate
to prove it roadworthy have been computerised, entering the chassis
number/VIN (vehicle identification number) of the vehicle causes the test to
be refused as the incorrect weight retrieved from the database flags a class
7 test.  The vast majority of MOT garages are only equipped for class 4
vehicles, not class 7.

Lots of additional info about this here:

I think a classic case of garbage in garbage out...


Date: Fri, 8 Jan 2010 00:50:02 -0000
From: "Richard Pennington" <richardhelen_at_private>
Subject: Re: Eurostar RISKS (Thorn, RISKS-25.89)

Here are a few comments on Anthony Thorn's piece about the Eurostar failures
on 18 Dec 2009.

Firstly, one of my colleagues traveled on the last Eurostar train to pass
through the Channel Tunnel from France to England before the trains failed.
He reports that his train was obviously losing power and finished the
journey traveling very slowly.

Secondly, I have seen no public report into what the difference was between
the "winterisation" applied to the Eurostar trains this year (when there was
a massive common-mode failure) and in the 15 previous years of reliable
operation (in all sorts of weather conditions including a very cold spell in
February 2009).

Thirdly, I have seen no public report into what happened to the signaling
system.  In particular, why did the controllers keep sending more trains
into a tunnel which was already blocked by the previous failed trains?  [As
a result, they ended up with five trains trapped in the tunnel, all with
identical failures.  There is one track in each direction, with crossovers
for use in emergencies.]  I can understand that a total electrical failure
(which appears to have occurred in each of the five failed trains) would
prevent communications between the trains and the controllers - although
that in itself raises an obvious single point of failure - but what happened
to the trackside signalling systems, and why did they not send a message
back to the controllers?  And how long did it take the controllers to
realise that there were no trains coming out of the other end of the tunnel?


Date: Fri, 8 Jan 2010 19:57:03 +0900
From: Curt Sampson <cjs_at_private>
Subject: Leaves on Tracks (was Re: LED Traffic Lights are efficient...

On Sun, 27 Dec 2009 05:38:43 -0500, Jerry Leichter <leichter_at_private> writes:

> Every fall [in the NY area], we get delays in mass transit because of wet
> leaves on train tracks. I never recalled hearing of such problems years
> back....

He goes on to say that this problem has been attributed to the change from
friction braking to regenerative braking. I believe that this may not be
entirely, or even substantially correct.

The problem itself is not so very new to my knowledge: I clearly recall it
being reported in the UK (on Thatcher-era passenger stock), in 1991, the
first year that I lived there. Further, R. A. Wood's 1999 paper "Train
Detection by Track Circuit: the Effect of the Wheel/Rail Interface"
discusses leaves (among other track contaminants) and blames the issue on
two quite different modernisation issues.

The first is the switch from steam to diesel locomotion ("Leaves were rarely
a problem in steam days, for the simple reason that flammable vegetation at
the side of the track was incompatible with machines that ejected burning
cinders into the air."--section 2) and better bogies ("The main factor
appeared to be the greatly improved suspension systems of modern
bogies. Instead of bouncing, scraping, and sliding around the track, the
wheel on a modern bogie runs straight and true along the rails, with a
significantly reduced scrubbing action between wheel and rail."--section 3).

So there's the correction. Additionally, I must say, I do feel a little
frisson when I think about a fire hazard mitigating another risk.

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 (Johnson, 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?

Likely predates RISKS, but this old fogey recalls the introduction of the 2
filament tail-light/brakelight bulb in common use for at least 50 years.
This was introduced to address the problem mentioned here.  At night, when
visibility is lowest, and the tail lights would be on, the heat of the tail
light would defrost the lens so the brakelights were more visible.

Just as an aside - on LED lights - I saw an ad that said that LED brake
lights were safer since they lit up more quickly, at least a tenth of a
second. I poo-poo'd this until I thought a bit.  60 mph is 88 feet/second
1/10 second is 8.8 feet saving even half that much in a panic stop is quite
significant !

P.M. Wexelblat PhD, Erst of the Dept. of Computer Science
University of Massachusetts Lowell, One University Ave, Lowell, MA 01854


Date: Fri, 08 Jan 2010 09:41:00 -0500
From: Terrence Enger <tenger_at_iseries-guru.com>
Subject: Re: LED Traffic Lights are efficient (Seaman, RISKS-25.89)

> LEDs are desirable because they inexpensive to operate due to their high

LEDs *are* highly efficient, but I suspect that desirability comes far more
from the long lifetime.  It is not much work to unscrew a bulb and screw in
a new one, but getting into position to do that is not so easy.

So, the cost of energy to melt the precipitation is not obviously a
show-stopper for a simple-minded heater.  We know from past experience that
the power for one light is at least adequate.  And the cost of installation
can probably be brought into the same order of magnitude as the cost to
...um... change a light bulb.


Date: Fri 1 Jan 2010 07:34:44 -0700
From: waltstrickler_at_private
Subject: Re: Silent Hybrid Nearly Causes Carbon Monoxide Poisoning (R-25.88)

So I have a (maybe obvious) question: Why would a car whose engine is
running need synthetic engine noise? The letter to the editor even said that
it was running at full throttle, but the author seems to have missed the

I suspect that this is not a risk of the hybrid being silent, but of the
fact that the Prius is turned off by taking the RFID (Radio Frequency
Identification Device) that enables it out of range, or by performing the
unintuitive (and not usually necessary) act of pushing the START button for
3 seconds. In this case, the RFID was probably left in a purse, which was
left in the car, and the car was most likely in battery-charging mode when
left in the garage. The 4 hours mentioned in the letter seems like a long
time to charge the batteries, but perhaps this one had been converted to a
plugin hybrid with much larger battery capacity.


Date: Mon, 4 Jan 2010 14:07:25 -0500 (EST)
From: Internet Society <craemer_at_private>
Subject: NDSS Program

17th Annual Network and Distributed System Security (NDSS) Symposium
The Dana on Mission Bay, San Diego, California, 28 Feb -- 3 Mar 2010

New research on 24 topics to be presented

The NDSS '10 program committee has selected 24 original research papers for
presentation in San Diego.  Topic areas include:

* Distributed Systems and Networks
* Web Security and Privacy
* Intrusion Detection and Attack Analysis
* Anonymity and Cryptographic Systems
* Security Protocols and Policies
* Languages and Systems Security
* Malware
* Spam

A complete list and summaries of each paper can be found at:

Keynote by former White House counterterrorism and cyber security czar
Richard A. Clarke.  Special panel discussion on Ethics in Networking and
Security Research.

Registration Information: www.isoc.org/ndss10
Organized by the Internet Society


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.90
Received on Fri Jan 08 2010 - 15:21:19 PST

This archive was generated by hypermail 2.2.0 : Fri Jan 08 2010 - 16:12:52 PST