The RISKS Digest
Volume 25 Issue 93

Friday, 29th 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…


Doug Maughan's CACM article & Roadmap for Cybersecurity Research
UI fix freezes NYSE, affects 975 stocks
T Byfield
False positives galore in SARs
Geoff Kuenning
DC Metro - only kills average of 1 customer each 3 years
Paul Robinson
GPS Control Software Glitch: NANU Issued
How Not to Design Authentication
Alexander Klimov
Radiation Offers New Cures, and Ways to Do Harm
David Hollman
Warning: Your Cell Phone May Be Hazardous to Your Health
Christopher Ketcham via PGN
Driver watching laptop movie kills woman
Walter Roberson
It depends on which bus you take
Paul Robinson
Driving and walking through buildings
Pete Kaiser
Re: Teleportation via Skyhook
Tony Lima
Re: Extending TCP/IP into space
Mark Jackson
Info on RISKS (comp.risks)

Doug Maughan's CACM article & Roadmap for Cybersecurity Research

"Peter G. Neumann" <>
Thu, 28 Jan 2010 16:19:18 PST

Doug Maughan's Inside Risks column on the Cybersecurity Roadmap and the
underlying security issues will appear in the Feb 2010 *CACM*.  An html
version is now up on my Inside Risks website:

  Douglas Maughan,
  The Need for a National Cybersecurity Research and Development Agenda
  *Communications of the ACM*, February 2010

It includes hotlinks to the roadmap and various other relevant documents on
the Department of Homeland Security Science and Technology cybersecurity
website.  (The roadmap document is currently the first item in the list.)

UI fix freezes NYSE, affects 975 stocks

t byfield <>
Thu, 28 Jan 2010 01:11:45 -0500

Ars Technica reports (Jon Stokes, "How a stray mouse click choked the NYSE &
cost a bank $150K," 27 Jan 2010):

  On November 14, 2007 at 3:20pm one of Credit Suisse's trading algorithms
  suddenly went haywire, and, in a few moments, sent hundreds of thousands
  of bogus requests to the exchange. This sudden surge of requests, which
  were cancellations for a large batch of orders that the machine had never
  actually sent out, acted like a denial-of-service attack on some parts of
  the New York Stock Exchange. The messages clogged the tubes and caused
  parts of the exchange to freeze up, affecting trading in 975 stocks.

The article goes on to blame "a programmer [who] took it upon himself to
unilaterally improve [the Credit Suisse program] by adding a new user input
feature," which lacked "feedback and 'forgiveness'" and a lack of testing.

  On November 14, a few seconds after 3:20, a trader put a number in the box
  and then double-clicked the "up" arrow. This double-click was interpreted
  by SmartWB as two separate clicks, so the system dutifully sent out a
  second batch of cancel/replace orders in addition to the batch that was
  intended by the trader.  This sudden flood of cancel/replace orders, half
  of which were requesting cancellation of orders that had never been sent,
  overwhelmed the system and backed up five of the posts on the NYSE trading

Without endorsing the programmer's impromptu improvement, it's fair to ask
why a "flood" of bogus orders from a single bank would overwhelm the system.

False positives galore in SARs

Geoff Kuenning <>
Thu, 28 Jan 2010 23:05:14 -0800

I went to a talk today by a rather clueless Los Angeles company who is
partnering with the Washington, DC, police in a number of efforts, many
based on web-scraping.  One of the things they're proud of is a
(non-scraping) system that automatically delivers SARs ("Suspicious Activity
Reports") to interested parties.  For example, if an SAR has a location
that's within 1000 feet of a university, they send a text to everybody's
cellphone.  They're at least a little bit clever; for example, for a big
school they'll only contact the students living in the dorm(s) nearest the

OK, what's an SAR?  Just about anything.  If a little old lady sees a
"suspicious man on the corner" (e.g., waiting for a taxi) and calls it in,
that's an SAR.  Obviously, in these fear-everything days, any forgotten
package becomes an SAR-worthy possible bomb.  About 300-400 SARs go out per
day, though to be fair not every SAR goes to every person.

When queried, they informed us that of course most SARs are bogus, but
"three or four per year" are valid.  Hmmm...300*365/4 = 27,375.  That's a
pretty impressive false-positive rate.  They don't seem to see a problem
with crying "wolf" that often.  And one of their examples of a "true"
positive was a political protest by Greenpeace, involving a
not-very-dangerous stuffed polar bear.

Nor do they seem to have thought about security and privacy issues.  How do
they protect their database of who lives in which dorm?  Questions were cut
off before I got a chance to ask that one, but I'm not optimistic.

The RISK here is that everybody (developers and police) is so in love with
the shiny technology that nobody stops to notice that the emperor has no

Geoff Kuenning

  [If you *can't* measure it, it's not science.
  Robert A. Heinlein, "The Door Into Summer"]

    [If you think you *can* measure it, something is probably wrong anyway.
    Peter G. Neumann, The ACM Risks Forum
    (Check your model and your assumptions at the door, eat a
    Heisenburger, and beware of many other risky challenges.)]

DC Metro - only kills average of 1 customer each 3 years

Paul Robinson <>
Fri, 22 Jan 2010 00:18:27 -0800 (PST)

The Washington Metropolitan Transportation Authority, which runs the
metrorail system in Washington, DC, has had exactly two accidents that
killed customers in the 34 years it has been operating.  From the system's
opening in 1976 until 1982, there were no passenger fatalities.

The first accident occurred when a derailed train was backed up, but the
other half of the train had also derailed, crashing it into a tunnel
abutment and killing 3 passengers.  The accident happened on January 13,
1982, at the same time as the Air Florida Flight 90 crashed into the 14th
Street Bridge.

The second accident where 9 people were killed was in June, so if you
average this, chances are either Metro won't kill someone until 2012, or,
since each time they do have an accident, they kill 3 times as many, we
could expect that since it was 6 years for the first accident, then 17 more
for the second, that sometime around 2055, another Metrorail accident will
kill 22 people!

And it's this sort of estimation that actuaries use to figure out insurance
rates. Given enough incidents you can do a pretty good job of figuring out
how often you'll have claims.

Actually, you're more likely to be killed on Metro if you're an employee
than a customer, based on the number of employee deaths they've had.  This
also brings up a question: is the low number of customer deaths and long
times between accidents a result of luck or some factors such as the
equipment as designed being relatively safe?

GPS Control Software Glitch: NANU Issued

"Peter G. Neumann" <>
Thu, 28 Jan 2010 16:06:38 PST

Mostly affects military users, but also implications for some civilians.
[TNX to Paul Saffo for spotting this one.  (Robin Williams' Nanu-Nanu
references probably unfamiliar to many readers.)  PGN-ed]

``Moving Three GPS Satellites into New Orbits will have a profound effect on
GPS capabilities for all civil, commercial, and military users worldwide.''
The GPS AEP Command and Control operational software update enables new
capabilities ... but requires absolute compliance with the published GPS
Interface Control Document (ICD).  Some of the new features that are
incorporated work only with authorized military receivers that have
successfully passed security tests.  However the live introduction of the
new functions is causing problems wherein some of these receivers are
intermittently not tracking Y-code, and non-compliant civilian receivers are
also reporting continuing problems.  Corrective action could encompass
either the Air Force rolling back the update or revising its software, or
the manufacturers modifying GPS software within the receivers to be totally
compliant with the ICD.

January 21, 2010

How Not to Design Authentication

Alexander Klimov <>
Wed, 27 Jan 2010 11:32:06 +0200

"Verified by Visa and MasterCard SecureCode:
 or, How Not to Design Authentication"
by Steven J. Murdoch and Ross Anderson

  Banks worldwide are starting to authenticate online card transactions
  using the `3-D Secure' protocol, which is branded as Verified by Visa and
  MasterCard SecureCode. This has been partly driven by the sharp increase
  in online fraud that followed the deployment of EMV smart cards for
  cardholder- present payments in Europe and elsewhere. 3-D Secure has so
  far escaped academic scrutiny; yet it might be a textbook example of how
  not to design an authentication protocol.  It ignores good design
  principles and has significant vulnerabilities, some of which are already
  being exploited.  Also, it provides a fascinating lesson in security
  economics.  While other single sign-on schemes such as OpenID, InfoCard
  and Liberty came up with decent technology they got the economics wrong,
  and their schemes have not been adopted.  3-D Secure has lousy technology,
  but got the economics right (at least for banks and merchants); it now
  boasts hundreds of millions of accounts. We suggest a path towards more
  robust authentication that is technologically sound and where the
  economics would work for banks, merchants and customers — given a gentle
  regulatory nudge.

Radiation Offers New Cures, and Ways to Do Harm

David Hollman <>
Wed, 27 Jan 2010 09:47:25 +0000

Radiation Offers New Cures, and Ways to Do Harm
The New York Times, January 23, 2010

This article goes into some detail about several failures in radiation
treatments which lead to severe injury and deaths in patients.
Although there was substantial human error involved, it seems that in
some cases computer crashes and lack of failsafe functionality were at
least contributing causes.

In one example, a crash of the controlling computer led a technician
to mistakenly believe that instructions to properly restrict the
amount of radiation received were saved, when in fact they were not.
This was then compounded by additional error as operators failed to
manually check whether the settings were correct. The patient was then
massively over-radiated on several occasions.

I wonder if the general flakiness in personal computers that we are
all used to results in an attitude that accepts such things as normal
and acceptable, even in people who should have been trained to know
better, and possibly even product designers and managers.  In this
example, such an attitude would probably have worse consequences than
the actual technical fault in the equipment.

Warning: Your Cell Phone May Be Hazardous to Your Health

"Peter G. Neumann" <>
Thu, 28 Jan 2010 16:15:45 PST

  Ever worry that that gadget you spend hours holding next to your head
  might be damaging your brain? Well, the evidence is starting to pour in,
  and it's not pretty. So why isn't anyone in America doing anything about

[Source: Christopher Ketcham, February 2010 issue of *GQ*, PGN-ed]

Driver watching laptop movie kills woman

"Walter Roberson" <>
Thu, 28 Jan 2010 13:05:22 -0600

[The article emphasizes that it was a porn movie being watched, but it seems
to me that the result could easily have been the same for many other genres
-- WDR]

State police say a truck driver was watching pornographic movies on his
laptop computer when his rig struck a disabled car on the New York State
Thruway near Buffalo last month, killing the driver.  Thomas Wallace of Ohio
was arrested Tuesday. He's been charged with second-degree manslaughter in
the death of 33-year-old Julie Stratton, a mother of two from a Buffalo
suburb. [...]  Investigators say Wallace also violated federal trucking
rules by sleeping no more than four of 27 hours before the crash.

It depends on which bus you take

Paul Robinson <>
Fri, 22 Jan 2010 03:06:23 -0800 (PST)

To go home from the Washington DC Metro I take either the 83 or 86 Metrobus
into Maryland.  The difference between the two routes is that the #86 takes
a detour into the Prince George's Plaza station.

There is a street that crosses both routes.  On the #86, the bus turns off
Baltimore Ave and eventually reaches 40th Avenue, turns onto Oglethorpe
street, where it turns on 42nd Ave.  On the 83, it continues on Baltimore
Ave and simply crosses Oglethorpe.

However, on board every bus running on the 83 and 86 lines is a display that
shows to the passengers every street where the bus is making.  It is
consistent, in that on every #86 bus, it indicates when it is at *Oglethorpe
Street*.  On every #83 bus, it indicates when it is at *Ogelthorpe Street*.

Maybe it's just a GSP, err I mean GPS error...

Driving and walking through buildings

Pete Kaiser <>
Wed, 27 Jan 2010 12:15:48 +0100

Near where I live in Zurich, Friedackerstrasse meets Friedheimstrasse in a T
intersection.  But Google Maps and the street map overlay in Google Earth
show Friedackerstrasse making a 45-degree angle there.

The canopy of a tree at that intersection overhangs the entire actual
meeting point of the two streets, something perfectly evident to the human
eye in the aerial photograph.  I hazard the guess that software used to
detect roads on aerial photographs simply lost the streets there because of
the tree, leaving the algorithm to do something — anything — about that,
using some additional GIS data indicating that the streets really do
intersect.  And the algorithm routed (the mapping of) Friedackerstrasse
through the house on the northeast corner.  (It also routes a nearby
pedestrian walk squarely through the apartment building it abuts.)

In practice this one case isn't a large risk because you can't really get
lost because of it, but it provides some insight into how the software
works, and how it fails when it fails.  Where else are streets re-routed,
nonexistent segments added, or existing ones omitted?  And other features?
It's not hard to imagine how this might be important.

This error, combined with the (here well known) principle "there's never
just one bug", must give us pause.

Re: Teleportation via Skyhook (Bliesener, RISKS-25.89)

Tony Lima <>
Wed, 27 Jan 2010 16:59:18 -0800

Actually this is a user error.  Opera Mini uses transcoding to present the
web page on mobile devices.  That means every single bit transmitted and
received is processed through Opera's computers.  That's the reason for the
Norwegian IP address.

Gary should have paid a few bucks for Opera Mobile which does not use
transcoding, relying on more traditional on-device html interpretation.

I spent quite a bit of time testing both versions.  Opera Mini is, indeed,
very fast, but it always struck me that users were giving up way too much

Tony Lima Associates, Los Altos, CA, USA, 650-243-1286

Re: Extending TCP/IP into space (Randall, RISKS-25.92)

Mark Jackson <>
Wed, 27 Jan 2010 15:12:21 -0500

When the Shuttle overflies the runway when returning from the next ISS
mission, we'll know why.

Mark Jackson -

Please report problems with the web pages to the maintainer