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