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 20 Issue 91

Thursday 8 June 2000


o White House admits over one year of VP's e-mail lost forever
Doneel Edelson
o Julia Roberts wins control of her net name
o Dot-Com nightmare -- domain-name hijacking
o Cyber pirates
o UPS kills power
Daniel Norton
o Ford Explorers recalled due to "lock-up"
Alex Wiebe
o Re: "Incompatible software" blamed for phone-book fiasco
Malcolm Pack
Kevin Parker
o Bloat Dissections II
R.A. Downes
o Re: How not to distribute white papers
Ian Goldberg
Stanley Chow
Paul Wallich
o Re: Trash Compactor
Bernard W. Joseph
Robert Alberti
Bob Dubery
o Re: India piggybacking on railway controls
Douglas W. Jones
o Bcc: filtering vs spam - almost risk-free
Charles Arthur
Bob Jewett
Fredrik Staxaeng
o Re: Blocking e-mail on headers
William Colburn
o Y2K bug still manages to bite after five months
Paul van Keep
o Info on RISKS (comp.risks)

White House admits over one year of VP's e-mail lost forever

"Edelson, Doneel" <>
Thu, 8 Jun 2000 15:45:35 -0400
The details are that when a contractor migrated the server for the Office of
the Vice President (OVP) to NT 4, a new partition was created, an E: drive,
in order to have the standard IS&T configuration (Information Systems and
Technology division of the Office of Administration), and this drive was not
added to the OVP backup schedule.  This drive contained the OVP e-mail
files.  The migration was done in April 1998 and the problem was discovered
by IS&T staff in May 1999.

The full document is at:

Julia Roberts wins control of her net name

"NewsScan" <>
Thu, 01 Jun 2000 07:33:01 -0700
Actress Julia Roberts has won control of the Internet name, after an international arbitration panel ruled that an
accused cybersquatter had no legitimate interest in that name and registered
it in bad faith. The World Intellectual Property Organization, which is one
of four designated arbitrators of Internet domain name disputes, cited
evidence that the defendant, Russell Boyd, had registered names of several
famous movie and sports celebrities, and had even tried to auction the
Roberts address on eBay. In reaching its quick decision, the panel is
demonstrating its willingness to extend protection to famous individuals,
even if they haven't formally registered their names as trademarks. [*Wall
Street Journal*, 1 Jun 2000; NewsScan Daily, 1 June 2000:]

  [NewsScan Daily is underwritten by IEEE Computer Society and Arthur
  Andersen, world-class organizations making significant and sustained
  contributions to the effective management and appropriate use of
  information technology. NSD is written by John Gehl and Suzanne Douglas,  NewsScan items are reproduced in RISKS with
  permission.  PGN]

Dot-Com nightmare -- domain-name hijacking

"NewsScan" <>
Fri, 02 Jun 2000 08:12:05 -0700
At least two Internet companies recently suffered a dot-com's worst
nightmare -- their domain names were reregistered without their knowledge,
and all traces of their legal ownership were erased., based in
Toronto, and of Hong Kong both have suffered crippling losses from
the hijacking, which occurred last weekend. Sleuthing by's owners
found that someone in Jakarta, Indonesia had sent a forged e-mail to Network
Solutions, asking them to redirect all the site's e-mail and Web site
information to a new location. He then requested that the registration,
which had been recorded with Network Solutions in 1993, be transferred to a
Toronto registrar, and asked them to switch the ownership to someone living
in Hong Kong. In's case, an investigation shows that the name now
belongs to someone living in Madrid, Spain. "These are what I call A-class
domain names," says Toronto Star columnist K.K. Campbell. "If the person
collected 50 of these, they'd have $5 million in assets they could afford to
sit on for a little while until they're laundered and then resold."
[*Toronto Star 1 Jun 2000; NewsScan Daily, 2 June 2000:]

Cyber pirates

"NewsScan" <>
Mon, 05 Jun 2000 09:01:10 -0700
A company called Havenco has built what it calls a "data haven" on an
abandoned military platform in the sea, six miles off Britain's coast, in
order to offer communications services to clients who want to avoid
monitoring by governmental authorities. Declaring his small fortress a
sovereign country beyond the reach of British law, Havenco co-founder and
chief executive Sean Hastings, a 32-year-old U.S. citizen, says, "Technology
has made it easier to move information and hide information. Soon it will be
impossible to trace where money is and who has money, and that will
eventually force governments to move away from income taxes and toward
consumption taxes." [*The New York Times*, 4 Jun 2000; NewsScan Daily, 5
June 2000:]

UPS Kills Power

Daniel Norton <>
Wed, 07 Jun 2000 09:20:39 -0400
I received this over the weekend:

>Sunday, June 04, 2000 - 9:51:44 AM
>[We] would like to apologize for any inconvenience caused by our brief
>outage on Sunday, June 4. A UPS backup system burned out, cutting off
>power to some of our systems. Ironically, it is the UPS's job to make sure
>that our systems HAVE a constant power supply, so this problem was
>unexpected, and something we would not normally anticipate. Thankfully,
>one of our systems administrators who was on call noticed the problem and
>went onsite to rectify the situation.
>Thank you for your patience

As it turned out, my own systems automatically paged me within 20 minutes of
the failure.  Why did they need someone to "notice" the problem?

Daniel Norton

Ford Explorers recalled due to "lock-up"

"Wiebe, Alex" <>
Tue, 6 Jun 2000 08:46:18 -0500
Here's the link:

The title is shocking: Ford recalls Explorer due to air bag problems

The body is mildly humorous for those who can envision the slap stick comedy
routine that could result from "An inoperative front windshield wiper system
could adversely affect driver visibility."  Looks like a bit of electrical
noise can cause some central computer to lock up, the result is anything ON
will stay ON, anything OFF will stay OFF.

The risks are: There is no mention of the air bag in the article. Was this
an eye catching hook? or was some critical detail left out of the article.
Electrical noise locking up a computer? This is a problem as old as
transistors - maybe older. A vehicle is a very noisy place, hopefully the
[engin]eers who let this slip get their hands slapped.

Alex Wiebe, Online Business Systems - (204) 982.0200
Voice: (204) - 982.0322

Re: "Incompatible software" blamed for phone-book fiasco (RISKS-20.90)

Malcolm Pack <>
Mon, 05 Jun 2000 23:06:34 +0100
I received this from a San Diego resident. I'll post it verbatim, because it
will hopefully raise a smile, even if it doesn't add to your knowledge of
the matter...

| BTW, have you hoid about the fiasco/brouhaha here in sunny Southern
| California?   The fruits and nutz are alive and well.  Picture this...
| Sicily, 1945... no wait!
| Cox Communications, the local cable TV monopoly ain't making enuff money
| on cable TV, so dey spread out ( SPREAD OUT! ) into being an ISP.  Dat's
| nice.  Are they happy having money raining down on them faster then they
| cam count it?
| OF COURSE NOT!  So, what better idea then to SPREAD OUT! into providing
| phone service too!
| So far, so good.  Now the fiasco...
| It seems CoxPhone needs to send in their phone subscribers'
| names/addresses/phone numbers to Pacific Bell aka PacBell.
| Well, it seems Cox sent in *all* their phone subscribers' n/a/#s,
| including the folks paying extra for unlisted numbers. PacBell prints
| the phone books and starts distributing them. 400k of 1.3 mil phone
| books were distributed before someone, like a Cox phone subscriber hits
| the roof when s/he finds out their 'unlisted' number is listed.
| Quick like a bunny, Cox calls PacBell to STOP DA PRESSES!
| PacBell sez, no problem.  Now it seems they can't get together to figure
| out what to do.  Junk the phone books they have left, retrieve the 400k
| they distributed, who pays for what, etc.  PacBell is going to
| distribute the rest of the phone books as they don't want to lose
| advertising dollars and it wasn't their problem that they didn't
| notice Cox's database of names include unlisted numbers.
| Anyways, we'll have everyone suing each other while Cox and PacBell
| claim a 'computer error' for the problem.  So it wasn't their fault.
| Everyone is nuts here!  Must be sunstroke or the bottled water, IMO.

Malc, Southend-on-Sea, UK

Re: "Incompatible software" blamed for phone-book fiasco (RISKS-20.90)

Kevin Parker <>
Mon, 05 Jun 2000 15:02:57 -0700
An interesting story concerning the Cox/Pac Bell unlisted phone number fiasco.

When I got the new phone book a few weeks ago from Pac Bell, I thought I'd
look up an old acquaintance from high school to see if he was listed.  Not
only was he listed, but he lived in our housing development, two doors down
from friends of mine.  The next time I went to visit the friends, I stopped
by to see if John was home.  A woman and some kids were out front, so I
asked her if John C. lived here.  "Why do you want to know," she said.  I
knew him in high school, I replied.  "What's your name?," she wanted to
know.  I told her.  She then asked me how I got their address.  I told her
that it was in the new Pac Bell phone book.  Impossible, she said, since
ours is an unlisted number.  Well, I told her, not only is your phone number
printed, but so is your address.  She became really concerned and said,
"This is not good.  John and I are both police officers, and John works
undercover.  He can't have his name published."

A few weeks later the *LA Times* mentioned the snafu.

  [The risks of this episode run deep.  PGN]

Bloat Dissections II (Re: RISKS-20.35)

R.A. Downes <>
Mon, 05 Jun 2000 15:01:05 +0000
The bloat dissections continue. One remaining question in the article cited
above and its follow ups is: "would dissecting such an application as
RegClean at source level really reduce its bloat?"

Curious coincidence then, that I should happen upon the source code to
another Microsoft Registry cleaner - RegMaid, from 1993 - 95 (btw, this
application might very well be the basis of the later RegClean project as
well, judging from the embedded resources).

Fact: the distributed executable to RegMaid is 153,600 bytes.
Fact: it is distributed with its source code.
Fact: after less than ten minutes work I got it down to 69,632 bytes.

This is a savings of 83,968 bytes, or well over half the original image
size. This is a new image only 45% the size of the original. And in less
than ten minutes. I got 83,968 bytes of bloat off my disk that fast.

Not to beat the dead horse but - just think about it. Ten minutes, 55%
savings of 83,968 - and I had never seen this code before in my life.

If this doesn't prove that bloat is inexcusable, I'll just have to send more
examples. Cutting the bloat in that application, and attempting to estimate
the cost of doing so, really misses the point too: the code itself is rather
intricate, and this Rome was not built in a day.  Barring the author's
getting the architecture completely right from the beginning, the ten
minutes it took to shave the EXE by 55% represent:

1. Half of only one coffee break.
2. A late arrival into the Thursday night Quake game.
3. One final tweak in the evening before dinner is really served.
4. Something to do on the laptop while commuting to work in the morning.

It's *trivial*. Avoiding bloat has never been an effort, despite what the
defenders of latter-day commercial software like to claim. Things can be
done right from the beginning, or even if not, corrected in a negligible
envelope of time.

As for really astounding comparisons, try:

Where we got a monster down from 3.5MB to just 7KB (seven kilobytes) in
a single hour!

It's professional pride on the one side -- and "who cares?" on the other.

RA Downes <>

Re: How not to distribute white papers (Re: Rubin, RISKS-20.90)

Ian Goldberg <>
Mon, 5 Jun 2000 14:44:45 -0700
Actually, the "unzip" program available for Linux (as well as, I assume,
the equivalent unzip programs for Windows) is able to decompress these
self-expanding archive programs.

So there's no need to actually run the .exe file (which is good, since
I don't *have* a Windows box on which to do so, anyway).

Of course, once we do that, we discover that it expands into a Microsoft
Word file...

- Ian "Yes, I know about wvWare."

  [Similar comments from several others.  TNX!  PGN]

Re: How not to distribute white papers (Re: Rubin, RISKS-20.90)

Stanley Chow <>
Tue, 06 Jun 2000 14:48:32 -0400
Avi Rubin (RISKS-20.90) talked about the difficulty of using "sacrificial"
machines for quarantining potential malware.

The latest release of VMWare (see has some useful
features for this purpose. One can set up a virtual machine to have the
desired O/S, patches, products, etc, then take a snap shot. You can then
just copy a new virtual machine and throw it out after. (There are some path
settings that have to be done, but I wrote a perl script). They also allow
the disk to roll back, very cool.

Note that my relationship to VMware is purely as a customer.

Stanley Chow        VP Engineering
Cloakware Corp      (613) 271-9446 x 223

Re: How not to distribute white papers (Re: Rubin, RISKS-20.90)

Paul Wallich <>
Tue, 6 Jun 2000 09:33:33 -0400
Microsoft is more likely doing this to restrict distribution of the text
file as it sees fit. The same savings of space could be achieved simply by
delivering a zipped file and letting the user's software recognize the MIME
type for decompression. Bundling the file into an executable, however,
arguably meets the requirements of the Digital Millennium Copyright Act for
a technological copy-protection mechanism, which makes unauthorized
redistribution of the text a serious crime (where "serious" means "you could
go to jail for more than a year").

I don't know if that particular white paper (or the page from which it was
downloaded) contained a license agreement restricting redistribution of the
text, but if it did, that would certainly appear to meet the DMCA
requirements. (This kind of thing has already bitten other ostensibly open
MSFT documents.)

Indeed, depending on the state from which you accessed the document
(or in which the server was located) UCITA might apply as well, in
which case you could have to check the download page for links to any
agreement governing use of the document, and recheck at regular
intervals should MSFT decide to restrict the text in the future...

> I could not believe that this is how Microsoft
> distributes its white papers. It is beyond comprehension.

If you view control, rather than dissemination, as the goal of putting
documents on a web site, it's easy to comprehend.

Paul Wallich <>

Re: Trash Compactor (RISKS-20.90)

Thu, 08 Jun 2000 09:40:26 -0400
In RISKS-20.90, Robotech_master wrote about a thief jumping into a
weight-activated trash compactor.  I live here where it happened and attest
that the story was the first one that went over the wire services.  As the
story developed, new facts indicated that it was a garbage truck into which
she jumped, and that the workers manually activated the compactor.  That
didn't make the wire services.

In his book Fables for Modern Times, James Thurber said, "He who hesitates
is sometimes saved."  The news services probably should not have been so
eager to publish before all the facts were known; Robotech_master probably
should not have jumped on the story as a risk; I probably should not have

Bernard W. Joseph

  [Also noted by Vincent Dovydaitis, in
  Hesitates?  The object of the media is to sell their wares.  *The New
  York Times* meticulously publishes corrections on Page A2 each day.
  Not everyone else is as careful.  But RISKS tries very hard to correct
  the record, although if we waited for verification on such items,
  the wait would be very long...  Incidentally, the risk of a hyperactive
  automated compactor still remains a risk.  PGN]

Re: Trash Compactor (RISKS-20.90)

Wed, 7 Jun 2000 11:25:27 -0500
Two AP follow-up articles state that the compactor was not automatic, but
was started by employees while the woman was inside.  Unfortunately for her,
the employees were apparently deaf...

Robert Alberti, BORN Security Practice Lead  <>

Re: Trash compactor kills shoplifter (RISKS-20.90)

"Bob Dubery" <>
Tue, 6 Jun 2000 08:31:05 +0200
Surely when designing such a device, one is entitled to not have to cater
for the fact that people may use the device for something that it is not
designed for?

I recently had someone tell me that a light fitting on the external wall of
my house was a risk because somebody could get a shock from it. I replied
that yes, somebody could, but only if they were trying to remove it - in
which case they probably deserved the shock.

Everyday I see indications that people are less and less inclined to take
responsibility for their own stupidity or, in some cases, dishonesty. The
risks to society of that attitude far outweigh the risks posed by automated
hardware that doesn't cater for the whims of every turkey that walks down
the street.

Re: India piggybacking on railway controls (Bakowski, RISKS-20.90)

Wed, 7 Jun 2000 17:33:44 +0530
Actually the guy called Ashok Jhunjhunwallah who is spearheading the efforts
is a respected professor from IIT Madras and is working for the promotion of
indigenization of technologies. He has been working with WILL and DSL on Cu
for a while now... He has been reasonably successful so far.

Moreover, the fact is that the railway stations are interconnected for
normal voice traffic thru quad Cu cable. As a matter of building in a
possible onfail crossover and to control the trains in future by some means,
there is also a spare cable (running parallel to the whole system) which is
*not at all* used. Ashok and friends want to make use of this spare, to
start with, to operate a railway based Internet backbone n/w.  And later,
they are planning to factor in the spare capacity of the railway's fibre
optic n/w as also by laying fresh cables. The spare cable will be used for
high bit rate data link and WILL will / could be used in hubs at railway
stations etc. Actually it looks like an elegant and pragmatic solution,
political will permitting...

This much said, I don't think there is a risk associated with this as the
trans modes are not at all going to interfere with the existing comm systems
for the management of Indian railways...

But don't you think, it will be easier to "train" our guys to use the
Internet this way? ;-)


Re: India piggybacking on railway controls (Bakowski, RISKS-20.90)

Douglas W. Jones,201H MLH,3193350740,3193382879 <>
5 Jun 2000 22:13:08 GMT
No, this looks exactly like the way the Sprint long distance carrier got
its service.  Consider the expansion of the acronym:

   Southern Pacific Railroad INternal Telecommunication

(recalled from memory, so it may only be approximately correct.)  This
company was founded to sell exactly the kind of excess bandwidth that the
Indian railways are interested in exploiting, and there's no evidence that
use of surplus capacity in lineside cables leads to trouble.

Doug Jones <>

Bcc: filtering vs spam - almost risk-free (Bean, RISKS-20.90)

"Charles Arthur, The Independent" <>
Tue, 6 Jun 2000 10:36:55 +0100
> My log files showed that 96% of the spam was being deleted by the Bcc:
> filter and not even getting to the "clever" ones.

That has been exactly my experience (I had 95%).

I can't understand why Microsoft introduced content-based filtering. This
is sure to be (1) slower (2) less accurate. The unique thing about spam is
not its content, which can be just about anything, but the fact that it's,
well, spam, and hence not aimed at you.

Some spam programs do do individual addressing: these are the
annoying 5% which elude the Bcc filter. For anyone who may expect to
receive e-mail from people they've never met (such as journalists like
myself) though, you can't just trash stuff on that basis.

From being a major annoyance though, spam has become a minor irritation via
Bcc filtering. It is now the only spam filter I use. (After other filters
looking for stuff from mailing lists have done their work.)

Maybe MS couldn't copyright Bcc filtering?

Bcc: filtering vs spam - almost risk-free (Bean, RISKS-20.90)

Bob Jewett <>
Mon, 5 Jun 2000 21:08:07 -0700 (PDT)
In RISKS-20.90 Ron Bean remarks that his Bcc: filter had few false
positives.  That filter is also used by many here, but that may have to
change.  There is now circulating a "Use BCC or be assaulted" hoax.  The
summary from is:

  "Woman is stalked by on-line acquaintance; use the "blind carbon copy"
  feature in e-mail to prevent this from happening to you!"

I am seeing increasing numbers of mailing list submissions which have no
valid To: or Cc: address.  Is it just ignorant users who have stumbled onto
mailer features?  I fear that they fear the above.  I got the hoax in e-mail
from the usual (fearful) person who sends me hoaxes.  Did a spamster start
the hoax?

Bob Jewett

Bcc: filtering vs spam - almost risk-free (Bean, RISKS-20.90)

Fredrik Staxaeng <>
Wed, 7 Jun 2000 18:46:08 +0200 (CEST)
Any junk-mail filter made by Microsoft will soon have a 100% false positive
rate. The spammers will check that their message passes the filter.

Fredrik Stax\"ang | | (+46) 8 678 09 94

Re: Blocking e-mail on headers (RISKS-20.90)

Schlake (William Colburn) <>
Mon, 5 Jun 2000 21:24:01 -0600
I define a lot of anti-spam here for my users without them ever being aware
of it.  I am always very careful about what I block, and I get e-mail
summaries of the messages every day (which I actually look at every
weekday).  In addition to my own anti-spam, I also include pieces of Eric
Allman's anti-spam from the file.  Eric uses a rule that blocks
"friend@" and "" in the "To:" field.  If Eric Allman uses it,
then it is good enough for me, or so I thought.

Turns out that there is someone out there with a real last name of "Friend".
His e-mail address was "friend@<somewhere>.edu", and mail from us to him was
being blocked.  I modified the rules to check for the specific case of
"" in the "To:" line instead of "friend@anywhere" and
"".  Then I contacted the guy whose e-mail I had blocked,
and told him all about why his e-mail had been blocked.

He was most grateful to me, and said that he had a lot of e-mail disappear
all the time, and then he changed his account name.  The risk here, is that
automated processes can chug along for years without anyone ever noticing
that they are broken.  Poor Mr. Friend may have been silently losing e-mail
for years, and could still have been losing e-mail today if it hadn't been
noticed at my end.  There is also a risk in someone trying to plug in
someone elses solution.  Eric Allman's personal machine is a lot different
than my mail server with 3000 users on it.

Y2K bug still manages to bite after five months

Paul van Keep <>
Thu, 08 Jun 2000 17:28:40 +0200
To my amazement I was hit by a Y2K bug last week. Last Wednesday I was in
Chalon-sur-Saone at a pickup point from La Redoute, a french mail order
company.  I was there to collect an order and pay for it. And that's where
things went wrong. The clerk tried to enter my credit card into their
computer system, but it kept refusing it, claiming the account was blocked
(not the card.) Of course it took her a couple of tries before she realized
that the problem wouldn't disappear by itself. So she called their head
office in Roubaix to ask them to unlock the account. It took two long phone
calls but in the end my card was accepted and I could pay for the goods.
When I asked her why my card was rejected she said it was caused by a Y2K
problem. Their computer system stores a maximum of two credit cards in an
account profile. This is, as we all know, a big risk in itself. It simply
means that my card information is available to anyone at La Redoute who has
access to their customer system. In my case, two card numbers were stored,
both my wife's and mine. But when they converted their system to be Y2K
compliant the process erased a number of expiration dates including that of
my wife's card and probably mine too, both being 06/00. When I tried to pay
with my card, the correct expiration date was entered into the system again,
but my wife's card number still had a blank date connected to it. So the
system decided to block the account.  There are two extra risks besides the
obvious one of storing credit card information: wiping valid data while
trying to clean up a database for a Y2K conversion and being overprotective
when checking account information.

Paul van Keep

Please report problems with the web pages to the maintainer