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 49

Friday 13 August 2004


U.K.: Don't smile for your passport picture!
Gloria Estefan performance in Dallas canceled due to computer crash
Ben Moore
Airport Express crypto broken by DVD Jon
Cory Doctorow via Monty Solomon
Buffer Overflow in "I'm Away" feature of AOL Instant Messenger
Paul Robinson
Windows Buffer Overflow Protection Programs: Not Much
Paul Robinson
Obion County Tennessee vote counting problems
Jeremy Epstein
Drivers let Big Brother in to get a break
Kevin Maney via Monty Solomon
DidTheyReadIt operations and security concerns
Rob Slade
Risks of ordinary GUI "pop-up" windows?
Cody Boisclair
REVIEW: "Stealing the Network: How to Own a Continent", Ryan Russell
Rob Slade
Info on RISKS (comp.risks)

U.K.: Don't smile for your passport picture!

<"Peter G. Neumann" <>>
Fri, 6 Aug 2004 22:44:39 PDT

The U.K. Home Office ruled that all new passport photos must show an
unsmiling face with closed mouth because open mouths can confuse facial
recognition systems. The new guidelines require good contrast between the
face and background; the full face looking straight at the camera; no
shadows; and a neutral facial expression. The rules will apply immediately
to new and replacement passports.  U.K. prohibits smiling faces on passports,
*The Register*, 6 Aug 2004

  [When Lauren Weinstein saw this, he commented:
     "But what if people keep smiling at the airport?"  PGN]

Gloria Estefan performance in Dallas canceled due to computer crash

<"Ben Moore" <>>
Thu, 12 Aug 2004 15:09:02 GMT

Estefan Enterprises and Clear Channel Entertainment announced (on 9 Aug
2004) that Gloria Estefan's 9 Aug performance at the American Airlines
Center in Dallas, Texas has been canceled.  After performing to a packed
house in Houston, the touring company experienced a computer crash that
affected the production and its special effects, forcing the cancellation of
the performance.  Engineers guarantee that the system will be repaired by in
time for the next performance in Phoenix, Arizona on 12 Aug.   [PGN-ed]

Airport Express crypto broken by DVD Jon (via Monty Solomon)

<Cory Doctorow <>>
Thu, 12 Aug 2004 03:28:43 -0400

Jon "DVD Jon" Johansen has cracked the Apple Lossless encryption used by the
Airport Express to communicate with iTunes, so that programmers can write
tools that use any application and any operating system to send audio to an
Airport Express.  I've released JustePort, a tool which lets you stream
MPEG4 Apple Lossless files to your AirPort Express.

 The stream is encrypted with AES and the AES key is encrypted with RSA. ...

Buffer Overflow in "I'm Away" feature of AOL Instant Messenger

<"Paul Robinson" <>>
Tue, 10 Aug 2004 15:26:44 GMT

An 9 Aug 2004 *Infoworld* article
notes that there is a bug in AOL Instant Messenger allowing an attacker to
send a message that can cause a buffer overflow and possibly execute code on
the attacked machine.  Apparently this will only occur if the attacker sends
a url - like the one in this message - as a hyperlink and the victim clicks
on it, which makes the probability of attack much lower than a "standard
buffer overflow attack" upon a program.

Windows Buffer Overflow Protection Programs: Not Much

<"Paul Robinson" <>>
Mon, 09 Aug 2004 17:24:19 GMT

I  happened to stumble upon the most recent issue of the hacker e-zine
Phrack, Issue #62, of July 10, 2004, and looking over the table of contents
I found article #5, "Bypassing 3rd Party Windows Buffer Overflow Protection"
which can be read at the following url:

I found the article fascinating in that it shows exactly why several major
commercial anti-buffer overflow exploit programs are inadequate for their
advertised purposes.  The article even points out what you are going to end
up with: a false sense of security.

For those who are not so technically inclined, a buffer overflow exploit is
one in which someone sends too much data to a program (such as a web server
application), sending far more data than the program would expect, in order
to force arbitrary data into a storage area (a "buffer") so the amount of
data forced into the buffer goes beyond the expected limits, causing the
data to overflow the buffer and makes it possible for that data to be
executed as arbitrary program code.  Since the attacker forces code of his
choosing into the execution stream, he now 0wns your box, because as the
saying goes, if I can run code on your machine - especially if it's a
Windows machine where there is not much protection - I can pretty much do
anything I please there.

These anti-buffer overflow exploit protection programs then try to prevent
this by watching for attempts to execute calls to the operating system, in
places where only data should occur as opposed to program code.  The article
shows why these programs are inadequate both from a standpoint of how they
fail to provide full protection, and how to get around the limited
protection they do provide.

This sort of article is an excellent example of why full disclosure of a
serious problem is necessary in order to solve it.  The type of response to
an anti-buffer overflow exploit protection program by an attacker would, as
a matter of necessity, be somewhat complicated and technical in nature, and
the only way one could explain why there is a problem, what the problem is,
and then allow someone to be able to solve it, is to describle how to
exploit the flaw.  Nothing less will do because nothing less will explain
how the flaw is exploited.

It is reports such as these that are important even to those that are not
interested in breaking into a place, and in fact are probably of crucial
interest to security people in order that (1) they not be given a false
sense of security by these products that only solve part of the problem; (2)
explain exactly why the products are ineffective; and (3) explain exactly
what the issues are.

An explanation such as the one given shows why these products are
ineffective, shows what those who have to defend themselves need to look
for, and can show those trying to build safety systems in the future how to
better secure them.

Does this mean someone can create an attack using the information shown?

This does not make the exposure of such information any less valid.  Telling
someone that it is still possible to trigger a buffer overflow exploit even
if a buffer overflow exploit security program is in place is probably not
going to convince them without some proof.  Explaining that these systems
don't block everything and mentioning why will not give someone enough
information to reliably check what is happening or understand how the
problem affects them.  Only a clear explanation of how the process is done
is going to show someone how to guard against it.

Digging one's head in the sand does not hide a danger, nor does making it
illegal to publicize such information help, as those who will use such
information for criminal purposes, since they are already breaking the law,
any penalties for selling such information to other crackers (or trading it
for other information) simply keeps it out of the hands of the good guys who
would need it to figure out how to work around it.

Additionally, by making such information available, third parties, who are
neither selling security software, nor trying to crack other people's boxes
in order to 0wn them, can read this information and give an objective
validation as to whether they are valid or not, and perhaps can supply
solutions not requiring multi-thousand-dollar support contracts from some
vendor who is more interested in what they can sell than in security, who
just happen to sell this particular type of product because there is a
market for it and who might not be interested in giving away information
that they can sell to others.  There's nothing particularly wrong with
charging whatever the traffic will bear for what you know, but it creates a
strong disadvantage for those kept in the dark.

Which is the only thing that security by obscurity - trying to hide problems
in the hope someone doesn't discover them - does, it keeps the people who
most need to know how to solve the problem in the dark.

Obion County Tennessee vote counting problems

<Jeremy Epstein <>>
Wed, 11 Aug 2004 13:21:29 -0400

Obion County in Tennesee had to revise its preliminary election results
after they discovered that early votes weren't counted.  Seems that the DRE
vendor changed how the system counted the early votes, which wasn't
initially noted.  They're now confident they got it right.  One preliminary
victor will now be defeated.

Note that the problem here wasn't in the voting machines themselves (which
is where most of the historical problems have been), but rather in how the
results are tallied at the end of the election.$rec=29188?frontnews

Drivers let Big Brother in to get a break (Kevin Maney)

<Monty Solomon <>>
Wed, 11 Aug 2004 01:33:12 -0400

In two new tests, car owners will be able to let insurance companies monitor
their driving via new technology in exchange for lower rates.  The
technology will track some combination of when, where, how far and how fast
they drive, giving insurers a way to reward low-risk driving. Now just
experiments, the technology might be a glimpse of the future of car
insurance.  The trials will begin this year.  [Source: Kevin Maney, *USA
TODAY*, 9 Aug 2004]

DidTheyReadIt operations and security concerns

<Rob Slade <>>
Mon, 9 Aug 2004 14:34:39 -0800

DidTheyReadIt is a new service on the Net.  It has garnered some attention
from the privacy community already: I will deal with some of that later.  I
would like to examine the actual operations of the service.  The discussion
surrounding it has been marked by assumptions and lack of knowledge.  Some
assertions have been made that are at odds with the actual operations.
DidTheyReadIt is both less, and more, dangerous than has been made out.

As the name implies, it provides a kind of "return receipt" for e-mail.  It
does this, of course, using Web bugs.  A "single pixel" image file is called
from the central host, using a hash that presumably corresponds to the
sender, subject, and receiver, looking like the following:

width="1" height="1" /

(I have removed the surrounding angle brackets: hopefully this will prevent
any mailers from trying to render the HTML.)

Having obtained an account from DidTheyReadIt (and paid for the privilege),
there are two ways to use the service.


If you have WinXP or W2K (and a "standard" mailer) you can run a background
program on your computer.  I have downloaded the installation program and
made a cursory examination of it, but I have strong reservations about
actually running it on my system.  One can assume that the process runs in
the background, adds the Web bugs to outgoing e-mail traffic, and sends
information to the central computer.  However, even a brief analysis of the
code indicates it can do more than that.  Among other things it calls the
kernel, uses the Registry, and obtains information on privileges within your
system.  These may be valid activities within the context of the operation
of the program, but, given what the program must be doing, what else is it
doing?  There is a significant possibility for information leakage here.


You can use the program without running the background process.  To do this,
you append "" to the e-mail address.  If I wanted to send a
message to my address, I would send it to  The central computer then reformats the
e-mail in HTML and adds the Web bug.  In this way, obviously, DidTheyReadIt
gets to read all the e-mail I send.

When e-mail is opened using a mailer that automatically calls for
information from the Web, the URL is requested, and the central computer has
confirmation that the individual actually read the e-mail.  DidTheyReadIt
promises that they can tell you how long the e-mail remained open.  (In the
tests that I've done so far this information has been available in slightly
under half of the cases.)

(When the URL is requested, a series of packets each containing a single
byte is sent.  Lauren Weinstein [see below] has noted that this may be the
way the Rampell measures how long the message remains open.  In tests the
file transfer time seems to vary, but has always been shorter than the
longest time that I've been "informed" a message has remained open.  Others
have theorized that the material transferred may be scripting that remains
active as long as the message is open, passing information back to Rampell.
This does not seem to be the case.  When downloaded manually, the file is
302 bytes, has the internal structure of a JPEG file, and displays as a one
[or possibly two] pixel black dot.  A refresh tag could be used, but this
has been observed neither in the coding seen nor the activity of browsers.
At this point I don't know what the basis of the "read duration" is.)


The central computer actually has rather a lot of information from that URL
request.  There is information about the time it was opened.  There is
purported information about the location and organization, but this is
obviously obtained from a whois lookup from the IP address.  There is
information about the browser application, and the language used.  In the
case of Windows software running under emulation on a non-Windows system,
there was enough information to indicate that this was so.


The amount of information that DidTheyReadIt could build up is quite
staggering.  As well as simple lists of valid e-mail addresses, they can tie
address information to browsers and other applications, and the language of
the user.  They can, of course, build maps of connections between
correspondents.  The hash seems to also be linked to the subject line, so
that even if e-mail is not being sent through the central computer itself a
database of topics and interests can be built.  I'm rather surprised that
Rampell Software (the company behind DidTheyReadIt) is even trying to sell
their service: make it free, get the masses on board, and they have a gold
mine of marketing information.

Rampell is presumably well aware of the marketing possibilities.  Each and
every confirmation message from them carries at least two marketing
messages: one pushing you to buy an upgrade to the version you have, and
another promoting some other Rampell product.

The system is not perfect, of course: send a message to me and you will
probably not get acknowledgement that I read it, since my mailer does not
(automatically) render HTML and go to the Web.  However, prevailing upon
some friends with more "standard" mailers, such as Outlook and Eudora, the
system does seem to work (at least partially) with a wide variety of
systems, including Macs, and Macs running Outlook under PC emulation.
Cookie filters that prevent you from going to an "outside" site might limit
the susceptibility of Web based mail systems, but otherwise these should all
return the tracking URL.

The system has interesting limitations with regard to mailing lists, and
copies.  When sent to a mailing list, and even to a number of people copied
on the "To:" and "Cc:" lines, only one hash is generated.  Although the
confirmation message from Rampell mentions the possibility of further
confirmations whenever someone subsequently reads the message, in testing
that does not appear to happen.  Each hash appears to be good for one use,
and one use only.  Sending a message to a mailing list gets you a response
from the first person (or the first *susceptible* person) to read it.

As noted at the beginning, there has already been some interest in the
system and the privacy considerations.  There have been two mentions of the
system in the RISKS-FORUM Digest, beginning with

In the first, Lauren Weinstein gave a reasonable account of the system and
the potential problems, noting the possible solutions.  The use of text-only
e-mail is the best solution, and blocking the Rampell server would work as
well.  Turning off image display may alleviate privacy problems, but that
does depend upon how different applications handle that option.  Some may
submit the URL to the Rampell server, and simply not display the image.
A second posting noted that DidTheyReadIt is illegal in France, and
speculated that travelers to France might find themselves in legal trouble
if they were subscribers.  In practical terms, having the Rampell software
installed on your system could be evidence against you.  In which case,
using the modified e-mail addresses would leave you free and clear, so long
as you didn't send any modified mail while in France.  France might, of
course, want to block Rampell's IP addresses.

A marketing consultant did an article on the errors that Rampell made in
promoting the service.  He suggested that an opt-out approach or option
would have avoided the bad press.  Unfortunately, this demonstrates that he
doesn't understand how the system or the technology works.  As Weinstein's
analysis indicated, you have to change your software, or have some backend
support, in order to prevent detection.

It is, of course, quite possible that Rampell has only the purest of motives
in providing the service, and would never consider using the information
obtained by providing it.  I would not dare to impugn the integrity of the
company or its principles and principals.  However, I would note that

 - A certain delivery company stated that it would never sell the database
of digitized signatures collected when it started using electronic pads--and
then, some years later, did exactly that.

 - Companies with very rigorous privacy policies, having collected
significant amounts of personal customer data, have gone bankrupt, and the
files have been offered for sale.

 - It has, sadly, been known to happen that evil intruders have broken into
companies and stolen personal information from computerized files--or even
planted backdoors and logging/reporting software in their systems.    or

Risks of ordinary GUI "pop-up" windows?

<"Cody B." <>>
Fri, 30 Jul 2004 15:40:12 -0400

Ah, yes. I don't know how many times I could potentially have sent private
or even confidential information to someone inadvertently because that
person decided to send me an instant message, which of course would
preemptively pop up directly in front of whatever I happened to be working
on at the time.  The good news is that I've managed to catch myself before
ever sending anything potentially risky... still, I *have* confused people
with a few stray words or even a snippet of computer code that I just
happened to have been in the midst of typing when they sent me an IM.

For that matter, there's already an exploit for Mozilla's XPInstall that
takes advantage of this particular race condition, as demonstrated by
Jesse Ruderman of
Basically, Ruderman came up with a deceptive page that causes the installer
dialog to appear at just the right moment to trap your keystroke of 'Y',
which of course it then interprets as 'Yes'. If you've wondered why Mozilla
grays out the buttons in its install dialog for five seconds after you
choose to install an extension, this is why-- it's to prevent an inadvertent
installation through a stray keystroke or mouse click!

Cody "codeman38" Boisclair

REVIEW: "Stealing the Network: How to Own a Continent", Ryan Russell

<Rob Slade <>>
Mon, 9 Aug 2004 08:06:39 -0800

BKSTNHOC.RVW   20040721

"Stealing the Network: How to Own a Continent", Ryan Russell, 2004,
1-931836-05-1, U$49.95/C$69.95
%E   Ryan Russell
%C   800 Hingham Street, Rockland, MA   02370
%D   2004
%G   1-931836-05-1
%I   Syngress Media, Inc.
%O   U$49.95/C$69.95 781-681-5151 fax: 781-681-3585
%P   402 p.
%T   "Stealing the Network: How to Own a Continent"

This book is fiction (more a series of short stories or scenarios than
a novel), but, like Winn Schwartau's "Pearl Harbor Dot Com" (cf.
BKPRHRDC.RVW, and "Terminal Compromise" before it, BKTRMCMP.RVW),
authors intend the book to be taken as a serious addition to security

Chapter one is basically about hiding and paranoia.  The central
character seems to be using a considerable amount of money to hide
while setting up some kind of crime, and then abandons everything.
The points in regard to ensuring computers and data are unrecoverable
are interesting, and probably workable.  The more important aspects of
the plot which involve creating a team, employing cutouts, and
disappearing are left almost completely undetailed.  If, therefore, we
are supposed to learn anything either about crime, or how to detect or
prevent it, the content and information simply aren't there.  The
claim that the "technology" is real, and would work, is unverifiable
because we haven't had any technology yet.  (The writing is edgy,
interesting, and mostly readable.  However, it's also difficult and
confused in places.)

The story continues, via another character (two, actually) in chapter
two.  This time the technical aspects are more detailed (and fairly
realistic) although the community factors are questionable (and the
story has some important gaps).  (I can personally vouch for the fact
that the description of the physical attributes of that specific hotel
are bang on, although the ... umm ... social amenities are not.)  An
"Aftermath" section is at the end of every chapter.  In some instances
the segment provides a little advice on detecting the attacks
described in the story, but this is by no means true in all cases.
Nothing much is added in chapter three: a wireless network is
penetrated for a second time.  Man-in-the-middle attacks, some IP, and
UNIX cracking are added in chapter four, phone phreaking in five, and
sniffing and rootkits in six.  Chapters seven and eight describe
software analysis and exploits.  Malware is used in chapter nine,
although there are the usual unresolved problems with directing
attacks and limiting spread.  The lack of particulars on the intent of
the attack makes the chapter quite perplexing.

As with any volume where multiple authors work on separate chapters,
the quality of the writing varies.  (That the authors did strive
together on the overall plot is evident from a few subtle ties between
different stories.  An appendix lists some of the discussion in this
regard: for those interested in the process of writing and
collaboration it is an interesting piece in its own right.)  One
specific point is that a few sections have very stilted dialogue.
Overall, most of the book is readable as fiction, although it is
hardly thriller level plotting.

Since it is fiction, the story has to be a story, and interesting, and
therefore contain elements that are not related to the technology
under examination.  It is difficult to draw the line between not
enough and too much, but the authors do seem to have included an awful
lot of material that is unimportant either to the security functions
or to the plot.  A number of these digressions are simply confusing.

The characters used in the stories are frequently stereotypes,
although not always of the same type.  (I was very amused by the note
that the book attempted to remain true to geek culture, including
"swearing, boorishness, and allusions to sex without there being any
actual sex.")  If you watch a lot of movies with somewhat technical
themes you can recognize where quite a number of personae come from.

Basic editing is the province of the publisher rather than the
author(s), but it must be noted that spelling, grammatical, and
typographical errors are surprisingly common.  Not enough to be a real
annoyance, but a proper copy edit would have improved the book quite a

This book is certainly interesting enough (albeit rather disjointed)
as fiction, and technical enough for everyone tired of the usual
Hollywood view of computers.  The security risks noted are real, and
therefore a read through the book could be used to alert non-
specialists to a number of security issues and vulnerabilities
(although you'd hardly want to use it for training).  I enjoyed it and
I think it's got a place, although I'm having difficulty in defining
where that place is.

copyright Robert M. Slade, 2004   BKSTNHOC.RVW   20040721    or

Please report problems with the web pages to the maintainer