The RISKS Digest
Volume 21 Issue 73

Monday, 5th November 2001

Forum on Risks to the Public in Computers and Related Systems

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

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


FAA Asleep at the Control Column?
Bill Duncan
Jilted boyfriend hacked into ex-girlfriend's Internet bank account
Kids' learning game site becomes porn site
Anonymous e-mailer convicted of cyberstalking
Declan McCullagh
Sony uses DMCA against Aibo Enthusiast's Site
Monty Solomon
RU-Blue? or RU-Yellow?
DeCSS is Speech
James S. Tyre via David Farber
Risks of concentrated power and the surveillance state
Peter Wayner
Risk of monoculture and exponential false AV positives
Devon McCormick
Fake ID anyone?
Tim Rushing
Bank assets disappear, convert customers into Euro-peons
Paul van Dijken
DoS attack on Mac OS9
Erann Gat
Conference management software reveals "hidden" authors
Michael Ortega-Binderberger
Insecure promo from American Express
Cameron Simpson
Re: ACT Election Electronic Voting
Henry Grebler
Re: TD Bank Canada system crash
Przemek Skoskiewicz
Re: Stray bomb caused by typo
James R. Cottrell Jr.
Re: Int. Conf. on COTS-based Software Systems
Kearton Rees
Info on RISKS (comp.risks)

FAA Asleep at the Control Column?

<Bill Duncan <>>
Sun, 4 Nov 2001 17:15:16 -0500 (EST)

A few days ago while looking through the e-mail rejection logs, I was
surprised to find some e-mail blocked by virtue of being in an RBL list and
coming from a host in the FAA.GOV domain.  The e-mail was obvious spam, as
I'd blocked the same sender (from a domain in the UK) from various other

Being a new private pilot and with the recent of September events fresh in
my mind, I quickly investigated.  Sure enough, there was a host on their
network, loaded with software from that outfit in Redmond, and happily
spewing relayed mail.  (I tested whether it would relay mail from anywhere
to anywhere else by telneting to its smtp port.)

Furthermore, to get on this exclusive RBL list, the e-mail relay must've
been in operation for some time.

Imagining scenarios where relaying e-mail through the FAA system might at
best be an embarrassment, and at worst might be some kind of a security
threat, I immediately e-mailed whatever addresses I could find on their
website as well as the usual etc.  So far, no response,
and according to my log files, I'm still rejecting spam from them.

While many US Federal Government agencies are discovering the virtues of
Open Source for security, I'm dismayed to find that the FAA is still using
software well known for insecurities on their website as well as other hosts
connected to the Internet.  Getting junk e-mail relayed through the FAA might
be just an annoyance, but it might also point to other security issues

So if you get any e-mail from the FAA, be careful.  It's probably just
SPAM, but it might be worse.

  Follow-up: Mon, 5 Nov 2001 15:41:11 -0500 (EST)

I didn't want to include the identifying IP address in the original
submission, to protect the guilty, but it looks like they took it off this
morning.  I tried pinging the address and they are no longer there.  The
last SPAM which was sent my way from that address was at 1:15 this morning

Although I e-mailed about 4 addresses at the FAA, including one for emergency
response, I've received no replies as yet.  But I guess the message finally
got through this morning.  Maybe they'll take it as a wakeup call, which I
didn't think they'd really need after the recent events...

Here's the last log entry from my mail log, with the local address changed.
I'm using Exim.

2001-11-05 01:15:18 recipients from [] refused
2001-11-05 01:15:18 recipient <> refused
  from []
  sender=<> (host_reject_recipients)

Bill Duncan, VE3IED
+1 416 693-5960

Jilted boyfriend hacked into ex-girlfriend's Internet bank account

<"Peter G. Neumann" <>>
Wed, 31 Oct 2001 9:37:30 PST

After their relationship ended, Cheug Wing-hang took 420 pounds (HK?)  from
his girlfriend's HSBC Internet bank account.  He was convicted on four
counts of theft and five counts of dishonest computer access.  The *South
China Morning Post* reported he will be sentenced on 13 Nov 2001.

  [Despite the lack of specificity on what kind of pounds were involved,
  we can assume that his girlfriend did not weigh more than 500 pounds.]

Kids' learning game site becomes porn site

<"Peter G. Neumann" <>>
Wed, 31 Oct 2001 10:10:48 PST

The Web sites at and once housed an online
interactive children's game created by Ernst & Young to help youngsters in
grades 6 to 8 learn about finances.  Recently, E&Y gave up the .org domain,
which has now become Euro Teen Sluts (TM), registered in Yerevan, Armenia.
Old bookmarks beware.  [Source: The Washington Post, 25 Oct 2001; PGN-ed]

  [I presume that this issue of RISKS will succumb to some filtering
  because of its mentioning the name of the new owner of the domain.]

Anonymous e-mailer convicted of cyberstalking

<Declan McCullagh <>>
Wed, 31 Oct 2001 08:39:46 -0800 (PST)

A California man who used a public library computer terminal to send
anonymous e-mail threats to a Michigan man has been convicted by a jury of
cyberstalking.  The prosecution used circumstantial evidence to prove its
case, since no logs of the e-mails or computer users were kept by the

Sony uses DMCA against Aibo Enthusiast's Site

<Monty Solomon <>>
Thu, 1 Nov 2001 20:39:12 -0500

Sony Dogs Aibo Enthusiast's Site

Courts: The company uses a controversial law to stop owners from altering
the robotic pet. Some consumers balk.

Sony Corp. is using a controversial U.S. law aimed at protecting
intellectual property to pull the plug on a Web site that helps owners of
Aibo, Sony's popular and pricey robotic pet, teach their electronic dogs new
tricks.  Aibo owners are outraged, and hundreds have vowed to stop buying
Sony products altogether until the company backs off. Sony has sold more
than 100,000 Aibos worldwide since 1999, at prices ranging from $800 to
$3,000. The dogs have spawned a community of enthusiasts who fuss over the
mechanical marvels as if they were real canines.  [Source: Article by Dave
Wilson and Alex Pham, *Los Angeles Times*, 1 Nov 2001]

RU-Blue? or RU-Yellow?

<"Peter G. Neumann" <>>
Thu, 1 Nov 2001 19:59:47 PST

The United States is changing the color of food ration packets it is
dropping in Afghanistan because they are the same color — yellow — as
unexploded cluster bombs.  Gen. Richard Myers, chairman of the Joint Chiefs
of Staff, said the United States will change the color of the food packets
to blue.  [Thanks to Mike Hogsett, from]

  [Now, you will get very "blue" if you choose the yellow,
  and you will be "yellow" if you do not choose the blue.
  Watch out for the Yellow Submarine Sandwich.  PGN]

DeCSS is Speech (James S. Tyre, from IP)

<David Farber <>>
Thu, 01 Nov 2001 19:07:37 -0500

  [Summary: Source code is speech.  Object code is not speech.  PGN]

>Date: Thu, 01 Nov 2001 13:02:54 -0800
>From: "James S. Tyre" <>
>Subject: DeCSS is Speech

>> "Like the CSS decryption software, DeCSS is a writing composed of computer
>> source code which describes an alternative method of decrypting
>> CSS-encrypted DVDs.  Regardless of who authored the program, DeCSS is a
>> written expression of the author's ideas and information about decryption
>> of DVDs without CSS. If the source code were "compiled" to create object
>> code, we would agree that the resulting composition of zeroes and ones
>> would not convey ideas.  (See generally Junger v. Daley, supra, 209 F.3d
>> at pp. 482-483.)  That the source code is capable of such compilation,
>> however, does not destroy the expressive nature of the source code
>> itself. Thus, we conclude that the trial court's preliminary injunction
>> barring Bunner from disclosing DeCSS can fairly be characterized as a
>> prohibition of "pure" speech."

> This is *not* from the Second Circuit, where we did the amicus brief.
> This is from the California state court trade secrets case, DVDCCA
> v. Bunner, in which the court today reversed the preliminary injunction
> issued against the Defendants.  PDF Opinion:

> James S. Tyre                     
> Law Offices of James S. Tyre          310-839-4114/310-839-4602(fax)
> 10736 Jefferson Blvd., #512               Culver City, CA 90230-4969
> Co-founder, The Censorware Project   

For IP archives see:

Risks of concentrated power and the surveillance state

<Peter Wayner <>>
Fri, 26 Oct 2001 08:45:55 -0400

  Federal prosecutors said Mr. Hanhardt used law enforcement computers and
  other databases to get information on traveling jewelry sales
  representatives, including itineraries and car rental information.
  Prosecutors said many of the thefts were from the rented automobiles.
  *The New York Times*, 26 Oct 2001]

Mr. Hanhardt was Chief of Detectives for the Chicago Police Department.  His
gang, which operated from the early 1980's to 1998, reportedly stole more
than $5 million.  This may not be the best estimate because as part of his
plea bargain, he's going to pay $4.8 million and cash equal to half of the
equity in his home.  There were 6 people in the gang.  We probably don't
know the full extent of his crime spree.

Risk of monoculture and exponential false AV positives

<Devon McCormick <>>
Sat, 27 Oct 2001 09:04:53 -0700 (PDT)

I'd like to point out two related risks: the risk of monoculture and the
risk of a potential exponential increase in spurious collisions between
legitimate software and anti-virus.

First, I'll summarize a complaint (on a mailing list) from a consultant: a
popular AV (anti-virus) software package may be disallowing operation of
normal software as being possibly viral.  Of course, the "safe" solution The
AV chooses is to disallow some file access by the offending software.

This simplistic, inflexible default is exacerbated by similar inflexibility
on the part of the IT group which tends toward monoculture, admittedly in
the face of overwhelming complexity.  By monoculture, I mean restricted
support of or interest in any software outside a narrow list of approved

The consultant uses a niche product with which the IT department is
unfamiliar, therefore they lack the competence to check out his claim of
innocence so he must assume the burden of proof.  Furthermore, he has no
authority to conduct a simple test, switching the anti-virus off and on
again to show that it, not his software, is the problem.

The risk of monoculture is further raised by the speculation that the the AV
conflict may be caused by his software directly writing files with binary
data instead of using a more standard, and increasingly more common, access
method such as ODBC.

This leads us to the 2nd risk: (possibly) exponentially increasing AV false

I once had a similar problem with an AV: an optimization I was running
triggered a virus warning and stopped the run.  I suspected that the bit
pattern of an intermediate file was matching that of a "known virus", so I
shortened the inputs to the optimization by the least significant digit,
thus slightly changing these intermediate values, and it ran without a
problem after that.  Fortunately I knew my results were not sensitive to
such a small change.

As in the case above, I was using specialized, niche, software.  However,
the other risk this illustrates is the realization that the number of false
positives from AV is the product of 2 numbers: how may different signatures
(indicators of known viruses) being checked and the number of different
intermediate results any software may produce.

Both of these factors are increasing over time.  This increase may be
exponential (in the loose sense) because, at first glance, this likelihood
of collision resembles the Birthday Problem.  This is the well-known,
non-intuitive result that there's about a 50% chance that 2 people, out of a
random group of 25 or 26, will share a common birthday.

Similarly, the chance of a spurious AV hit depends on the
product of the linear increase of the 2 factors mentioned.

Fake ID anyone?

<Tim Rushing <>>
Thu, 25 Oct 2001 09:55:14 -0500

I live in Indiana and recently lost my wallet on a weekend.  I was
pleasantly surprised that the bank allowed me to cash a check without id or
check card by punching my ATM code into the keypad at the teller's window.
However, the process for actually getting my license replaced at the state
license bureau was not as inspiring.

Initially, I was impressed.  I had gone with an expired passport (picture
taken in 1986 when I was much younger and lighter), bank statement and a
number of other items.  When I arrived, they compared my proofs of identity
against a checklist.  Apparently, various items are worth between 1 and 6
points, with a valid driver's license worth 6 points and my bank statement
worth 1.  You need 6 points to get a driver's license issued to you.  With
the passport, I had 7 points.  Unfortunately, the passport was only worth 3
if it was less than 2 years expired.

So, armed with the list, I made another trip home and easily returned with 8
valid points.  I made it past the screener to get to the person at the
terminal who actually sets up the license.  She also carefully checked
through all my documentation, handed it back to me, turned to her computer
and asked, "Name?"  She even had my spell my last name.  No attempt to
correlate the name with the documentation and she had written nothing down
from my paperwork.  Now, Indiana does have digital pictures on the license,
so it is possible that once she pulled it up, she had a picture of me to
look at.  I wasn't reassured.

Once again, a great demonstration that a well-designed security system can
be easily undermined in implementation.

Tim Rushing

  [And airlines are contemplating using smart cards for fast access by
  passengers!  PGN]

Bank assets disappear, convert customers into Euro-peons

<"Paul van Dijken" <>>
Wed, 31 Oct 2001 22:49:12 +0100

On 29 Oct 2001, my sister and brother-in-law experienced one of their worst
nights ever.  When trying to pay some bills using the Internet site of the
SNS bank (one of the major banks in the Netherlands), the transactions were
rejected, because no sufficient amount was available.  This was strange,
because normally a couple of thousand guilders (a few thousand dollar, about
half) should be there.  When he checked his savings, the entire amount was
gone.  All accounts had a zero amount.

Thinking on how they should pay the new shoes for the children, etc., they
lay awake all night.  The next morning, my brother-in-law arrived at work in
a terrible temper.  When asked, he explained to his colleagues the entire
story and tried to show it.  To his relief, all amounts were back, but this
time in euros.  Apparently the bank had gone through the euro conversion
that night, but failed to shutdown its website or to warn its customers.

Fortunately, my brother-in-law has a strong heart.

  [Good thing.  He needed a Eurologist, not a Cardiologist.  PGN]

DoS attack on Mac OS9

<Erann Gat <>>
Mon, 5 Nov 2001 11:51:53 -0800 (PST)

This is an old RISK, but I haven't seen it mentioned here before.  Macintosh
OS9 comes with a "multiple user" control panel that provide password
protection.  Trouble is, to change a password you don't have to type in the
old password again, and you don't have to confirm the new password.  So a
malicious user who gains physical access to the machine can render that
machine useless by changing the password and shutting the machine down.  You
get the same result from a typo too.  If what you actually typed as your new
password isn't what you think you typed you're hosed.  Poor Apple.  They
must be finding it hard to get good help these days.

Erann Gat <>

Conference management software reveals "hidden" authors

<Michael Ortega-Binderberger <>>
Fri, 26 Oct 2001 00:56:30 -0700 (PDT)

Conference paper submissions are hardly a life and death issue, but I just
found a problem when submitting a paper.

The ACM SIGMOD conference is in its second year of a new double blind
reviewing policy to improve fairness. You register a paper, write the names
of the authors in a form, but not in the actual pdf submission, which only
carries the paper id. In this environment, the idea of keeping authors
hidden is of some value.  While registering a paper, the Microsoft
conference management software told
me one of my co-authors was already registered in the system, and whether I
truly wanted to add him to my paper. This was my advisor, and as it turns
out, another student is also submitting a paper, which is fine.  But in
general I could register any bogus paper, and give names of "competitors"
and find who else is up to submitting papers to the conference. An
interesting vulnerability given the stated aims of double blind reviewing.

Michael Ortega-Binderberger, CS U.Illinois Urbana, on loan to U.C. Irvine,,,

Insecure promo from American Express

<Cameron Simpson <>>
Mon, 5 Nov 2001 21:57:39 +0000

Today I received an an e-mail from AmEx promoting its Online Services, with
offers of a chance to win lots of reward points if I sign up. However, there
are enough bogus things in this missive to make me want to check very
thoroughly that this actually comes from AmEx.

The first, and minor, point is the From: address:
[Numbers mangled for privacy reasons.]

Looks pretty bogus, eh? I suspect that it's a bounce detector from the shape
of it. [Checks... the MXs are and
which are pretty suggestive.] There's even a note at the bottom of the
message saying "Please do not reply to this e-mail for any enquiries -
messages sent to this address cannot be answered." It's only a list removal
address, with apparently a 3 week(!)  implementation time.

The second, and major, point is the contact URL. Look at this:
	[I've stripped off the identifying parameters.]

There's no sign whatsoever that this is a bona fide AmEx host! A whois on says nothing useful either:

	Domain Name: TM0.COM
	Whois Server:
	Referral URL:
	Updated Date: 27-oct-2001 doesn't give an answer at all. So this would easily be a bogus
domain by someone harvesting credit card information. Now, I happen to have
a tool for this kind of thing and it says:

	REDIRECT(302) to
	REDIRECT(302) to
	REDIRECT(302) to
	REDIRECT(302) to

and off into https land it goes. So this URL does hand off to Amex (with
great inefficiency), and so the necessary degree of subversion is somewhat
greater, requiring some DNS hacking. Or at least it does if my query tool
goes there (in my paranoid musings I can imagine the server only
behaving suspiciously if the User-Agent matches one of the popular browsers,
which my tool does not.)  But how is the average user to check this? They
can't. I expect I should be thankful (I'm merely surprised) that this was a
plain text message; if it were HTML then recipients would have even less
hint about the suspect URLs.

What else to fear? The opening URL is plain HTTP, liberally adorned with
presumably identifying numbers. Somewhat insecure also.

If done properly, this should have been a direct HTTPS like to an
obviously AmEx owned domain. There are no contact details on the e-mail
except these URLs. I call AmEx customer service and the first thing they
want is my card number. I'm now sufficiently soured on the whole thing
that I just put the phone back down:-(

The RISK? Aside from the chance this actually is a scam (which I doubt, but
only after digging around a bit), this is exactly the kind of message the
naive user should never respond to. Yet such practices, like M$'s loathsome
practice of publishing documents as .exe files, actively encourages such
laxness and complete faith in third parties. Yea, even in *unknown* third
parties as in this case!

This does nothing for my confidence in them, and is somewhat ironic while
they're actively promoting their "blue" smartcard enhanced credit card,
which somehow offers improved fraud security (in totally nebulous terms
as near as I can tell so far).

Cameron Simpson, DoD#743

Re: ACT Election Electronic Voting (Polette, RISKS-21.72)

<Henry Grebler <>>
Wed, 31 Oct 2001 09:57:44 +1100

> The 11,340 pre-poll electronic votes were supposed to have been counted just
> after the polls closed at 6pm AEST but took about 90 minutes ...

Give me a break! These numbers just don't add up. "11,340 pre-poll
electronic votes" would not strain the resources of my $2 calculator.
"discs for the eight polling stations" - in other words, 8 floppy disks -
took 90 minutes to load ... because the entire population of Australia who
actually cared enough to access the website - that's all 10 of us - resulted
in them "getting lots of hits on our internet site".

They may well have had problems, but the evidence presented does not support
the conclusions.

Finally, paying attention to the so-called problem of getting delayed
results runs the RISK of not addressing all the real security RISKS
mentioned in previous editions of RISKS.

Re: TD Bank Canada system crash (Akerman, RISKS-21.72)

<"Przemek Skoskiewicz" <>>
Mon, 5 Nov 2001 17:11:00 -0500

> The bank's computer systems have all sorts of "redundancies" built in ...

and the very next entry from PGN describes "ANOTHER SRI-wide Power Outage"
due to the pressing of an incorrect button!

Sometimes I feel that RISKS readers expect to live in a perfect world. A
remarkable thing about the Toronto-Dominion bank failure would be if it had
accepted the transactions and lost them, or erased customer data, rather
than it being down for the weekend. Do we really expect to spend so much
time and money designing our systems against *every* conceivable occurence?
Besides an inconvenience, was the bank's downtime really such a dramatic
event that it ought to have designed against random board failures?

And what about the SRI's power failure? I'm sure that SRI's power backup
systems are some of the best thought-through and designed systems in place,
yet one press of the wrong button took them down. Does this mean that their
design was an utter failure and they should start from scratch?

I think that sometimes we are better off accepting such "random" occurences,
not bothering too much about them and treating them as normal annoyances of
modern life. Like whenever I walk out of my apartment and there are 3 empty
taxis lined up in front, but whenever I actually need one, there isn't one
for miles, :-(

Przemek Skoskiewicz

Re: Stray bomb caused by typo (Jacobson, RISKS-21.71)

<"James R. Cottrell Jr." <>>
Mon, 05 Nov 2001 14:10:45 -0500

I believe the submitter missed the point of the original submission.  If the
check digit is calculated such that transposition of two legal values
(latitude 89.0 and 80.9) provides a different value, then it doesn't matter
that all possible latitudes are valid.  I believe this was done with bank
account numbers in the 1970s to reduce/eliminate typos.

Jim Cottrell  1-781-271-6475

Re: Int. Conf. on COTS-based Software Systems (RISKS-21.70)

<Kearton Rees <>>
Thu, 25 Oct 2001 14:26:57 +0100

In Europe the UK-based Safety-Critical Systems Club
( has also been looking at the issues raised
by the use of COTS, in this case for use in safety-critical systems - April
2001 (

Kearton Rees, BTexact Technologies, Adastral Park, Martlesham,
Ipswich IP5 3RE, UK

Please report problems with the web pages to the maintainer