The RISKS Digest
Volume 20 Issue 40

Tuesday, 18th May 1999

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…


o Nuclear plant Y2K: High risk-readiness or high-risk readiness?
Mike Perry
o Biometric risks
Dan Wallach
o Singaporean ISP scans users' PCs
Andrew Brydon
o ATMs gobble up cash cards
John Colville
o Web browsers, URL collisions, and all that...
Zygo Blaxell
o False Viruses
Thomas Gilg
o HotMail is no Early Bird: happy99.exe
Malcolm Pack
o Virus cleaner corrupts e-mail database
Diomidis Spinellis
o MIME-Messages: quoted-printable chars in URLs
Christoph Conrad
o New-fangled petrol pumps
Ian Chard
o Re: C compilers vs editors: WYSI NOT ALWAYS WYG
Roy O. Wright
o Re: Wrong e-mail address
Andrew J Klossner
o Re: Risks of 3-letter user IDs
Thayne Forbes
o Dimwitted naughty-word filtering lives...
Daniel Rutter
o REVIEW: "Removing the Spam", Geoff Mulligan
Rob Slade
o Info on RISKS (comp.risks)

Nuclear plant Y2K: High risk-readiness or high-risk readiness?

"Perry, Mike" <>
Mon, 17 May 1999 16:05:42 +0100
I read this last week on's news site (

  A US nuclear plant has received a warning from the Nuclear Regulatory
  Commission (NCR) after fears were raised over the Y2K readiness of an
  emergency backup generator.  Massachusetts Congressman, Edward Markey,
  said the NRC has written to the Pilgrim nuclear plant expressing concern
  that the generator will not be able to keep the facility safe in the event
  of a Y2K blackout.  The plant's owner said the problem will be solved by
  adjusting the temperature limit for the generator.

Well, that's alright then, I don't suppose that the temperature limiter
serves any valid safety purpose, nor that running it outside the limits
prescribed by the manufacturers carries any RISKs....

Mike Perry  Data General Ltd

Biometric risks

Dan Wallach <>
Fri, 14 May 1999 14:51:51 -0500
Bank United of Texas has said they're about to introduce retina scanners to
authenticate their customers to an ATM [1].  No more PINs.  No more plastic
cards.  The article says they'll be using technology from Diebold, although
no such technology is described on Diebold's Web page [2].

RISKS readers should be well aware that there are three different kinds of
authentication (something you know, something you have, or something you
are), and relying strictly on any one is a recipe for disaster.  A
particular concern with purely biometric authentication systems is that
there's no way to revoke your retina and get a new one.  If somebody manages
to make a copy, you're out of luck.

Says the article: "In response to questions about privacy concerns, Bank
United said the iris pictures will not be distributed to anyone outside the

Naturally, this is deeply unassuring.  Even assuming we don't have bad guys
going around cutting out people's eyes, and even assuming the ATM vendor is
smart enough to verify the eye has a pulse (i.e., it's still connected to
its owner's head), there isn't a whole lot preventing some other vendor from
photographing your iris and using your biometric against you.

Also from the article: ``It has a very high cool factor,'' Coben said. ``We
think of it as James Bond meets stocks and bonds.''

Hopefully, Bank United will have a golden eye for detail, and will never say
never again to poor authentication.  I wouldn't want my optometrist, Dr. No,
to have a view to a killing in ATM crime.

Dan Wallach, Rice University


  [This message is clearly not just for YOUR EYES ONLY, but should
  scare THE LIVING DAYLIGHTS out of others as well.  However, with
  potential eye damage from miscalibrated units, remember that
  YOU ONLY LIVE TWICE (pronounced "TWO-EYES").  With all this Bonding
  going on, there must be a SCAN-DOLL in there somewhere.  PGN]

Singaporean ISP scans users' PCs

Andrew Brydon <>
Sat, 15 May 1999 07:09:50 +0100
Daily Telegraph (UK) Thursday 13th May 1999 - Connected (IT pullout) p.2

Singaporean Internet provider SingNet has apologised to its subscribers
after scanning their PCs without their knowledge. SingNet asked the
Singaporean Home Affairs Ministry to help check the computers of its 200,000
subscribers in the wake of the damage caused by the CIH virus.
Unfortunately for SingNet an anti-hacking program being used by a customer
picked up scanning, which was reported to the police. The scan was traced
back to the government. The company says it did not look at any confidential
files but did find that 900 subscribers have virus- infected computers.

Andrew Brydon, Systems & Software Safety Analyst

ATMs gobble up cash cards

John Colville <>
Mon, 17 May 1999 09:16:37 +1000
From AAP via Sydney Morning Herald, Monday may 17, 1999, p4
with insertions by JC in [ ].

Many St George Bank [Australia's fifth largest bank] customers were left
short at the weekend when automatic teller machines gobbled up their cash
cards as the bank installed a new computer system.

The bank refused to say how many customers lost their cards.  [The bank
probably do not know how many cards were 'gobbled' yet because they were
closed from their normal Saturday morning trading in preparation for the

A spokesman said the problem occurred because of the expiry dates on certain
cards.  Canberra resident, Mr Steve Pye, who lost his card on Saturday, said
there would be no replacements until Wednesday for "people like me with no
money in my pocket . . .  "I'm as mad as hell about it."

John Colville, University of Technology, Sydney
Broadway, NSW, Australia, 2007  +61-2-9514-1854

Web browsers, URL collisions, and all that...

Zygo Blaxell <>
16 May 1999 04:05:45 -0400
This happened to me the other month: an interesting interaction between two
convenience features in web browsers and operating systems.

Where I work there is an internal server (let's call it 'qqq') that
maintains some data used by the group I work in.  The machine generates test
data and serves dozens of report pages all hyperlinked together and
accessible via a web client.  Because it's on a corporate intranet, all
desktop machines that can access the server happen to be configured such
that they are able to use the short version of the server's name, rather
than the long version of the name.  So instead of typing "",
users can just type "qqq" and the client's OS configuration for DNS lookups
will find the right host.  This is a convenient, time-saving feature.

On the public Internet, by contrast, there is a widespread convention for a
web server owned by "The Example Corporation" to be named "".
No doubt this convention was influenced by Netscape's decision to
automatically expand bare hostnames typed into the "Location" field by
prepending "www." and appending ".com".  So instead of typing
"", a user can just type "example".  This is a convenient,
time-saving feature.

Some months ago, the nameservers here at my employer were slightly amnesic,
and kept forgetting the DNS entry for our server.  So some mornings we would
type 'qqq' into the Location: field of Netscape, and we would get "server
does not have a DNS entry," because neither 'qqq' nor '' nor
'' existed.  Although Netscape only reports 'qqq' in the dialog,
it does report the other names it tries in the status bar.  This is mostly

One day, somebody set up a web site under the name ''.

From then on, whenever my employer's DNS server forgot the IP address of
'' but could find '', Netscape would decide that
when I typed 'qqq' I must have meant '', since neither 'qqq'
itself nor '' exist, and would proceed with its request using
the new host name.

To make matters worse, Netscape can sometimes do this even after it has
already done the DNS lookup on the host name.  If this happens at just the
wrong time, it means that the remote system with the similar name gets all
the information we would have sent to our own server: names and passwords
used to authenticate with the local server, any cookies set by programs on
the server, and usually a few user ID's and file names in the URLs.

If our clients were point-of-sale terminals, this data could have included
everything from credit card numbers and purchase details to complete credit
histories from applications for financing.

Interestingly enough, this problem never happened at one of my former
employers, which has a different policy for corporate host names.  They
insist on naming all hosts according to a company-wide encoding system that
includes machine type, function, location, partial encoding of the IP
address, and a check digit, which results in tens of thousands of machines
with host names like "n3rndghh" or "amhjrxml".  To date I know of nobody who
has ever registered the domain name "", nor any other .com
domain name that is valid in the scheme used by my former employer, so there
have probably been no such collisions to date (although of course it's
always possible to cultivate one).

Zygo Blaxell, Linux Engineer, Corel Corporation. (work) or (play).

False Viruses

"GILG,THOMAS J (HP-Corvallis,ex1)" <>
Mon, 17 May 1999 15:08:59 -0700
When the Melissa virus hit, everyone in our R&D software lab updated their
virus checkers and went into inoculation and quarantine mode.  Several weeks
later, I tried to run one of my old utility applications written in
Microsoft Visual Basic (VB) and compiled into a .exe, and it was suddenly
flagged as a "Backdoor.Trojan" virus.  While the UNIX & Java in me saw great
humor in it, I was no longer able to run a useful app.

Debugging the situation, I found that some function calls from a VB app into
a Visual C++ COM object resulted in some VB .exe code that looked like a
virus. Changing the type, order and number of parameters in a function call
and/or changing the location from which the function call was made would
influence whether or not the resulting .exe looked like a virus.  For those
interested, I spent most of my time reproducing the problem with:

   .idl:    ... HRESULT test([in] BSTR foo, [in] int bar)
   .h:     STDMETHODIMP(test)(/*[in]*/ BSTR foo, /*[in]*/ int bar)
   .cpp  STDMETHODIMP MyClass::test(BSTR foo, int bar)

   .bas   mc.test "Hi", 2

I reported the problem to the virus checker company, and they confirmed some
"false detection" cases. Fortunately for both of us, their latest virus
definition update contained a fix for this problem.  Unfortunately for some
other folks in our lab, they ran into the same false virus alert with their
VB apps and they removed them without question.

Clearly viruses and the code to detect them are getting extremely complex,
so the opportunity for false alerts will do nothing but rise.  It also
occurred to me that the publication of false alert notices has its own set
of risks.

Thomas Gilg, R&D Software Engineer, Hewlett-Packard

HotMail is no Early Bird: happy99.exe

Malcolm Pack <>
Sat, 15 May 1999 08:57:59 +0100
A colleague at work was browsing his personal e-mail on HotMail, and asked
me innocently if I knew what "HAPPY99.EXE" was, since someone he knows had
sent it to him as an attachment. I explained that it was a "worm", and he

o   Delete it in situ, rather than download it.
o   Inform the sender of their infection.
o   Point them at a URL with suitable removal instructions[0].
o   Advise them to contact other people they might have e-mailed
    recently and warn them of the worm, etc.[1]

He also elected (belatedly) to run HotMail's live Virus Scan,
ostensibly an implementation of NAI's McAfee, over the attachment.

It reported nothing amiss.

Note that locally-running versions of McAfee Virusscan will correctly
identify the worm as W32/Ska.exe.

I have requested an explanation from HotMail, and will forward what I

In the meantime, trust no one[2].

[0] Interestingly, an Infind <> search for
    sites referencing "HAPPY99" turned up one personal site which
    offered for download an executable to effect removal. I
    naturally chose to ignore this program of unknown provenance.
    Oh, how the risks mount up.

[1] So we have a whole series of legitimate e-mail warnings flying
    around in competition with the hoax e-mail warnings flying
    around and the warnings to ignore the hoax e-mail warnings
    flying around and...

[2] Especially if his initials are BG, and his company creates
    operating systems which are virus-friendly[3], but owns an
    on-line mail system which seemingly fails to spot those
    same viruses.

[3] And publically blames anti-virus software for a third of all
    crashes of its most "robust" OS.

Malcolm Pack <>

Virus cleaner corrupts e-mail database

Diomidis Spinellis <>
Tue, 18 May 1999 11:39:59 +0200
I was told the following story by an associate who is managing a large
distributed IT installation.  The administrators at one site installed an
anti-virus product on a machine running the Microsoft Exchange e-mail
server.  Exchange keeps all incoming mailboxes in a monolithic database
of a proprietary format.  The administrators enabled a parameter of the
virus scan program to automatically clean the virus-infected files.  The
virus scanner detected an instance of the CAP macro virus in a mail
attachment WITHIN the Exchange database and proceeded to "clean" the file by
performing an in-place modification on it.  As a result the database was
corrupted, users could not access their mail, and subsequent attempts to
repair the database using the facilities provided by Exchange failed.
Eventually the database was recovered from a backup resulting in lost e-mail
messages.  There are many lessons that can be drawn from this story; I would
like to emphasise the risks of proprietary, opaque, or gratuitously
complicated file formats such as those used by Microsoft Word documents, and
the Exchange database.  Architecting and implementing an efficient,
extensible, and functional file format and interface can be difficult and
expensive.  However, the cost is most cases justified the resulting
robustness, openness, usability, and extensibility of the system.

Diomidis Spinellis, University of the Aegean

MIME-Messages: quoted-printable chars in URLs

Christoph Conrad <>
17 May 1999 07:19:56 +0200
Recently I made a request for an X509-certificate. The certification
authority (CA) mailed me an URL for fetching my certificate, but it didn't
work. It looked like ([...] parts are omitted by me):


So I wrote back to them and they answered that the last five digits are
five seven seven four six, before the equal sign. I realized that this is
a problem with MIME quoted-printable handling.

The real URL was:


"=57" is also a quoted printable char and means "character with value
0x57", this is a 'W'!

New-fangled petrol pumps

Ian Chard <>
Thu, 13 May 1999 21:50:38 +0100 (BST)
I filled my car up with petrol today with one of these new-fangled petrol
pumps that lets you stick your credit/debit card in, fill up you car and
then drive away without having to queue up in the shop.  I didn't really
trust the pump (and I thought the poorly trained staff might think that I
was just driving away without paying), so I asked it for a receipt.  I
reached under the pump (where the printer is), grabbed the receipt, and
drove away.

When I got home, I fished the receipt out of my pocket, and it struck me
that the 28 quid I had been charged was rather more than my car could hold.
"Hmm," I thought, "maybe the prices have gone up".  I then noticed that the
card type was "MASTERCARD", which I don't have.  "Hmm," I thought, "maybe it
just represents Switch (my card type) as Mastercard.  Then I noticed that
the first digit of the (full) card number on the receipt was a 5, whereas
mine was a 6.  Then the penny dropped.

The printer took rather longer than I thought to print the receipt.  What I
got was someone else's receipt, with their full credit card number and
expiry date.  To my horror, I also realised that the next customer will get
my card number and expiry date.  Alas, it was now 30 minutes later, and my
details are almost certainly in someone else's pocket.

The RISK here is not only that old adage about not printing the full card
number when the last five digits will do.  I wouldn't have had a problem if
the thing had said "PRINTING PLEASE WAIT".  What it did say was "PLEASE TAKE
RECEIPT FROM BELOW PUMP".  I looked, saw a piece of paper, and took it.

Ian Chard, Sheriffmuir <>  +44 976 249081

Re: C compilers vs editors: WYSI NOT ALWAYS WYG (Graifer, RISKS-20.39)

"Roy O. Wright" <>
Mon, 17 May 1999 17:02:06 -0500
In MS Visual J++, Microsoft will sometimes use a single carriage return as a
line terminator.  As pointed out by Daniel Graifer, this can introduce bugs
when moving the source code to a different compiler - EVEN ON THE SAME
PLATFORM (ex. Semantic's Visual Cafe and the Sun's Java SDK on MS Windows)
This looks like either an attempt to lock a developer into one set of tools
or very sloppy design.

The two workarounds I have found are to either load the source file into an
editor that recognized "\n", "\r", & "\r\n" as line terminators (ex. PFE)
then resave the file, or to write a filter to handle the translation.

Roy Wright, Cisco Systems 1-512-378-1234

Re: Wrong e-mail address (Wampler, RISKS-20.39)

Andrew J Klossner <andrew@pogo.WV.TEK.COM>
Mon, 17 May 1999 16:36:17 -0700
All the risks that Bruce Wampler mentions for misaddressed e-mail have been
present for centuries with misaddressed paper mail.  Mangle one digit of a
street address and your envelope can quietly go to the wrong place.  It's
then up to the good graces of the inadvertent recipient to reroute it and to
respect its confidentiality.

The only difference I note is that important but misaddressed paper mail has
a noteworthy appearance to distinguish it from bulk commercial
advertisements, and is therefore less likely than e-mail to be discarded

Andrew Klossner (

Re: Risks of 3-letter user IDs (Yurman, RISKS-20.39)

Mon, 17 May 1999 12:28:40 -0400
It's worse than he thinks.  First, I spoke with a friend who works at
Hotmail and they currently have about 43 million subscribers.  Surprisingly,
about 1/3 log in every day.  Assuming yahoo! and the rest are in the same
ballpark, then Dan is off by an order of magnitude.  Furthermore, people at
these sites frequently get mail that was meant for the same username at
another site.  I.e. jsmith@hotmail gets mail meant for
Their friends just can't remember what site they are at.  (I have this
problem with my kids, who all have free accounts SOMEwhere).  Lastly, I
would have thought that I could get an account with my name (thayne) but
could not.  I got forbes_thayne, but was surprised to learn that there is
actually someone else on the net with the same combination of slightly
unusual names.  I guess the lesson is that when you are dealing with
millions of monkeys, anything is possible.

Dimwitted naughty-word filtering lives...

Daniel Rutter <>
Mon, 17 May 1999 17:24:45 +1000
I'm a subscriber to the Healthfraud discussion list (e-mail for info), and every now and then get a warning
e-mail from the Healthfraud ezmlm program telling me that messages to me
have been bouncing, with the usual note that if the warning bounces too I'll
be unsubscribed.

Often, the bounces are because my mailbox has been filled. My ISP here in
Australia, Dialix (, allows its users only a 1Mb
mailbox, which is OK with me because I check mail often and can access the
local Dialix mail server much faster than the other couple of servers
available to me. If a friend decides to send me a monster AVI file, though,
a few messages will bounce before I clear the blockage.

Other bounces, though, are because of "suspicious keywords in FROM:",
according to the Dialix mail server error message; some source e-mail
addresses don't pass muster with the server. For this reason, I will of
course never see the error messages myself unless something, like ezmlm or a
human with a different e-mail address from the one that bounces, brings them
to my attention. I have just discovered that these "suspicious keywords" are
defined to include dirty words, even if these words are coincidentally
included in an innocuous non-spam e-mail address, on the assumption that any
e-mail address with a dirty word in it must be from a spammer spruiking a
sex site, or some such.

So, for example, messages to the Healthfraud list from a retired nurse with
the e-mail address nursex@... never made it to me. I presume e-mail from
people called Frederick Uckham or Shirley Travis might not make it, either,
if their e-mail addresses were composited from their names in an unfortunate
way. I have no way of knowing how much valid e-mail has been bounced by this
this over-inclusive, misguided "anti-spam" system.

Dialix provides absolutely no notification for its users about the existence
of the system. I didn't even know it existed until a Dialix support person
e-mailed me with the news that he'd removed "sex" from the exclusion list
for the mail server at _my_ Dialix point of presence, and was still trying
to FIND the master exclusion list!

The RISK - don't assume that your ISP isn't doing stupid, STUPID things just
because they don't say they are, and don't get cocky about the reliability
of e-mail. Dimwitted system administrators can silently zot your e-mail
better than any random Internet problem.

Daniel Rutter - DNRC Gadget Wrangler - in-depth hardware reviews and more!

REVIEW: "Removing the Spam", Geoff Mulligan

Rob Slade <>
Mon, 17 May 1999 10:57:05 -0800

"Removing the Spam", Geoff Mulligan, 1999, 0-201-37957-0,
%A   Geoff Mulligan
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D   1999
%G   0-201-37957-0
%I   Addison-Wesley Publishing Co.
%O   U$19.95/C$29.95 416-447-5101 fax: 416-443-0948
%P   190 p.
%T   "Removing the Spam: Email Processing and Filtering"

This book is intended for the system manager, rather than the end user.
More specifically, it is aimed at the mail administrator for an ISP
(Internet Service Provider) or corporate network.  Slightly unfortunate is
the fact that it becomes more particular still, being of greatest use to
those running UNIX, sendmail, ProcMail, and either Majordomo or SmartList.
Regardless of system expression, anti-spam configuration is, as Mulligan
points out, important for two reasons.  The lesser of the two concerns is
the most obvious: that of restricting the amount of spam reaching your own
users.  The more vital is that by failing to restrict the possible abuse of
your system by spammers, and particularly by permitting unrestricted relays,
you face the increasing possibility of becoming blacklisted, and therefore
hampering the legitimate use of the net by your clients.

Chapter one is an excellent overview of electronic mail.  It is concise,
complete, and accurate.  Newcomers to the field will find not only a
conceptual foundation for all the aspects of Internet e-mail, but also
pointers to other references.  Professionals will find fast access to a
number of details that need to be addressed on a fairly frequent basis.  The
main theme, of course, is how spam uses the functions of e-mail systems, and
how it can be impeded, with as little impact as possible on normal
communications.  A good framework is presented in this chapter, with a
number of references to spam- fighting resources.  If I were to make one
suggestion, it would be to increase the number of examples of forged e-mail
headers, and how to dissect them.

Chapter two describes sendmail, and goes into sufficient detail for
interested people to obtain it and start using it.  At that point, the text
concentrates on barriers to spam, such as restriction of relaying and the
access database.  Administrators using sendmail will find this a quick guide
to basic functions.

ProcMail has a variety of functions, and most of chapter three looks at the
number of uses it can have.  The spam filtering section is relatively brief,
but provides some recipes, and directions to other ProcMail based filters.
Again, sysadmins can use this as a quick start for basic mail processing.

Chapter four doesn't have a lot to say about spam, but it does review the
proper setup of mailing lists, which can have a significant impact in
reducing unwanted mail.

This book should be required reading for all mail administrators.  The
usefulness is not restricted to spam, since admins will be able to find
brief discussions of a variety of common mail problems.  As Mulligan notes,
the fewer improperly configured mail servers there are out there, the more
constricted spam sites will become, until at last they can be eliminated
altogether.  While the details of managing other mail server programs may
not match those given in the book, the functions should be available, and
should be turned on.  If the functions aren't available, perhaps it's time
you got some new software.

copyright Robert M. Slade, 1999   BKRMSPAM.RVW   990328    or

Please report problems with the web pages to the maintainer