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 21 Issue 59

Friday 10 August 2001


Laser eye surgery
Henry Baker
"You Can't Hide Those Lying Eyes in Tampa"
Adam Shostack
The Internet park bench
Richard Jay Solomon via Dave Farber
PDF backward compatibility failures
Marc Auslander
A lucrative fiasco
Brian Randell
Risks of automatic verification
Geoff Kuenning
Possibility of a Warhol Worm: Complete infection in 15 minutes!
Nicholas C. Weaver
Adobe clarification on spyware article
Gunar Penikis
Danish police: Safeguard Easy not broken; passwords were weak
Bo Elkjaer
Re: OT: rot13, practical uses of
Rich Wales
Re: Georgia scholarship info exposed
Phil Kos
Re: Freeware app to retrieve passwords from Internet Explorer
Marc Roessler
Mutual authentication - not!
Michael Bacon
Re: What is your area code, really? (
Declan McCullagh
Is your phone bill private? Think again...
Ted Lee
Re: Firefighter's phone lines disrupted ... SMS hoax
Stanislav Meduna
Caller ID "hack" not a hack at all
William Kucharski
ANI is NOT Caller ID
Danny Burstein
DoCoMo thttpd is not thttpd
Fred Cohen
Info on RISKS (comp.risks)

Laser eye surgery

<Henry Baker <>>
Thu, 09 Aug 2001 13:52:21 -0700

Someone close to me had laser eye surgery to correct significant
near-sightedness two days ago.  The surgery apparently went very well, but
as I watched the procedure being performed, I was horrified to see two

* the use of Windows as the major interface for this system
  (, both for the output of the real-time video of the
  eye, both the tracked and the untracked views, as well as for the entry
  and display of the parameters.  Based on my personal experience with
  Windows (I reboot on the average of 3-4X per day), I find it almost
  inconceivable that someone would trust their eyesight to such a software
  disaster area.  I wasn't aware that _anyone_ had done any source checking
  of the Windows system to make sure that the numbers typed in were properly
  interpreted in all cases.  Furthermore, even if someone had done such a
  check, it is inconceivable that such checks would remain valid for more
  than one version of the software.  (Getting input routines correct isn't
  easy -- I'm aware of popular software systems (non-Windows) that still
  contained the same input conversion bugs after almost ten years and 5

* during the entry of parameters, the technician quickly "clicked
  away"/dismissed a number of error windows of the form "parameter out of
  bounds" -- seemingly on almost every number entered.  When error windows
  of this type pop up so frequently and are routinely dismissed, it is like
  crying "wolf" -- eventually, no one listens even when there is a really
  bad problem.

I was, however, very impressed with the quality of the eye-tracking system,
which keeps the laser locked onto the pupil for upwards of 2.5 minutes, with
_no_ noticeable jitter (I would estimate that the jitter was well under a
single pixel out of an image probably 640 pixels wide).

"You Can't Hide Those Lying Eyes in Tampa"

<Adam Shostack <>>
Wed, 8 Aug 2001 13:03:34 -0400
is the story of Rob Milliron, whose picture, captured from Ybor city
surveillance cameras, was published in US News and World Report.  A woman in
Tulsa saw his picture and (incorrectly) identifying him as her ex-husband,
called the police.

Many of the risks are generally familiar, issues like mis-identification.
Worth asking is why didn't they choose the picture of a criminal who was
actually caught?  Perhaps because the system does not function as

The Internet park bench (From Dave Farber's IP list)

<Richard Jay Solomon <>>
Fri, 10 Aug 2001 13:35:01 -0400

Thursday, 9 August, 2001, 13:44 GMT 14:44 UK

Bad start for Internet bench: The teenagers took advantage of the free service

Two teenagers discovered the world's first Internet bench could be used to
make free international telephone calls.  The cyber-seat, which is based in
a public park in Suffolk, UK, went online on Monday.  Neil Woodman and Dan
Sanderson, both 17, took a normal telephone handset along to the bench,
which was created by Microsoft's MSN service in partnership with the local
council.  The pair cheekily phoned St Edmondsbury Council to warn them of
the problem and then tried to call Microsoft boss, Bill Gates.

PDF backward compatibility failures

<Marc Auslander <>>
10 Aug 2001 16:50:56 -0400

I can't read my Vanguard statements (back to 1998) with Acrobat 5.0.  In
looking at the Adobe site, this is not the only backward compatibility
failure reported.

So what has become a defacto document storage standard may in fact leave us
with documents we can't read!

Marc Auslander   <>   914 945-4346  (Tieline 862 Fax x4425)

A lucrative fiasco

<Brian Randell <>>
Thu, 9 Aug 2001 22:28:45 +0100

Magistrates courts staff are having to work with two computers on their
desks instead of one after being presented with new PCs which do not have
the software to do the main job they were bought for.  In the latest in a
long line of government IT humiliations, the Lord Chancellor's Department is
pressing ahead with the installation of new computers in 400 magistrates
courts even though delivery of the core application, a new case management
system, has been indefinitely delayed.  The result is that staff still rely
on their old computers - installed 10 years ago - to access the casework
system, while using the new PCs only for basic functions such as word
processing and e-mail.  An investigation by *Computer Weekly* has
established that by installing the computers, the contractor ICL is now
entitled to be paid more than half the contract's 319,000,000 pounds value,
despite its failure to deliver the core application.  [Source: Court staff
hit by IT fiasco; software snag hits magistrates computer project, Stuart
Millar, (UK) *The Guardian*, 9 Aug 2001]

Full story at,7369,534162,00.html

Dept. of Computing Science, University of Newcastle, Newcastle upon Tyne,
NE1 7RU, UK  +44 191 222 7923

Risks of automatic verification

<Geoff Kuenning <>>
Tue, 7 Aug 2001 17:24:17 -0700

In the past year or so, a lot of e-shopping sites have installed
fraud-prevention software that attempts to verify that you aren't using a
stolen credit card.  These systems generally operate by comparing the
billing address for the card with an address provided by the shopper or with
the shipping address for the merchandise.

These systems have caused me endless headaches, because my billing address
is a P.O. box in a different state.  For some reason, the automated
verification system insists on rejecting me with a message indicating that
my information doesn't match what's in my bank's records -- despite the fact
that I have spoken with the bank to make sure that it is the same.  On more
than one occasion, I have been forced to resort to telephone calls to get my
transaction to go through.

But my favorite was when one site gave me a reject message, so I retried
with a slight variation on the address.  After a second reject, I got on the
phone and straightened it out (without any particular verification
requirement, I might add).

That evening, the bank called to ask why I had three charges from the same
Web site...

The RISK: programmers who assume that everyone runs their lives the same way
the programmer does.  There's an incompetent-programmer RISK here too, but
what else is new?

Geoff Kuenning

Possibility of a Warhol Worm: Complete infection in 15 minutes!

<"Nicholas C. Weaver" <nweaver@EECS.Berkeley.EDU>>
Thu, 9 Aug 2001 15:11:50 -0700 (PDT)

Michael Constant and I have performed a basic analysis of a possible
worst-case virulence for an active worm like Code Red.  By simply changing
the infection strategy, a "Warhol Worm" could be developed, able to infect
all vulnerable machines in 15 minutes from the moment of initial infection
of a single machine!
Nicholas Weaver,

  [And in Case you have not heard, Code Red III is now operating.  PGN]

Adobe clarification on spyware article (Maggard, RISKS-21.56)

<"Gunar Penikis" <>>
Thu, 9 Aug 2001 13:24:49 -0700

This is in response to Michael F. Maggard's posting in RISKS-21.56.

I would like to clarify some misconceptions and misinformation that was
posted regarding Adobe applications "phoning home".  The component in
question is AOM, Adobe Online Manager which is included in most Adobe

1. AOM does not scan your computer for registration and product information.

AOM runs concurrently with most applications, it's purpose is NOT to scan
for registration and product information and phone home to Adobe.
Registration information such as serial number, product name is ONLY sent
from the product when the user selects the Registration menu item in the
product. This launches the default browser to the registration web page that
has product and registration information pre-filled as a convenience (so the
customer doesn't have to find the product box, etc.) The serial number is
obfuscated in this transaction to protect our customers and Adobe from
piracy.  Alternatively, customers can print out a registration form, use the
registration card, or register via the and type in the product
information manually.

2. AOM only sends registration information when you select Online Registration

As I mentioned above, we only send registration information when the user
clicks the Registration menu in the product.  It is never sent at any other
time or with any other interaction.

3. Removing any components is NOT recommended.

We highly suggest NOT removing AOM or other files since these components are
critical to functionality of the connectivity, collaboration and support
features of the product.  As part of the regular updates to the products, we
are investigating eliminating the dependency of AOM.  In the meanwhile, we
suggest that users of older products update their version of AOM by
selecting Adobe Online and clicking the refresh or update button.  Newer
product should select the Downloadables or Updates menu item to check for
product updates.

What is AOM used for anyway?

AOM stand for Adobe Online Manager.  It is core component that coordinates
the online interaction between Adobe products.  When customers request
updated information from within Adobe products by selecting Adobe Online or
Updates/Downloadables, AOM processes these requests so that collisions do
not occur and the appropriate information is displayed to the user.

I hope this helps clarify some of the concerns your readers have

Gunar Penikis, Product Manager, Adobe Systems

Danish police: Safeguard Easy not broken; weak passwords (R 21 58)

<Bo Elkjaer <>>
Thu, 9 Aug 2001 22:18:57 +0200 (CEST)

This is to elaborate and correct the initial mentioning of Safeguard Easy
in RISKS-21.58.

It was reported in national media - including tv - that the police had
successfully broken the encryption. This, it seems, is not the case. The
police have managed to find the passwords of the five encrypted computers.
The information concerning the successful decryption of the five computers
protected with Safeguard Easy was presented in court by chief prosecutor
Poul Gade. Investigation is lead by chief of police in Holstebro, Jens

I have just interviewed Jens Kaasgaard. He says:
'To avoid misunderstandings, we haven't broken Safeguard by technically
breaking down the encryption. We have located the passwords in different
ways. We have done it like any hacker would have done, by trying to figure
out the most probable passwords. This has payed success in five cases.'
'After doing that we entered the document-parts, the harddisk of the
computer. Here we found some of the files unencrypted and other files
further encrypted.'
'When you use Safeguard you put a sort of shell around your data. This is
the first part you need to enter. This is what is claimed to be
impossible. It is impossible. We have had six private companies looking at
this, and they have all failed.'
'We have used completely ordinary police investigation methods. We know
precisely who have had access to the encrypted machines. Then we can start
assessing probabilities and calculate upon this and set up models for how,
if you were a hacker, you'd find your way into the machines.  That's what
we have done.'
You did this yourself?
'Yes. We did this inside the police system.'

To conclude: Be careful when you choose your password.

Bo Elkjaer

Re: OT: rot13, practical uses of (Manfre, RISKS-21.58)

<Rich Wales <>>
Thu, 9 Aug 2001 17:06:52 -0700 (PDT)

Let's not forget, of course, that when the US Army decided to get serious
about enforcing a "no encryption software" policy on the SIMTEL20 archive
back in 1990, one of the programs that was kicked off the site was ... you
guessed it ... a ROT13 utility.

Rich Wales

Re: Georgia scholarship info exposed (Slatkin, RISKS-21.58)

<Phil Kos <>>
Thu, 9 Aug 2001 14:45:08 -0700

> the security file was wiped out, exposing other files.

I think I would be a bit ticked off if my IT people decided that one of my
web servers should automatically be "cleaned" of not-recently-used files,
but let's not let that distract us from the real issue.

Rachel hopes that the "security file" was .htaccess. While I can't disagree,
I think that it misses the point. Frankly, even .htaccess is not sufficient
to protect passwords stored in plain text on an unsecured web server. This
is the real problem here. Storing passwords in plain text is an even
better-known bad idea than using unchecked buffers on the stack frame, and I
hope the person responsible for this piece of phenomenally bad design gets
the blame due them.

Re: Freeware app to retrieve passwords from Internet Explorer

<Marc Roessler <>>
Wed, 8 Aug 2001 17:45:08 +0200

Now this is interesting.  I remember seeing something similar about three or
four years ago, named "Snadboy Revelation" back then, worked fine with

I had expected MS to make this more difficult after seeing such a tool..
The RISKs of using password remembering functions are well known, but making
revelation of passwords that easy borders the laughable.

Of course, displaying an asterisk for each character of the password is
another RISK in itself since it leaks information on the length of the
password.. Standard UNIX login does not echo anything at the Password prompt
for a reason..

Marc Roessler

Mutual authentication - not!

<"Michael (Streaky) Bacon" <>>
Tue, 7 Aug 2001 18:58:38 +0100

I recently received a telephone call from the fraud department at my bank.
I had recently been using a card that I don't normally use and they were
just checking that it was still in my possession.

The fraud department asked me to identify myself by giving them my date of
birth and 'secret code' that I had supplied years beforehand.  They told me
what the question was, so I remembered the answer.  I declined, and asked
them to positively identify themselves to me before I would give them the
information.  "But we only need to confirm it, I have it on my screen", the
lady said.  "OK, you tell me what it is and if I agree that's what I told
you then I've authenticated you", said I - knowing that it should fail, but
hoping that it wouldn't.  "Then you can authenticate me."

After much discussion and calling two supervisors, we agreed that they would
tell me the last two purchases I had made on that card (approximately 1 hour
and 20 minutes beforehand respectively from two different stores).  If they
could, then they were probably from the bank, and I would authenticate
myself to them.  All three people I spoke to said that, "No-one has ever
asked us to identify ourselves!"

The RISKS are clear.  You supply some 'secret' data to the bank so that they
can authenticate you when you call them.  But there is no simple way to
authenticate the bank when it calls you.  You can't ask for the number and
call them back, because you have no way of authenticating the number given.
They're ex-directory, so you can't confirm it through Enquiries, and they
withhold the number so the CLI doesn't show!  If you blindly supply the data
(as clearly many people do), then you may be divulging to a crook the
'secrets' necessary to authenticate yourself to the bank.  The bank has not
thought to provide any means of authenticating themselves.  I suspect this
to be endemic.

Oh, and when I asked what would happen if I refused to authenticate myself
-- they said that my card would be suspended "As a precaution."  So at least
I would know then that it had been the bank I hung up on!


Re: What is your area code, really? ((Koenig, RISKS-21.57)

<Declan McCullagh <>>
Tue, 07 Aug 2001 21:35:02 -0400

> Five minutes later, two police officers showed up at my door, saying
> that they had received a 911 (emergency) call from my home.

I had a similar problem this week. I was visiting my parents and helping my
mother configure a PC that was last used on a university campus. The PC was
still configured for the old area code, and that combined with the "9"
prefix that was required to connect to an off-campus dialup gave a dial
prefix of "911". (That's the police emergency number, for non-U.S. readers.)

Without knowing how to change the default location -- not a trivial task
for a Windows novice -- a person using the computer would have had to edit
the dial string every time they tried to connect. Eventually, no doubt,
someone would have neglected to do so with results similar to what Andrew

The risks here are obvious. Unfortunately the obvious fix -- a prompt
saying "Do you really wish to dial 911 and call police?" if the location is
in the U.S. -- might come as a mild surprise if the user is connecting via
an unusual PBX system that may require a "911" prefix.


Is your phone bill private? Think again...

Tue, 7 Aug 2001 15:03:02 -0500

I suppose this has already shown up and I missed it, but we'll see.  I just
called ATT's customer service line with a question about my bill.  (I don't
recall how many menus deep I had to go to get the answer, and even though it
was too many, that's not my point.)  Somewhere in the process I was asked if
I was calling from the number I was calling about and since I wasn't (I was
at work) I was then asked to enter the number -- and immediately it came
back with a statement about what my bill was and when I'd paid the last one.
I have to wonder what other information I might have been able to get
without having to authenticate myself in any way.

Ted Lee, Minnetonka, MN

Re: Firefighter's phone lines disrupted ... SMS hoax (RISKS-21.55)

<Stanislav Meduna <>>
Fri, 10 Aug 2001 08:06:33 +0200

> The cause was a hoax SMS spreading in the network of one of the GSM
> operators stating that it is possible to make free calls using this
> number.

Slowly the details of the case have emerged and - not surprisingly -
revealed another common risk - a risk of not assessing the effects of a
software change, even if it is fixing a simple bug.

There really _was_ the possibility to make free calls. Let zzz be the
emergency number. If you called zzz, the call was properly routed.  If you
called zzzyyyyyy, a software bug caused zzz to be stripped and the call was
routed to yyyyyy instead. Charging software looks at the beginning of the
number and have seen an emergency number, so such call was not billed.

Then the operator fixed the bug and the fix was analogous to plain old
telephone - ignore remaining digits. Suddenly, all of such calls ended at
the firefighters.

So we are back to software development basics: specify handling of an
invalid input, test the handling and think before you make a fix public. The
fix was good enough for the billing department, but caused massive problems
somewhere else.

Caller ID "hack" not a hack at all (RISKS-21.51)

<"William Kucharski" <>>
Mon, 23 Jul 2001 22:52:16 -0600

In Risks 21.51, Alexandre Pechtchanski wrote of receiving a phone call with
"hacked" Caller ID information.  In fact, it is likely no such "hack"
occurred, nor is a hack necessary.

Caller ID, (actually CNID, Calling Number ID), is based on data that is sent
on trunk lines along with other SS7 signalling data in a phone system. For
home users, this information is normally the originating phone number for
the call, as that is how your local telco has their switches set up.

Things are a bit different for PBX (Private Branch Exchange) systems,
typically found in businesses. They feed directly into telco trunk lines,
and the systems are responsible for feeding their own CNID information into
the telephone network.

Most newer PBXs can be programmed to either send along the originating phone
number of a call or to send a single pre-programmed piece of information. As
an example, a company may want the same information sent (say the company
name and their main incoming phone number) on all outgoing lines so those
receiving calls from the company see the company name and number rather than
the number corresponding to the actual outgoing phone line used to place the

This is all perfectly OK, as CNID data is not and was never designed to be
secure, and is not used for anything but caller ID services.

In Alexandre's case, it's likely a telemarketer either just programmed a
nonsense number into their PBX, or perhaps their PBX came preprogrammed from
the vendor with a "sample" phone number in place (e.g. "John Doe (212)

Note that there is a completely different system, ANI (Automatic Number
Identification), that is used when it is important a caller be properly
identified.  It is ANI information that is used to generate phone
billing records and to provide calling number identification for 911 services.

(For the security conscious, ANI information is also NOT blockable, and
most phone companies offer real-time ANI to their toll-free customers. This
means that even if you have "Caller ID blocking," if you call a company
using their toll-free number, they will have your phone number pop up
on their screen when the phone rings on their end or will receive it in their
end-of-month statement.  This has been ruled fair, as THEY are paying for the
phone call, thus they have a right to know who is calling them.)

The real RISK here is trusting a system that was never designed to be even
remotely secure as a source of accurate information as to the identity of a

William Kucharski <>

ANI is NOT Caller ID (Re: Green, RISKS-21.57)

<danny burstein <>>
Tue, 7 Aug 2001 21:03:13 -0400 (EDT)

This brings up the reminder that Caller Name/Number ID (CNID) is NOT the
same thing as Automatic Name/Number Identification (ANI).

The former, which is what is used by (the vast majority of) homes and
"regular" (non "800") business lines, can be blocked by the caller on
either a permanent per-line basis, or as a choice per-call. (Usually by
prepending a special code, generally "*70", before dialing out).

The latter, which is in use internally by the telcos and by businesses
with (so-called) toll-free (1-800/888/877/866, and soon 855) numbers, can
NOT be blocked  by the caller. Adding in the blocking prepend will NOT
have any effect.

So... whenever you reach out to a tollfree number, the recipient of that
call *will* get your phone number. Which, of course, lets them kick it
through a database for all sorts of other purposes. Sometimes, as in this
case, namely credit card receipt verification, a perfectly valid and
legitimate one.

The RISK: having just enough knowledge (about blocking CNID) to believe
you're keeping info (your phone number) private when no such thing is

DoCoMo thttpd is not thttpd (Re: Poskanzer, RISKS-21.58)

<Fred Cohen <>>
Fri, 10 Aug 2001 07:23:10 -0700 (PDT)

It should be noted that this is not the 'thttpd' from that provides
secure Web services...

Fred Cohen		Fred Cohen &		The University of New Haven.....		Sandia National

Please report problems with the web pages to the maintainer