The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 25 Issue 87

Tuesday 15 December 2009

Contents

A Deluge of Data Shapes a New Era in Computing
John Markoff via PGN
Forensics, COFEE, and Decaf
PGN
Encryption Considered Harmful
Curt Sampson
Toronto subway line closed for 6 hours after tunnel pierced by gas line crew
Tony Harminc
Happy Holidays?
Zach Tudor
Jeremy Epstein
Re: The Joy of satellite navigation failures
Michael D. Sullivan
Re: Teleportation via Skyhook
Jonathan de Boyne Pollard
Re: Android Mythbusters
Phil Colbourn
Re: Toyota uncontrolled acceleration
Jeremy Epstein
Graham Reed
Info on RISKS (comp.risks)

A Deluge of Data Shapes a New Era in Computing

"Peter G. Neumann" <neumann@csl.sri.com>
Tue, 15 Dec 2009 7:17:12 PST

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


Forensics, COFEE, and Decaf

"Peter G. Neumann" <neumann@csl.sri.com>
Tue, 15 Dec 2009 6:41:52 PST

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.


Encryption Considered Harmful

Curt Sampson <cjs@cynic.net>
Tue, 15 Dec 2009 13:05:08 +0900

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


Toronto subway line closed for 6 hours after tunnel pierced by gas line crew

Tony Harminc <tony@harminc.net>
Mon, 14 Dec 2009 14:18:40 -0500
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]


Happy Holidays?

Zach Tudor <zachary.tudor@sri.com>
Tue, 15 Dec 2009 12:47:50 -0500

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!


Happy Holidays?

Jeremy Epstein <jeremy.epstein@sri.com>
Tue, 15 Dec 2009 13:09:47 -0500

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....


Re: The Joy of satellite navigation failures (Loughran, R-25.85)

"Michael D. Sullivan" <mds@camsul.com>
Sun, 29 Nov 2009 01:00:24 -0500

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."


Re: Teleportation via Skyhook (Wood, RISKS 25.85)

Jonathan de Boyne Pollard <J.deBoynePollard@Tesco.NET>
Wed, 02 Dec 2009 05:33:55 +0000

"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.


Re: Android Mythbusters (RISKS-25.85)

phil colbourn <philcolbourn@gmail.com>
Sun, 29 Nov 2009 16:50:46 +1100

> 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.


Re: Toyota uncontrolled acceleration (Lesher, RISKS-25.82)

Jeremy Epstein <jeremy.j.epstein@gmail.com>
Sat, 28 Nov 2009 20:38:09 -0500

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


Re: Toyota uncontrolled acceleration (Cantrell, RISKS-25.85)

Graham Reed <greed@pobox.com>
Sat, 28 Nov 2009 18:47:19 -0500

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

Top