The RISKS Digest
Volume 18 Issue 71

Monday, 23rd December 1996

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…


Ghost 911 calls: software upgrade brings police
Timothy L. Kay
Re: Ghosts
Bright Field accident in New Orleans
Michael Quinlan
ACTION ALERT: Stop the spread of personal information on the net
Jon Handler
"Cryptography Policy and the Information Economy" draft available
Matt Blaze
Security vulnerability in CERN access protection
Christopher Fraser
Re: Emergency Key Recovery and Reconstruction
Adam Shostack
Bill Murray
Protean documents
Daniel P. B. Smith
Re: Problems of "unforeseen" system aging
Andrew Koenig
Paul E. Bennett
Re: PCs and configuration management
Henry G. Baker
Microsoft documents and Rosetta stones
Darrin B. Jewell
Re: Arrogance of Micro$loth Products
Bob Vaughan
Jonathan I. Kamens
Secure passwords on the web? Not at Microsoft!
Andrew Marc Greene
Info on RISKS (comp.risks)

Ghost 911 calls: software upgrade brings police

"Timothy L. Kay" <>
21 Dec 1996 18:11:59 GMT
I use software that sends pages by dialing my modem and communicating
directly with the paging company's paging terminals.  I was using
first-generation software that didn't understand area codes, so I had to
enter the full dial string, 1-408-xxx-xxxx of the paging terminal.  It
worked fine.

Then I downloaded a new version of the software, which is much more
"intelligent" about area codes and dialing.  It now expects the user to
enter numbers without the leading 1, such as 408-xxx-xxxx.  (I didn't know
this.)  If the number matches your area code, it strips the area code.
Otherwise, it adds a 1 before the number.  The new software also defaults to
a PBX configuration in which you have to dial 9 to get an outside line.  (I
didn't know this.)

I tried my first page.  The software compared my area code (415) with the
prefix of the number it was to dial (1-408-xxx-xxxx).  It found that 415
does not match 140, and therefore prepended a leading 1.  It also prepended
a 9 to get an outside line.  The software then dialed


The police showed up about 5 minutes later.  They confirmed my phone number
and asked why I didn't answer their return call.  I replied that it is my
modem number, and I thought somebody was sending me a fax.

I have reported this problem to the software manufacturer, and I assume
they will address the problem.  In their case, upgrades to their software
lead directly to the problem I described.  (The tech support person replied
that my description probably explains "something else that was happening.")

Bad design aside, a simple practice should be observed whenever software
dials the phone: the software should have a sanity check to make sure that
911 isn't being dialed.  For that matter, wouldn't it make sense for modem
manufacturers to include such a sanity check in their modem firmware?  Are
there legitimate reasons for a modem to dial 911?


  [Yes, but also Yes.  PGN]

Re: Ghosts (RISKS-18.70)

"Peter G. Neumann" <>
Mon, 23 Dec 1996 8:15:24 PST
Well, Timothy gives us another example of ghost phone calls.  Long-time
RISKS readers will recall

* RISKS-2.27: Ghost phone calls to 911 from cordless phone interference
  when batteries ran down

* RISKS-16.88: Calling Number ID ghost calls (from preprogrammed demo

In response to my BART ghost-train item in RISKS-18.70, a RISKS reader asks,
WHAT IS A GHOST TRAIN?  Answer: A train that isn't there but that the
computer believes IS there.  Here are a few from the RISKS archives:

* SF Muni Metro: Ghost Train recurs, forcing manual operation
* SF Muni Metro: Ghost Train reappears; BART problems same day
* Chunnel has ghost trains, emergency stops (due to salt water?)
* `TCAS Sees Ghosts' (see IEEE SPECTRUM, August 1991, p.58)
* Chicago's O'Hare Airport radar lost planes, created ghosts

It all ghost to show, especially if you are in the show.

Bright Field accident in New Orleans

Michael Quinlan <>
Sat, 21 Dec 1996 22:45:08 GMT

  ``The captain also acknowledged forgetting he had a computer override
  button on his console that could have allowed him to bypass the computer
  and increase the ship's speed and maneuverability.''

Michael A. Quinlan

ACTION ALERT: Stop the spread of personal information on the net

Jon Handler <>
Mon, 23 Dec 1996 10:52:55 CST
By permitting individuals to publish information about themselves and their
activities, the Internet has become a powerful tool for creating new social
connections across the barriers of geography and background. Recently,
though, several firms have started abusing the power of the Internet to
publish large databases of personal information without permission.  This is
impolite, and it many cases it can even be dangerous.

True story: recently, I followed a lead from MacUser magazine to a web page
for dealing with spam e-mailers. That page suggested that one of the first
steps to take was to contact services that track people's e-mail
addresses. With growing horror, I connected to page after page on the list
and located myself in their databases. Some services listed far more than
just name and e-mail address. My home address and phone number were
accessible from the same record. Two services even had a facility to show a
map of my neighborhood and the location of my house in it.

The widespread dispersal of information of this sort, without prior consent,
is a serious invasion of privacy. In some cases, publishing personal
information can be harmful to the individual.  For example, battered women
have very good reasons to keep present addresses confidential. Because these
services gather their data silently, from many sources, they present a real
threat to those who require anonymity. In addition, public databases serve
as a source for stalkers, scam artists, and junk mailers. Because they
potentially support these activities, databases of personal information
weaken the social environment of all people on the net inhabit.

Below I have listed the URL's for the pages, along with the information that
they contain and the contact address for that site.  Send mail to the
contact address, requesting that they 1) remove you from their database and
2) refrain from including you in the future.  Note, the mail you send must
contain enough information for the services to know which record to delete.
It's best to send the information that the service tracks. Also, be aware
that, unfortunately, there is no legal obligation for the companies to
remove your name.
  e-mail/phone/address (DELETE in the subject line)
  This service requires a subscription to view information.
  Their information page claims that they track names,
  addresses, and telephone numbers.

Jon Handler

"Cryptography Policy and the Information Economy" draft available

Matt Blaze <>
Fri, 20 Dec 1996 18:59:06 -0500
RISKS readers may be interested in a draft of my critique of US crypto
policy.  It summarizes comments I made to a recent meeting of the Computer
and Communications Industry Association, and is an updated version of
testimony I gave to the Senate Commerce Committee earlier this year.

Postscript is at
ASCII text is at


Security vulnerability in CERN access protection

"Christopher Fraser" <>
Sun, 22 Dec 1996 15:53:26 -0500
Some time ago I came across a security vulnerability in the access
protection code in CERN httpd. I reported it to CERN last February but I
haven't received any reply and the bug is still in the current sources. The
bug is interesting because because it highlights a general risk which may be
present in other Internet software.

CERN accepts access protection as either IP address patterns (such as
192.14.203.*) or as DNS hostname patterns (* Because
the two share a similar syntax it uses the same code to the
comparisons. However, it's entirely possible to construct DNS names
that look like IP addresses and match the access protection rules.
(I did a quick survey and the only other net software I could find which
has the same problem is INN).

The bottom line is that if you run a the CERN httpd server as a proxy on a
gateway machine and you use IP address patterns to restrict access to the
proxy, external attackers can use the proxied services to access internal
machines. This vulnerability exists even if your site filters out IP source
address spoofed packets and has a paranoid resolver library.

I can supply a rough patch to interested parties; please contact me if you
would be prepared to test it. Otherwise, a patch will be available from in the next few days. In the meanwhile, if
you are currently using CERN as a proxy on a gateway machine, I would highly
recommend using router or host OS IP filtering to restrict access to the proxy
service. Additionally you may want to look at newer proxy software, such as
Squid, which may or may not be more secure (I haven't looked).

Christopher Fraser

Re: Emergency Key Recovery and Reconstruction (Perillo, RISKS-18.70)

Adam Shostack <>
Mon, 23 Dec 1996 09:57:30 -0500 (EST)
Robert J. Perillo writes of a school that hired a teenager to break in, and
points (properly) to the need for key recovery mechanisms for encryption
systems.  There is, of course, a risk when a backup system is created.

The principal and former vice principal were on vacation.  (Shouldn't the
passwords have been changed?)  Another employee had a stroke.  So, who
present should have been able to authorize emergency key release if the
files had been encrypted?  The recovery system probably should have a wide
notification feature, to help detect misuse, but whom to notify, and would
they understand the messages they receive?

Re: Emergency Key Recovery and Reconstruction (Perillo, RISKS-18.70)

"William Murray" <>
Sat, 21 Dec 1996 20:50:58 CST
Of course, this problem is as old as bank vaults, where the security
interest requires that only one person know the combination but other
interests require that in the event of his death the vault can still be
opened by non-destructive means.

I think that a review of the market will demonstrate that "modern security
and cryptography" meet this requirement where it exists.  The reader who
thinks otherwise should compare PGP, intended for personal use, to PGP
Business Edition.

The former does not include any emergency key recovery while the latter
does.  Because of my profession, my age, and my failing memory, I choose to
use the latter and its features.  For the same reason, I choose to use RSA
Secure which not only makes my file encryption automatic but also provides
emergency key-recovery features.

It should be pointed out that these features (unlike proposals by the
Clinton administration) provide me with arbitrarily strong protection
against abuse by the trustees.  They permit me to name an arbitrary number
of trustees and require an arbitrary number of them to cooperate to recover
the key that I have used.  The higher the number that I name, the lower the
probability that they will be unavailable when needed.  The more of them
that I require to participate in the recovery, the lower the probability
that the requisite number will behave inappropriately.

Two examples may help.  For the protection of my file system, I have named
two trustees.  Since I carry my file system with me, sleep with it under my
pillow, and am more concerned about the behavior of my memory than the
ethics of my colleagues, either of them acting unilaterally can recover my

It should also be pointed out that I do not use these techniques for those
keys that I use only for communication security.  They are restricted to
those that I use for file encryption.  If I should forget the passphrase
used to protect my communication private key, the appropriate remedy is to
revoke the old public key, generate a new key pair and publish the new
public key.  If there are messages that I received but cannot read, they
must be resent.

Note that using emergency key recovery for communication keys is not secure
and may compromise my correspondents.  It is at best rude and may violate my
obligations to them.

Consider by contrast the master key for a major credit card company.  This
key was generated under rigourous conditions inside a hardware box called
the BBN Safekeyper.  It is a property of this box that it resists all
attempts to remove the private key from the box.  Beneficial use of the
private key requires possession of the box and all three of the physical
keys that fit the three locks on the box.

Since the box is subject to physical destruction and since loss of use of
the key would be disruptive, not to say destructive, the box published five
numbers such that another Safekeyper box could reconstruct the private key
from any three of the numbers.  Thus, any three of the trustees could
prevent the recovery.  Of course, the values five and three are arbitrary
but they are also illustrative.  If 3 out of 5 works for this very sensitive
application, it is difficult to imagine an application for which a larger
number of trustees are required.

A security professional cannot recommend that important keys be stored in
any other way.  While I may consent to other arrangements, I recommend that
important (usually master) keys be stored in hardware dedicated to that
purpose with 3 out of 5 emergency key reconstruction.

Modern key management enables us to meet all of the security requirements
and without creating new problems of their own.  Any suggestion to the
contrary is, at best misleading.

There appears to be an active campaign on the part of the government to
pretend that these techniques do not exist and need to be invented.  There
is also a pretense on their part that the same remedies are necessary and
appropriate for communications applications as for file applications.  As I
have attempted to show, the remedies for one are inappropriate and insecure
for the other.  Because the government insists upon pretending to an untruth
where they must be presumed to know the truth, we should seriously question
their motives.

William Hugh Murray, CISSP  New Canaan, Connecticut

Protean documents

"Daniel P. B. Smith" <>
Sat, 21 Dec 1996 10:08:18 -0500 (EST)
Roland Giersig's remarks reminded (RISKS-18.70) me of a whole spectrum of
issues that arise when one user creates a document and another user *on
another computer* tries to edit it.  Frequently, a significant portion of
the document's state or structure are contained in various preference,
configuration, and initialization files, or in the state of the system
itself (what fonts are installed, what printer is selected, etc), and
surprising transformations occur when the document is transplanted into a
different user's computer.

The war story: the urgent proposal had to go out immediately; X, who
prepared it, was out; Y was frantic because when she opened the fifty-page
proposal on her system, everything that should be in boldface was plain, and
everything that should be plain was bold.

What had happened was that, in some mysterious manner, X's NORMAL.DOT
default style sheet had somehow gotten into a state where the normal style
had the bold attribute.  X had vaguely wondered for months why her word
processor "always comes up in bold," but she just typed CTRL-B and went
merrily onward.  The "bold" attribute applied to text is exclusive-ored with
the bold attribute from the style sheet, so everything seemed normal; when
she thought she was applying bold, she was really removing it from the text
(and allowing the style sheet "bold" to take effect), and vice versa.  So
all documents created by X had bold and plain swapped when viewed or printed
on anyone else's computer.

Daniel P. B. Smith

  [Protean = readily assuming different shapes or roles.  (Webster's) PGN]

Re: Problems of "unforeseen" system aging (Brown, RISKS-18.70)

<Andrew Koenig <>
Mon, 23 Dec 1996 10:12:08 +0500
Once upon a time I read an article by one Gerry Weinberg, who might have
been the same Gerry Weinberg who wrote the excellent book `The Psychology of
Computer Programming.'  In the article, he said that he was running a
company that wrote applications software for other companies, and that his
standard practice was for all programs he delivered to have a stipulated
lifetime of five years unless there was an explicit agreement otherwise.

The client agreed that at the end of the program's lifetime, either the
client would pay to have the program refurbished or all copies would be

Andrew Koenig

Re: Problems of "unforeseen" system aging (Brown, RISKS-18.70)

"Paul E. Bennett" <>
Mon, 23 Dec 1996 11:03:33 GMT
As one of many engineers in the Safety Critical Systems Arena I have seen such
specifications. The normal lifetime expectancy for equipment (in harsh
environments) is thirty years. After this time the equipment may need to be
refurbished and continue another twenty years.

Such extended lifetimes do cause some problems, especially in trying to source
components that can last that long (large capacitors are especially difficult).
For this reason (among many others) many systems for such extended life
embedded applications are becoming networked solutions. By networking,
replacement sub-units can be installed that take advantage of the newer
components available but able to work together with older technology units.
This approach, of course, raises a whole set of new risk elements.

Paul E. Bennett <>  Transport Control Technology Ltd.
+44 (0)117-9499861

Re: PCs and configuration management (Epstein, RISKS-18.70)

Henry G. Baker <>
Sat, 21 Dec 1996 13:01:42 -0800 (PST)
Actually, the computer industry has (up til now) been surprisingly good at
keeping model information/configurations consistent.  The auto industry, on
the other hand, has a dreadful record along these lines.  Any car buff knows
that auto manufacturers put whatever they had on hand into their cars, and
the model number itself is merely one of many clues with which to start your
search for the proper replacement part.  Depending upon whose stuff arrived
that morning, who was on strike that day, the phase of the moon, etc., you
may get one of 3-5 different vendor's parts.  I've even seen different
vendor's parts on different sides of the same car!  What's worse: the
bracket may be different for each vendor's part, so that nominally
interchangeable parts require sheet-metal work because the bolt patterns are

The worst example I've seen so far in ensuring consistency is Toshiba
laptops, where each model number has a different BIOS, _and you aren't
allowed to upgrade the disk to a larger disk_ (even it it is a Toshiba
disk), because the BIOS won't recognize that size disk.  The only way I
could get the larger disk to work was to use Norton DiskEdit to set up the
volume info to include one volume that the Toshiba BIOS liked, and made sure
that that volume was the boot volume.  The Toshiba employees who thought up
this scheme should be rounded up and shot by the Dilbert patrol.

Henry Baker

Microsoft documents and Rosetta stones (Giersig, RISKS-18.70)

"Darrin B. Jewell" <>
Sat, 21 Dec 1996 06:29:39 -0500 (EST)
This past summer I was getting increasingly frustrated by users who were
sending me e-mail with Microsoft Word ".DOC" files attached to them via MIME
encodings.  I do not own a copy of Microsoft Word and did not want to
purchase one simply so that I could read documents people send to me.
Instead, I wanted the specification for Microsoft Word file format so that I
would have a Rosetta stone for the documents I wished to read.

I contacted Microsoft's customer support and was informed of the following:

 1. The specification for Microsoft Word file format is unpublished
    proprietary information.  However, I could download a free reader
    for Microsoft Word files which would run under one of Microsoft's
    operating systems.  Source code for the reader was not available.

 2. I could ask the sender of the message to send me the attachment encoded
    in Rich Text Format which is the official export format for Microsoft
    Word documents.  The specification for Rich Text Format was publically
    available from Microsoft.

Since I did not own a computer running one of Microsoft's operating systems,
I asked Microsoft for the specification for Rich Text Format files.  As a
computer programmer, this was also a more useful and interesting form of
Rosetta stone than a precompiled translating program.

I was then directed to the file GC0165.EXE on the Microsoft ftp site, which
I was able to download and unzip.  (Itself another decoding adventure.)
Included was the file GC0165.DOC, a Microsoft Word format file containing
the specification I desired.  The included README.TXT file contained the
following comment in plain ASCII:

  The GC0165.DOC file included in this compressed file is the Rich Text
  Format (RTF) Specification version 1.3.  The document is in Word 6.0 for
  Windows format. If you have neither Word 6.0 for Windows nor Word 2.0 for
  Windows with the 6.0-to-2.0 converter, you will need to call Microsoft
  Product Support Services at (206) 462-9673 to obtain a hard copy of the

At this point, I decided it was fastest to have my friend who owned
Microsoft Word print out the RTF specification for me.

Since this experience, I usually ask people who wish to send me Word
documents to send them in RTF format.  When I explain to people the RISKS
involved in using documents without open standards, I get comments about
being ridiculous and pedantic or perhaps a blink and a "So what?"  Even
though Microsoft Word supports an "official export format", it is clearly
not obvious to everyone why it should be used.


Re: Arrogance of Micro$loth Products (Giersig, RISKS-18.70)

Bob Vaughan <techie@kzsu.Stanford.EDU>
Fri, 20 Dec 1996 18:02:44 -0800 (PST)
My personal experiences have shown that Micro$loth software has some very
severe compatibility problems.. - they are not even compatible with themselves.

Case in point: I recently designed lighting for a dance show, as part of the
process, I needed to create a cue sheet for the stage manager to work from
during the rehearsal process. Despite my extreme dislike for Micro$loth in
general, I decided that MS Excel for the Mac was the appropriate program to
use.  I proceeded to input my data for the first act, and saved a copy on
the desktop. I continued to input data, and saved a new copy (as a different
name) on the desktop, as well as a copy to the CAP server on the nearby Sun
workstation. I also printed 2 copies before closing the file.  At this
point, I had 2 printed copies, and (I thought) 2 online copies, on 2
different servers. I then grabbed a floppy disk, and went to copy the file
to it so that I could work on it at the theatre the next day. However, when
I went to grab the copy on the desktop (which had been saved not once, but
two times!), I found that it did not exist, however the copy from the first
act was there (with it's data intact, for the first act only). I then tried
the copy stored on the CAP server, only to find that Excel would not open it
as a Excel file, no matter how hard I tried.

I think the risks are obvious.

Another time, I was taking a class at a local community college, as part of
the class, we were required to use Word for Windows (unknown version - this
was several years ago, and my memory is a bit fuzzy). On several occasions,
a file would get saved on a floppy disk, only to find that the file could
not be opened by Word for Windows on any machine in the cluster, including
the one that it had been created on.  (This is typical of my experiences
with Micro$loth products in general)

As it turned out, I had almost as much knowledge about DOS/Windows as the
instructor, and I try very hard to avoid DOS/Windows like the plague.  My
purpose for taking the class, was to brush up my knowledge of DOS, against
the increasing possibility that I would be asked to provide some support for
DOS/Windows users (in spite of my hatred of DOS/Windows).  As it turned out,
the class did not go into DOS at all, instead concentrating on Windows
applications, and not at all on the internals of the system itself. The
class seems oriented towards future secretarys, and not towards users who
wish to learn about how a computer system works.  This was in spite of the
course description, which implied that the class would be a general purpose
introduction to the IBM PC.

The Risks? our society is rapidly turning out "trained computer users",
who have no idea how the machine works, or even how to restart Windows
from a DOS prompt.

Bob Vaughan, P.O. Box 9792, Stanford, Ca 94309-9792  KC6SXC@W6YX.#NOCAL.CA.USA.NOAM

Re: Arrogance of Micro$loth Products (Giersig, RISKS-18.70)

"Jonathan I. Kamens" <>
Sat, 21 Dec 1996 20:25:05 -0500
With all due respect, I don't see how bugs in Microsoft products have
anything to do with Microsoft's "arrogance."

I realize that a large segment of the computer-science community likes to
bash Microsoft at every opportunity.  A good deal of that bashing may even
be deserved.  But it is hardly productive or responsible to take every
single bug in a Microsoft product as proof that Microsoft is Evil.  All that
accomplishes is to evoke the "boy who cried wolf syndrome," thus causing
real, legitimate complaints about Microsoft to be taken less seriously.

The last sentence of your message was rather indicative, I think.  "Sorry if
this sounds very emotional, but I have already wasted enough precious time
with things like these."  Yes, your message did "sound very emotional" — in
my opinion, inappropriately so.  I'd like to think that the RISKS Digest is
above petty anti-Microsoft grand-standing.

Jonathan Kamens   OpenVision Technologies, Inc.

  [So would I.  PGN]

Secure passwords on the web? Not at Microsoft!

"Andrew Marc Greene" <>
Mon, 23 Dec 1996 11:23:11 -0500
I maintain a web site for the Zamir Chorale of Boston, and so I signed up at
the Microsoft Site Builder network web site. Like so many others, it
requires a username and password, and I used my standard "insecure" password
-- that is, the one that I use at most similar sites. I certainly can't be
bothered to remember which password goes with each of fifty web sites that I
visit infrequently!

Well, I got USPS mail from the Microsoft Site Builder network the other day,
encouraging me to visit their web site again — and, just in case I'd
forgotten my username and password, .... [Remainder of item unnecessary for
regular RISKS readers.]

Please report problems with the web pages to the maintainer