RISKS-LIST: Risks-Forum Digest Thursday 7 January 2010 Volume 25 : Issue 89 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.89.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: "HAPPY NEW YEAR!!!" Y2K+10 problem 1. German contactless bank cards (Debora Weber-Wulff) Y2K+10 problem 2: Symantec (PGN) Y2K+10 problem 3: Bank of Queensland Eftpos system (Jared Gottlieb) Y2K+10 problem 4: SpamAssassin tags "2010" e-mail as spammish (Danny Burstein) Y2K+10 Bug, for those who thought that Y2K was a made up crisis (Bob Gezelter) Verizon: I just don't know what to say (Geoff Kuenning) Eurostar Risks (Anthony Thorn) Display: none; visibility: hidden; overflow: hidden (jidanni) Crumbling Crypto: RSA 768 modulus factored + security implications (PGN) Couple Stuck in Oregon Snow for 3 Days After GPS Leads Them Astray (Richard Grady) Risks of Relying on Downstream Syndication (Bob Gezelter) Re: Teleportation via Skyhook (Gary Bliesener) Toyota acceleration; is it just the gas pedal or not? (David Lesher, Curt Sampson, Dick Mills, Jerry Leichter, Amos Shapir, Rob Seaman) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 05 Jan 2010 00:33:39 +0100 From: Debora Weber-Wulff <weberwu_at_htw-berlin.de> Subject: Y2K+10 problem 1. German contactless bank cards (3 messages) Happy New Year! Germans now have the answer as to why they came up short at the ATMs after the New Year. Tagesschau reports online that people who were using newer cash machine cards that had new-fangled golden chips in them were told at the machine that their cards had an error because of a "software error". Not only ATM machines were affected, supermarkets and such that check cards online refused to accept the cards. http://www.tagesschau.de/wirtschaft/eckarte102.html Since I have spent the first 4 days of the year writing "20010", anyone want to speculate that this is the error? No details on the exact nature of the error as yet. It is scheduled to be fixed tonight (Jan. 4!). Not all of the machines refused to work, only the newer ones with the "EMV-Standard" (http://en.wikipedia.org/wiki/EMV) which are to keep the cards from being duplicated illegally and "secure" the data. Older cards, which store information on a magnetic strip, were not affected. I'm glad I still have an old card and an ancient machine around the corner. I got money after New Year's. More: Wed, 06 Jan 2010 17:36:57 +0100 It is getting curiouser and curiouser! The Tagesschau reports in http://www.tagesschau.de/wirtschaft/eckarte108.html and http://www.tagesschau.de/wirtschaft/kreditkarten144.html, which I translate and summarize here: It turns out that even more cards are affected, and even more people are unable to use either their EC cards or their credit cards to obtain cash or to pay in stores. The culprit has been named: The company that produces the cards, Gemalto. Seems that the software thinks that it is the year 2016 and not 2010, so all of the cards are no longer valid. A friend pointed out to me that 2016 is 11111100000 in binary. [*] The problem is a program stored on the chip. The banks don't want to have to exchange all of the cards (a really expensive solution), so they are looking for a workaround. One was promised for Monday evening, but it has not yet materialized. ATMs are generally now accepting the cards again [meaning they probably don't do any checking now...], but the Point of Sale terminals refuse to cooperate. 30 million cards are affected, and changing them would entail the owners all having to learn a new code for their cards. Only German cards are affected. Many hundred thousand cards were just exchanged in November because of problems with the data of cards used in Spain having been available after a security breach. The company Gemalto was formed 2006 in the fusion of the French company Gemplus International and the Dutch Axalto Group. The company has 10.000 employees and produces bank cards, telephone SIM cards and electronic passports. The company reports a volume of 1,68 billion euros in 2008. Consumer organizations and the consumer minister are blasting the banks for informing the consumers only a little bit at a time. * On a side note, customers of smartphones using Windows Mobile operating system have been noticing that incoming SMS messages also have the date 2016. Still More: Thu, 07 Jan 2010 08:58:34 +0100 Just a bit of scotch tape, sir! The great Y2K+10 problem in Germany continues: The chips were put on the cards to make them more difficult to duplicate. But it turns out, they at least have a fail-safe mode. If the chip is found to be malfunctioning or not there, the card readers resort to reading the magnetic stripe. Spiegel and others report that all it takes is a little Scotch tape over the contacts of the card, and the readers will switch to fail-safe mode. Retailers now dispense tape at the cash registers. http://www.spiegel.de/wirtschaft/soziales/0,1518,670433,00.html It is great that they have this mode, but it kind of makes you wonder how safe these expensive chips really make you, if they can so easily be defeated. Prof. Dr. Debora Weber-Wulff, HTW Berlin, Treskowallee 8, 10313 Berlin Tel: +49-30-5019-2320 http://www.f4.htw-berlin.de/people/weberwu/ ------------------------------ Date: Thu, 7 Jan 2010 11:44:54 PST From: "Peter G. Neumann" <neumann_at_private> Subject: Y2K+10 problem 2: Symantec Symantec Y2K10 Date Stamp Bug Hits Endpoint Protection Manager http://www.eweek.com/c/a/Security/Symantec-Y2K10-Date-Stamp-Bug-Hits-Endpoint-Protection-Manager-472518/?kc=EWKNLSTE01072010STR1 Updates after 31 Dec 2009 11:59 p.m are being labeled as "out-of-date." ------------------------------ Date: Sun, 3 Jan 2010 11:22:18 -0700 From: jared gottlieb <jared_at_private> Subject: Y2K+10 problem 3: Bank of Queensland Eftpos system Retail businesses across the country have lost thousands of dollars over the long weekend because a computer glitch left shoppers unable to use the Bank of Queensland's Eftpos terminals. BOQ's Eftpos machines skipped ahead six years when the clock ticked over to January 1 and started date stamping January 2016. BOQ staff have not been able find what caused the problem, but a temporary solution has been put in place to ease retailers' frustrations. The glitch cost businesses untold amounts as the Eftpos terminals read customers' [debit] cards as having expired and refused their transactions. [Source: *Sydney Morning Herald* 3 Jan 2010, AAP news wire] ------------------------------ Date: Sat, 2 Jan 2010 10:28:38 -0500 (EST) From: danny burstein <dannyb_at_private> Subject: Y2K+10 problem 4: SpamAssassin tags "2010" e-mail as spammish Spam Assassin is a pretty widely used e-mail filtering program. One of the rules it uses is checking the date on incoming e-mail. If it's wrong, then some points are added to the "is this spam?" score. It seems that up until a rushed update the afternoon of Jan. 1st, 2010, the standard installations, using the default rule set, considered the year "2010" to be way off in the future. Accordingly they gave e-mail with that date an automatic 3.5 points. Five points gets you to the "spam threshold", so lots of material coming through on the new year got clobbered. It seems the "year date" was hard/hand coded, as opposed to making a comparison to "today's" date. The SpamAssassin folk have a new version which corrects this problem. Folk running SA can also modify that one rule set and bypass the issue. Details: http://wiki.apache.org/spamassassin/Rules/FH_DATE_PAST_20XX https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269 [Also noted by Dave Horsfall: "To summarise, it blocks messages with dates set too far in the future (which apparently is a common spammer trick - I read my e-mail in forward order of delivery) and 2010 was inside the range of 2010-2099."] https://secure.grepular.com/blog/index.php/2010/01/01/spamassassin-2010-bug/ ------------------------------ Date: Wed, 06 Jan 2010 16:52:14 -0500 From: Bob Gezelter <gezelter_at_private> Subject: Y2K+10 Bug, for those who thought that Y2K was a made up crisis Recently, I have seen several letters questioning the whether Y2K was a real hazard, or whether it was an invented crisis. Several of these letters have appeared in *The New York Times* Letters page following the publication of "It's Always the End of the World as We Know It" (Op Ed, 1 Jan 2010). The coincidence is uncanny. Yesterday (5 Jan 2010), Network World published "Y2K all over again in 2010?" on a series of outages related to this most recent decade change. The Network World article can be found at: https://www.networkworld.com/news/2010/010510-date-change-problems.html The New York Times Op Ed can be found at: http://www.nytimes.com/2010/01/01/opinion/01dutton.html The Letters relating to Op Ed can be found at: http://www.nytimes.com/2010/01/06/opinion/l06climate.html - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Sat, 02 Jan 2010 14:23:51 -0800 From: Geoff Kuenning <geoff_at_private> Subject: Verizon: I just don't know what to say Recently, Verizon took over MCI, resulting in me getting them as my new local telephone provider. This afternoon, I used Verizon's online site to change the billing address for my account. About an hour later, I got a nice automated phone call that was intended to verify that the change was legitimate. So far, so good. But the automated voice informed me that if I hadn't authorized the change, I should "contact us at [slight pause] between the hours of [slight pause] and [slight pause]. Thank you for choosing Verizon." I guess I should be glad that "[slight pause]" didn't come out as "left parenthesis null pointer right parenthesis." Geoff Kuenning geoff@private http://www.cs.hmc.edu/~geoff/ ------------------------------ Date: Sun, 27 Dec 2009 10:09:44 +0000 (GMT) From: "anthony.thorn_at_private" <anthony.thorn_at_private> Subject: Eurostar Risks On December 18th, 5 Eurostar passenger trains failed, in the Channel tunnel trapping 2000 passengers. (Eurostar is the rail service through the tunnel under the English channel) The service only resumed on Tuesday 22nd. The failure was due to inadequately "winterised" trains encountering snow and extremely cold weather: "The snow entered the locomotives' ventilation system... When the trains entered the great warmth of the tunnel, the electrical system short-circuited and the traction motors of the Eurostars cut out and would not start again." This problem was known. It is NOT a "Black Swan" ! Apparently in contrast to the passenger trains, the car-transporter trains are sufficiently winterised. If the failure was not already a disaster, there is no doubt at all about the evacuation. Some passengers were trapped in the tunnel for up to 14 hours, and complained about lack of/conflicting information, as well as the heat. Thousands of passengers waited at the railway (train) stations for a service that would not be available for days. There was not much of an alternative: huge queues for ferries , and planes delayed by the weather. e.g. http://www.independent.co.uk/news/uk/home-news/thousands-stranded-as-eurostar-service-is-suspended-1846350.html The risks: 1. (IMHO) an inadequately tested contingency plan. 2. We passengers assume that a rail service will be reliable -because it almost always is. Perhaps we should not/cannot and need to take our own "emergency equipment" along? ------------------------------ Date: Tue, 05 Jan 2010 06:37:57 +0800 From: jidanni_at_private Subject: Display: none; visibility: hidden; overflow: hidden I suppose it's fair game these days to hide anything you like within an HTML div style="display: none; visibility: hidden; overflow: hidden;" like they do on http://topics.cnn.com/topics/weather . They even store a "404 Error The page you requested cannot be found" inside that HTML div. "Who would ever browse without using (our) stylesheets?" ------------------------------ Date: Thu, 7 Jan 2010 11:40:28 PST From: "Peter G. Neumann" <neumann_at_private> Subject: Crumbling Crypto: RSA 768 modulus factored + security implications After an extensive multiyear collaborative effort, the RSA 768-bit challenge number has been factored, suggesting that 1024-bit prime products may be somewhat closer to approaching the end of their practical lifetimes. http://bit.ly/8xXSgy (International Association for Cryptologic Research) ------------------------------ Date: Mon, 28 Dec 2009 13:52:20 -0800 From: Richard Grady <richard_at_private> Subject: Couple Stuck in Oregon Snow for 3 Days After GPS Leads Them Astray KLAMATH FALLS, Ore. A Nevada couple letting their SUV's navigation system guide them through the high desert of Eastern Oregon got stuck in snow for three days when the GPS unit sent them down a remote forest road. http://www.foxnews.com/story/0,2933,581303,00.html ------------------------------ Date: Mon, 04 Jan 2010 19:20:31 -0500 From: Bob Gezelter <gezelter_at_private> Subject: The Risks of Relying on Downstream Syndication It is common to rely on downstream syndication feeds (e.g., ATOM, RSS, usenet news) for information. Unfortunately, sometimes there are "clogs" in the pipeline that result in delayed, lost, or out of sequence messages. Those who read RISKS using Google Groups have recently experienced just such an episode. RISKS 25.85, 25.86, and 25.87 are out of sequence on the archive at http://groups.google.com/group/comp.risks and RISKS 25.88 is completely missing as of this date (4 January 2010), despite having been posted on 26 December. Fortunately, the RISKS page at http://www.risks.org is up to date. Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Tue, 29 Dec 2009 10:45:31 -0500 From: Gary Bliesener <gbliesener_at_private> Subject: Re: Teleportation via Skyhook The default browser, Polaris 6.0, on my Samsung Rant is nearly useless so I installed the Opera Mini-Browser. I ran into IP geolocation issues when responding to e-mailed employment alerts, as many websites would reject my application with a message informing me that one must be a United States resident to apply for their position, even though I am an American using the phone in the mid-Atlantic region of the United States. The Opera mini-browser evidently brings with it an IP address out of what IP geolocation types would label a "Norwegian address pool". I had to wait until my return home to apply, rather defeating the purpose of purchasing a web and e-mail enabled cellphone. Gary Bliesener, Unix System Administrator ------------------------------ Date: Sun, 27 Dec 2009 01:35:32 -0500 From: David Lesher <wb8foz_at_private> Subject: Toyota acceleration; is it just the gas pedal or not? (RISKS-28.85) <http://www.latimes.com/business/la-fi-toyota-throttle29-2009nov29,0,5254584.story> An *LA Times* item has lead the coverage of the issue, bringing up the accusation that the problem is not just mechanical interference between the mats and the pedals, but also more. Eric Weiss was stopped at a busy Long Beach intersection last month when he said his 2008 Toyota Tacoma pickup unexpectedly started accelerating, forcing him to stand on the brakes to keep the bucking truck from plowing into oncoming cars. .. But Weiss is convinced his incident wasn't caused by a floor mat. He said he removed the mats in his truck months earlier on the advice of his Toyota dealer after his truck suddenly accelerated and rear-ended a BMW. Also, I saw a mention that a previous driver of the car that crashed had complained to the dealer about the problem, but it was reissued to the victim despite that. If true, THAT would not alter the cause, but would likely change the legal liability issues. ------------------------------ Date: Sun, 27 Dec 2009 16:14:54 +0900 From: Curt Sampson <cjs_at_starling-software.com> Subject: Re: Another user interface fatal accident in Afghanistan Re: Mark Thorson, RISKS-25.88 > When the target position is cleared, it would probably be better to > initialize it 100 meters to the east or something, rather than right on > top of the observer position. Where it might drop on your friends? It seems to me one wants to expand the range of values to include "no target position." It can't be all that unusual sometimes not to want to drop a bomb. Curt Sampson <cjs_at_private> +81 90 7737 2974 ------------------------------ Date: Sun, 27 Dec 2009 09:47:25 -0500 From: Dick Mills <dickandlibbymills_at_private> Subject: Re: LED Traffic Lights are efficient ... (R 25 88) John Johnson (R 25 88): "The problem is also evident on motor vehicles with LED signal and stop lights. Snow is not melted away by the signal and stop lights and accumulation blocks the lights." Neither can incandescent stop and signal lights melt snow if they are not used often; such as long stretches of driving on the open highway. Nor could they melt snow when there was a generous air gap between the bulb and the lens cover. I can't recall any mention of this risk in the pre LED era. What's new? ------------------------------ Date: Sun, 27 Dec 2009 05:38:43 -0500 From: Jerry Leichter <leichter_at_private> Subject: Re: LED Traffic Lights are efficient ... (R 25 88) John Johnson's mention (R 25 88) of a story that LED traffic lights can be a problem if it snows because they don't generate enough heat to clear themselves brings to mind a repeated story from the NY area. Every fall, we get delays in mass transit because of wet leaves on train tracks. I never recalled hearing of such problems years back, and indeed reports have indicated that this is another side-effect (or lack of a side-effect!) of new technology. In the old days, trains stopped by apply brake pads to the wheels. The resulting friction heated the wheels and rails and rapidly dried and burned off any leaves. Today, the trains use regenerative braking: The wheel motors are run as generators, recovering much of the kinetic energy of the train as electricity. Much more efficient - but as a result, the wheels and rails no longer hot enough to perform a leaf-clearing function. ------------------------------ Date: Sun, 27 Dec 2009 17:55:49 +0200 From: Amos Shapir <amos083_at_private> Subject: Re: LED Traffic Lights are efficient ... (R 25 88) This is actually an old problem with a new twist: the designers of traffic lights and headlights were -- probably unknowingly -- relying on an undocumented feature of incandescent light bulbs, namely their ability to generate enough heat to melt snow on cold days. Obviously it did not occur to anyone that light fixtures should be redesigned for a different type of bulbs. ------------------------------ Date: Mon, 28 Dec 2009 00:07:47 -0700 From: Rob Seaman <seaman_at_private> Subject: Re: LED Traffic Lights are efficient ... (R 25 88) The general class of risk here is that of unintended consequences. It may be helpful to drill down into the specifics of what is going wrong. In both of these submissions (traffic or vehicle signals), LEDs are replacing incandescent bulbs in outdoor applications subject to varying weather conditions. The notion appears to be that nobody could have predicted that more efficient lamp technology would be subject to a failure mode in the snow. Such a notion is mired in confusion over the difference between describing a problem and entertaining solutions to that problem. "Unintended consequences" is another way of saying "undiscovered requirements". The underlying problem is one of signaling, not of lighting technology. After all, before there were traffic lights, there were unlighted traffic semaphores. Drivers still use hand signals on occasion to supplement lighted turn signals and brake lights. The common goal is to communicate signals (of intent, permission, and proscription) between a community of drivers, pedestrians, and other roadway users. In addition to numerous requirements relating to sequencing of interlocking signals, there are - as a matter of course - various requirements regarding weather and ambient visibility (and other sensory) conditions. For instance, presumably the LED manufacturers did not neglect to consider the effect of rain on the operation of their signals. A complete set of top level requirements for a roadway signaling system might not even mention lighting technology at all. More likely, constraints on lighting will appear as non-functional requirements describing current practices and standards (eg., the order of the colors on a traffic signal). A statement that a signal device should continue to operate when it is snowing (presumably up to some NNN-year blizzard threshold) is very much a functional requirement inherent in the concept of operations. A compliance audit/acceptance test should have caught this issue - almost by inspection - before deployment. LEDs are desirable because they inexpensive to operate due to their high efficiency. They are efficient because they emit far less waste heat. What happens to the snow accumulation when heat is removed from the system? Some possible solutions have already been mentioned: a heating element (perhaps actively controlled), weather shielding, special coatings. The point is that there is one problem description ("signal must continue to operate when it is snowing"), but many different options for solutions. It is impossible to evaluate the acceptability of any solution without matching it point-by-point against the problem requirements the solution is meant to address. Some risks are long and involved to describe. It is precisely that this issue can be characterized so succinctly that reveals a requirements failure. Whether the vendor or the customer bears a larger burden of the responsibility for the failure is a separate question. Rob Seaman, National Optical Astronomy Observatory seaman_at_private ------------------------------ 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.89 ************************Received on Thu Jan 07 2010 - 15:17:41 PST
This archive was generated by hypermail 2.2.0 : Thu Jan 07 2010 - 16:13:22 PST