precedence: bulk Subject: Risks Digest 25.90 RISKS-LIST: Risks-Forum Digest Friday 8 January 2010 Volume 25 : Issue 90 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 as The current issue can be found at Contents: NIST-certified USB Flash drives with hardware encryption cracked (PGN) Skype: the case of disappearing telephone numbers (Chrisf J Brady) Libel by Twitter? (Al Stangenberger) Risks of USB chargers for cell phones (Paul Pomes) Y2K+10: look at the Hex (Dave Hansen) Y2K+10: what's underlying? (Chris Smith) Y2K+10: The problems with sticky tape (Peter Houppermans) Weight of a Land Rover incorrectly input into UK VCA database (Matthew Wilson) Re: Eurostar RISKS (Richard Pennington) Leaves on Tracks (Curt Sampson) Re: LED Traffic Lights are efficient (Dick Mills, Terrence Enger) Re: Silent Hybrid Nearly Causes Carbon Monoxide Poisoning (Walt Strickler) NDSS Program (Internet Society) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Fri, 8 Jan 2010 10:47:27 PST From: "Peter G. Neumann" Subject: NIST-certified USB Flash drives with hardware encryption cracked Certain USB drives using AES encryption have a major flaw that allows a way to bypass the login rules: "The SySS experts wrote a small tool for the active password entry program's RAM which always made sure that the appropriate string was sent to the drive, irrespective of the password entered and as a result gained immediate access to all the data on the drive." In essence, despite the use of AES 256-bit encryption, the password checker program always put out the same bitwise-identical POSITIVE response to a successful password check, which was trivially reproducible. [Source: The H Security, 4 Jan 2010; Thanks to John Curran; PGN-ed] http://www.h-online.com/security/news/item/NIST-certified-USB-Flash-drives-with-hardware-encryption-cracked-895308.html [Misleading title; make sure you understand what is `certified' and what that means (or doesn't mean) with respect to systems in the large. PGN] ------------------------------ Date: Thu, 7 Jan 2010 17:10:04 -0800 (PST) From: Chris J Brady Subject: Skype: the case of disappearing telephone numbers The latest version of Skype (partly owned by eBay) is causing major irritations amongst web designers and users. By default when downloaded and installed it also installs a small utility unbeknown to the user. This utility effectively reformats any telephone &/or fax. nos. on a web page including adding a little flag icon and also embeds a link behind these to link to Skype. Theoretically clicking on the telephone no. then initiates a Skype call to that no. Unfortunately there are some side effects. Web designers are especially upset that the reformating effectively destroys the look of a web page, especially if a web site has been designed to a corporate style when Skype then reformats parts of every page to suit itself. Secondly in many cases the telephone &/or fax nos. are simply deleted from the web page displayed never to be seen again. Even more irritating is that telephone nos. disappear when web-based emails are viewed such as when using Yahoo Mail and/or Google Mail. That is until a cure is implemented. And the cure is to remove the embedded utility - not easy. And/or remove Skype entirely. Both are reported to be effective. The risk of course is trusting Skype when the company (partly owned by eBay) has deliberately chosen to allow this feature to be installed by default without any user choice in the matter. ------------------------------ Date: Mon, 04 Jan 2010 19:31:53 -0800 From: Al Stangenberger Subject: Libel by Twitter? Interesting legal commentary on the problem of crafting a comment within Twitter's 140-character limit for messages. The forced brevity can cause the unwary to make statements but not to qualify them as opinion due to the maximum message length. http://writ.news.findlaw.com/hilden/20100104.html ------------------------------ Date: Wed, 30 Dec 2009 20:40:54 -0800 From: Paul Pomes DVM Subject: Risks of USB chargers for cell phones My wife recently purchased a no-name third-party USB charger for her Droid cell phone. When the included cable is connected to the USB port of her laptop, the phone charges normally albeit somewhat slowly. Connecting the cable to the included voltage-sensing wall transformer starts a menagerie of interesting effects: opening applications, creating garbled text messages, changing settings, etc. No doubt this is due to floating signal lines with induced voltages that is triggering this storm of activity. It takes little imagination, however, to visualize more sinister applications. A very small amount of logic, specific for each cell phone model the charger is marketed for, could be embedded inside the plastic transformer block. After a few minutes delay the phone could be probed for sensitive information and the results sent to an electronic dead-drop. The risk is a classic trade-off of security vs convenience. Having a single charger for our Kindles, cell phones, PDAs simplifies the number of ancillary chargers we need to tote around. Mixing the mission of power supply and data conduit opens a covert channel. Paul Pomes, DVM (formerly a network and computer security engineer until I got tired of meetings) http://www.FurryFriendsVet.com http://PaulPomes.livejournal.com http://www.facebook.com/Paul.Pomes ------------------------------ Date: Fri, 8 Jan 2010 12:14:15 -0500 From: Dave Hansen Subject: Y2K+10: look at the Hex A lot of the problems seem to share a common characteristic -- instead of 2010, the date appears to be 2016. Debora Weber-Wulff wrote: > 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. It's more interesting to look at both numbers in hexadecimal: 2009 is 0x7d9 while 2016 is 0x7e0. A little BCD math, perhaps? ------------------------------ Date: Fri, 8 Jan 2010 11:12:28 -0500 (Eastern Standard Time) From: Chris Smith Subject: Y2K+10: what's underlying? "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." I - and I suspect many others - would be interested in knowing the underlying error behind this problem. One the best reasons to read RISKS is to expand your personal list of bugs to watch out for. I can see at least one strong possibility. It relates to the point that chip cards - and especially contactless chip cards - are very low power, low resource, devices. The hardware and software developers optimize *everything*. Expressing the problem as though a two-digit year were in use, the problem was that 9 was followed by 16, not 10. But in hexadecimal, $09 was followed by $10 - but it should have been $0A. Chip cards could reasonably use BCD (binary coded decimal), where a decimal number is stored in a byte as two separate digits, one per nibble. At some point, if the chip provides a current year value, it would provide it as 10 (hex $10, binary 0001000). But if a terminal thinks this is a *binary* field, it will misinterpret it -- starting in the year 2010. Any conversion from 10 to 2010 would have been done by the terminal. It is also worth noting that card systems in general make heavy use of BCD. The numbers on your magnetic card stripe, for example, are all BCD. Note that this raises the possibility that the *terminal* is at fault for misunderstanding the data format, not the card. But it also makes clear - consistent with reports - that even if the card is the problem, the terminal can correct the difficulty with a customized conversion routine, as long as it can accurately identify which cards have the problem. Note that BCD is sufficiently common in small processors that the 6502 processors actually had a 'decimal mode', where adding $01 to $09 resulted in $10, and adding $01 to $99 both gave $00 and set the carry flag. ------------------------------ Date: Fri, 08 Jan 2010 09:56:19 +0100 From: Peter Houppermans Subject: Y2K+10: The problems with sticky tape (RISKS-25.89) The "German" credit card problem is interesting from a number of angles: * Disaster Recovery: imaging you're abroad and your cash becomes inaccessible, but this time not because your bank fails. At least the good news is that that's easier to solve, and a fallback was available. Uncomfortable idea when you're traveling. * Technology migration risk: I guess it's now properly publicly known that the so-called safe chip is easy to defeat by simply avoiding it. This presents an interesting issue with respect to card cloning as you actually do not need access the chip itself. Copy the magnetic strip and make sure any chip on the target card malfunctions (expect a surge in nail varnish sales). The fallback option has now reduced the level of trouble for the end user, but I suspect a surge in that method of old, magnetic strip cloning, is unavoidable. * Think before you report: my immediate reaction was "uh oh" when I saw the sticky tape reporting, because I knew what would happen next: tight (anti-fraud) mechanical tolerances in ATMs resulting in transfer of sticky tape from card to mechanism, thus gumming up the works (and possibly retaining the card in the process). Sure enough: in the evening those same sources reporting the "solution" were now labeling it a "problem" without the slightest hint of irony.. ------------------------------ Date: Fri, 8 Jan 2010 10:25:25 -0000 From: "Matthew Wilson" Subject: Weight of a Land Rover incorrectly input into UK VCA database It appears that the UK's Driver and Vehicle Licensing Agency - DVLA - have routinely been giving older series Land Rovers a revenue weight of 3499 kgs, which puts them in the commercial class 7 bracket of vehicle. The Land Rover (apart from some specialist version of the vehicle) should be a class 4. It seems this weight choice was done when the computer database was set up and this 'random' value chosen. Now that the garages where you submit your vehicle to gain a MOT certificate to prove it roadworthy have been computerised, entering the chassis number/VIN (vehicle identification number) of the vehicle causes the test to be refused as the incorrect weight retrieved from the database flags a class 7 test. The vast majority of MOT garages are only equipped for class 4 vehicles, not class 7. Lots of additional info about this here: http://www.glencoyne.co.uk/motclass.htm I think a classic case of garbage in garbage out... ------------------------------ Date: Fri, 8 Jan 2010 00:50:02 -0000 From: "Richard Pennington" Subject: Re: Eurostar RISKS (Thorn, RISKS-25.89) Here are a few comments on Anthony Thorn's piece about the Eurostar failures on 18 Dec 2009. Firstly, one of my colleagues traveled on the last Eurostar train to pass through the Channel Tunnel from France to England before the trains failed. He reports that his train was obviously losing power and finished the journey traveling very slowly. Secondly, I have seen no public report into what the difference was between the "winterisation" applied to the Eurostar trains this year (when there was a massive common-mode failure) and in the 15 previous years of reliable operation (in all sorts of weather conditions including a very cold spell in February 2009). Thirdly, I have seen no public report into what happened to the signaling system. In particular, why did the controllers keep sending more trains into a tunnel which was already blocked by the previous failed trains? [As a result, they ended up with five trains trapped in the tunnel, all with identical failures. There is one track in each direction, with crossovers for use in emergencies.] I can understand that a total electrical failure (which appears to have occurred in each of the five failed trains) would prevent communications between the trains and the controllers - although that in itself raises an obvious single point of failure - but what happened to the trackside signalling systems, and why did they not send a message back to the controllers? And how long did it take the controllers to realise that there were no trains coming out of the other end of the tunnel? ------------------------------ Date: Fri, 8 Jan 2010 19:57:03 +0900 From: Curt Sampson Subject: Leaves on Tracks (was Re: LED Traffic Lights are efficient... On Sun, 27 Dec 2009 05:38:43 -0500, Jerry Leichter writes: > Every fall [in the NY area], we get delays in mass transit because of wet > leaves on train tracks. I never recalled hearing of such problems years > back.... He goes on to say that this problem has been attributed to the change from friction braking to regenerative braking. I believe that this may not be entirely, or even substantially correct. The problem itself is not so very new to my knowledge: I clearly recall it being reported in the UK (on Thatcher-era passenger stock), in 1991, the first year that I lived there. Further, R. A. Wood's 1999 paper "Train Detection by Track Circuit: the Effect of the Wheel/Rail Interface" discusses leaves (among other track contaminants) and blames the issue on two quite different modernisation issues. The first is the switch from steam to diesel locomotion ("Leaves were rarely a problem in steam days, for the simple reason that flammable vegetation at the side of the track was incompatible with machines that ejected burning cinders into the air."--section 2) and better bogies ("The main factor appeared to be the greatly improved suspension systems of modern bogies. Instead of bouncing, scraping, and sliding around the track, the wheel on a modern bogie runs straight and true along the rails, with a significantly reduced scrubbing action between wheel and rail."--section 3). So there's the correction. Additionally, I must say, I do feel a little frisson when I think about a fire hazard mitigating another risk. Curt Sampson +81 90 7737 2974 ------------------------------ Date: Sun, 27 Dec 2009 09:47:25 -0500 From: Dick Mills Subject: Re: LED Traffic Lights are efficient (Johnson, 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? Likely predates RISKS, but this old fogey recalls the introduction of the 2 filament tail-light/brakelight bulb in common use for at least 50 years. This was introduced to address the problem mentioned here. At night, when visibility is lowest, and the tail lights would be on, the heat of the tail light would defrost the lens so the brakelights were more visible. Just as an aside - on LED lights - I saw an ad that said that LED brake lights were safer since they lit up more quickly, at least a tenth of a second. I poo-poo'd this until I thought a bit. 60 mph is 88 feet/second 1/10 second is 8.8 feet saving even half that much in a panic stop is quite significant ! P.M. Wexelblat PhD, Erst of the Dept. of Computer Science University of Massachusetts Lowell, One University Ave, Lowell, MA 01854 ------------------------------ Date: Fri, 08 Jan 2010 09:41:00 -0500 From: Terrence Enger Subject: Re: LED Traffic Lights are efficient (Seaman, RISKS-25.89) > LEDs are desirable because they inexpensive to operate due to their high efficiency. LEDs *are* highly efficient, but I suspect that desirability comes far more from the long lifetime. It is not much work to unscrew a bulb and screw in a new one, but getting into position to do that is not so easy. So, the cost of energy to melt the precipitation is not obviously a show-stopper for a simple-minded heater. We know from past experience that the power for one light is at least adequate. And the cost of installation can probably be brought into the same order of magnitude as the cost to ...um... change a light bulb. ------------------------------ Date: Fri 1 Jan 2010 07:34:44 -0700 From: waltstrickler@hotmail.com Subject: Re: Silent Hybrid Nearly Causes Carbon Monoxide Poisoning (R-25.88) So I have a (maybe obvious) question: Why would a car whose engine is running need synthetic engine noise? The letter to the editor even said that it was running at full throttle, but the author seems to have missed the irony. I suspect that this is not a risk of the hybrid being silent, but of the fact that the Prius is turned off by taking the RFID (Radio Frequency Identification Device) that enables it out of range, or by performing the unintuitive (and not usually necessary) act of pushing the START button for 3 seconds. In this case, the RFID was probably left in a purse, which was left in the car, and the car was most likely in battery-charging mode when left in the garage. The 4 hours mentioned in the letter seems like a long time to charge the batteries, but perhaps this one had been converted to a plugin hybrid with much larger battery capacity. ------------------------------ Date: Mon, 4 Jan 2010 14:07:25 -0500 (EST) From: Internet Society Subject: NDSS Program 17th Annual Network and Distributed System Security (NDSS) Symposium The Dana on Mission Bay, San Diego, California, 28 Feb -- 3 Mar 2010 New research on 24 topics to be presented The NDSS '10 program committee has selected 24 original research papers for presentation in San Diego. Topic areas include: * Distributed Systems and Networks * Web Security and Privacy * Intrusion Detection and Attack Analysis * Anonymity and Cryptographic Systems * Security Protocols and Policies * Languages and Systems Security * Malware * Spam A complete list and summaries of each paper can be found at: www.isoc.org/isoc/conferences/ndss/10/program.shtml Keynote by former White House counterterrorism and cyber security czar Richard A. Clarke. Special panel discussion on Ethics in Networking and Security Research. Registration Information: www.isoc.org/ndss10 Organized by the Internet Society ------------------------------ Date: Thu, 29 May 2008 07:53:46 -0900 From: RISKS-request@csl.sri.com 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@csl.sri.com 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@csl.sri.com or risks-unsubscribe@csl.sri.com 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 . => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => SUBMISSIONS: to risks@CSL.sri.com 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 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: for browsing, or .ps for printing ==> Special Offer to Join ACM for readers of the ACM RISKS Forum: ------------------------------ End of RISKS-FORUM Digest 25.90 ************************