The RISKS Digest
Volume 25 Issue 23

Friday, 18th July 2008

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…


E-mail response to wrong address, intended recipient arrested
Danny Burstein
San Francisco admin hijacks city net
David Lesher
Risks of wrong preprogrammed emergency message system being sent
C.Y./J.E. Cripps
P2P Data Breach affects SCOTUS
Jay R. Ashworth
"Plug and Play" Hospitals
Terrence Enger
Gmail Reveals the Names of All Users
Gene Wirchenko
Google Desktop, Word may expose encrypted data
Gene Wirchenko
UPS "Virus Warning" virtually indistinguishable from phishing attack
Jonathan Kamens
DR/BCM lessons from the Vancouver fire
Daniel Wesemann in SANS via Brent J. Nordquist
Re: Map coordinate errors for California fire
Henry Baker
Al Stangenberger
California's Super-Stupid Anti-Science Cell Phone Law Takes Effect
Kurt Thams
Handheld mobile safety
Paul D.Smith
The toll for terrorism is too high
David Lesher
Firefox 3's Step Backwards For Self-Signed Certificates
Lauren Weinstein
A not-so-obvious hyperinflation risk
B. Elijah Griffin
Re: Approval voting and sincerity
Anthony W. Youngman
Re: ComCast in Concrete? (
Greg Fife
Paul Wallich
US FTC seeks comments on privacy in contactless payments
Kevin Fu
Info on RISKS (comp.risks)

E-mail response to wrong address, intended recipient arrested

<danny burstein <>>
Thu, 10 Jul 2008 09:04:04 -0400 (EDT)

(slightly edited/reformatted for clarity)

Mark Hamblett, Mistaken Identity in Civil Rights Lawsuit

Bronx [NYC] resident William Hallowell filed suit in the Southern District
yesterday claiming police and prosecutors blundered by wrongfully arresting
him for an e-mail he never sent.

Mr. Hallowell was working part time at the Riverdale Country School Library
in April 2007, and exchanging e-mails about the return of a library key with
his supervisor, Robin Berson, when Ms. Berson inadvertently typed the wrong
e-mail address - to a Ben Hallowell.

She received in return an unsigned e-mail saying the recipient had sold the
key for "hookers," a "handful" of drugs and a gun. The writer also professed
his desire for Ms. Berson and proposed a sexual liaison in the library.

The lawsuit alleges that, on a complaint from Ms. Berson, New York City
police, "Despite the obvious lack of evidence against him," arrested William
Hallowell and held him for more than 30 hours.

The complaint, charging false arrest and malicious prosecution, states,
"Determined to make an arrest, any arrest, defendants bluntly violated
Mr. Hallowell's rights by turning a blind eye to the overwhelming evidence
of his innocence," and blames prosecutors for waiting for four months to
dismiss the case.  The Bronx County District Attorney's Office declined

San Francisco admin hijacks city net

<"David Lesher" <>>
Tue, 15 Jul 2008 23:39:00 -0400 (EDT)

San Francisco IT worker arrested in hijacking of city network, CNET


A disgruntled city worker is in jail on $5 million bail after allegedly
locking other administrators out of the city's wireless network.

The Risk? The same one the Intelligence Community faces daily: the people
often are the problem...

  [Jim Horning noted "S.F. officials locked out of computer network" in
  the *San Francisco Chronicle*.  PGN]

Risks of wrong preprogrammed emergency message system being sent

<"C.Y./J.E. Cripps" <>>
Thu, 10 Jul 2008 23:45:59 -0400 (EDT)

Potential risks in preprogrammed emergency message systems:

  About 2,000 State Farm employees spent almost two hours Thursday afternoon
  in the lower level of the company's corporate headquarters [in
  Bloomington, Illinois] after a passer-by reported seeing a man with a
  "long gun" outside the building.

  A preprogrammed tornado announcement sent people to the lower level when
  the company had intended to send out an emergency warning.

  Police eventually determined the person actually saw a custodian holding
  what probably was a pipe.

[Source: State Farm, police pleased with response to security
threat; see link for full article and some further risks.  PGN]

P2P Data Breach affects SCOTUS

<"Jay R. Ashworth" <>>
Wed, 9 Jul 2008 09:57:30 -0400

Mr Justice Stephen Breyer was apparently among the over 2000 people affected
by a personal data breach caused when an employee of a financial services
firm installed Limewire on a computer he used for work, was careless about
how he configured it, and shared some directories containing the data in

Brian Krebs' piece in *The Washington Post* [1] missed both of the important
points; the one I made above in how I (correctly) characterized what
(probably) actually happened — not glossing over the fact that p2p servent
software is not inherently black-hat, as the piece encourages the reader to
assume — and the other one, covered by the comment I posted, which I
reproduce here:

  I'm more than a little bit disappointed that this piece fails to mention
  the root cause of *why* this breach bothers so many people — because the
  last clear chance to avoid it did not happen when the file sharing program
  was installed.

  It happened when AT&T, and the credit card companies, and whosoever, saw
  fit to treat as *authenticators* the mere knowledge of birthdates and

  That someone knows my bday, or SSN, *does not prove they're me*, and this
  problem will not go away until large corporations cease acting as if it
  does... which is a point privacy activists have been making loudly in
  public places since at least 1992 that I know of, and likely longer.

  If you want to authenticate me, do a better job. And don't make *me*
  responsible for paying to deal with the consequences of you not being
  smart enough to do so.

  That's my manifesto. Maybe if enough other people say it too, loudly, it
  will stop. This is why I customarily refuse to give out my SSN.

This is not an idea original to me, of course, and I originally stole it
either from RISKS or from Lauren Weinstein's Privacy Forum, to which I've
CC:ed this message.

But the risks here are multiple, and subtle (at least to some :-), so
I'll enumerate them:

1) Thinking that p2p software is all inherently bad because a) a p2p servent
producer picked a bad default and a non-savvy user accepted it.

2) Blaming the subsequent breach on p2p software inherently, and painting it
as a bad thing — when indeed several major companies are developing legit
p2p distribution networks for various things.

2a) The fact that so many supposedly technology-centric reporters miss the
most important points on stories where technology intersects with society
and the law — which is most of them these days, right?

3) Blaming the breach on even the bad guys, when the root cause is an
excrescently poor process design decision on the part of the good guys, to
wit: choosing to use, as absolute proof that an applicant is who they claim
to be, the fact that they know a birthdate, SSN, mother's maiden name, or
city of birth.

Just as with reusable password security: one of the reasons you use
different passwords for different services (or at least, different security
classes of service) *is because you can't trust the operator of the service
not to leak them*.

Well, this is worse: just like with biometrics, *you can't change the things
these companies are asking for*.

And nowadays, you can't even lie about them, since apparently, violating the
terms of service of a *free* website is a felony[2].

Does anyone see any reasonable way out of this conundrum?  'Cause I don't.



Jay R. Ashworth, Ashworth & Associates, St Petersburg FL USA +1 727 647 1274

"Plug and Play" Hospitals

<Terrence Enger <>>
Thu, 10 Jul 2008 11:20:55 -0400

MIT's *Technology Review* has an article "Plug and Play" Hospitals: Medical
devices that exchange data could make hospitals safer.  Just the title is
enough to excite my "oh yeah?" reflex.

The body of the article focuses entirely on the benefits of the new
technology.  Speaking of the ventilators, which are potentially
life-preserving, it says the following without even a hint that there may be
a risk:

  Goldman says that as a result of his demonstration, standards for
  ventilators are in the process of being revised so that future versions of
  the devices will include a pause function and will be subject to network
  control, moving toward interoperability.

Don't hold your breath.  [What about the nurse who takes a nap on the remote
controller?  And of course the veterinarian in the missing L-wing is "Pug
and Pay".  PGN]

Gmail Reveals the Names of All Users

<Gene Wirchenko <>>
Thu, 17 Jul 2008 08:16:27 -0700

"Have you ever wanted to know the name of Now you can.
Through a bug in Google calendars the names of all registered Gmail accounts
are now readily available. All you need to find out the names of any gmail
address is a Google calendar account yourself. Depending on your view this
ranges from a harmless "feature" to a rather serious privacy
violation. According to some reports, spammers are already exploiting this
"feature"/bug to send personalized spam messages."

Google Desktop, Word may expose encrypted data

<Gene Wirchenko <>>
Thu, 17 Jul 2008 08:33:28 -0700

Opening paragraphs:

"If you're using encryption software to keep part of your computer's hard
drive private, you may have a problem, according to researchers at the
University of Washington and British Telecommunications.

They've discovered that popular programs like Word and Google Desktop store
data on unencrypted sections of a computer's hard drive — even when the
programs are working with encrypted files."

UPS "Virus Warning" virtually indistinguishable from phishing attack

Tue, 15 Jul 2008 09:33:26 -0400

This morning, I received an e-mail message purporting to be from UPS (I have
an account at and reading in part as follows:

  *Attention Virus Warning*

  We have become aware there is a fraudulent e-mail being sent that
  says it is coming from UPS and leads the reader to believe that a
  UPS shipment could not be delivered. The reader is advised to open
  an attachment reportedly containing a waybill for the shipment to be
  picked up.

(I'm sure we've all seen the spam to which the warning is referring.)

My full name is not mentioned anywhere in the message.  The numerous
links in the message are all encrypted query strings and point at rather than  The e-mail header contains a bunch of
randomized garbage (for example, the envelope address looks like this:, and
doesn't appear anywhere in it.

I'm savvy enough to know that this is /probably/ a legitimate e-mail
message from UPS, but a savvy attacker could craft a message that
looks exactly like this one, so I'm also savvy enough to know not to
be foolish enough to click on any of the links.

On the other hand, checking out the links with lwp-request (a Perl
command-line HTTP client) is safe enough.  I checked the "Privacy
Policy" link, and it redirects to, so at least one of the
encrypted links in the message is legitimate.

In this day and age, it is amazing to see a corporation as large as
UPS failing to use the two easiest and most well-known methods of
differentiating legitimate e-mail from scams — put the customer's name
in the e-mail, and make sure that all the links point directly at your

Are there any RISKS readers with connections inside UPS to whose
attention they might bring this matter?

DR/BCM lessons from the Vancouver fire (Daniel Wesemann in SANS)

<"Brent J. Nordquist" <>>
Tue, 15 Jul 2008 08:13:44 -0500

[quoting from <>:]

  DR/BCM lessons from the Vancouver fire
  Published: 2008-07-14   by Daniel Wesemann (Version: 1)

  An fire in an underground power distribution room today knocked a good
  portion of Vancouver's inner city power grid offline. Several news media
  like the Vancouver Sun are carrying the story by now.

  As bad as this event is on its own, the e-mail provider Hushmail reports
  on its web page some additional interesting details. What happened,
  apparently, was that Vancouver's "Harbour Centre" web hosting location
  brought their emergency generator successfully online when the power
  dropped. But as soon as the fire department started drawing massive
  amounts of water in their attempt to contain the fire, the water pressure
  in the mains was reduced to a level where the (water cooled) emergency
  generator couldn't operate any more. Poof. Darkness.

  Now, let me guess how many BCM/DR plans out there didn't think of that
  one... Time to update!

Re: Map coordinate errors for California fire (Baker, RISKS-25.22)

<Henry Baker <>>
Wed, 09 Jul 2008 00:33:24 -0700

After additional research, this particular error may not be a conversion
error at all, but a more classical error.  Apparently, the "Gap" fire was
originally reported to have started at the "Gap", which does indeed reside
at the original coordinates close to Highway 154.  However, this original
report was in error, so the naming of the "Gap Fire" after the "Gap" was
actually a misnomer.  Unfortunately, once the fire had been named the "Gap
Fire", it would have been even more confusing to change its name, so the
name has stuck, even though (so far) the fire hasn't come near the actual

This naming error is entirely analogous to the naming of mathematical
theorems, very few of which are named after their actual/original

Re: Map coordinate errors for California fire (Baker, RISKS-25.22)

<Al Stangenberger <>>
Mon, 14 Jul 2008 17:45:24 -0700

Fortunately, InciWeb is not part of the command and control system for
fighting fires, but is an informational database which attempts to supply
information on incidents nationwide.  Hence the consequences of an error in
location of a fire are not catastrophic.

However, InciWeb has been plagued by instability (possibly server overload)
during the California fire emergency of the past couple of weeks.

As I write this, the Plumas National Forest has set up a Google group to
release information on the Canyon Complex of fires in a timely fashion.

From the PNF homepage: "Due to the unstable nature of InciWeb, updated
information about the Canyon Complex can temporarily be found here [URL for
the Google group]".

Al Stangenberger, Univ. of California at Berkeley, Center for Forestry
145 Mulford Hall # 3114 1-510-642-4424  Berkeley, CA 94720-3114

California's Super-Stupid Anti-Science Cell Phone Law Takes Effect

<Kurt Thams <>>
Tue, 08 Jul 2008 12:08:27 -0700

On day 3 of the new law, we were speculating whether forcing people to use
headsets would have the effect of encouraging people to talk longer,
increasing overall risk.

During our discussion, a friend called to say she'd be late. While fumbling
for her headset she had hit a curb and blown a tire.

The toll for terrorism is too high

<"David Lesher" <>>
Thu, 17 Jul 2008 11:07:11 -0400 (EDT)

The *Los Angeles Times* is reporting that the city is using $16,000,000 of
"anti-terrorism" money to install faregates on their rail lines.

  Both Los Angeles Mayor Antonio Villaraigosa and state Homeland Security
  Advisor Matthew Bettenhausen said the turnstiles will enhance security at
  the rail lines, as well as stop fare jumpers, although a transportation
  security expert said the gates by themselves will have only a nominal
  effect on stopping potential terrorist attacks.

Of course, someone, in this case Don Surber of the Charlston Daily Mail, HAD
to mention the "Gov. William J. Le Petomane Thruway"
<> approach. Why
am I reminded of "Terrorists Can't Type" yet again?

RISK 1: Throw enough money into the air, and it's amazing how many problems
shall appear that need it... for some value of "need"...

RISK 2: With enough RISK 1's, and the fighting over the spoils that results;
real honest-to-gosh threats can be, well, lost in the dust.

Firefox 3's Step Backwards For Self-Signed Certificates

<Lauren Weinstein <>>
Tue, 8 Jul 2008 12:25:28 PDT

            Firefox 3's Step Backwards For Self-Signed Certificates

Greetings.  If you've switched over to Firefox 3 as your Web browser already
-- and in general it's a fine upgrade — you may at some point discover that
rather than encourage (or at least not overly discourage) the use of
self-signed security certificates, Firefox 3 makes it *less* likely that
anyone other than an expert user will ever accept a self-signed certificate.
This is particularly of concern to me since I've urged an expansion of
self-signed certs deployment as a stopgap measure toward pervasive
encryption ( ).

Compared with Firefox 2, version 3 throws up so many barriers and
scary-sounding warnings to click through to accept such certs, that it would
be completely understandable if most persons immediately aborted.

What's going on is that Firefox is now putting so much emphasis on identity
confirmation that it's making it even harder for people to use the basic
encryption functionality of the browser, which works just fine with
self-signed certificates (which admittedly are not good carriers for
identity credentials).

But in many situations, we're not concerned about identity in particular, we
just want to get the basic https: crypto stream up and running.

I am fully aware of the associated identity considerations, and I know that
basic signed certificates that will work in Firefox and some other browsers
(but last I heard not in Internet Explorer at this time) can be obtained for
free.  If browser acceptance of free signed certs broadens out (and
especially if wildcard certificates also become freely available) the need
for self-signed certificates could significantly diminish.

But for now, Firefox 3 is going overboard with its complicated and alarming
warnings, which if nothing else could include improved explanatory text, so
that users would be able to better judge whether or not they should accept
any particular self-signed certificate.  The current wording is unreasonably
judgmental given the range of perfectly legitimate situations where
self-signed certificates might be used.

I'm not saying to give self-signed certs the same invisible, automatic
acceptance as signed certificates, but Firefox 3 has simply gone too far
toward making self-signed certs unusable — from a practical standpoint --
in many situations where they otherwise would be completely adequate and

Lauren Weinstein +1(818)225-2800

Co-Founder, PFIR and NNSquad (Network Neutrality Squad, PRIVACY Forum - Lauren's Blog:

A not-so-obvious hyperinflation risk

< (B. Elijah Griffin)>
Wed, 16 Jul 2008 17:49:57 -0400 (EDT)

The Zimbabwe government is facing a money printing crisis: the government
has been able to maintain power by printing more and more money to pay the
security forces. Now there is a threat to the paper supply needed to print
more and more money. No computer risk there, but the last paragraph has a
kicker. Besides needing paper to print more money, they use computer
software to design the ever larger denominations required to keep pace with
the hyperinflation, and there is a risk: "that its software license for the
European banknote design technology that it uses could be withdrawn because
of new sanctions threatened against the Mugabe government."

Re: Approval voting and sincerity (Drysdale, RISKS-25.21)

<"Anthony W. Youngman" <>>
Tue, 8 Jul 2008 20:19:51 +0100

The best proportional system I've come across requires ranking but doesn't
seem to have been covered here so far.

The voter lists all the candidates they wish to in order of preference.  If
you don't list the candidate, they don't count as far as your vote goes.

When counting the votes, it's treated as a series of two-horse races - for
each pair of candidates you count how many people list A above B, and B
above A.  Unless you get a very weird result (i.e., it's statistically very
unlikely), one candidate will win all his individual contests.  That person
should be elected.

Failing that, someone will almost certainly lose all his contests and should
be eliminated.  When they're removed from consideration the win-lose cycle
can be repeated until you're left with a winner.

(Effectively, you're voting FOR the people you DO want, AGAINST the people
you DON'T want, and ABSTAINING for people you DON'T CARE about.)

Re: ComCast in Concrete? (Schaefer, RISKS-25.22)

<Greg Fife <>>
Wed, 09 Jul 2008 07:15:01 -0400

I ran across this problem with ComCast in Harrisonburg, VA about a year ago.
The Linksys router's "MAC Address Clone" feature was sufficient to fix the

The ethernet adapter in a PC and the ethernet "WAN Port" on a router both
have a unique six byte identification known as a MAC (Medium Access Control)
address. The first three bytes identify the manufacturer (i.e.  Linksys),
and the other three bytes identify the specific device. Default values are
assigned by the manufacturer and programmed into the hardware.  A "MAC
Address Clone" merely allows you to change the factory assigned external MAC
address on a router.

Basically, ComCast's DHCP server just takes each distinct MAC address and
assigns an Internet Protocol (IP address). From the pathological behavior
that we've seen, I assume that ComCast programs their DHCP server to reject
equipment made by Linksys, Belkin, DLink, and so on.

In most consumer routers that I've worked with, the MAC Address Clone is
somewhere in the advanced configuration pages of the web configuration
system. It will probably default to clone the MAC address of your PC's
ethernet adapter, but if not, you can get your PC's mac address from
"IPCONFIG /ALL" in a Windows XP command window or the WINIPCFG program in
Windows 98.

If this doesn't work, I would turn off remote management, "Universal Plug
and Play," and anything else that might allow the cable company to interact
with your router over the network and recognize its specific behavior.

Greg Fife <> 1-540-447-4038

Re: ComCast in Concrete? (Schaefer, RISKS-25.22)

<Paul Wallich <>>
Tue, 08 Jul 2008 16:47:49 -0400

> To sum up, the implication is that at the same instant that ComCast chose to
> refuse to work with Firefox browsers on Win98 machines they also were
> (allegedly) in collusion with Lynksys to obsolete a model of wireless
> router, all scheduled to occur just in time for the July 4th holiday. ...

This sounds fishy at best (albeit it's unclear where the fishiness is).  At
the point where you're doing DHCP negotiation, it's impossible for the ISP
to know what browser you're using. It may be a little easier to know which
router or other machine is attached to the cable modem, but the motivation
for keeping a list of allowed and disallowed routers (especially given the
possibilities for spoofing) seems unclear to me.  What I do know is that
customer service representatives are typically graded on their ability to
get a customer off the line quickly, and if telling them "We don't support
X" will do it faster than "One of our internal routers just went belly-up"
then that's likely what they'll do.

On the other side of the argument, ComCast is pretty much known for doing
thorough inspection, aka wiretapping, of the packets its customers send out,
and for sending packets that misrepresent the state of machines with which
their customer is communicating. So it seems they would be perfectly capable
of bollixing someone's connection in this way, with the only question being
where the profit is.

US FTC seeks comments on privacy in contactless payments

<Kevin Fu <>>
Wed, 9 Jul 2008 18:46:30 -0400

The US Federal Trade Commission issued a request for comments on issues such
as security and privacy of contactless payments last month, but the FTC has
extended the deadline to submit comments.  If you have any comments for the
FTC on privacy for contactless payments, do submit ASAP.  Here are the
comments received thus far.

You may submit either by e-mail or the Web form.

Kevin Fu, Assistant Professor, Computer Science Department, Univ. of
Massachusetts Amherst 413-545-4006

Please report problems with the web pages to the maintainer