Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
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]
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.
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
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
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?
"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.
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..
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...
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?
On Sun, 27 Dec 2009 05:38:43 -0500, Jerry Leichter <leichter@lrw.com> 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 <cjs@cynic.net> +81 90 7737 2974
> 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
> 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.
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.
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
Please report problems with the web pages to the maintainer