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…
John Markoff, Science Times, *The New York Times*, 15 Dec 2009 A superb article by John Markoff this morning pays a wonderful and well-deserved tribute to Jim Gray's notion of a "fourth paradigm" — that computing is fundamentally transforming the practice of science. (The first three paradigms are experimental, theoretical, and computational.) "In essence, computational power created computational science, which produced the overwhelming flow of data, which now requires a computing change. It is a positive feedback look in which the data stream becomes the data flood and sculptures a new computing landscape." I love the quote from John Wilbanks: ``I Have Seen the Paradigm Shift, and It Is Us'' (his chapter title). Please read Markoff's pithy article. I still read *The NYT* in hardcopy, and believe in supporting the future of real news, analysis, and thoughtful writing. Thus, I try not to exceed fair use guidelines in RISKS. However, you can find the article with minimal browsing. PGN
COFEE (Computer Online Forensic Evidence Extractor) has been distributed through Interpol only to law enforcement agencies for the past 2.5 years. COFEE consists of about 150 tools used to collect digital evidence at crime scenes. (``Microsoft has been pouring free COFEE to law enforcement officers since at least mid 2007.'') However, it has recently been accidently released more widely. Perhaps not surprisingly, a subverting program called Decaf has now been released that monitors Windows systems for the presence of COFEE, and automagically executes some countermeasures that effectively dilute the benefits of COFEE (but apparently without any nasty side-effects to the system). [Source: Dan Goodin, *The Register*, 14 Dec 2009; PGN-ed, with thanks to Jeremy Epstein for spotting this item.] http://www.theregister.co.uk/2009/12/14/microsoft_cofee_vs_decaf/ An excerpt from *The Register* article: ``We want to promote a healthy unrestricted free flow of internet traffic and show why law enforcement should not solely rely on Microsoft to automate their intelligent evidence finding,'' one of the two hackers behind Decaf told *The Register* in explaining the objective of the project.
In RISKS-25.86, under the subject "Massive New UK Internet Wiretapping Plan Announced," Lauren Weinstein <pfir@pfir.org> writes, > [Notes on a British ISP perpetrating a man-in-the-middle attack on their > customers.] > > Notably, the answer to these dilemmas is contained in a single word, which > you've seen me use many times before: *encrypt*! Unfortunately, this is just wrong. That single word is not the answer, and in fact is an even worse problem in disguise. We must be careful about giving out very dangerous advice. > In fact, a spokesman related to the new Virgin ISP spying project > notes that, "encryption of the data packet would defeat us." It will only do so until they get someone just a wee bit smarter to use attack methods that have been available in open source software for some time [1,2]. What they'll do is this: Alice (the user at this ISP) will attempt to connect to Bob (some file-sharing source). But of course, Mallory (the ISP) has control of every packet flowing between them, and can decide to drop them, forward them, and even change them. When Alice connects to "Bob" for the first time, she'll get a notice that Bob is using a self-signed certificate that she's never seen before, and would she like to accept it or not. She'll say yes, a little lock icon will appear, and she'll exchange sensitive material in the comfort that it's all being encrypted. And it is. Twice. Unfortunately, it was Mallory who generated and sent her "Bob's" certificate, set up his own encrypted connection to Bob (pretending to be Alice), and who is now proxying that connection. (There's a nice little picture of this at [3].) When Alice sends an encrypted packet to "Bob," Mallory decrypts it, examines the content, changes it as he wishes, re-encrypts it, and sends it on to the real Bob. In short, encryption without authentication is not only useless against an attacker who forwards your packets, but is in fact dangerous, because it looks as if you're safe when you're not. This is the very reason that recent versions of Firefox have made it much more difficult to accept self-signed certificates. Johnathan Nightingale, in [4], mentions that your ISP is not the only danger here; there are open source, point-and-click tools available[1] to attackers to subvert your router or other hosts on your own network to perform this same attack. It is ever more important, now that attackers are heading in on all sides, that we discourage as much as possible the use of encryption without authentication. Unfortunately, this is still widespread, even amongst those who you'd think would be reasonably savvy about such things. I know far too many industry professionals who would never think about using unencrypted telnet to connect to a remote system, but who happily run SSH clients with "StrictHostKeyChecking off" and blithely accept the credentials of any remote system for which they don't already have a public key. 1. http://ettercap.sourceforge.net/ 2. http://www.pburkholder.com/sysadmin/SSL-mitm/ 3. http://www.pburkholder.com/sysadmin/SSL-mitm/webmitm.jpg 4. http://blog.johnath.com/2008/08/05/ssl-question-corner/ Curt Sampson +81 90 7737 2974 http://www.starling-software.com
The computer risks to this story are peripheral, but it strikes me that it's a classic "category error" of the sort that leads to some of the medical, aviation, and GPS misadventures we have seen. [I suppose the computerized Ontario One Call registry is as close as it gets to being computer-related.] On November 18 2009, a work crew digging a trench for a natural gas line on Jackes Avenue discovered that they had broken through into the top of a Toronto Transit Commission (TTC) subway tunnel. Work was stopped, and the subway line — the city's busiest — was isolated at that point, with turnbacks splitting the line into two for a six hour period that included evening rush hour, until emergency structural repairs could be made. There were no injuries, but thousands of commuters had unplanned long walks or crowded shuttle bus rides. Permanent repairs are still ongoing, and work in progress can be seen from subway trains passing the spot. The fundamental problem appears to be that the crew thought they were working on a road, but they were actually digging their trench on a bridge. The subway line in question was opened in 1954, and originally this midtown section was in an open cut for several blocks, with sloped grassed sides, and with minor roads carried over the line on flat bridges with low railings. Over the subsequent decades, much of the open cut has been covered over right up to the bridge edges, in some cases with parks, and tennis courts, in others with various buildings including parking structures and high rise apartments. In the case of Jackes Avenue, the original distinctive railings have been removed, though on other streets one or both remain. While there are disagreements between the TTC and the construction company engaged by Enbridge, the gas distributor, to work on its pipes, it appears that the work crew followed accepted procedures for digging a trench on a road; they obtained a city permit for the dig, contacted Ontario One Call, the province-wide agency run by various utilities (gas, electrical, phone, etc.) to locate underground services, and cut both sides of a trench using a concrete saw. Evidently they were removing some of the sawed concrete at one end when they broke through, and realized they had a problem. The TTC is not a member of Ontario One Call, and it's not clear if large-scale objects like subway tunnels and bridges would be expected to be listed with such an agency. I have lived in this area for a long time, and saw the covering over of the subway through the years, and so it is inconceivable to me that anyone could not know there are bridges there. But to someone not familiar with the area, there are few visual clues that there's anything different about those bits of road; perhaps the absence of large trees nearby is the biggest. Even the characteristic low green railings, while iconic to me, would doubtless have no special meaning to others, and in any case are no longer there on Jackes Avenue.. Your favourite mapping website can show you aerial and street views of the bridge in question, and some of its neighbours. Rather than include ephemeral URLs, I'm giving nearby street addresses, which I imagine will last longer. There are also various news sites with maps and diagrams of the incident, with unknown web lifespans. * 38 Jackes Avenue, Toronto" (the site of the incident, no railing on either side) * 26 Woodlawn Avenue East, Toronto" (the next bridge south, with an original railing on the south side only, serving no obvious purpose) * 24 Summerhill Avenue, Toronto" (one further south, with original railings on both sides) * 20 Roxborough Street East, Toronto" (further south, and suddenly it's quite obvious this one is a bridge) Would you dig a hole in a road at any of these sites? Not that last one, surely. But any of the others? What would it take to change your world view, once you were thinking it was just another road, and that the locate call had come back all-clear? The sound of subway trains rumbling underneath? An unexpected layer of concrete under the paving? Breaking through and seeing a train...? [Enbridge seems to be entrenched in its endeavors. But the risks are seemingly ENdless, so I thought it might be interesting to include this item. PGN]
A friend is a Senior VP of risk management at Citi. I e-mailed to tell him I wouldn't click on the link in this card, especially given the amount of spear phishing that targets bank (especially Citi Bank) customers. He replied that it was the marketing folks that came up with the idea (and he joked that "you security folks" are so touchy). I was glad that he at least knew about it, and that it wasn't a hook!
IEEE sent out something similar for their annual salary survey. I pointed out the same thing - they said that the outsourced marketing company they use required unique URLs for each person. Amazing how one side of an organization doesn't know what the other side is doing....
Steve Loughran entertainingly takes apart a BMW ad for suggesting that its GPS will guide the user home, noting issues concerning satellite coverage, map quality, etc. One difference between auto makers' built-in GPS navigators and the ones available from TomTom, Garmin, Magellan, etc., is that at least some auto makers don't rely solely on GPS satellites for their navigation systems, but incorporate dead reckoning as well. I don't know whether BMW's nav systems do this, but my VW 2005 Touareg's nav system uses dead reckoning in addition to GPS. It can correctly track my car's location to the lowest level of my office building's underground garage and follow it through underwater tunnels. It never gets thrown off in urban canyons or in heavily tree-shaded rural areas where GPS reception gets a bit dicey. So for a carmaker's built-in navigation system, the actual location of the car shouldn't be a serious issue, if the carmaker has taken advantage of the data available in the in-car electronic environment. Maps, on the other hand, are a problem. Many mapping data suppliers have included intentional errors, usually of a harmless nature, that give their products "creativity" and thus provide copyright protection. Sometimes, these errors can be serious, however, if the driver does not exhibit appropriate skepticism. Near my home there is a road that dead-ends at a homeowner's driveway. Some online and GPS maps, however, show the road continuing through the driveway and right past the home through a forest to a public street a few hundred feet away. If somebody decided to rely on that map late at night, a serious accident could occur. Likewise, in another nearby location some online and GPS maps show a road continuing through between two other roads when in reality that lot contains only a footpath; the road restarts with the same name on the other side. I've also run into a situation where my car's nav system told me that a footbridge was a road. And, of course, even with updated discs no nav system is going to have totally current mapping data as roads expand and reroute. I just drove between DC and Philly, and the road construction on I-95 left even the August 2009 update disc behind. The key to the BMW ad is that the GPS will "guide" you home. It will not unerringly direct you. "Guidance" inherently needs to be evaluated as to whether it is reasonable and correct. I don't think Steve would want nav systems to provide all of the disclaimers he amusingly asserts with respect to the ads, at least on an ongoing basis. It would be hard to pay enough attention to pick the wheat from the chaff if the nav system were to say, "Unless you are in Scotland or the Lake District or Alaska or woodlands or canyonlands or an urban area, or you don't have the latest mapping disc, or any number of situations where this system's guidance is questionable, in 400 meters, bear right," . . . and thereafter, "Take next right turn, unless you meet the criteria stated previously, in which case you are on your own."
"What surprises me is that [Skyhook Wireless doesn't] appear to have a fallback to IP geolocation." says Charles Wood. I expect that that is because the people at Skyhook Wireless read RISKS. I pointed out the problems of IP address geolocation five years ago (almost to the day), in RISKS-23.63, mentioning then that they are well known, but less well known than they should be. To recap: the data are either coarse-grained, or subject to IP address churn; and in either case they eventually become dated to the point of uselessness. To emphasize these points, I report the following: I today ran the DNS query against "clientcontinent.cr.yp.to.", that I mentioned in RISKS-23.63, from a computer in Europe. Dan Bernstein's database, still based upon the 2001 IANA IPv4 address space allocation list, reports that the machine is in North America. "The example in the teleportation post would very easily have been solved by use of IP geolocation", says Charles Wood. No, no, and no again. I strongly emphasize that IP addresses are *not* a reliable mechanism for determining the geographical location of a machine. Posit that I, with the computer in Europe mentioned above, were in the same situation as M. Wood of having no Skyhook Wireless mapping information available. Had Skyhook Wireless fallen back to IP address geolocation using (say) the same source data as Dan Bernstein, Skyhook Wireless would have placed me on entirely the wrong continent. Even if its data were more recent, the degree to which Bernstein's database is now dated, and was dated even back at the time of RISKS-23.63, shows how quickly the data quality of *any* such IP address geolocation dataset erodes over time. There's a fairly simple point here, and yet it's one that I regularly observe people missing again and again. IP addresses, postcodes, and the like, were not invented to directly encode geographical locations. That is, simply, not their purpose. IP addresses are used for routing network traffic around Internet, and postcodes are used by postal services to route mail through a postal system. They are designed for *those* purposes. The "locations" that they do encode are locations in the topographies of Internet network connections and of postal system sorting and delivery systems, which are often *very* different to actual geography. Any correspondence that they might have to actual geographical locations should be considered fortunate, and unreliable. Don't expect postcodes to always work in navigation systems. Don't expect your computer's IP address(es) to identify what country, or even what continent, you are in. They weren't designed for that purpose, aren't maintained and updated for that purpose, and often produce highly erroneous results when (mis-)used for that purpose. So one should not, really, be surprised at Skyhook Wireless avoiding this well-known (but still, five years on, not well-known enough, it seems) error in this instance.
> Executive summary: Android is a screwed, hard-coded, non-portable abomination. I'm not sure the Executive summary cited in RISKS-25.85 is justifiable: 1. Android is open source although Google do add closed source applications. 2. It has been ported to many devices and even PCs, laptops and netbooks. 3. In order to keep boot times low and software base minimal, it is expected that the OS be customised for the target device - it is not designed as a general purpose OS in the same way that, say, Ubuntu is. It is an embedded OS. 4. People are free to port 'normal' Linux to their device if they choose to. 5. Design choices about what aspects of the Linux kernel or GNU libraries are implemented is a design choice. I suspect that the designers wanted to reduce the attack surface. I think the biggest issue is the lack of open source Google Apps, which includes MarketPlace. The key point is that Android OS is Open Source - do with it as you please.
JC Cantrell wrote: >Well, that is why I buy a manual transmission. When that clutch is in, I >KNOW I can stop the car... Well, at least so long as your clutch is a physical device, and not a "fly by wire". I don't know if such things exist, but I can think of many reasons why a fly-by-wire clutch would be a good thing - maybe software could reduce the opportunities for stalling, or switching into the wrong gear, or burning it out by riding the clutch. And once that happens, then how long before the fly-by-wire clutch decides you really shouldn't be going into neutral at highway speeds, so it refuses to engage... and silently stops the fail-safe mechanism Cantrell describes. --Jeremy
On Mon, 9 Nov 2009 12:41:33 -0800 (PST) JC Cantrell <jccant@pacbell.net> wrote: > Well, that is why I buy a manual transmission. When that clutch is in, I > KNOW I can stop the car... This is getting away from the computing RISKS, but I have had clutch failure on manual vehicles. This failure mode leaves the controls unable to disengage the clutch, which means the engine cannot be decoupled from the transmission. I use generic terms because one such incident was on a motorcycle with a hydraulic clutch. I had a cooling system fault, and was approaching boil-over in a traffic jam. Deciding the hard shoulder was better than a full breakdown in the traffic lane, I began my maneuver. Only to find that the clutch lever had no resistance--the hydraulic fluid was too hot, and it had boiled. (The clutch fluid was nearly due for changing at the time, and contaminants in it were not helping the situation.) Fortunately, I've practiced shifting gears without the clutch, and was able to gear down enough to get off the road. Getting into neutral wasn't much more difficult. I even used the kill switch to stop the motor, even though there was nothing wrong with the ignition key circuit; I was well into emergency procedures, and forgetting "normal" operating modes. I've also had cable clutches fail to disengage due to thermal expansion. Still, with a true manual, you can always get to neutral with the shift lever, even without a clutch. It's the more expensive stuff, like those "flappy paddle" boxes, that adds automatic gearbox failure modes (in the control system and actuators) to the existing failure modes of a manual box (broken shift forks, dogs, splines, and so on) and clutch (hydraulic or spring failure).
Please report problems with the web pages to the maintainer