Risks Digest 25.15
- From: risko@xxxxxxxxxxx (RISKS List Owner)
- Date: Fri, 16 May 2008 14:49:07 PDT
RISKS-LIST: Risks-Forum Digest Friday 16 May 2008 Volume 25 : Issue 15
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
No-flies on you? (PGN)
Gone in 60 seconds: Spambot cracks Live Hotmail CAPTCHA (Emil Protalinski
via Monty Solomon)
Hacker leaks 6 million Chileans' records (Amos Shapir)
Dilbert site wants to install a widget (William Ehrich)
Used hardware containing sensitive data (Tony Harminc)
88,000 hospital patient records stolen in NYC (Danny Burstein)
UK CCTV used to create a music video (Forest Mars)
QWERTYUIOOPS (Charles C. Mann)
Post Office changes 100 SF addresses (Rob McCool)
PO-boy (Peter Zilahy Ingerman)
Debian OpenSSL Predictable PRNG Toys (H D Moore via Monty Solomon)
Debian OpenSSL Vulnerability (Monty Solomon)
How not to use SSL (Nickee Sanders)
A risk for those that own Digital photo frames (Identity withheld)
'Peel and Stick' Tasers Electrify Riot Control (Paul Saffo)
Risks of Be-clowning Yourself at Computerized Speeds, Internationally
REVIEW: "Geekonomics: The Real Cost of Insecure Software", David Rice
Abridged info on RISKS (comp.risks)
Date: Thu, 15 May 2008 10:01:17 PDT
From: "Peter G. Neumann" <neumann@xxxxxxxxxxx>
Subject: No-flies on you?
The *NYTimes* on 15 May 2008 has an editorial (We'll Have to Check, Sir)
noting that the no-fly list is still populated with names that cause too
many false positives. [We've mentioned Senator Edward Kennedy and everyone
named David Nelson here before.] One airline reports 9,000 false hits every
day, according to DHS head Michael Chertoff. He is proposing each would-be
flier provide airlines with his/her date of birth (which would cut down
extensively on bogus hits -- but ONLY if the person's DoB was given
accurately AND if the birthdate of the actual terrorist were known!). The
terrorist watch list now contains more than 900,000 names. TSA estimates
that 15,000 people have actually managed to get their own names off the
list, although the process is reportedly "frustratingly slow".
Date: April 16, 2008 8:05:12 AM EDT
From: Monty Solomon <monty@xxxxxxxxxx>
Subject: Gone in 60 seconds: Spambot cracks Live Hotmail CAPTCHA
[Source: Emil Protalinski, ArsTechnica, 15 Apr 2008]
Internet users are quite familiar with the Completely Automated Public
Turing test to tell Computers and Humans Apart (CAPTCHA), a quick method
that verifies whether or not the user trying to sign up is a person or a
bot. A picture with swirled, mangled, or otherwise distorted characters is
displayed and the user then types in the correct letters or numbers. Thus
far, the system has worked well to slow down malicious bots, but recently
the groups behind such software have made significant strides. A security
firm is now reporting that the CAPTCHA used for Windows Live Mail can now be
cracked in as little as 60 seconds.
Back in early February, a group cracked Windows Live Hotmail's CAPTCHA. A
few weeks later, Gmail's version followed suit. In just over a month's time,
some anti-spam vendors were forced to completely block the domain for the
popular service as bots signed up for thousands of bogus accounts and began
to flood the tubes with e-mail advertisements for lottery tickets and
watches. The close proximity of the two cracks has done everything but
sealed CAPTCHA's fate.
To make matters worse, Websense Security Labs is now reporting that the
method for getting around Windows Live Mail's CAPTCHA has been improved to
the point that a bot can decipher the text and make a guess in less than six
seconds, on average. Windows Live Hotmail's Anti-CAPTCHA automatic bot,
which hooks itself into Internet Explorer on a victim's machine, has a
success rate of about 10-15 percent. That means that it takes up to one
minute for a single bot to create a new account. ...
Date: Mon, 12 May 2008 19:17:58 +0300
From: Amos Shapir <amos083@xxxxxxxxxxx>
Subject: Hacker leaks 6 million Chileans' records
"A computer hacker in Chile has published confidential records belonging to
six million people on the Internet, officials say."
Full story at: http://news.bbc.co.uk/2/hi/americas/7395295.stmAmos Shapir
Date: Mon, 05 May 2008 09:31:16 -0500
From: William Ehrich <ehrich@xxxxxxxxxxx>
Subject: Dilbert wants a widget
The Dilbert site (www.dilbert.com) wants me to install a special 'widget' to
let me see their cartoons. That rings all my alarm bells. Even if honest and
safe, it seems a bad precedent.
Like some other sites, they want an e-mail address which would presumably get
a corresponding entry in my spam filter.
Date: Fri, 9 May 2008 16:13:18 -0400
From: "Tony Harminc" <tony@xxxxxxxxxxx>
Subject: Used hardware containing sensitive data
There have been plenty of stories of used laptops and hard drives containing
confidential data, and my impression is that even the non technical people I
know now understand this risk when disposing of old hardware. But recently I
picked up two items at the local Goodwill store for $5 each; a home-style
DSL router/NAT box, and a burglar/fire alarm panel, evidently removed during
a renovation. Both have user manuals available online, and both contained
easily readable data that would provide at least the basis for a denial of
service attack, and possibly much more.
Although the router was password protected, a particularly bad (but
documented) design allows for access to be regained and the existing
password to be discovered, all through the browser interface. The router
also contained a PPPOE userid and password, and a first name - quite
possibly enough for some social engineering, and probably enough to log in
to the PPPOE provider and cause trouble. I have seen a number of similar
boxes at the same Goodwill, presumably as people change their home networks
to WiFi and can't think of anything to use the old unit for.
The alarm panel, not a consumer product exactly, but still well documented
online, had an account identifier both on a sticker inside and programmed
in, and primary and backup numbers for the box to call. In my experience
alarm companies will, not unreasonably, respond to alarms from even a closed
or delinquent account, since the potential liability for them is very much
higher if they fail in error to respond to a real call than if they notify
the emergency services and let them attend at the last known address just in
Risks: Try to give your old hardware a good home, and risk annoyance or worse.
Date: Sun, 4 May 2008 13:42:54 -0400 (EDT)
From: danny burstein <dannyb@xxxxxxxxx>
Subject: 88,000 hospital patient records stolen in NYC
"Computer equipment stolen from an administrative office in Clifton (a
neighborhood in Staten Island, NYC) in December contained personal
information from 88,000 patients that have been treated at Staten Island
University Hospital. After four months with no arrests, hospital
administrators are just now beginning the process of sending out letters to
patients whose names, Social Security and health insurance numbers were
contained in computer files on a desktop computer and a backup hard drive
stolen Dec. 29 from the hospital's finance office at 1 Edgewater Plaza."
This case is a bit different from the standard RISKS story, inasmuch as it's
based on a traditional physical theft, and from inside a working office,
rather than a car. But it does go to show that the old risks are still
(There's a side issue of the hospital taking four months before notifying
the public, which may actually be in violation of NYS law and federal regs.)
Date: May 12, 2008 7:00:42 PM EDT
From: Forest Mars <lostjournals@xxxxxxxxx>
Subject: UK CCTV used to create a music video
[From Dave Farber's IP distribution, in response to Frode Hegland,
U.K. turns CCTV, terrorism laws on pooping dogs
"The United Kingdom has the most surveillance cameras per capita in the
world. With the recent news that CCTV cameras do not actually deter
crime, how can the local town councils justify the massive surveillance
program? By going after pooping dogs."]
I don't know what is going on with the UK, it's like they're using 1984 as
an installation guide.
In case anyone missed this clever turning of the tables, however, here's the
story of a music band who not being able to afford to produce their video,
performed in front of 80 of the estimated 13 million (public) surveillance
cameras in UK, and then got the footage by filing a request under UK's Data
Link includes the finished video.
"The Get Out Clause are an upcoming UK band who are currently unsigned.
They took a brilliant and I'm sure soon to be much copied method to
producing their own video. Unable to hire a production crew for a standard
1980's era MTV music video, they performed their music in front of 80 of the
13 million CCTV "security" cameras available in England, including one on a
They then used Britain's Data Protection Act to request the footage that was
shot of them. Grab some decent and inexpensive video editing tools
(say. . . an iMac) and presto! They got themselves a unique and in my
opinion quite interesting music video."
Date: Mon, 05 May 2008 05:06:36 +0000
From: ccmann@xxxxxxxxxxx (Charles C. Mann)
[From Dan Farmer's list. PGN]
My laptop is on its way to decrepitude, so I've been thinking about looking
around for a replacement. I always figured I should just buy a big company's
machine, as they're a commodity, and just look for the cheapest price for
what I want, since they're all basically the same. Apparently this logic is
flawed. Apparently Dell has just released a laptop in which the arrangement
of keys on the keyboard is mistaken:
Fortunately for us in the US, this just affects their European models. But
still, it's kind of amazing.
Date: Thu, 8 May 2008 15:06:21 -0700 (PDT)
From: Rob McCool <robm@xxxxxxxx>
Subject: Post Office changes 100 SF addresses
The US Postal Service has changed the address of 100 people in San
Francisco. According to the story, the problem arises because at one end of
the street in question, the name is "La Playa", and at the other it is
"Great Highway" -- and where the split is between them depends on whose map
you are looking at.
The article does a pretty good job of diving into the implications of this,
and the risks, including the technical problems that can happen such as GPS
units not being updated with the "latest" decision about what name this
A Post Office spokesperson was quoted as saying that the decision to
eliminate one of the ambiguous street names for these addresses was based on
a database upgrade: "The legal address of the area in question is La Playa.
We are required to deliver to the legal address. We understand that some
residents have been using the Great Highway address for decades, but at some
point we updated our database and (La Playa) is what is in our database."
Date: Sun, 11 May 2008 18:45:14 -0400
From: "Peter Zilahy Ingerman, PhD" <pzi@xxxxxxxxxxxx>
My street address is 40 Needlepoint Lane. When I tried to use it on the
Amtrak web site as a mailing address, it was rejected as being a post office
box. Discussion with Amtrak's Internet Help Desk revealed that this is a
known problem: the software that detects/disallows post office boxes simply
looks for an adjacent "po" in the address! UGH!
Date: Thu, 15 May 2008 23:26:18 -0400
From: Monty Solomon <monty@xxxxxxxxxx>
Subject: Debian OpenSSL Predictable PRNG Toys
H D Moore, Metasploit
On May 13th, 2008 the Debian project announced that Luciano Bello found an
interesting vulnerability in the OpenSSL package they were distributing. The
bug in question was caused by the removal of the following line of code from
[ .. ]
MD_Update(&m,buf,j); /* purify complains */
These lines were removed because they caused the Valgrind and Purify tools
to produce warnings about the use of uninitialized data in any code that was
linked to OpenSSL. You can see one such report to the OpenSSL team
here. Removing this code has the side effect of crippling the seeding
process for the OpenSSL PRNG. Instead of mixing in random data for the
initial seed, the only "random" value that was used was the current process
ID. On the Linux platform, the default maximum process ID is 32,768,
resulting in a very small number of seed values being used for all PRNG
All SSL and SSH keys generated on Debian-based systems (Ubuntu, Kubuntu,
etc) between September 2006 and May 13th, 2008 may be affected. In the case
of SSL keys, all generated certificates will be need to recreated and sent
off to the Certificate Authority to sign. Any Certificate Authority keys
generated on a Debian-based system will need be regenerated and revoked. All
system administrators that allow users to access their servers with SSH and
public key authentication need to audit those keys to see if any of them
were created on a vulnerable system. Any tools that relied on OpenSSL's PRNG
to secure the data they transferred may be vulnerable to an offline
attack. Any SSH server that uses a host key generated by a flawed system is
subject to traffic decryption and a man-in-the-middle attack would be
invisible to the users. This flaw is ugly because even systems that do not
use the Debian software need to be audited in case any key is being used
that was created on a Debian system. The Debian and Ubuntu projects have
released a set of tools for identifying vulnerable keys. You can find these
listed in the references section below. ...
Date: Thu, 15 May 2008 23:26:18 -0400
From: Monty Solomon <monty@xxxxxxxxxx>
Subject: Debian OpenSSL Vulnerability
DSA-1571-1 openssl -- predictable random number generator
Date Reported: 13 May 2008
Affected Packages: openssl
Security database references: In Mitre's CVE dictionary: CVE-2008-0166.
Luciano Bello discovered that the random number generator in Debian's
openssl package is predictable. This is caused by an incorrect
Debian-specific change to the openssl package (CVE-2008-0166). As a result,
cryptographic key material may be guessable.
This is a Debian-specific vulnerability which does not affect other
operating systems which are not based on Debian. However, other systems can
be indirectly affected if weak keys are imported into them.
It is strongly recommended that all cryptographic key material which has
been generated by OpenSSL versions starting with 0.9.8c-1 on Debian systems
is recreated from scratch. Furthermore, all DSA keys ever used on affected
Debian systems for signing or authentication purposes should be considered
compromised; the Digital Signature Algorithm relies on a secret random value
used during signature generation. ...
Date: Sun, 4 May 2008 09:05:45 +1200
From: Nickee Sanders <njsanders@xxxxxxxxxx>
Subject: How not to use SSL
I fly to Paris next week. A couple of days ago I booked a shuttle into the
city itself. This is a company I have used before and I was happy to use
them again. They must have a manual reservations process, because although
one can "book" and pay on the web, the confirmation e-mail doesn't arrive
until up to 24 hours later. Because of this I like to keep the confirmation
webpage loaded in my browser until the e-mail arrives.
This time around, I had to restart my machine before I got the e-mail. So I
went back into my browser history on the off-chance that reloading the page
would show enough details about the transaction.
This worked better than I'd expected. There was my name, my confirmation
num-...hey, hang on...isn't that a different confirmation number from the
original one? Yup, I was right. What the heck?
I immediately went to the URL...and found to my utter amazement, that after
the "https://" and the domain name, were the entire details of my
transaction, including my credit card number, expiry date, and the 3 digits
off the back of the card.
Of course I was charged a second time with the page reload, but this is
obviously not the first time this has happened and the folks handled the
situation very well. But way to go to completely defeat the point of SSL!
Date: Mon, 5 May 2008
From: [Identity withheld]
Subject: A risk for those that own Digital photo frames
Mocmex, an insidious computer virus that collects passwords for online
games, recognizes and blocks antivirus activity from over 100 vendors, and
also evades Microsoft security and firewalls. It hides itself in photo frames.
[Source: Deborah Gage, *San Francisco Chronicle*, 15 Feb 2008]
[Old item, but we had not noted it before. PGN]
Date: Wed, 14 May 2008 06:44:49 -0700
From: Paul Saffo <paul@xxxxxxxxx>
Subject: 'Peel and Stick' Tasers Electrify Riot Control
I'll bet someone figures out countermeasures to this real fast...
Source: 'Peel and Stick' Tasers Electrify Riot Control
Company's New Converter Kit Turns Shields into Shockers
Noah Shachtman, WiReD BLOG Network, 14 May 2008 [PGN-ed]
Pretty soon, cops won't just be packing stun guns. They'll be carrying
electrically-charged riot shields, zapping their unruly without unholstering
their weapons. That is, if the folks at Taser International have their way.
The company just introduced the "Taser Shield Conversion Kit featuring the
Taser Repel Laminate Film Technology." The kit "features a peel and stick
perforated film, power supply and necessary conversion equipment. This
laminate becomes electrified providing a powerful deterrent to protect
officers and keep suspects or rioters at bay." What could possibly go wrong?
[See Noah's blog for the Rest of the Story. PGN]
Date: Tue, 06 May 2008 01:02:49 -0400
From: "R.G. Newbury" <newbury@xxxxxxxxxxxx>
Subject: Risks of Be-clowning Yourself at Computerized Speeds, Internationally
So I received a phish mail...my (non-existent) account at the Bank of
Montreal has been suspended... yada yada nada...
Obviously a phish from a Microsoft script-kiddy as the entire URL is
visible in text
For your safety we have decided to suspend your access.
You will need to verify your identity.
Customer Service, Bank of Montreal.
So I decided to visit the root system. Turns out, they design and build
websites. All Microsoft websites. Lotsa flash and flashy motion and loud
audio. And no e-mail address for a contact, only a flash (in the old sense
of the word) web-contact page. Which of course, does not work with Firefox
and Fedora. Same thing for the client system which lives further down the
URL chain. Wanna see a directory listing of Helen Peng's directory. Go
right ahead. So I can't tell them they have been screwed, in more ways than
once. Maybe they will notice the extra server load and the high traffic
levels serving one particular page which they don't actually know about? Ya
Date: Mon, 05 May 2008 11:37:09 -0800
From: Rob Slade <rmslade@xxxxxxx>
Subject: REVIEW: "Geekonomics: The Real Cost of Insecure Software", David Rice
"Geekonomics: The Real Cost of Insecure Software", David Rice, 2008,
%A David Rice david@xxxxxxxxxxxxxxxxxxx
%C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%G 0-321-47789-8 978-0-321-47789-7
%I Addison-Wesley Publishing Co.
%O U$29.99/C$32.99 416-447-5101 800-822-6339 bkexpress@xxxxxx
%O Audience n+ Tech 2 Writing 3 (see revfaq.htm for explanation)
%P 362 p.
%T "Geekonomics: The Real Cost of Insecure Software"
In the preface, the author states that the only pre-requisite for reading
the book is a "hint of curiosity." This is because the work explores the
issue of insecure and unreliable software from a sociological and economic
perspective, rather than giving the topic a purely technical examination.
Rice's book is readable, informative, and makes important points. I enjoyed
it. Normally such an assessment comes at the end of the review, but I want
to state this up front, because, in the remainder of the commentary contains
a number of critical comments. For the most part, though, these apply to
components that Rice has not included, and which would tend to support his
contention, rather than detract from it.
Chapter one repeats a lot of the material in the preface, sometimes in
greater detail. Rice compares software with cement, in terms of the
infrastructure of modern society, and also introduces the economic concepts
of incentives and utility. The emphasis, in the analysis of software flaws,
is on intrusions and networking, but the examples cited concentrate on
concerns of reliability, rather than intrusions, somewhat weakening the
overall argument. The lack of software standards, and the fact that
unregulated markets militate against quality and safety, are addressed in
chapter two. The text also specifically explores the problems involved in
the ubiquitous practice of patching software faults. Rice's reasoning on
the matters, while generally sound and extremely convincing, does have some
odd quirks. For example, he repeats the widely held belief that building
secure software in the first place must necessarily be more expensive, or
companies would be doing it. (A relevant counter-example in the world of
non-computer technology would be that of refrigerator doors. For years
fridge door latches were a danger to children when old fridges were
abandoned. Children playing around the fridges could enter them, and then
become locked inside. It was only after appliance companies were forced to
change the door locking mechanisms that they turned to magnetic
closures--and found that not only were those mechanisms safer, but also
cheaper and more energy efficient. Thus, companies may sometimes need to be
forced into practices that may actually be to their advantage. Overall,
consideration of such additional elements only serve to strengthen Rice's
basic premise that insecure software is unnecessarily costly.)
In chapter three, Rice notes the extremely low rate of prosecution for
computer crimes, and moves from there to the statement that professional
cybercrime is not just a criminal matter, but that the issue of software
unreliability is of concern for national, and even international, economic
security. He concentrates, again, on software vulnerabilities, failing to
fully assess investigative weaknesses (and the economic pressures preventing
law enforcement agencies from hiring and retaining trained forensic staff),
the inherent risks of information warfare (to the attacker as well as the
target), and the difficulty of establishing and validating trust
relationships. He correctly identifies the problem with paying bounties for
vulnerabilities (which many have forgotten). Noting the deleterious effect
of allowing visible dilapidation to go unrepaired, he asserts that the
invisible imperfections of software are even more important, but his
argument appears incomplete.
After reiterating the point that speed of innovation and time-to- market is
important to software developers, chapter four appears to lose focus,
finally seeming to make the point that we need some kind of licensing for
software development. Chapter five's review of tort law tends to overshadow
the more significant message that software developers enjoy an unparalleled
immunity from lawsuits, and thus have no motivation to produce software of
high quality. Various characteristics of open source software, and related
development processes, are used to point out, in chapter six, differing
economic forces both for and against software reliability.
Near the beginning of chapter seven Rice admits that he proposes no ultimate
answers to the question of code quality. He does, however, list arguments
that can be used to start further discussion on the possible approaches to
revise the incentive environment in order to promote quality software. The
list of potential approaches includes allowing the "free market" to deal
with the problem (in other words, do nothing), promote litigation, license
software engineers, create standards, or impose some form of vulnerability
tax on developers.
Towards the end of chapter seven, the author states that "[t]his book has
argued, no matter how imperfectly, that incentives are key to changing the
story of software." Despite my minor quibbles, Rice's case is solid, and
his thesis is important. This work should be required reading for all
involved in matters of technology policy, from managers and security
professionals responsible for application development, to politicians. If
this publication is successful enough, the publisher might have an incentive
to ask the author to update his text for a second edition, at which time
Rice might tighten up his arguments and include some of the missing bits.
Then this book should be required reading for all developers and programming
copyright Robert M. Slade, 2008 BKGKNMCS.RVW 20080207
rslade@xxxxxxxxx slade@xxxxxxxxxxxxxx rslade@xxxxxxxxxxxxxxxxx
Date: 17 Oct 2007 (LAST-MODIFIED)
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@xxxxxxxxxxx or risks-unsubscribe@xxxxxxxxxxx
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@xxxxxxxxxxxxxxx>.
=> SPAM challenge-responses will not be honored. Instead, use an alternative
address from which you NEVER send mail!
=> SUBMISSIONS: to risks@xxxxxxxxxxx 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.15