The RISKS Digest
Volume 26 Issue 03

Sunday, 25th April 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…


April Fools: 7,500 Online Shoppers Unknowingly Sold Their Souls
Sam Posten
Teens and Mobile Phones
Pew via Monty Solomon
Social Netting lets the mosquitos through
Renay San Miguel via PGN
Anti-malware backfires
Jeremy Epstein
Computer error affected West Virginia mine scrutiny
Sam Hananel via PGN
Software controlled Toyota roll-over
Jeremy Epstein
Bogus Jury Duty notices lead to identity theft
School Admin Takes Fifth Amendment in "Peeping Tom" Case
David Murphy via Monty Solomon
Barclay Card Rewards Advert Promotes PIN Insecurity
Chris J Brady
Penguin recalls cookbooks
Nick Rothwell
Re: RFID zapper made from a disposable camera!
Oliver Leistert
Re: Apache Bug tracker attack
Steve Loughran
Dimitri Maziuk
Nick Brown
Re: Canada's planned electronic passports ...
James Cameron
Re: Incorrect software change to emergency ambulance call-handling
Chris D
Re: Is your security policy smarter than a 3rd grader?
David-Sarah Hopwood
Re: ... circumventing Bayesian filters
Raj Mathur
Broadband survivability and certification
Charles Jackson
Info on RISKS (comp.risks)

April Fools: 7,500 Online Shoppers Unknowingly Sold Their Souls

Sam Posten <>
April 19, 2010 9:12:34 AM EDT

  [From Dave Farber's IP distribution.  PGN-ed]

  [Be careful what you agree to when you click that EULA...  Sam]

A computer game retailer revealed that it legally owns the souls of
thousands of online shoppers, thanks to a clause in the terms and
conditions agreed to by online shoppers.
[Source;, 15 Apr 2010; PGN-ed]

British game retailer *GameStation* has revealed that it legally owns the
souls of thousands of online shoppers, thanks to a clause in the terms and
conditions agreed to by online shoppers.  On April Fools' Day they had added
the "immortal soul clause" to the contract that you would sign before making
any online purchases.  It states that customers grant the company the right
to claim their soul.

  "By placing an order via this Web site <#> on the first day of the fourth
  month of the year 2010 Anno Domini, you agree to grant Us a non
  transferable option to claim, for now and for ever more, your immortal
  soul. Should We wish to exercise this option, you agree to surrender your
  immortal soul, and any claim you may have on it, within 5 (five) working
  days of receiving written notification from or one of its
  duly authorised minions."

GameStation's form
also points out that "we reserve the right to serve such notice in
6-foot-high letters of fire, however we can accept no liability for any loss
or damage caused by such an act. If you a) do not believe you have an
immortal soul, b) have already given it to another party, or c) do not wish
to grant Us such a license, please click the link below to nullify this
sub-clause and proceed with your transaction."

The GameStation folks apparently intended to make a very real point: No one
reads the online terms and conditions of shopping, and companies are free to
insert whatever language they want into the documents.

While all shoppers during the test were given a simple tick box option to
opt out, very few did this, which would have also rewarded them with a
5-pound voucher.  Due to the number of people who ticked the box,
GameStation claims believes as many as 88 percent of people do not read the
terms and conditions of a Web site before they make a purchase.

The company noted that it would not be enforcing the ownership rights,
and planned to e-mail customers nullifying any claim on their soul.

Teens and Mobile Phones (Pew)

Monty Solomon <>
Sun, 25 Apr 2010 14:58:45 -0400

Amanda Lenhart, Rich Ling, Scott Campbell, Kristen Purcell, Teens and Mobile
Phones, Pew Internet & American Life Project 20 Apr 2010

Daily text messaging among American teens has shot up in the past 18 months,
from 38% of teens texting friends daily in February of 2008 to 54% of teens
texting daily in September 2009. And it's not just frequency - teens are
sending enormous quantities of text messages a day. Half of teens send 50 or
more text messages a day, or 1,500 texts a month, and one in three send more
than 100 texts a day, or more than 3,000 texts a month. Older teen girls
ages 14-17 lead the charge on text messaging, averaging 100 messages a day
for the entire cohort. The youngest teen boys are the most resistant to
texting - averaging 20 messages per day. ...

Social Netting lets the mosquitos through (Renay San Miguel)

"Peter G. Neumann" <>
Thu, 22 Apr 2010 14:20:08 PDT

[Source: Renay San Miguel, Hackers and Social Networking: A Love Story,
*TechNewsWorld*, 22 Apr 2010; PGN-ed, with thanks to Gary McGraw.]

This is a fascinating article on the Social Networking bandwagon and the
Cloud Computing megaballoon.  It quotes Cloud Computing Alliance's Wen
Tseng, Entrust's Eric Skinner, and Cigital's Gary McGraw.  I won't begin to
summarize it, but Gary gets the last words: "Generally speaking, it looks
like HR is all for the social networking thing, and so they're kind of
pushing for the networking — using LinkedIn and Twitter and outreach
communications without thinking through the implications of it all.  So
stepping back and thinking,  'What's the downside' is always a good
idea. Just because you can do something doesn't mean you should."

  [See also Brad Stone and Ashlee Vance, Companies Slowly Join
  Cloud-Computing, *The New York Times*, 18 Apr 2010.  PGN's favorite
  quote from the Stone/Vance article is this:
    Ah, the cloud - these days, Silicon Valley can't seem to get its head
    out of it. The idea, though typically expressed in ways larded with
    jargon, is actually rather simple.  Cloud providers, large ones like
    Amazon, Microsoft, Google and AT&T, and smaller ones like Rackspace and
    Terremark, aim to convince other companies to give up building and
    managing [in-house] data centers and to use [the provider's] computer
    capacity instead.  PGN]

Anti-malware backfires

Jeremy Epstein <>
Wed, 21 Apr 2010 16:05:08 -0400

There's a McAfee anti-virus update today that went wrong.  It is bringing
down millions of XP machines worldwide.  So if you decided to be "safe" and
run McAfee, your machine is dead.  If you decided to live dangerously, you
haven't lost anything.  The rational economic argument for users is on the
side of not using anti-virus (in this case)...

  [Lauren Weinstein notes a *USA Today* article on the COST.  PGN]
    Total cost of McAfee's antivirus error will be many millions

Computer error affected West Virginia mine scrutiny (Sam Hananel)

"Peter G. Neumann" <>
Tue, 20 Apr 2010 20:32:24 PDT

A computer error prevented the West Virginia coal mine where 29 workers died
in an explosion last week from receiving a warning about safety violations.
Evidently, a computer program used by the Mine Safety and Health
Administration screens mines for patterns of violations.  Because eight
citations at the mine in question were apparently omitted, the program did
not flag the mine for safety violations.  However, the mine operators
apparently had fixed the identified problems earlier.  Nevertheless, the
inadequate reporting has alerted U.S. House lawmakers.  [Source: Sam
Hananel, AP item, 13 Apr 2010; PGN-ed. Thanks to dkross.]

Software controlled Toyota roll-over

Jeremy Epstein <>
Mon, 19 Apr 2010 17:18:43 -0400

In the aftermath of Consumer Reports recommendation against buying the
Toyota GX 460 SUV because of a risk of rollovers, Toyota is recalling 9400
vehicles in the US (and others overseas) for a software upgrade - a flaw in
the Vehicle Stability Control (VSC) software can allow unstable handling.
The part I find disconcerting is that the update is going to be available by
the end of April (less than two weeks from now), which hardly seems long
enough to make a software fix and perform adequate testing.

'nuff said.

Bogus Jury Duty notices lead to identity theft

"Peter G. Neumann" <>
Tue, 20 Apr 2010 8:04:30 PDT

A caller claims to be a jury coordinator.  If you protest that you never
received a summons for jury duty, the scammer asks you for your Social
Security number and date of birth to be able to verify the information and
cancel the arrest warrant.  Giving out such information has resulted in
identity fraud in at least 11 states, including Oklahoma, Illinois, and
Colorado.  The FBI and the federal court system have issued nationwide
alerts on their websites, warning consumers about the fraud.

School Admin Takes Fifth Amendment in "Peeping Tom" Case

Monty Solomon <>
Sun, 18 Apr 2010 15:55:37 -0400

Around 2,300 students across two schools in the Lower Merion School District
of Ardmore, PA earlier have received $1,000 Macintosh laptops for use with
preinstalled video-monitoring software that can be remotely activated.  A
motion against the District was filed on 15 Apr.  The suit accuses the
school district of violating various federal and state statutes against
surveillance and wiretapping, including the federal Electronics
Communications Privacy Act.  [Source: David Murphy, *PC Magazine*, 18 Apr
2010; PGN-ed.  This follows up on the earlier items in RISKS-25.95,97.],2817,2362791,00.asp

Barclay Card Rewards Advert Promotes PIN Insecurity

Chris J Brady <>
Sun, 11 Apr 2010 22:42:10 -0700 (PDT)

With so many credit/debit card cloning scams and the consequent
multi-million (multi-billion?) pound losses it might be expected that banks
such as Barclays would be promoting security with card transactions
especially with regards to the use of 'chip and pin.'

However, the latest advert for Barclay Card's 'Rewards' programme - which is
airing regularly on British t.v. - depicts just the opposite. Indeed it is
an excellent example of how to NOT carry out a 'chip and pin' transaction.

The advert shows a somewhat narcissistic and effeminate guy - for some
reason carrying a piece rolled up carpet - shopping and paying for goods and
services by 'chip and pin.' However whilst the chip might be secure, he
openly flouts his PIN to all and everyone including shop assistants and
waiters and anyone standing in his near vicinity. The smirk on his face at
every successful transaction - as he punches in his PIN accompanied by
annoying musical 'plinks and plonks' - in full view of anyone watching - is
indicative of his total ignorance of card cloning and fraud.

This irritating advert demonstrates the very worst of Barclay's attitude
towards security both of customers credit/debit card accounts and the losses
it sustains due to card cloning and fraud.

Apparently musical 'plinks and plonks' of customers punching in their PINs
to earn some ephemeral 'rewards' for using their cards is more important
than demonstrating the necessity of keeping one's PIN secret, i.e. NOT
allowing others to see the PIN punched in. The mind boggles at Barclays
utter stupidity in using this advert for their services.

Risks: You can't beat the Banks for demonstrating stupity when looking after
someone else's hard-earned cash and credit card accounts.

Penguin recalls cookbooks

Nick Rothwell <>
Wed, 21 Apr 2010 11:29:21 +0100

Penguin is destroying all 7000 copies of its Pasta Bible after a misprint
suggesting that a dish requires "salt and freshly ground black people".  The
head of publishing "defended proofreaders for letting through a misprint
that he suggested came from a spell-check program."

The RISKS archives are of course peopled - er, peppered - with such

  [Mark Brader suggested a title for this item:
  "Freshly ground books and msipelt tagliatelle."
  Actually, blaming spelling checkers is *not a legitimate defense*.

Re: RFID zapper made from a disposable camera! (RISKS-26.02)

Oliver Leistert <>
Mon, 19 Apr 2010 17:03:55 +0200

This is nothing new. The RFID Zapper had been already presented at the Chaos
Computer Congress in Berlin in 2005.[1] Prof. Wool is definitely not the
first person to publish and present on this topic. But the statement in the
RISKS Newsletter reads like that. The Zapper had been developed by Computer
Science students from Berlin.


Oliver Leistert, Universitšt Paderborn, Warburger Str. 100 33098 Paderborn

Re: Apache Bug tracker attack (RISKS-26.02)

Steve Loughran <>
Mon, 19 Apr 2010 11:48:19 +0100

One of the great features of humanity is that we can not only learn from our
own mistakes, we can learn from other peoples -and, through the written word
and youtube videos, from people at a distance, after the event. It's a shame
that some people felt that the best comment they could add was criticism,
but perhaps they resented having to change their single-web-site password
across all web sites.

Looking at the apache attack, it appears that the escalation from JIRA admin
to system admin was due to inadequate password policy, rather than any OS
vulnerability. Once on the machine they attempted to cross over from the
public, apache committer-accessible server to the main SVN servers, and fell
foul of the fact that it's login mechanism is much stricter -and failures
picked up on immediately.

The fact that an attack came from a rented VM is interesting as it shows a
trend to worry about in future: now all you need is a stolen credit card to
gain a small cluster of machines with good network access and a restricted
audit trail. The network load of a VM trying to log in to a remote service
isn't going to show up on the billing and monitoring infrastructure of a
hosting datacentre, so it will be up to every endpoint to defend for
that. Fail2Ban is a solution -one which requires every service to log
unauthenticated operations. If you have a login point, log failures. That
includes every SOAP or REST endpoint -but you also need to make sure the
logs themselves don't trigger a failure, else you have created a new DoS

Some other issues

* ASF Hardware is often donated, and is colocated on different sites.  There
is no "secure datacentre", back end subnet or other multi-layer defences:
everything is in the DMZ. This makes it harder to secure systems, but stops
you getting complacent. If there is a network -even a VPN- which grants
extra rights to callers, you need a plan to deal with it being compromised
and the tests to detect it.

* If the JIRA cookies had been marked HttpOnly, then XSS scripts would be
unable to read them. I wasn't personally aware of HttpOnly cookies until
this incident; I shall be adding Jetty and Tomcat filters to my applications
in future to make cookies HttpOnly regardless of the applications' policies.

* Log analysis would be easier if events were not scattered across different
machines, but instead analysable across them "show me all requests to ASF
infrastructure from IPAddr". The cloud computing projects within
Apache are building tooling which could do this: anyone wiling to apply the
CouchDB and Hadoop project's products for such capture and mining would be
encouraged to do so.

* TinyURL was used to obfuscate the XSS attack, so the script did not appear
in any (sanitised) email bug reports. There's no easy defence against that,
except maybe to use some tooling other than the web browser to resolve
tinyURL links. longSHORE, at ( ) can do that; the thought of a Firefox plugin
that works with this service appeals to me, though of course as longshore is
accessed via HTTP, you have to trust DNS in your browsing location.

* The HTTPS certificate has to be considered
compromised. This is why it's important to have a different https
certificate for every host, not save money for a *
certificate. It is also why client applications should check certificates
for revocation.

It's easy for people to look at the post mortem and criticise, but consider
this: the team wrote up what happened, in enough detail for the readers to
follow. We don't see that very often; it would have been easier to say "A
zero-day exploit" and leave it at that.

Re: YOUR SAT NAV IS WRONG - GO BACK! (RISKS-26.02 and others)

Dimitri Maziuk <>
Mon, 19 Apr 2010 12:09:23 -0500

A few observations from a recent road trip with our brand new TomTom:

"Fastest route" seems to assume you'll be doing speed limit and thus prefers
major freeways. It's a reasonable assumption, except major freeways in big
cities tend to be congested most of the time — presumably paid subscription
to real-time traffic reports service helps with that.

In a couple of places "shortest route" had us turn off a highway into a side
street (across oncoming traffic), turn right into another side street, and
then back into the same highway (left, across all traffic again). A look at
the map showed the highway turning left in wide bend. I expect the
"shortcut" was indeed a few metres shorter.

Then there's GPS/map/address accuracy: we're coming to a motel hiding at the
end of a driveway on the left side of a wide boulevard, right next to a
major intersection. To follow TomTom's "make a u-turn and you've arrived at
your destination", I'd have drive over the divider lawn and into some sort
of an office building. There was left turn pocket a few metres back, with a
big "no u-turn" sign on it. It does into the driveway we wanted, but the
driveway entrance is probably not exactly at the motel's listed address, the
driveway veers back a little (causing TomTom — I guess — to insist on
"u-turn" instead of just "turn left"), and by the time TomTom decides
"you're there", you've actually already passed the turn.

Not too unreasonable, and once you get the hang of it and look at the screen
and/or map (traffic conditions permitting) instead of blindly following the
voice prompts, no worse than any other piece of software I get to work with.
Of course, I do software for living, by now I have an intuitive feel for how
it works and what the limitations would be. I've no problem believing that
an average GPS user would drive off a non-existing bridge or wedge a truck
under a too-low overpass.


Dimitri (Dima) Maziuk, BioMagResBank, UW-Madison —

Re: YOUR SAT NAV IS WRONG - GO BACK! (RISKS-26.02 and others)

"BROWN Nick" <>
Wed, 21 Apr 2010 10:15:30 +0200

Even when you choose the alternative of "shortest time", that doesn't always
help.  A lot of GPS map data seems to divide roads into a rather small
number of classes, with all roads within a class considered to be equally
"fast".  Typically, minor asphalted country roads may be considered to be in
the same class as farm tracks, so whichever route appears to be shorter will
always be chosen.

Re: Canada's planned electronic passports ... (Laurie, RISK-26.01)

James Cameron <>
Tue, 20 Apr 2010 15:44:32 +1000

> ... it relayed a passport I was holding to a similar reader in the UK,
> using a mobile phone data link.

Presumably the same attack would work against many RFID systems?

Beware of people sidling up to you in a pub, they may be opening your
car, home, workplace, lab ...

At least with the old coded metal bar keys they could be reasonably
hidden in trouser pockets.  ;-)

Re: Incorrect software change to emergency ambulance call-handling

"Chris D." <>
Tue, 20 Apr 2010 22:00:15 +0100
  (Horrocks, RISKS-25.98).

NB: E-mail address munged to defeat spam, "yeeha" = "yahoo", of course.

> It's not clear from the article whether the change was incorrectly
> implemented or exactly as requested.

As the old joke goes, the trouble with software engineers is that
they give you what you asked for, not what you actually wanted...

Re: Is your security policy smarter than a 3rd grader? (RISKS-26.02)

David-Sarah Hopwood <>
Wed, 21 Apr 2010 01:10:06 +0100

This article says, "Blackboard and school officials clarified Thursday
that the boy had not found and exploited a security vulnerability, but rather
that he had obtained a teacher's password."

So allowing privilege escalation from "teacher" to "administrator" is not a
security vulnerability? Of course it is — if those roles were not intended
to be equivalent, then there is a mismatch between the intended policy and
the implemented one. Exploiting that can certainly be described as

David-Sarah Hopwood

Re: ... circumventing Bayesian filters (Kamens, RISKS-26.02)

Raj Mathur <>
Mon, 19 Apr 2010 08:34:35 +0530

Facing precisely that problem, I'd created back in 2005, a sort
Perl script that generates an spreadsheet which loads up
SpamAssassin configuration and known spam and ham messages.  Once loaded,
you can tweak individual SpamAssassin scores in the spreadsheet itself and
see their effect on spam/ham classification in real-time.  The script also
shows you the number of false positives and negatives for a set of scores in

The program is available at:

Feedback appreciated.

Raj Mathur

Broadband survivability and certification

"Charles Jackson" <>
Fri, 23 Apr 2010 14:46:45 -0400

Notice of Inquiry, 21 Apr 2010: The FCC adopted a Notice of Inquiry to
enhance its understanding of the present state of survivability in broadband
communications networks and to explore potential measures to reduce network
vulnerability to failures in network equipment or severe over-load
conditions, such as would occur in natural disasters, pandemics, and other
disasters. The Commission seeks comment on the ability of existing networks
to withstand localized or distributed physical damage, including whether
there is adequate network redundancy and the extent of survivability of
physical enclosures in which network elements are located. Comments are due
45 days from publication in the Federal Register; replies 75 days from

Notice of Inquiry, 21 Apr 2010: The FCC issued a Notice of Inquiry that
seeks comment on whether the Commission should establish a voluntary program
under which participating communications service providers would be
certified by the FCC or a yet to be determined third party entity for their
adherence to a set of cyber security objectives and/or practices. The
Commission also seeks comment on the components of such a program, if any,
and whether such a program would create business incentives for providers of
communications services to sustain a high level of cybersecurity culture and
practice. Comments will be due 60 days after the NOI is published in the
Federal Register; replies will be due 120 days after publication.

Charles L. Jackson, PO Box 221, Port Tobacco, MD 20677, 1-301 656 8716

  [Don't you love these easily remembered URLs?  PGN]

Please report problems with the web pages to the maintainer