The RISKS Digest
Volume 19 Issue 04

Friday, 4th April 1997

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…


Moynihan Commission hooked on Penpal virus hoax
George Smith
Sheriff prefers jail-door computer malfunction to April Fool's joke
Darrell R. Pitzer
The ghost of the Pentium FDIV bug
Frank Solomon
War story on errors in library versions
John Paulson
Re: CalTrain computer stolen — rider alert
Mike Lipsie and Al Stangenberger
Emergency! Crisis in the Cockpit, by Stanley Stewart
Robert Dorsett
Spam, the naming of parts
Dan Sheppard
But I don't LIKE spam...
John Oram
Re: Spam-proofed "From:" lines
Curt Sampson
Tim Pierce
Re: Risks of automatic spam blockers
C Matthew Curtin
Ted Wong
Harlan Rosenthal
Dan Franklin
J. DeBert
Info on RISKS (comp.risks)

Moynihan Commission hooked on Penpal virus hoax

"George Smith [CRYPTN]" <70743.1711@CompuServe.COM>
04 Apr 97 18:00:21 EST
In an astonishing gaffe, government intelligence experts writing for the
Moynihan Commission's recent "Report . . . on Protecting and Reducing
Government Secrecy" reveal they've been hooked on one of the Internet's
ubiquitous e-mail computer virus hoaxes known as "Penpal Greetings"!

In a boldly displayed boxed-out quote in a _lengthy_ part of the report
entitled "Information Age Insecurity," the authors proclaim:

"Friendly Greetings?

"One company whose officials met with the Commission warned its employees
against reading an e-mail entitled Penpal Greetings.  Although the message
appeared to be a friendly letter, it contained a virus that could infect the
hard drive and destroy all data present. The virus was self-replicating,
which meant that once the message was read, it would automatically forward
itself to any e-mail address stored in the recipients in-box."

The Penpal joke is one in half-a-dozen or so permutations spun off the
well-known GoodTimes e-mail virus hoax.  Variations on GoodTimes have
appeared at a steady rate over the past couple years.

The report's authors come from what is known as "the Moynihan commission," a
group of heavy Congressional and intelligence agency hitters tasked with
critiquing and assessing the Byzantine maze of classification and secrecy
regulation currently embraced by the U.S. government.

Among the commission's members are its chairman, Daniel Moynihan;
vice-chairman Larry Combest, Jesse Helms, ex-CIA director John Deutch and
Martin Faga, now at a MITRE Corporation facility in McLean, Virginia, but
formerly a head of the super-secret, spy satellite-flying National
Reconnaissance Office.

The part of the report dealing with "Information Age Insecurity" merits much
more comment.  But in light of the report's contamination by the Penpal
virus hoax, two paragraphs from the March 4 treatise become unintentionally

"Traditionally, computer security focuses on containing the effects of
malicious users or malicious programs. As programs become more complex, an
additional threat arises: _malicious data_ [Crypt Newsletter emphasis added]
. . . In general, the outlook is depressing: as the economic incentives
increase, these vulnerabilities are likely to be exploited more frequently.

---W. Olin Sibert, 19th National Information Systems Security Conference
(October 1996)"


"Inspector General offices, with few exceptions, lack the personnel, skills,
and resources to address and oversee information systems security within
their respective agencies. The President cannot turn to an Information
General and ask how U.S. investments in information technology are being
protected from the latest viruses, terrorists, or hackers."

Got that right, sirs.

 - - - - - - -
Notes: Other authors of the commission report include Maurice Sonnenberg, a
member of the President's Foreign Intelligence Advisory Board; John Podesta,
a White House Deputy Chief of Staff and formerly a visiting professor at
Georgetown University's Cyberlaw Center; Ellen Hume, a former reporter for
the Wall Street Journal; and Alison Fortier, a former National Security
Council staffer and current Rockwell International employee.

Unsurprisingly, much of the report appears to be written by staff members of
the commission chairmen.  An initial phone call to the commission was
answered by a staffer who declined to name the author of the part of the
report carrying the Penpal hoax. The staffer did, however, mention he would
forward the information to the author.

Contact for the Moynihan Secrecy Commission: 202-776-8727.

An electronic copy of the Moynihan Commission report is mirrored on the
Federation of American Scientists' Website (

George Smith  Crypt Newsletter

Sheriff prefers jail-door computer malfunction to April Fool's joke

Fri, 4 Apr 1997 09:35:05 -0500
>From "The Advocate" (Baton Rouge, LA), 4/3/97, page 1A (front page):

   Glitch in jail system opens doors, again  (Associated Press)

   ASHLAND — All the inmate cell doors at the Terrebonne Parish Jail
   opened automatically late Tuesday night because of a computer
   malfunction.  It was the third time in the past two months that computer
   problems caused a security breach at the prison, located about seven
   miles south of Houma, said Terrebonne Parish Sheriff Jerry Larpenter.
   All of the jail's 464 inmates stayed in their cells, Larpenter said.
   Larpenter said that he got the call about 9 P.M. "I didn't appreciate
   it. I was hoping it was not an April Fool's joke," Larpenter said.
   "I don't like being on the opposite end of a joke."

What a great attitude!?! He'd prefer a malfunction that opens all of the
cell doors as opposed to being the subject of an April Fool's prank.  I've
always complained about the stereotypical Southern law enforcement officer
depicted in movies ... maybe I'll stop complaining.

I guess the April Fool's prank was on the inmates ... Door's open, you can
leave.  Oops! Sorry!  Computer malfunction!  Get back in your cell.

Darrell Pitzer <DRPITZER@ACM.ORG>

The ghost of the Pentium FDIV bug

Frank Solomon <>
Fri, 04 Apr 1997 09:09:41 -0500
It seems that the ghost of the FDIV bug lives on in Excel spreadsheets
created using Pentiums affected by the problem.

I finally got rid of my Intel Pentium computer with the FDIV bug.  Last
night, while checking out my new Pentium Pro computer with Microsoft Excel
97 I decided to open up the spreadsheet which demonstrates the Pentium
Floating Point divide bug.  I was surprised to find that that the
calculation of:

4195835 - (4195835/3145727)*3145727

within the spreadsheet still showed the answer 512 instead of zero.

I pressed the recalculate key (F9) to no avail.  So then, I retyped the
formulas in neighboring cells.  Where I had retyped the formulas the
answer(s) were correct, but the same formulas that had been saved from when
I had done the calculation on the defective Pentium still showed the wrong
answer!  In other words, here, on the same spreadsheet was the same problem
with two different answers, one correct and one incorrect.

The only way I could find to "correct" the incorrect answers was to retype
the formulas over the originals.

It seems to me that this "ghost" could represent some risk since it is
logical to assume that if you're no longer using a defective Pentium, you
needn't be concerned about wrong answers on the spreadsheets you've moved
to a new machine.  This obviously is not so.

I've sent in a bug report to Microsoft as of this morning.

Frank Solomon, University of Kentucky (606)257-2133

War story on errors in library versions

John Paulson <>
Fri, 4 Apr 1997 10:13:42 -0800
Anyone interested in a "war story" about how errors are introduced into the
relatively simple problem of releasing new versions of a library should read .  It would make an
interesting exercise in a software engineering course to describe how a
process could be developed which would have prevented some of these errors
from occurring.

  [I hope this URL sticks around.  Much as I hate to put possibly
  ephemeral URLs into the long-term archives, this item is worth
  reading but is to complex and interesting to summarize briefly.  PGN]

Re: CalTrain computer stolen — rider alert (Brandt, RISKS-19.02)

Al Stangenberger <>
Thu, 3 Apr 1997 08:49:54 -0800 (PST)
The original posting about automatic cancellation of cards may have been in
error - see attached posting.

Another poster said the building from which the computer was stolen looks
like a dilapidated shack and not really a good place to store sensitive data
or easily-stolen computers.

Al Stangenberger, Dept. of Env. Sci., Policy, & Mgt., Univ. of California at
Berkeley, Berkeley, CA  94720-3114  (510) 642-4424

 - - - -

From: (Mike Lipsie)
Newsgroups: ba.transportation,misc.transport.urban-transit
Subject: Re: CalTrain computer stolen — rider alert!
Date: Thu, 03 Apr 1997 03:44:23 GMT

  [Referring to (Adrian Brandt), included in RISKS-19.02]

As I read the letter, CalTrain had told the credit-card people that the
numbers were in a computer that was stolen and expected the cards to be
cancelled.  I think the credit-card companies are saying, "Again?  Usually
they are stealing the computer and not the data.  We'll wait and cancel if

[...] However, this is the second time within a year that a computer with my
credit-card number on it has been stolen.  I will be extra alert but I don't
really expect anything to happen.  And, since I have a half-dozen (or so)
auto-pay arrangements, I really hope that is the case.

Mike Lipsie

Emergency! Crisis in the Cockpit, by Stanley Stewart

Robert Dorsett <>
Fri, 4 Apr 1997 09:56:39 -0800
Emergency! Crisis in the Cockpit
by Stanley Stewart
TAB Books, 1991
264 pages, illustrated w/bibliography
ISBN: 0-8306-6499-8

I just finished _Emergency! Crisis in the Cockpit_.  Apart from the horrible
title, this is a rather interesting book by Stanley Stewart, a BA 747
captain.  He deals with in-flight emergencies in which death was *avoided*.
Imagine that. :-) He thoroughly describes nine incidents/accidents:

1. Pacific Search.  Deals with a 1978 incident involving an Air New Zealand
   DC-10 assisting in the search for a lost GA pilot over the Pacific.

2. The Bermuda Triangle.  EAL L-1011 vs. no O-rings on its chip detectors
   resulting in shut down of all three engines.

3. To Take-off or Not to Take-off.  The Pan Am 747 collision with runway
   lighting on takeoff resulting in the loss of three of four hydraulic

4. The Windsor Incident.  The AAL DC-10 floor collapse.

5. Don't be Fuelish.  The Air Canada 767 fuel starvation incident.

6. The Blackest Day.  Black September, focusing on the hijacking of the PAA

7. Ice Cool.  Ryan Aleutian Airlines vs. frozen fuel pumps.  All-engine

8. Roll out the Barrel.  The China Airlines 747 flip-over.

9. Strange Encounter.  British Airways 747 vs. a volcanic ash cloud.  Loss
   of all engines.

Each story is based on interviews with the crews and on external printed
sources.  Each is presented verbatim, warts and all.  If crews made dumb-ass
mistakes handling the emergency, they are presented verbatim as part of the
decision flow, without comment.

Although the book is designed for a general audience, the stories are told
from the pilot's perspective (not a single "Little Johnnie was waiting in
Cleveland for the liver transplant in the cooler in the back." :-)) and
sometimes gets fairly technical.

I enjoyed it.  Recommended.

Spam, the naming of parts

Dan Sheppard <>
Wed, 2 Apr 1997 01:37:08 -0800 (PST)
In RISKS-19.02 there are a number of articles concerning `spam'.

There is a Risk in the use of this (Monty Python derived) term in
discussion of this issue, as it is not precisely defined. If we are to
start using measures against these communications, we should, in my
opinion, start using a more precise term.

`Spam' is used to cover ECP (Excessive cross posting) and EMP
(Excessive multiple posting) on Usenet, UCE (Unsolicited commercial
e-mail) or occasionally any unwelcome unsolicited e-mail. ECP (and to
a lesser extent EMP) can be detected and removed automatically, and a
number of precise metrics have been developed and generally (although not
universally) accepted as to when this is appropriate.

The use of the term `spam' for electronic mail is less well defined. It is
generally assumed to include UCE, but is often used to refer to any unwanted
unsolicited mail.

As to my preferred anti-UCE method (about which there seems to have been
little discussion), I am alpha-testing an implementation of aliases as
time-expiring Capabilities, the expiry time usually set to around a
fortnight. Usenet is in essence, a transitory medium, soon the capability to
mail me shall be just as transitory. Whilst any freshly cropped aliases will
still work, it makes the compilation of UCE lists difficult, (I also need
only stop posting for a week or so and I will receive _no_ UCE, until I
start posting again).

Whilst those who regularly post to Usenet will still receive a reasonable
amount of UCE, many people who post infrequently have none the less found
themselves on a UCE list, the use of time expiring aliases prevents this
having long-term consequences. A well thought out implementation can even
allow the filtering to be performed by a trusted third party, and the
creation of aliases on machines with transient connectivity.

I have tried, in developing this, to minimise the work which needs to be
done by someone who is genuinely replying to a message, as pointed out
[Wayne Mesard in RISKS-17.02] an inconsideration and potential stumbling
block for new users, whilst providing security against address
unmungers. The compromise means for a short time after posting a few UCE get
through. I'd welcome comments on the potential risks and benefits due to
this technique before I release my (free) implementation for beta-testing.

Dan Sheppard.

But I don't LIKE spam...

John Oram <oram@unixg.ubc.Xca>
Fri, 28 Mar 1997 00:21:26 -0800 (PST)
Re: aste-RISKS (Warning to MSIE users), RISKS 18.94

>  [Ah, yes, by all means, avoid the aste-RISKS of being spammed! ...  PGN]

I am guessing that mass-e-mailers have trolled the RISKS archives.  Some
recent spams I have received:

    Date: Thu, 13 Mar 97 01:32:05 EST
    Subject: *** 8 MILLION E-MAIL ADDRESSES ***

    Date: Sun, 23 Mar 97 22:09:38 EST

    Date: Mon, 24 Mar 97 11:03:43 EST
    Subject: Purchase Corporate MKTG lists, SIC's, Area Codes, etc.

Any other contributors so blessed?

Given this influx, I like the idea of the mangled (yet still human-readable)
e-mail addresses. I think the placement of the 'aste-RISKS' is important,

I suggest putting the aste-RISKS within the top level domain (i.e. .Xca,
.Xcom) rather than on the user id.  This puts the load on the spammers' DNS,
rather than on the receiver's internet provider.  No point having my ISP
waste cycles looking up bogus accounts.

Or maybe we could ROT-13 e-mail addresses?

A RISK of aste-RISKS technology?  Everyone will start using the same method,
and spammers will simply know to replace .Xcom with .com.  So I guess you
should all ignore my advice and do your own thing...

Wbua Benz,, uggc://jjj.benz.pbz

X marks the spam - remove the X from my return e-mail address.

Re: Spam-proofed "From:" lines (Mesard, RISKS-19.02)

Curt Sampson <>
Tue, 1 Apr 1997 22:09:26 -0800 (PST)
Wayne Mesard mentions that a trend on the Internet is to change one's e-mail
address on outgoing news and e-mail so it is not valid in some obvious way,
and request that the recipient make the appropriate changes to make this
e-mail address valid.

He forgot one risk in his list: when you send out e-mail like this, you
won't get any indication if your e-mail cannot be delivered, because the
automatic systems that notify you that your mail could not be delivered will
not be able to send you that notification.  I've noticed this problem in
particular with some of my customers who use a Windows newsreader called
Free Agent; they use it for mail as well, but they can't have separate
e-mail and news From: addresses, so it's inconvenient for them to use a
modified address for news, but not for mail.

Curt Sampson  Internet Portal Services, Inc.
Vancouver, BC (604) 257-9400  Info at

Re: Spam-proofed "From:" lines (Mesard, RISKS-19.02)

Tim Pierce <>
Fri, 4 Apr 1997 18:33:52 -0600 (CST)
The cost of this is not to be underestimated.  For most people, the chief
problem with spam is not that it consumes a significant amount of any
tangible resource (money, network bandwidth, disk space).  The cost is in
the time spent deleting and/or complaining about the spam, and in the
annoyance factor, both of which harm productivity.  Spam is problematic
because it shifts the cost (of targeting one's message) from the producer to
the consumer.  Similarly, spam-proofing one's e-mail address is problematic
because it shifts the cost of communication from the sender to the

Another risk is that an e-mail address so ``spam-proofed'' may inadvertently
identify some innocent third party.  (This has been discussed here before,
in the context of deliberately forged messages and accidentally
misconfigured message clients.)  Posters who change the domain name of their
addresses to `' may be surprised to learn that is a
real domain, but the users or postmasters who receive responses
to their mail may not be amused.

>- False security 2: In the ever-escalating spam arms race, it won't be
>  long before spammers' address-gathering software is modified to
>  unmunged munged "From:" lines.  [...]

I will discuss one of these techniques, if only because most people do not
seem to believe me when I say that I have actually witnessed it.

Most e-mail spam does not actually list the recipients of the spam in its
headers, but some spams do.  I received such a message a few weeks ago, and
in the process of examining the headers in order to complain, I came across
the most curious pair of addresses.  They were of a format similar to this:

Now, it's entirely possible that the user responsible for these addresses
actually did use both of them at one time or another, but it seems awfully
unlikely: the phrase ``thistoemailme'' does not clearly indicate an action
for the recipient to take.  More plausible is that the spammer responsible
for this message filtered his list of addresses through a program which
removes strings like `remove', `spam', or `nospam' (and then includes both
the filtered and unfiltered addresses just to be on the safe side).

It shouldn't be long before someone teaches them about regular expressions.

Re: Risks of automatic spam blockers (Zerkle, RISKS-19.02)

C Matthew Curtin <>
Tue, 1 Apr 1997 18:35:54 -0800 (PST)
<> The risk of false and malicious blacklisting of non-spammers.  (Riddle)
Dan> This is a serious problem.  A step towards solving it would be [...]

This is unnecessarily complex.  The NoCeM effort (see for
details) has simply, and effectively, dealt with the spam problem for
usenet.  Efforts are underway to adapt this to e-mail.

NoCeM works this way:
 * Someone takes it upon himself to watch for spam in a newsgroup (or groups).
 * When spam does appear, that someone posts a "NoCeM" message to
   news:alt.nocem.misc and/or, PGP signed.
 * Users who want to benefit from the filters have clients that, when
   they grab news, look in news:alt.nocem.misc (and potentially other
   places) for NoCeM messages.  The client verifies the signatures,
   and if it's signed by someone the client agrees to listen to, the
   message won't be shown to the user at all.
 * Clients are also available to work with news servers, to NoCeM
   messages on a site-wide basis.  (I believe that these actually
   cancel the NoCeM'd messages on the site.)

This is nice, because it uses what's already there (news), and allows the
user (or admin, depending on the model) to select which users' NoCeMs he
honors.  Either you trust someone's judgement and honor their NoCeMs, or you
don't, and they're completely ignored.

Dan> Unfortunately, doing this would subject whoever did it to a suit
Dan> by spammers who didn't want to be blocked.

Superfluous lawsuits are threatened all the time... few have the resources
of CyberPromo to actually be stupid enough to try any of this.  (It's
another thing about doesn't kill the messages, it just is another
post, that certain clients deal with behind the scenes. :-)

Matt Curtin  Chief Scientist  Megasoft, Inc.

Re: Risks of automatic spam blockers (Zerkle, RISKS-19.02)

Ted Wong <>
Wed, 2 Apr 1997 11:57:49 -0800 (PST)
Instead of having a central repository of spam, why not use a
distributed spam-control system analogous to NoCeMs for Usenet news?
Anyone could then issue digitally-signed spam-block notifications, but
an individual user would configure their system to only apply notices
that came from cancellers they trusted. An Alpha version of NoCeM for
e-mail already exists, at <>.

Some advantages of this system are:

o It thwarts malicious individuals or organizations attempting to
systematically censor e-mail. Unless the user lists them as trusted
cancellers, their notices will be ignored.

o A 'spotcheck' mode would allow users to occasionally receive an otherwise
cancelled e-mail, to ensure that an otherwise trusted canceller hasn't
stepped over the line between spam-blocking and censorship.

o There is no risk of some central database being compromised by spammers or

o Users receive more timely warnings of new spam, without needing to
periodically check and download a spam-list.

o  The spammers have no-one to sue for freedom-of-speech violations.
While I'm not a lawyer, I can't see any way to sue someone for merely
suggesting that a spammer's mail isn't worth reading.

> > The risk of harm to innocent bystanders who happen to share hostnames,
> > ISPs, or other characteristics with targeted spammers.
> This is not a risk.  This is a benefit.  [...]

I can't see that this is a benefit. Changing your ISP is hardly a trivial
task - you have to notify all of your correspondents of your new e-mail
address, archive any web pages you may have stored at your ISP, reconfigure
your internal network if you were using a Class C subnet, etc. It's grossly
unfair to punish legitimate users because they were unfortunate enough to
have some Canter and Siegal wanna-be set up shop on their ISP.

Ted Wong  Information Technology Section  Mann Library, Cornell University

Re: Risks of automatic spam blockers (Zerkle, RISKS-19.02)

"Rosenthal, Harlan" <>
Wed, 2 Apr 1997 08:33:02 -0800 (PST)
> [...] they will take their business elsewhere.

Easy to say from a university or company account.  In the real world, nobody
wants to change addresses and notify all of their correspondents, especially
if it means losing an established presence that may have been widely
disseminated to =potential= correspondents (not to mention reprinting
stationary and business cards).  And why should the multitude suffer this
inconvenience, expense, and loss of communication, for the activities of the

Spam is the biggest single argument for usage charges.  As long as it's
cheap to set up a new address and free to abuse it, there's no reason for
the spammers to cut down on e-mailing spam and freeloading on other people's
processors and comm lines.  The fact that spam can be sent from a domain
shared by many legitimate users, and that even new addresses may be reused
after the spammer changes away, means that abusers are hiding among the
innocent like hostage-taking terrorists - hyperbole, perhaps, but congruent
in style if not in magnitude.  The goal of any anti-spam approach should be
to block, slow, or encumber transmission as close to the source as possible.
Yet legitimate cases are always at risk; limiting the cc: lines, for
example, could inconvenience clubs or companies almost as much as it slows
the spammers.  As in any police-power or security effort, the problem is how
much freedom the average innocent person is prepared to give up so that the
abuser can be blocked.


Re: Risks of automatic spam blockers (Zerkle, RISKS-19.02)

Dan Franklin <>
Wed, 2 Apr 1997 09:32:46 -0800 (PST)
> The original spamming host is going to show up somewhere in the Received:
> line, [...]

Note that if you are fortunate enough to have Received: lines to work from
(the most recent spam I received had none at all, either because the relay
host was defective or because it really was sent directly to my mailhost)
you still have a challenge, because the spammer can insert one or more bogus
Received lines in the initial message, so the one added by the first relay
host will be buried in the middle.

By the way, it does not seem practical to me to block all mail-relay sites
that don't add Received lines.  How would you generate such a list?  What
incentive would you provide to such a site to change their software?

Dan Franklin

Re: Risks of automatic spam blockers (Zerkle, RISKS-19.02)

"J. DeBert" <>
Wed, 2 Apr 1997 10:57:55 -0800 (PST)
Any method of auto-blocking spam will create a serious problem for anyone
who later acquire the spammers' discarded domain names.

Spammers are registering lots of domain names and faking many to evade
anti-spam and cancel bots and to hide from their enemies as well as the
public at large. Once they are done with the domain names and they--the
registered names--become available again, the next organization to acquire
the name will find their mail bouncing or disappearing into /dev/null
somewhere and perhaps harassed by bots and hostile spam-haters which do not
know that the domain name has changed hands. The unfortunate victims of such
acts may not even be able to escape them by merely changing their domain
name, either.

Who is going to removed dead spammer domains from the anti- spam and cancel
bots' records and make sure that everyone knows about it? | I've only one thing to
 Send NO spam        | say to spammers: "47USC227".

  [Many thanks to an onymouse contributor (J DeBert),
  who acted as a guest moderator for this topic.  PGN]

Please report problems with the web pages to the maintainer