Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: RISKS List Owner (riskocsl.sri.com)
Date: Fri Jan 29 2010 - 13:07:25 CST
RISKS-LIST: Risks-Forum Digest Friday 29 January 2010 Volume 25 : Issue 93
ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
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
Doug Maughan's CACM article & Roadmap for Cybersecurity Research (PGN)
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 (PGN)
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)
Abridged info on RISKS (comp.risks)
Date: Thu, 28 Jan 2010 16:19:18 PST
From: "Peter G. Neumann" <neumanncsl.sri.com>
Subject: Doug Maughan's CACM article & Roadmap for Cybersecurity Research
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:
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.)
Date: Thu, 28 Jan 2010 01:11:45 -0500
From: t byfield <tbyfieldpanix.com>
Subject: UI fix freezes NYSE, affects 975 stocks
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.
Date: Thu, 28 Jan 2010 23:05:14 -0800
From: Geoff Kuenning <geoffcs.hmc.edu>
Subject: False positives galore in SARs
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 geoffcs.hmc.edu http://www.cs.hmc.edu/~geoff/
[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.)]
Date: Fri, 22 Jan 2010 00:18:27 -0800 (PST)
From: Paul Robinson <rfc1394yahoo.com>
Subject: DC Metro - only kills average of 1 customer each 3 years
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
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?
Date: Thu, 28 Jan 2010 16:06:38 PST
From: "Peter G. Neumann" <neumanncsl.sri.com>
Subject: GPS Control Software Glitch: NANU Issued
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
Date: Wed, 27 Jan 2010 11:32:06 +0200
From: Alexander Klimov <alserkliinbox.ru>
Subject: How Not to Design Authentication
"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
Date: Wed, 27 Jan 2010 09:47:25 +0000
From: David Hollman <dah8cornell.edu>
Subject: Radiation Offers New Cures, and Ways to Do Harm
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.
Date: Thu, 28 Jan 2010 16:15:45 PST
From: "Peter G. Neumann" <neumanncsl.sri.com>
Subject: Warning: Your Cell Phone May Be Hazardous to Your Health
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]
Date: Thu, 28 Jan 2010 13:05:22 -0600
From: "Walter Roberson" <robersonhushmail.com>
Subject: Driver watching laptop movie kills woman
[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
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.
Date: Fri, 22 Jan 2010 03:06:23 -0800 (PST)
From: Paul Robinson <rfc1394yahoo.com>
Subject: It depends on which bus you take
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...
Date: Wed, 27 Jan 2010 12:15:48 +0100
From: Pete Kaiser <djcresiak.org>
Subject: Driving and walking through buildings
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.
Date: Wed, 27 Jan 2010 16:59:18 -0800
From: Tony Lima <tonytonylimaassociates.com>
Subject: Re: Teleportation via Skyhook (Bliesener, RISKS-25.89)
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
Date: Wed, 27 Jan 2010 15:12:21 -0500
From: Mark Jackson <mjacksonalumni.caltech.edu>
Subject: Re: Extending TCP/IP into space (Randall, RISKS-25.92)
When the Shuttle overflies the runway when returning from the next ISS
mission, we'll know why.
Mark Jackson - http://www.alumni.caltech.edu/~mjackson
Date: Thu, 29 May 2008 07:53:46 -0900
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-subscribecsl.sri.com or risks-unsubscribecsl.sri.com
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.Marshallnewcastle.ac.uk>.
=> SPAM challenge-responses will not be honored. Instead, use an alternative
address from which you NEVER send mail!
=> SUBMISSIONS: to risksCSL.sri.com 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
==> 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.93