[RISKS] Risks Digest 25.22

From: RISKS List Owner <risko_at_private>
Date: Tue, 8 Jul 2008 11:21:05 PDT
RISKS-LIST: Risks-Forum Digest  Tuesday 8 July 2008  Volume 25 : Issue 22

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
  <http://catless.ncl.ac.uk/Risks/25.22.html>
The current issue can be found at
  <http://www.csl.sri.com/users/risko/risks.txt>

  Contents:
InciWeb map coordinate errors for California fire (Henry Baker)
Oyster and Mifare cracked: NXP sues to silence Oyster researchers (PGN)
Free Berlin subway rides (Debora Weber-Wulff)
Citibank ATM breach reveals PIN security problems (Jordan Robertson)
Web-based SSH key generation with escrow (Tina Bird)
ComCast in Concrete? (Robert P Schaefer)
State Dept: Celebrity passport files viewed repeatedly - CNN.com (PGN)
California's Super-Stupid Anti-Science Cell Phone Law Takes Effect
  (Lauren Weinstein)
Re: HTML comments reveal corporate weakness (Ivor Hewitt)
Re: Approval voting and sincerity (Andrew Koenig, Dag-Erling Smørgrav)
REVIEW: "The dotCrime Manifesto", Phillip Hallam-Baker (Rob Slade)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Thu, 03 Jul 2008 09:11:01 -0700
From: Henry Baker <hbaker1_at_private>
Subject: Map coordinate errors for California fire

InciWeb is (apparently incorrectly) reporting the location of the "Gap" fire
as 34.487 latitude, -119.783 longitude:

http://165.221.39.44/incident/1384/

This places the fire almost on Highway 154, and a number of miles away from
the description of the fire location as "The Gap Fire started at
approximately 5:45p.m. on July 1 in the West Camino Cielo area, 4 miles west
of State Highway 154 in Los Padres National Forest".

Google/Keyhole has the more-or-less correct location as 34°30'1.34"N,
119°51'26.50"W (=N34.50036 W119.85736), which places it very near West
Camino Cielo, as reported.

http://bbs.keyhole.com/ubb/download.php?Number=1198058

I would be willing to bet that this discrepancy is caused by conversion
among the plethora of different latitude/longitude formats, some having
decimal degrees, some having integral degrees and decimal minutes, and some
having integral degrees and minutes, but decimal seconds.  Unfortunately, I
can't figure out which conversion reproduces this error.

Needless to say, an incorrect location for a major fire can cause
significant problems.

------------------------------

Date: Tue, 8 Jul 2008 5:56:07 PDT
From: "Peter G. Neumann" <neumann_at_private>
Subject: Oyster and Mifare cracked: NXP sues to silence Oyster researchers

[Source: *The Register*, 8 Jul 2008; PGN-ed]
http://www.theregister.co.uk/2008/07/08/nxp_sues_oyster_researchers/

Researchers at Nijmegen's Radboud University have evidently cracked and
cloned London's Oyster travel card, after previously having had similar
success with the Dutch MIFARE travel card (which is supposed to replace
paper tickets on all trams, buses, and trains in The Netherlands).
http://www.ru.nl/english/general/radboud_university/vm/security_flaw_in/

The Dutch researchers are planning to publish their scientific paper,
Dismantling MIFARE Classic, in October at Esorics, in Spain.  The paper
extends a preliminary report.
http://www.cs.virginia.edu/~kn5f/pdf/Mifare.Cryptanalysis.pdf

The dichotomy between belief in security by obscurity and flawed systems
continues.

------------------------------

Date: Mon, 07 Jul 2008 20:50:55 +0200
From: Debora Weber-Wulff <D.Weber-Wulff_at_fhtw-berlin.de>
Subject: Free Berlin subway rides

Berlin newspapers report that on 1 Jul 2008 it was not possible to buy a
subway ticket during the morning rush hour.
http://www.morgenpost.de/berlin/article650601/BVG_Fahrkartenautomaten_komplett_ausgefallen.html

More than 600 of the 700 ticket machines refused to work after they were
updated from a central server overnight. An unnamed Swiss company was
updating the database (probably for fare calculation) when the machines
began failing. It took until 1 pm for the error to be fixed on all machines.

In the meantime, security people walked around encouraging people to just
get on the trains. The ticket checkers (who travel undercover and announce
ticket controls just after the doors close) were pulled from the subway and
put on bus and tram duty.

The BVG won't say how much income it lost in the incident, but they do state
that only a very few people complained about having to ride for free.
[These were probably people with passes who could not take advantage of a
free ride. -- dww]

Debora Weber-Wulff, FHTW Berlin, Internationale Medieninformatik,Treskowallee
8, 10313 Berlin +49-30-5019-2320 http://www.f4.fhtw-berlin.de/people/weberwu/

------------------------------

Date: Wed, 2 Jul 2008 12:50:09 PDT
From: "Peter G. Neumann" <neumann_at_private>
Subject: Citibank ATM breach reveals PIN security problems

Hackers broke into Citibank's network of ATMs inside 7-Eleven stores and
stole customers' PIN codes, according to recent court filings that revealed
a disturbing security hole in the most sensitive part of a banking record.
Hackers are targeting the ATM system's infrastructure, which is increasingly
built on Microsoft's Windows operating system and allows machines to be
remotely diagnosed and repaired over the Internet.  despite industry
standards that call for protecting PINs with strong encryption -- which
means encoding them to cloak them to outsiders -- some ATM operators
apparently aren't properly doing that. The PINs seem to be leaking while in
transit between the ATMs and the computers that process the transactions.
[Source: Jordan Robertson, Associated Press, 2 Jul 2008; PGN-ed]

Full story here: http://www.wtop.com/?nid=108&sid=1432201

------------------------------

Date: Sun, 29 Jun 2008 12:58:02 -0500
From: Tina Bird <tbird_at_precision-guesswork.com>
Subject: Web-based SSH key generation with escrow

http://sshkeygen.com/

Risks are left as an exercise to the reader...
  [This one requires little explanation  by your moderator.  PGN]

------------------------------

Date: Mon, 7 Jul 2008 10:42:27 -0400
From: "Schaefer, Robert P  \(US SSA\)" <robert.p.schaefer_at_private>
Subject: ComCast in Concrete?

This happened to me over the holiday weekend...

On 3 Jul 2008, approximately 9PM, my son detected that our desk PC (windows
98) was no longer able to access the Internet through the cable modem. I
started diagnosing the problem midday July 5. Resetting the cable box and
the computer several times did not help, neither did running
ipconfig/release ipconfig/renew at the command prompt. The error that
ipconfig returned was "DHCP Client refused". I phoned the Comcast 800
number, and after several resets at both ends with no success Comcast
revealed that they refused to support the Firefox browser. On that same
phone session I then attached a laptop running XP and Explorer to the cable
modem and successfully reconnected to the Internet.

I went back to the first computer and the Internet still did not connect. It
appears that Comcast not only does not support Firefox but can now detect
either Firefox or Win98 (which together form an ambiguity group) and refuse
to connect. The Win98 PC was initially also connected to a Lynksys wireless
router so I could connect to the Internet from the laptop anywhere in the
house. I connected the cable modem directly to the wireless router and
disconnected the laptop, I discovered that I could no longer connect to the
Internet through the wireless although the laptop saw full signal strength.

To recap: Win98 no, XP yes, direct cable yes, cable plus wireless, no.

I phoned Comcast a second time and learned that Comcast did not support the
Lynksys wireless router but they immediately and cheerfully without my
prompting provided the 800 number for Lynksys. The call to Lynksys revealed
that my wireless router was out of warranty, but for only $29.95..., I said
thank you and hung up. I phoned Comcast a third time and asked which
particular wireless router they did support, their answer was
"none". Luckily for me, I had an extra wireless router, Belkin, that I had
bought when I had to re-install the Lynksys but thought I had lost the
installation disk (and couldn't get any help from their website - Of course
the Lynksys installation disk turned up after I had bought its replacement.)
Anyway, I installed the Belkin and was good to go. Later, using a second
desktop with XP, Firefox, and a wireless modem I was also able to connect to
the Internet. That experiment adjusts the probability on the ambiguity group
(Win98 or Firefox) to point to either Win98 or now the Firefox "version". I
only just now in writing this realize that I could also have tried
re-reconfiguring the Lynksys again through the laptop, but it had worked
before, and the laptop did see full signal strength, so probably something
else was going on.

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.  Two
hours of my life as an unpaid system administrator for my home computers I
will never get back.

  [Subject line retitled by PGN.]

------------------------------

Date: Fri, 4 Jul 2008 8:22:20 PDT
From: "Peter G. Neumann" <neumann_at_private>
Subject: State Dept: Celebrity passport files viewed repeatedly - CNN.com

  [Thanks to Gene Spafford]

http://www.cnn.com/2008/POLITICS/07/03/us.passport.files/index.html

------------------------------

Date: Tue, 1 Jul 2008 13:26:56 -0700 (PDT)
From: Lauren Weinstein <lauren_at_private>
Subject: California's Super-Stupid Anti-Science Cell Phone Law Takes Effect

Greetings.  Well, today's the day that political expediency and anti-science
stupidity combine for the banning of handheld cell phones while driving in
California.

I've discussed this topic here <a
href="http://lauren.vortex.com/archive/000190.html">several times
before</a>, noting that virtually every study shows no reduction in accident
rates when talking on a hands-free cell phone vs. handheld units. In fact,
there are concerns that people fumbling around to dial and answer hands-free
units may actually make matters worse.

Even the Luddite who spent years pushing through this legislation admits
that the science and studies are against him, but he's convinced that having
both hands on the wheel is safer.  Of course, the law doesn't require two
hands on the wheel -- which would be fairly difficult for stick drivers like
me in any case, eh?

When I was out driving earlier today, I saw one women swerving while putting
on make-up, and a guy weaving all over while apparently wolfing down a
burger. Another car almost didn't make a stop while the woman inside
appeared to be screaming at her kids in the back seat -- all classic
distractions unaffected by the new law.  However, I saw several people now
driving illegally but safely with handheld cell phones.

There are already laws against distracted driving.  The new cell phone law
(as applied to adult drivers) is both unnecessary and counterproductive --
the latter by making people erroneously believe that they're safer with
hands-free phones while driving.

This sort of "feel good" law that flies in the face of science, <a
href="http://lauren.vortex.com/archive/000271.html">studies</a>, and logic,
is an example of our political system operating as a pandering pomposity of
the most inane kind.

http://lauren.vortex.com/archive/000396.html

------------------------------

Date: Mon, 30 Jun 2008 14:24:57 +0100
From: Ivor Hewitt <Ivor.Hewitt_at_private>
Subject: Re: HTML comments reveal corporate weakness (Jidanni, RISKS-25.21)

The "risk" in HTML comments revealing corporate weakness looks simply like
an HTML workaround technique for a bug in Netscape Navigator 4.7 (ns47) that
probably doesn't display correctly (behave) without having a fake
"concreate"(sic) row (i.e. HTML table).

Unlikely to bring "the entire house of cards down", simply a developer
documenting why he was required to do something weird in the markup.

  [Also noted by several others.  PGN]

------------------------------

Date: Mon, 30 Jun 2008 13:35:30 -0400
From: "Andrew Koenig" <ark_at_private>
Subject: Re: Approval voting and sincerity (Drysdale, RISKS-25.21)

If I remember correctly, the article deals with this question, but
unfortunately I don't remember all the details.

Approximately, though, the reasoning hinges on the definition of "approval."
The article claims that a voter's optimum strategy is to rank-order the
candidates, and then vote for all the candidates above a given threshold,
where that threshold depends in a way I do not recall on the voter's
assessment of how likely each candidate is to be elected.

In other words, if A is my favorite candidate, I am willing to tolerate B,
and I never want C to be elected, then I should certainly vote for A and
certainly not vote for C.  Whether I vote for B depends (again, according to
an algorithm that I do not recall) on how likely I think it is that my vote
will cause B to be elected instead of A.

If you consider the process of rank-ordering the candidates and then voting
for all the candidates beyond a threshold to be insincere, then I guess
approval voting could foster insincerity.  But I don't consider it that way,
and, if I remember correctly, neither did the article.

------------------------------

Date: Mon, 30 Jun 2008 03:16:00 +0200
From: Dag-Erling Smørgrav <des_at_private>
Subject: Re: Approval voting and sincerity (Drysdale, RISKS-25.21)

> Thus voting insincerely ... leads to a better result.

Define "better".  In the first scenario, 20% of the voters (those who voted
for C) are dissatisfied.  In the second scenario, 40% of the voters (those
who voted for B plus those who voted for C) are dissatisfied.

Dag-Erling Smørgrav - des_at_private

------------------------------

Date: Thu, 03 Jul 2008 11:06:12 -0800
From: Rob Slade <rmslade_at_private>
Subject: REVIEW: "The dotCrime Manifesto", Phillip Hallam-Baker

BKDCRMNF.RVW   20080317

"The dotCrime Manifesto", Phillip Hallam-Baker, 2008, 0-321-50358-9,
U$29.99/C$32.99
%A   Phillip Hallam-Baker dotcrimemanifesto.com hallam_at_private
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   2008
%G   978-0-321-50358-9 0-321-50358-9
%I   Addison-Wesley Publishing Co.
%O   U$29.99/C$32.99 416-447-5101 fax: 416-443-0948 800-822-6339
%O  http://www.amazon.com/exec/obidos/ASIN/0321503589/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/0321503589/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0321503589/robsladesin03-20
%O   Audience n+ Tech 2 Writing 2 (see revfaq.htm for explanation)
%P   415 p.
%T   "The dotCrime Manifesto: How to Stop Internet Crime"

In the preface, the author notes that network and computer crime is a
matter of people, not of technology.  However, he also notes that
changes to the network infrastructure, as well as improvements in
accountability, would assist in reducing user risk on the net.

Section one enlarges on the theme that people are more important than
machines or protocols.  Chapter one looks at the motive for Internet crime
(money, just like non-computer crime), and repeats the motifs of the
preface.  The text goes on to list various categories and examples of
network fraud.  The content of chapter two is very interesting, but it is
hard to find a central thread.  Overall it appears to be saying that
computer criminals are not the masterminds implied by media portrayals, but
that the problem of malfeasance is growing and needs to be seriously
addressed.  What Hallam-Baker seems to mean by "Learning from Mistakes," in
chapter three, is that security professionals often rely too much on general
principles, rather than accepting a functional, if imperfect, solution that
reduces the severity of the problem.  Chapter four presents the standard (if
you'll pardon the expression) discussion of change and the acceptance of new
technologies.  A process for driving change designed to improve the Internet
infrastructure is proposed in chapter five.

Section two examines ways to address some of the major network crime risks.
Chapter six notes the problems with many common means of handling spam.
SenderID and SPF is promoted in chapter seven (without expanding the acronym
to Sender Policy Framework anywhere in the book that I could find).
Phishing, and protection against it, is discussed in chapter eight.  Chapter
nine is supposed to deal with botnets, but concentrates on trojans and
firewalls (although I was glad to see a mention of "reverse firewalls," or
egress scanning, which is too often neglected).

Section three details the security tools of cryptography and trust.  Chapter
ten outlines some history and concepts of cryptography.  Trust, in chapter
eleven, is confined to the need for aspects of public key infrastructure
(PKI).

Section four presents thoughts on accountability.  Secure transport, in
chapter twelve, starts with thoughts on SSL (Secure Sockets Layer), and then
moves to more characteristics of certificates and the Extended Verification
certificates.  (The promotion of Verisign, infrequent and somewhat amusing
in the earlier chapters is, by this point in the book, becoming increasingly
annoying.  The author is also starting to make more subjective assertions,
such as boosting the trusted computing platform initiative.)  Domain Keys
Identified Mail (DKIM) is the major technology promoted in support of secure
messaging, in chapter thirteen.  Chapter fourteen, about secure identity,
has an analysis of a variety of technologies.  (The recommendations about
technologies are supported even less than before, and the work now starts to
sound rather doctrinaire.)  It may seem rather odd to talk about secure
names as opposed to identities, but Hallam-Baker is dealing with identifiers
such as email addresses and domain names in chapter fifteen.  Chapter
sixteen looks at various considerations in regard to securing networks,
mostly in terms of authentication.  Random thoughts on operating system,
hardware, or application security make up chapter seventeen.  The author
stresses, in chapter eighteen, that the law, used in conjunction with
security technologies, can help in reducing overall threat levels.  Chapter
nineteen finishes off the text with a proposed outline of action that recaps
the major points.

Hallam-Baker uses a dry wit well, and to good effect in the book.  The
humour supports and reinforces the points being made.  So does his
extensive and generally reliable knowledge of computer technology and
history.  In certain areas the author is either less knowledgeable or
careless in his wording, and, unfortunately, the effect is to lessen
the reader's confidence in his conclusions.  This is a pity, since
Hallam-Baker is championing a number of positions that would promote
much greater safety and security on the Internet.  Overall this work
is, for the non-specialist, a much-better-than-average introduction to
the issue of Internet crime and protection, and is also worth serious
consideration by security professionals for the thought-provoking
challenges to standard approaches to the problems examined.

copyright Robert M. Slade, 2008   BKDCRMNF.RVW   2008031
rslade_at_private     slade_at_private     rslade_at_private
http://victoria.tc.ca/techrev/rms.htm

------------------------------

Date: Thu, 29 May 2008 07:53:46 -0900
From: RISKS-request_at_private
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:
   http://lists.csl.sri.com/mailman/listinfo/risks
 Alternatively, to subscribe or unsubscribe via e-mail to mailman
 your FROM: address, send a message to
   risks-request_at_private
 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_at_private or risks-unsubscribe_at_private
 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.
   <http://www.CSL.sri.com/risksinfo.html>
 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_at_private>.
=> SPAM challenge-responses will not be honored.  Instead, use an alternative
 address from which you NEVER send mail!
=> SUBMISSIONS: to risks_at_private 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
 <http://the.wiretapped.net/security/info/textfiles/risks-digest/> .
==> 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:
    <http://www.acm.org/joinacm1>

------------------------------

End of RISKS-FORUM Digest 25.22
************************
Received on Tue Jul 08 2008 - 11:21:05 PDT

This archive was generated by hypermail 2.2.0 : Tue Jul 08 2008 - 11:48:08 PDT