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 23 Issue 88

Tuesday 31 May 2005


Landing gear problem due to apparent computer glitch
Steven M. Bellovin
The ChoicePointSyndrome
Robert Ellis Smith
A bank you might not want to have Wachovia
Hyperthreading vulnerability
Olin Sibert
MarketScore exploit
Aaron Emigh
"Rumplestiltskin worm" on the loose?
Brett Glass via Dave Farber
The latest in clever spammer technique
Dan Wallach
Trojan attack in Israel
Amos Shapir
Re: PDF not a good format for redacting classified documents
Steven M. Bellovin
Interesting typo
Jon Callas
Conference on Electronic Entertainment Policies, Problems, Solutions
Lauren Weinstein
Info on RISKS (comp.risks)

Landing gear problem due to apparent computer glitch

<"Steven M. Bellovin" <>>
Fri, 20 May 2005 15:33:15 -0400

The AP reports that an Airbus flown by a Turkish charter company had landing
gear problems when arriving at Ben Gurion airport.  Apparently, the pilot
received indications that the nose wheel had not descended properly.  In
fact, it was down; the plane landed normally after the tower observed it

The problem?  According to the Anatolia news agency, it was a "glitch ina
computer system".

Steven M. Bellovin,

The ChoicePointSyndrome

<"Robert Ellis Smith" <>>
Thu, 19 May 2005 12:41:03 -0400

To appreciate THE CUMULATIVE EFFECT, Privacy Journal newsletter in its May
issue compiled the following list of breaches of sensitive personal
information, disclosed just since January. It's not an atypical list for a
three-month period, but breaches are obviously getting more press attention.

* Tepper School of Business at Carnegie Mellon University reported that a
hacker had access to Social Security numbers and other sensitive personal
information relating to 5000 or more graduate students, staff, and alumni.
Another department at the university is responsible for receiving complaints
of Internet breaches and solving them.

* Tufts University notified 106,000 alumni, warning of ''abnormal activity"
on its fund-raising computer system listing names, addresses, phone
numbers, and, in some cases, Social Security numbers and credit-card account

* ChoicePoint, the insurance and employment investigative company and
"information broker" based in Georgia, sold personal data on from 100,000 to
500,000 or more persons to fraud artists posing as legitimate businesses.
(Still, the State of California plans to award a $340,000 contract to the
Equifax-created company to gather information on suspected criminals and
terrorists, according to The Sacramento Bee.)

* DSW Shoe Warehouse experienced a hacking incident involving access to an
estimated 1.4 million credit-card numbers and names, 10 times more than
investigators estimated at first, as well as driver's license numbers and
checking-account numbers from 96,000 transactions involving other customers.

* A computer system breach at an unnamed retailer involved at least 180,000
customers, perhaps more. HSBC North America, which issues GM's MasterCard,
urged all customers to replace their cards as quickly as possible because
the personal data was compromised. The Wall Street Journal identified the
retailer as Polo Ralph Lauren Corp., but the company insisted that in fact
no information was leaked, although a computer flaw was discovered and

* Ameritrade Holding Corp., the online discount broker, informed about
200,000 current and former customers that a back-up computer tape containing
their account information was lost when a package containing the data was
damaged during shipping.

* Canadian Imperial Bank of Commerce, CIBC, one of Canada's leading banks,
"failed to recognize" that misdirected confidential faxes sent to outside
parties over a three-year period were a breach of customers' privacy that
could have been prevented, according to a finding by the federal Privacy
Commissioner in Canada. Bank of Montreal, Royal Bank of Canada, Scotiabank,
TD Bank, and National Bank have also misdirected faxes with customer

* Motor vehicle departments in four states have lost personal data. The
Texas Department of Public Safety mailed to 500 to 600 licensed drivers
renewal documents that pertained to other persons. In March, burglars rammed
a vehicle through a back wall at a Nevada Department of Motor Vehicles
facility near Las Vegas and drove off with files on about 9000 people,
including Social Security numbers. In April police arrested 52 people,
including three examiners at the Florida Department of Motor Vehicles, in a
scheme involving the sale of more than 2000 fake driver's licenses. Also,
Maryland police arrested three people, including a DMW worker there, in a
plot to sell about 150 fake licenses.

* A Boston-based storage company named Iron Mountain Inc., lost Time Warner
Inc.'s computer back-up tapes with Social Security numbers and names of
600,000 current and former employees and dependents. This is the fourth time
this year that Iron Mountain has lost tapes during delivery to a storage
facility, according to The Wall Street Journal.

* Someone gained access to the personal information of 59,000 current,
former, and prospective students at California State University, Chico, the
university revealed in March.

* A laptop that contains about 100,000 Social Security numbers of students
and personnel at the University of California, Berkeley was stolen from the
school's campus.

* Someone hacked into a database at the Kellogg School of Management at
Northwestern University, possibly exposing data pertaining to 21,000
individuals at Northwestern.

* More than 1600 parents discovered in January that records in the Colorado
State Health Department relating to an autism study were lost. A laptop
computer left in a health department employee's automobile was apparently
stolen last October.

*** A free copy of the current issue of Privacy Journal is available through Specify e-mail copy or hard copy (and include a
mailing address).

Robert Ellis Smith, Publisher, Privacy Journal, PO Box 28577, Providence RI
02908  401/274-7861 fax 401/274-4747

A bank you might not want to have Wachovia (bad pun)

<"Peter G. Neumann" <>>
Mon, 23 May 2005 16:56:33 PDT

More than 48,000 customers of Wachovia Corp. and 600,000 of Bank of America
Corp. have been notified that their financial records may have been stolen
by bank employees and sold to collection agencies.  Nearly 700,000 customers
of four banks may be affected, according to police in Hackensack, N.J.  Nine
people have been charged, including seven bank workers.  Also affected were
Commerce Bank and PNC Bank of Pittsburgh.  Collection agent Orazio Lembo
Jr., 35, of Hackensack made millions of dollars through the scheme.  Lembo
received lists of people sought for debt collection and turned that
information over to the seven bank workers, who would compare those names to
their client lists. The bank workers were paid $10 for each account they
turned over to Lembo, Zisa said.

In a separate case with the potential for identity theft, a laptop
containing the names and Social Security numbers of 16,500 current and
former MCI Inc. employees was stolen last month from the car of an MCI
financial analyst in Colorado.

[Source: An AP item by Paul Nowell, Banks Notify Customers of Data Theft,

Hyperthreading vulnerability

<Olin Sibert <>>
Tue 17 May 2005 08:56:03 -0400

Security researcher Colin Percival recently (13 May) announced a security
vulnerability caused by the combination of the Hyperthreading and shared
cache features of Intel Pentium 4 processors.  By carefully measuring the
time required for instructions to execute in one thread while the other
thread is performing a cryptographic calculation, the secret key can be
determined.  A paper describing the flaw is here:

Colin notified OS vendors about the problem some months earlier, and fixes
are available for several BSD and Unix distributions.  It's been designated
CAN-2005-0109 in the Common Vulnerabilities and Exposures list; more details

This vulnerability was also announced by Adi Shamir during the
Cryptographer's Panel at RSA in February 2005.  I thought it was the most
interesting item in all the keynotes (although the hash function
announcements were a close second), but it got essentially no press coverage
(unlike this time, where it is being widely reported).  Adi subsequently
told me that he had a working implementation and planned to present it at
the Eurocrypt rump session next week.  The two attack implementations
(Colin's and Adi's) are apparently quite different, but yield the same
result, underscoring the severity of the problem.  It's also similar to Paul
Kocher's classic timing attacks.

The problem is particularly bad for processors with simultaneous
multithreading ("Hyperthreading"), since that allows context switches to
take place at a granularity of individual instructions, and thus allows very
fine-grained time measurements.  However, the same basic problem is present
in any computer with a cache that is physically shared by processes in
different security domains.

Although cache timing has been known as a covert channel for a long time, I
think this particular exploitation is really slick.  I "discovered" a
similar cache timing vulnerability during the covert channel analysis in the
Multics B2 evaluation back in 1983/84, but I didn't have the wit to
understand how interesting the consequences might be.  I put "discovered" in
quotes because of the way I was gently discouraged from further pursuit (or,
horrors, publication) by some of the NSA personnel who were also involved.
I was disappointed at the time, but in hindsight it seems likely they knew
precisely where such pursuit might lead.  Indeed, I understand that a
similar vulnerability was uncovered by Marv Schaffer et al. in 1979 during
the KVM/370 secure operating system project.

The RISK here is a classic example of relying on underlying abstractions
(the hardware memory model) to behave in an ideal manner, rather than
understanding their implementations.  Many security flaws result from the
adversary breaking the veil of abstraction to look at the soft, juicy parts
inside.  Even when the higher-level model is perfect (or formally verified),
the mapping to implementation can hide a multitude of sins.

MarketScore exploit

<"Aaron Emigh" <>>
Fri, 27 May 2005 01:10:19 -0700

A company called MarketScore has a spyware product that includes a
full-fledged man-in-the-middle attack on all web traffic, including
encrypted traffic.  While any malware running in administrative mode is
potentially catastrophic for subsequent trust and privacy, the MarketScore
attack is especially ingenious and simple.

MarketScore/NS configures the user's machine to proxy all web traffic
through their external server. One would ordinarily expect that SSL traffic
would pass through the proxy opaquely.  However, MarketScore also installs
itself as a trusted root certification authority (under the name "Netsetter"
or "MarketScore," depending on the version).  Whenever the user connects to
a secure site, MarketScore self-signs a certificate for the site and
presents it to the user's machine.  Since MarketScore is a trusted CA for
the user's machine, the user sees no warning and gets the lock icon and
yellow URL bar.  However, MarketScore decrypts the traffic at the proxy
server and re-encrypts it for its SSL session with the actual host.
MarketScore is therefore able to play a man-in-the-middle on all traffic,
including SSL traffic.

Apart from this exploit, MarketScore seems to be garden-variety spyware,
which offers an e-mail virus scanning service in exchange for monitoring
surfing activities as a sort of Nielsen service.  The risks of this
technique being applied toward identity theft and other malicious ends are,
however, clear.

Aaron Emigh, Radix Labs  415-297-1305

"Rumplestiltskin worm" on the loose? (From Dave Farber's IP)

<Brett Glass <>>
May 7, 2005 12:15:03 AM EDT

This week, I have begun to see evidence -- in the form of "bounced" e-mails
and error messages in our servers' log files -- that "zombie" machines which
are infected by malware (either worms or spyware) are launching aggressive
"Rumplestiltskin attacks" against mail servers throughout the Internet.

What is a "Rumplestiltskin attack?" As described in a paper I wrote several
years ago (where I coined the term for lack of a better existing one), it is
an e-mail address harvesting attack in which a machine attempts to send
e-mail messages to randomly guessed addresses at a domain. It might try
common first names -- for example, "", "," and
"" -- and then proceed to common last names and combinations
of names and initials. (In some cases, we've seen some very unusual guesses
that appear to have been extracted from lists of AOL screen names.)

If mail for a guessed address is accepted, the "zombie" machine records the
address and sends it back to its "master" -- a controlling machine which
adds it to a database of addresses which will become targets for spam.

Because the address guessing process is expensive (both in terms of
computing time and in terms of bandwidth), the best way to achieve results
is via a rogue form of distributed computing, in which large numbers of
"zombies" (machines co-opted via malware) are pressed to the task.

On our servers, these attacks and other traffic from spammers are now
consuming approximately ten times more resources than all of our legitimate
mail combined.

Because the "zombies" are generally not mail servers, the most effective way
to mitigate these attacks -- though it might offend the sensibilities of the
"Orthodox End-to-Endians" -- is for ISPs and enterprised to block outgoing
port 25 traffic from client computers that are not designated as, or
intended to be, mail servers. These computers should send outgoing mail only
through a designated mail server, which in turn monitors them for excessive
outgoing traffic.

ISPs' firewalls should monitor and log attempts to send such traffic, so
that infected machines can be spotted and cleansed of their infections.

As I've mentioned above, there will be some people who are philosophically
opposed to the notion of restricting Internet traffic so as to limit abuse.
Alas, such idealism is inappropriate for the real world, where spam is now
consuming so many resources that it threatens not only to choke off not only
legitimate e-mail but to consume the lion's share of ISPs' bandwidth.

[IP Archives:]

The latest in clever spammer technique

<Dan Wallach <>>
Mon, 09 May 2005 12:34:12 -0500

Earlier this year, we switched over to DSPAM, a fancy Bayesian spam
classification system.  We're also running SpamAssassin, which gives DSPAM a
chance to see SpamAssassin's automatic classifications and determine, for
itself, what weights are appropriate for each of those filters. After a
couple months of this hybrid usage, I'm now getting about 99.4%
classification accuracy (maybe two or three errors per day).  What's
interesting is what's still getting through.

Recently, I've gotten a number of spams that have perfect spelling and
vanilla plain text (as opposed to the insane HTML ov3rki!! variety).  If you
look at the mail headers, there's some evidence of zombie machines being
used to transmit the spam (i.e., received lines not matching up to the From
or Sender line) but otherwise the headers are quite clean.  For the message
in front of me right now, the user agent is even listed as Mozilla on Linux.
DSPAM has a clever feature where it will tell you what factors in the
message it used to make its decision.  In this case, DSPAM latched onto the
User-Agent string and other Mozilla-esque headers as having a very low
probability of being spam.  This outweighted a few strings that otherwise
should have tipped it off (e.g., "credit history" or "secure, private").

In some sense, this is exactly what Paul Graham predicted would eventually
happen in "A Plan For Spam".  My hope is that I can eventually untrain DSPAM
of its love for Mozilla headers; we'll see how well it does.  My fear is
that there will always be an avenue of attack for a "contrarian spammer" who
engineers spam to be unlike all the other spams out there.

P.S. At this point, virtually all of my false positives (normal messages
misclassified as spam) are coming from infrequent events that DSPAM would
never enough data from which to be properly trained, such as the e-mail
generated by a dot-com store when I bought a new camera lens.

Trojan attack in Israel

<"Amos Shapir" <>>
Mon, 30 May 2005 19:29:02 +0300

A large scale industrial espionage case is now unfolding in Israel (see ).  A hacker had developed a
Trojan horse application and sold it to several private eye companies -- it
seems the Trojan was used for keyboard sniffing as well as file transfer.
The private eyes' clients chose the the targeted victims, and the Trojan was
sent there by e-mail or posted CD, masquerading as legitimate business

The collected info was transferred from the victims' computers into an FTP
server site (it's not clear if this site was maintained by the private eyes
or the hacker) to which access was sold to the clients in the form of
one-time passwords at 2000 Euro per entry.

It seems none of the targeted systems was hardened in any way to detect such
an intrusion, and the scheme was discovered only because the hacker had
posted some of the illegally obtained items over the net.

Re: PDF not a good format for redacting classified documents

<"Steven M. Bellovin" <>>
Fri, 20 May 2005 15:26:35 -0400

Bob Blakley writes:

> To get documents onto such a server, you'd need to go through the analog
> hole, which would automatically guarantee that the document's appearance IS
> its deep structure.  Voila.

When NSA declassified the Skipjack cipher, many people laughed because the
document was a scanned image.  "Doesn't the NSA know how to use PDF
properly?"  Seems to me that NSA has understood this principle for many

Interesting typo (Wool, RISKS-23.87)

<Jon Callas <>>
Tue, 17 May 2005 17:34:22 -0700

In RISKS-23.87, "US Government to alter RFID passport regulations"

  "... embedded radio chip holding a digitized photograph and biographical
  information is more secure...."

Bio*graphical* information? This is new. Hold on a cotton-pickin' minute
here. What sort of biographical information is it going to hold, and what
about those of us whose biographies don't fit on a smart card.

Yeah, yeah, metric, graphic, what's the difference? It's just a measure of
inaccuracy in the writing.

Conference on Electronic Entertainment Policies, Problems, Solutions

<Lauren Weinstein <>>
Mon, 30 May 2005 07:59:54 -0700 (PDT)

                           EEPI 2005

        Conference and Workshop on Electronic Entertainment
               Policies, Problems, and Solutions

                   Los Angeles, California USA
                   Late Summer/Early Fall 2005
                          (2 to 3 days)

                   *** Call For Interest ***

       ***  Conference Web Page: ***

        EEPI - Electronic Entertainment Policy Initiative


      EEPI main address:
      EEPI conference/workshop:

Greetings.  EEPI is organizing a combined conference and workshop in Los
Angeles for late Summer or early Fall 2005.  The purpose of this gathering
is to fulfill a number of related objectives, all aimed at fostering
cooperative, interdisciplinary work toward finding solutions to an array of
issues related to entertainment technology policies and their impacts on
other aspects of technology and society at large.

Primary goals of this meeting include both providing attendees with insight
into the many often conflicting points of view and complex characteristics
related to these issues, and to work towards establishing a long-term
framework for finding and implementing practical, cooperative solutions
wherever possible.  This will not be a place for finger-pointing or
name-calling.  Attendees should be interested in learning more about these
issues and helping to solve the many complex problems in this arena that we
must deal with today and that we will be facing with increasingly rapidity
in the future.

We urge you to view for more details regarding EEPI and
the entertainment technology issues of concern, and some thoughts on the
categories of groups and individuals who may be particularly interested in
attending this meeting.

Formal papers are welcome but are not required for presentations at the
conference or workshop sessions.  Student registration discounts will be

Our aim is to bring together involved and interested parties from across the
electronic entertainment spectrum and beyond: record labels; film studios;
broadcasters; artists; technical development and manufacturing firms;
computer firms and organizations; Internet, government, legal, and public
interest individuals and groups; educators; students; media; concerned
members of the public, and more.

Since the focus for this gathering is interdisciplinary in nature,
highly-detailed technical presentations (as opposed to technical
"overviews") will be discouraged in main sessions, however, more detailed
technical discussions may be appropriate in particular workshop sessions
during the meeting.  Sessions may be organized on multiple tracks as deemed
appropriate, to be determined as meeting details are finalized.

Below is an alphabetical, non-inclusive list of some categories of issues
that are appropriate for this gathering, as they relate to electronic
entertainment.  Many of these are interrelated, of course:

 - Academic Institution Concerns
 - Alternative Licensing Models
 - Artists' Economic Concerns
 - Artists' Rights
 - Broadcasting Issues (Broadcast Flag, Copy Controls, Digital TV, etc.)
 - Cable TV Issues
 - Children's Online Protection Act (COPA)
 - Consumer Economic Concerns
 - Consumer Rights
 - Content Distribution Issues (Music, Films, etc.)
 - Content Filtering and Blocking (Internet, Other Media, etc.)
 - Copyright Issues
 - Corporate Economic Concerns
 - Corporate Rights
 - Criminal Prosecutions
 - Digital Rights Management (DRM) / Copy Protection Systems
 - Digital Video Recording (DVR), etc. and Related Impacts
 - Downloading of Audio and Video (Legal and Illegal)
 - DVD and "Next-Generation" DVD Issues (eg. Blu-Ray, HD-DVD, etc.)
 - Electronic Games (Content, Piracy, etc.)
 - Fair Use Issues
 - Intellectual Property Issues
 - International Issues
 - Internet Issues (the broad range of related Internet applications)
 - Judicial Issues (court rulings and their effects)
 - Lawsuits and other Civil Actions
 - Legislative Issues (local, state, and federal legislative actions)
 - Micropayment Issues
 - Payment Models
 - Peer-to-Peer (P2P) File Sharing Issues
 - Piracy Issues (Music, Films, Videos, other Content, etc.)
 - Regulatory Issues (Regulatory Agency Actions, e.g. FCC, DOJ, ITU, etc.)
 - Streaming Audio and Video Issues
 - Video on Demand Issues
 - Video to Consumers over Fiber, DSL, Internet Issues

 ... and a host of others!

 - - -

Obviously we will not be able to solve all of the many complex problems
related to these topics at this single gathering!  However, we hope to
demonstrate that it is possible for people to work together on these
problems, help attendees understand other persons' points of view regarding
these contentious issues, and lay the groundwork for long-term, continuing
efforts by interested individuals and groups to simultaneously find
solutions, and to reduce the level of animosity and its counterproductive
effects in the areas of concern.

  - - -

If you might consider attending, please send a note (all e-mail to
this address will be read by a human!) to:

or FAX to:
   +1 (818) 884-7502

Please let us know your level of interest, any relevant organizational
affiliations if you wish, and any related comments or questions.  Unless you
specify otherwise, we'll add your e-mail address to a private mailing list,
which will only be used to provide more information as additional details of
the meeting (exact location, dates, registration fees, etc.) are determined
and finalized.

Please also feel free to contact EEPI co-founder Lauren Weinstein by phone
via +1 (818) 225-2800.

We hope to see you at EEPI 2005!

Thank you very much for your consideration.

   - - -

          EEPI - Electronic Entertainment Policy Initiative
      "Working Together Toward Sensible Policies and Solutions"


              EEPI main address:

	      EEPI conference/workshop:

This document is subject to change and elaboration at any time.  5/30/05

Please report problems with the web pages to the maintainer