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 32

Thursday 11 September 2008

Contents

Google revives 6-year-old news story, sends United shared down 75%
Steven J Klein
Drew Dean
Scott Nicol
How Steve Jobs' obit got published
Philip Elmer-DeWitt via Monty Solomon
Internet Traffic Begins to Bypass the U.S.
John Markoff via Monty Solomon
Global Trail of an Online Crime Ring
Brad Stone via Monty Solomon
Automated Bill Payments Are a Cinch: Not So Fast
Ron Lieber via Monty Solomon
Hackers prepare supermarket sweep
Gabe Goldberg
Antivirus software in critical systems?
Erling Kristiansen
Re: States throw out costly electronic voting machines
Peter Houppermans
Jim Haynes
Risks of GPS Devices that we had Not Previously Heard Of
Mark Brader
Over-reliance on automated real estate valuation
Jeremy Epstein
Re: Control-Z vs. Bourne-Again SHell
David Chau
Re: Weird Clock Issue - a single bit error
Chris Smith
Mark Lutton
Amos Shapir
Re: Bruce Schneier on Airport Photo ID Checks
Andy Piper
Amos Shapir
Re: Risks of better security and "smarter" users
Dag-Erling Smørgrav
Ron Garret
Info on RISKS (comp.risks)

Google revives 6-year-old news story, sends United shared down 75%

<Steven J Klein <steveklein@mac.com>>
Wed, 10 Sep 2008 16:24:28 -0400

An unfortunate series of events:

1. In 2002, UAL (parent company of United Airlines) filed for bankruptcy, an
   event covered at the time by the Chicago Tribune.

2. The story was in the database of the Sun Sentinel, a Florida newspaper
   owned by the same company..

3. This last Saturday, lots of people (for reasons unknown) viewed the story
   on the Sun Sentinel's website.

4. Enough people viewed the story that it appeared in their list of "Popular
   Stories: Business."  That list is automatically generated based on
   page-views.

5. Google's News crawler saw the link in the "Popular Stories" list.  The
   current date, September 8, 2008, appeared on the web page with the story.
   The story itself carried no date.

6. Users  of  Google's  "email  alert"  service who  had  requested  stories
   mentioning  UAL were  sent links  to the  story.  Also,  anyone searching
   Google News for "UAL" or "United  Airlines" would have seen a link to the
   story.

7. The UAL story was circulated by Income Securities Advisors Inc., a stock
   research firm that publishes reports on the Bloomberg L.P.,
   financial-news service.

8. On Monday, September 8, at approximately 10:45AM, a headline from the
   report flashed across Bloomberg screens.

9. In the next 15 minutes, UAL shares in UAL dropped from almost
   $12.50/share to just $3, before trading was halted.  At least one block
   of 100 shares traded at 1 cent per share, though that trade was later
   voided.

Eventually UAL put out a press release clarifying that the story was almost
6 years old, and that they were not in bankruptcy.  Later that day the stock
(mostly) recovered to over $10/share.

This could be a very clever method of market manipulation.  If spammers sent
out millions of messages with links to the story, and just a small fraction
of recipients clicked the link, the story could easily move to the "popular
stories" list.  Or perhaps hackers controlling botnets just directed the
computers they control to send a request to the server to load the story.

Among the risks I can spot (no doubt I'm missing some):

A. The story was undated, making it appear current.  Possible solution: The
   automated system that adds stories to the database could include the date
   the story was added to the database.

B. The story was automatically spread by lots of systems doing exactly what
   they're supposed to do.

C. Neither Income Securities Advisors nor Bloomberg have humans fact-check
   these automated stories.

The story was widely covered.  I learned about it here:
http://online.wsj.com/article/SB122100794359017593.html

Steven J Klein, Your Mac & PC Expert (248) YOUR-MAC or (248) 968-7622


Google revives 6-year-old news story, sends United shared down 75%

<Drew Dean <ddean@csl.sri.com>>
Wed, 10 Sep 2008 23:09:56 -0700

There are (at least) two interesting points here:

(1) The current mystery is why this article became "popular" in the first
place?  How many HTTP requests did that take?  Are the User-Agent: headers
identical (in which case one should suspect a botnet) or not (which does not
rule out a botnet, of course)?  How are the IP addresses of requesters
distributed?  What time interval did the requests arrive in?

(2) What we really have here is a failure of composition: Google didn't see
a date on the article, so picked up the date on the web site's front page --
something that the web site author didn't intend to imply the date of
content linked to from the front page.  Oops.  Both parties did a reasonable
thing, but the composition turned out to be completely unreasonable.


Google revives 6-year-old news story, sends United shared down 75%

<"Scott Nicol" <scott.nicol@gmail.com>>
Wed, 10 Sep 2008 13:51:55 -0400

Tribune, Bloomberg and Google unite to clobber United

A nice summary of the events, followed by Google's and Tribune's take on
what happened.

http://www.washingtonpost.com/wp-dyn/content/article/2008/09/08/AR2008090803063.html?hpid=moreheadlines

http://googlenewsblog.blogspot.com/2008/09/update-on-united-airlines-story.html

http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/09-09-2008/0004882072&EDATE=


How Steve Jobs' obit got published (Philip Elmer-DeWitt's blog)

<Monty Solomon <monty@roscom.com>>
Fri, 29 Aug 2008 13:50:06 -0400

Philip Elmer-DeWitt, How Steve Jobs' obit got published, 28 Aug 2008

The first rule of publishing is that anything that can go wrong, will go
wrong. (A corollary favored at *Time Magazine*, where I labored for nearly
three decades, is that all copy is guilty until proved otherwise.)

None of this excuses, but it does help explain, how Bloomberg News managed
to publish an obituary on Wednesday afternoon of Apple (AAPL) CEO Steve
Jobs, who is still quite alive.

Advance work on famous figures' obits is nothing new, and given Jobs'
well-publicized brush with pancreatic cancer four years ago and recent
concerns about his weight loss, it's understandable that Bloomberg might
choose this moment to update its piece on Jobs, although the version that
got published contains no details about his health that weren't already in
the public record.

According to a Bloomberg spokesperson, however, it was a routine update of
the kind regularly performed by the obit department. ...

http://apple20.blogs.fortune.cnn.com/2008/08/28/how-steve-jobs-obit-got-published/

  [Boomberg or Bustberg?  PGN]


Internet Traffic Begins to Bypass the U.S. (John Markoff)

<Monty Solomon <monty@roscom.com>>
Sat, 30 Aug 2008 01:05:33 -0400

[Source: John Markoff, *The New York Times*, 30 Aug 2008]

The era of the American Internet is ending.  Invented by American computer
scientists during the 1970s, the Internet has been embraced around the
globe. During the network's first three decades, most Internet traffic
flowed through the United States. In many cases, data sent between two
locations within a given country also passed through the United States.

Engineers who help run the Internet said that it would have been impossible
for the United States to maintain its hegemony over the long run because of
the very nature of the Internet; it has no central point of control.

And now, the balance of power is shifting. Data is increasingly flowing
around the United States, which may have intelligence - and conceivably
military - consequences. ...
http://www.nytimes.com/2008/08/30/business/30pipes.html?partner=rssuserland&emc=rss&pagewanted=all


Global Trail of an Online Crime Ring (Brad Stone)

<Monty Solomon <monty@roscom.com>>
Sun, 31 Aug 2008 10:33:32 -0400

Brad Stone, Global Trail of an Online Crime Ring, *The New York Times*,
12 Aug 2008

As an international ring of thieves plundered the credit card numbers of
millions of Americans, investigators struggled to figure out who was
orchestrating the crimes in the United States.

When prosecutors unveiled indictments last week, they made a stunning
admission: the culprit was, they said, their very own informant.

Albert Gonzalez, 27, appeared to be a reformed hacker. To avoid prison time
after being arrested in 2003, he had been helping federal agents identify
his former cohorts in the online underworld where credit and debit card
numbers are stolen, bought and sold.

But on the sly, federal officials now say, Mr. Gonzalez was connecting with
those same cohorts and continuing to ply his trade, using online pseudonyms
- including "soupnazi" - that would be his undoing. As they tell it,
Mr. Gonzalez had a central role in a loosely organized online crime
syndicate that obtained tens of millions of credit and debit card numbers
from nine of the biggest retailers in the United States.

The indictments last week of 11 people involved in the group give a
remarkably comprehensive picture of how the Internet is enabling new kinds
of financial crimes on a vast international scale.

In interviews over the last few days, investigators detailed how they had
tracked Mr. Gonzalez and other members of a ring that extended from Ukraine,
where a key figure bought and sold stolen numbers over the Internet, to
Estonia, where a hacker infiltrated the servers of a Dallas-based restaurant
chain.

The criminals stored much of their data on computer servers in Latvia and
Ukraine, and purchased blank debit and credit cards from confederates in
China, which they imprinted with some of the stolen numbers for use in cash
machines, investigators say. ...

http://www.nytimes.com/2008/08/12/technology/12theft.html?partner=rssuserland&emc=rss&pagewanted=all


Automated Bill Payments Are a Cinch: Not So Fast (Ron Lieber)

<Monty Solomon <monty@roscom.com>>
Sat, 30 Aug 2008 01:07:15 -0400

[Source: Ron Lieber, YOUR MONEY: Automated Bill Payments Are a Cinch (Not So
Fast), *The New York Times*, 30 Aug 2008]

A few months ago, in my first column for this newspaper, I extolled the
virtues of automated bill payments: Set them up once, let your utilities,
phone and credit card companies pull what you owe from your bank account
each month and never sit through the drudgery of a bill-paying session
again.

And boy, did you let me have it. I heard from a number of readers who
thought I was out of my mind for suggesting that they send money out
automatically each month or give billers unfettered access to their credit
cards and bank accounts. Horror stories poured in, as well as several
specific questions and concerns.

So this week, we'll look at five reasons that people are wary of automating
their financial lives this way. But first let's back up and define precisely
what we're talking about.

Until the 1990s, most of us were stuck writing a whole bunch of checks each
month to pay our various bills. Then came the early Web-based bill payment
systems, where we'd go to a bank or biller's Web site and push a few buttons
to move money to the right places.

Only more recently, however, has it become possible to pay each bill every
month without lifting a finger. There are three basic ways to do this. You
can give each biller permission to pull the full amount from your bank
account. You can use the online bill system at your bank to push payments
out automatically each month. Or you can charge every bill to your credit
card and give only that card company permission to pull money from your bank
account when the credit card bill is due.

Each of these methods has its potential shortcomings, which will become
clear as we march through the hiccups that can occur when automating your
payments. ...

http://www.nytimes.com/2008/08/30/business/yourmoney/30money.html?partner=rssuserland&emc=rss&pagewanted=all


Hackers prepare supermarket sweep

<Gabe Goldberg <gabe@gabegold.com>>
Fri, 29 Aug 2008 06:26:14 -0400

Self-checkout systems in UK supermarkets are being targeted by hi-tech
criminals with stolen credit card details.  A BBC investigation has
unearthed a plan hatching online to loot US bank accounts via the checkout
systems.  Fake credit cards loaded with details from the accounts will be
used to get cash or buy high value goods.

The supermarkets targeted said there was little chance the fraudsters would
make significant gains with their plan.  With the help of computer security
experts the BBC found a discussion on a card fraud website in which hi-tech
thieves debated the best way to strip money from the US accounts.

http://news.bbc.co.uk/2/hi/technology/7584258.stm


Antivirus software in critical systems? (Re: jared, RISKS-25.29)

<Erling Kristiansen <erling.kristiansen@xs4all.nl>>
Wed, 03 Sep 2008 19:00:56 +0200

> [...There should  be no need for anti-virus software in a
> well-designed voting system.  PGN]

This is exactly a point I have been trying to make in several discussions
about critical systems for satellite telemetry and telecommanding:

If you think you need anti-virus software in a (safety) critical system,
there is something wrong with your design.  Such systems, and many other
safety-critical systems, should not contain

 * known vectors for viruses and other malware
 * known targets for such malware

Said differently, any data entering the system should be in a format YOU
define, and should have no accommodations for importing executable code.
And there should be no software in the system that will attempt to execute
any imported files.

So, no e-mail, no web servers or clients, no office packages, etc.

Actually, if the system has to undergo some kind of certification, I wonder
whether anti-virus software would be certifiable. Its behavior is, after
all, dependent on virus definition files updated regularly, and originating
from uncertified sources. Anti-virus scanners do have false positives (I
have seen at least one), so they may accidentally flag legitimate data as
malicious, and may endanger the proper operation of the system.

The reaction I mostly get is something like : You might be right, but let's
keep it just in case...  Which means they didn't get the point.


Re: States throw out costly electronic voting machines (RISKS-25.30)

<Peter Houppermans <peter@houppermans.com>>
Fri, 29 Aug 2008 10:56:24 +0200

Hmm, a lack of creativity here, methinks.

Innocent question: no chance of supplying a few to researchers to see if an
acceptable alternative can be developed?  If a company has the choice
between
 a. flogging dead stock
 b. trying to make something acceptable of the remnants (i.e. get at
    least a return on the junk) by developing a new approach that can be
    audited, is open and can be proven to be safe (assuming that such is
    possible)

... wouldn't that be an excellent argument to supply a few systems to
researchers for better, open developments?  I refuse to accept that such
systems are completely useless.  Maybe sponsoring of an open, auditable
project would be a better investment of government and corporate funds than
parking the lot forever or scrapping it, and even the Company Formerly Know
As Diebold (we know who you were) could then at least retain some market
value.

Or is that a far too sensible idea?


Re: States throw out costly electronic voting machines (RISKS-25.30)

<Jim Haynes <jhhaynes@earthlink.net>>
Fri, 29 Aug 2008 17:05:41 -0500 (CDT)

It seems that what's needed here is for one of these jurisdictions to make
some of the machines available to some public-spirited open source people,
who could reverse engineer the thing and then write open source software
that would make them perform correctly.


Risks of GPS Devices that we had Not Previously Heard Of

<msb@vex.net (Mark Brader)>
Fri, 29 Aug 2008 17:11:42 -0400 (EDT)

The instructions for a certain GPS device are excerpted in the October
issue of Consumer Reports:

  When you are directed to press a key, you should press and quickly release
  the key.  (You may need to be held down for a period of time to start a
  secondary function, when the instructions tell you to do so.)

Mark Brader, Toronto, msb@vex.net | "Fast, cheap, good: choose any two."

  [If you are held down long enough, you might have been a martyr with your
  Heldenleben (Heldownleben?).  PGN]


Over-reliance on automated real estate valuation

<Jeremy Epstein <jeremy.j.epstein@gmail.com>>
Sat, 30 Aug 2008 16:55:10 -0400

Background: most of the major lenders in the US are in deep financial
trouble, and are trying to reduce their risks.  One of the ways they're
doing that is to cut back on HELOCs (Home Equity Line of Credit, aka "second
mortgages") - telling existing customers that even though they have a loan
that says they're allowed to draw against the equity in their house, the
homeowner is no longer allowed to draw money out because (the lenders claim)
the value of the house is no longer enough to support the loan amount.  This
is being done in a blanket fashion - hundreds of thousands of people are
getting these letters, based on generalized trends, not individual
assessments.

My situation is similar to that of hundreds of thousands of other people,
but I'm being bitten by the Automated Valuation Method (AVM) used by
Homecomings Financial.  Basically, they have a secret formula that gives a
"value" to a house - and if you disagree with their conclusion, you have to
pay for an appraisal to challenge it.  In my case, I claim the value of the
house is about $X, they say it's between 39% and 51% of $X (the most recent
sale in my neighborhood was 1.1X, so I'm definitely in the right
neighborhood).  But because "the answer came from the computer", it's nearly
impossible to fight - the ability of the paper-pushers to look beyond the
computer has been taken away.

I've recently been listening to some old Isaac Asimov Robot stories, where
he talks about "the positronic machines" which make all of the financial
decisions, including adjusting production, based on gathering every possible
data point and even accounting for human desires to ignore the machines'
instructions.  At some point, the humans in the story become impossible of
operating without the Machines, and no longer even understand how the
Machines make their decisions.  Dealing with Homecomings makes me think that
Asimov's prediction has already come true, at least in some domains!


Re: Control-Z vs. Bourne-Again SHell (jidanni, RISKS-25.31)

<David Chau <davidchau@figmentsrus.com>>
Thu, 11 Sep 2008 00:10:37 -0400

> $ sleep 55; launch_rocket
> The problem is if one discovers a missing O-ring etc., then a Control-C
> interrupt will not cancel the whole launch ... Next time use an &&
> operator instead of a ;.

Unfortunately, && doesn't work so well either if one needs to temporarily
put the launch on hold, but not abort it altogether:

   $ sleep 55 && launch_rocket
   <Control-Z>
   [1]+  Stopped  sleep 55
   $ fg
... Hey, how come my rocket's still sitting there?


Re: Weird Clock Issue - a single bit error (RISKS-25.30)

<Chris Smith <smith@vex.net>>
Mon, 1 Sep 2008 21:02:19 -0400 (Eastern Daylight Time)

Steven Greenwald's radio synced clock error is not so weird once you
understand more pieces of the puzzle.

  http://tf.nist.gov/timefreq/stations/wwvbtimecode.htm

If you check the above site for the time code format used by WWVB, you will
get the information you need to figure out the problem.

The time code format uses a "day of the year" system, where days are counted
from 1 to 365 during the regular year. August 18th, 2008 (a leap year - days
will count to 366) is day 231. September 27th is day 271.

The difference is 40 days, AND both days are in the same "100", and under 80
-- one date is between 00 and 39 and the other is between 40 and 79. Because
WWVB uses a BCD representation, such a pattern means that the error
corresponds to a single bit error.

Normally, clocks will try some form of validation on the received data to
prevent problems like this. They might try to receive several minutes worth
of data and see if the results are consistent. If you read the spec
carefully, you will see that this is necessary because there are no error
detection capabilities in the format.

Although this may seem like an oversight when you are used to
internetworking protocols, it's much more common in the industrial design
space, where designers may have a final budget of only half a dollar for all
of the electronics in such a clock.

It is certainly possible that your location (in Miami, FL - not close to
Boulder, CO) and the storm create conditions sufficient to consistently have
your clock read wrong by one bit. I expect that by this time, your clock is
back to normal.

  [Also noted by F. Barry Mulligan.  PGN]


Re: Weird Clock Issue (Greenwald RISKS-25.30)

<Mark Lutton <mlutton@acquiremedia.com>>
Fri, 29 Aug 2008 11:25:58 -0400

This happens frequently.  The signal is transmitted by extremely-low-
frequency radio, and if you are far from the nearest transmitter the signal
can be faint or erratic.  There is just barely enough bandwidth in the
signal to send the time as a series of bits with no error correction and no
redundancy.  I've seen the wrong time and date on my own atomic clock.

You should use a quartz clock (or a plug-in electric clock if your 60Hz
house current is dependable enough) as your primary reference and set it
once a day from the atomic clock but only if the time shown on the atomic
clock is reasonable.  Under no circumstances should any automated process be
controlled directly by a radio atomic clock.


Re: Weird Clock Issue (Greenwald, RISKS-25.30)

<Amos Shapir <amos083@hotmail.com>>
Tue, 2 Sep 2008 18:08:23 +0300

This very subject had been discussed in RISKS-25.08; I quote my post
(under the subject "Risks of Leap Years and Dumb Digital Watches",
http://catless.ncl.ac.uk/Risks/25.08.html#subj14), about a similar device by
LaCrosse:

  (...) It sets itself by listening to a radio time signal, so theoretically
  it should never have to be set at all, but every now and then it glitches
  and displays a wrong time, date or year; the difference is always a power
  of 2 in one of the digits, which looks like it's getting the data in some
  sort of BCD format, without any checksum or sanity check (which is not
  news on RISKS).  I wonder how many critical installations are using the
  same chip.

  [What goes around comes around.  That seems to be particularly true of
  nondigital clocks -- although not always correctly.  PGN]


Re: Bruce Schneier on Airport Photo ID Checks (RISKS-25.30)

<Andy Piper <andy@xemacs.org>>
Mon, 01 Sep 2008 13:53:40 +0100

The method described for subverting online checkin procedures must be
airport / carrier / destination dependent to a certain extent. I usually
checkin online and the printed boarding pass invariably carries a barcode
that is scanned at security. A quick peek at the screen appears to show my
checkin information, so only a very lax official would miss differing
names.  This happens at least at SFO and LHR.

  [This is apparently a checkin-and-the-egg problem.  I don't want to egg
  Andy on, but the boarding pass is usually scanned by the airline folks as
  you board the plane, not by security.  The TSA security folks merely check
  that the name on the ID matches the name on the boarding pass.  And that
  is the vulnerability that Bruce notes.  Perhaps a computer program might
  later note a name mismatch when/if the name is linked by the airline to
  the barcode for the actual flight manifest, but the airline employee
  typically does not do this match -- not even at SFO.  They typically just
  scan the barcode and reach for the next boarding pass to keep people
  moving.  PGN]


Re: Bruce Schneier on Airport Photo ID Checks (RISKS-25.30)

<Amos Shapir <amos083@hotmail.com>>
Sun, 31 Aug 2008 17:41:20 +0300

The newly formed U.S. TSA has a serious problem: they have to supply
Security, but they have no idea how (and it seems that they are unaware that
nobody else does, either).  But they do know that Security causes
Harassment, and they do know how to do Harassment.  So the obvious logic is,
the more Harassment they'd do, the more Security will be produced. QED


Re: Risks of better security and "smarter" users (Garret, RISKS-25.30)

<=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>>
Thu, 11 Sep 2008 09:48:42 +0200

Ron Garret <ron@flownet.com> writes:

> 1. The web site used a secure authentication scheme that behaves almost
>    identically to a less secure scheme
>
> 2. I am familiar with the more common design of secure sites [...]

Are you?  Then surely, you're aware that the common form-based login method
*also* sends your password in the clear?  The HTTP "digest" method is the
only purely HTTP / HTML authentication method that doesn't.

I assume that you are also aware that this is all moot if the web site makes
proper use of SSL.


Re: Risks of better security and "smarter" users (Dag-Erling)

<Ron Garret <ron@flownet.com>>
Thu, 11 Sep 2008 08:47:23 -0700

> Are you?  Then surely, you're aware that the common form-based login
> method *also* sends your password in the clear?

Yes.  That is why sites use HTTPS, and users are trained to look for little
padlock icons.

> The HTTP "digest" method is the only purely HTTP / HTML authentication
> method that doesn't.

Yes.  Notwithstanding, it is hardly ever used, and I think my experience may
be one reason why.

> I assume that you are also aware that this is all moot if the web site
> makes proper use of SSL.

That depends on your definition of "proper use."

But yes, I am aware of all this, and I assumed that the article's readers
would be as well, so I left out some details in the interest of parsimony.
Perhaps I should not have.

The user experience that surprised me was the following:

1. Restart my browser.  Clear the cookie cache.

2. Go to the web site in question.  Navigate to the page with the LOGIN
link.  This page was not secure.

3. Click on the LOGIN link, expecting to be taken to a secure page with a
form to enter my credentials.  I wasn't.  Instead I was taken directly to my
account information.  This page was secure, but since I was not aware that
my browser was silently accessing my keychain it appeared that I had just
logged in without providing any credentials.  The fact that the process
started on an insecure page and ended on a secure one didn't seem relevant.

Please report problems with the web pages to the maintainer

Top