The RISKS Digest
Volume 16 Issue 65

Thursday, 15th December 1994

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…


Info on RISKS (comp.risks)
No, I'm not Newt.
"GingrichN" alias Steve Barr
Oral Hackers
Mark Colan via John Markoff
Technology Under the Weather
Gordon Symonds
Wendy's Stock
Charles R Trew
Re: Formal Methods and Exhaustive testing
Tony Lauck
Re: Mailing-list deadman switch
John Gardiner Myers
Re: Self-extracting emacs elisp code
Morgan Jones
RISKS demonstrates more RISKS in mailing list software
Sidney Markowitz

No, I'm not Newt.

Tue, 13 Dec 1994 18:56:01 -0500
AOL's software just makes it easy to pick a `screen name,' any screen name
(up to 5 screen names, in fact).

For the record, I am Steve Barr, reachable at
GingrichN, SarahBrady, BARRST, etc.,, and

AOL did seem to go through federal agencies.  IRS, [B]ATF, CIA, and FBI were
all unavailable.

BTW, someone else registered

Just a cautionary note.  Now all you need to spoof mail is a credit card
(stolen?) and a '10 free hours on AOL' disk.

Steve Barr

Oral Hackers

Wed, 14 Dec 1994 19:09:08 -0800
John Markoff thought the following item might amuse some of you.

>From: Mark Colan <>
>Date: 14 Dec 94 12:42:23 ES
>Subject: Oral Hackers
>from PC Week, 12/12/94, "Some Outrageous, and Not So Outrageous, Predictions
>PC audio's next push into the world of corporate computing will be dealt a
>major blow when a disgruntled layoff victim at General Motors destroys
>hundreds of hours of work by running through a floor of cubicles yelling,
>"FILE! CLOSE! NO!"  The tactic, which will come to be known as oral hacking,
>obliterates unsaved work on speech-enabled systems by closing files without

Technology Under the Weather

Gordon Symonds <>
Mon, 12 Dec 1994 13:37:42 -0500 (EST)
>From the Dec 11 edition of the Ottawa Citizen:

MONTREAL - Myopic weather observation machines installed at Edmonton and
Dorval airports to replace human observers as a cost-cutting measure can't
tell rain from snow and are being withdrawn from service.  Marc Gelinas, a
weather specialist at Environment Canada's St. Laurent office, said the
machines also cannot tell when there are clouds above 10,000 feet.  "At 6:15
PM Friday, it was completely overcast and snowing at Dorval but the
automatic weather system issued a report saying there were only scattered
clouds at 4,000 feet," Gelinas said.  The system at Dorval airport has been
providing pilots with inaccurate weather reports since it was installed Nov.
15.  Humans will remain on the job at the two airports until the machine can
produce accurate weather reports.  But the equipment will remain in place at
another 48 smaller airports across the country.


13 Dec 1994 14:10:14 GMT
Here's an expensive little mistake: American Stock Transfer and Trust Co. of
NY, which handles the stock dividend reinvestment program of Wendy's,
recently gave out double dividends to Wendy's shareholders. The company had
to reprint and remail account statements to thousands of investors
nationwide. I don't know if those receiving dividends via check were given
double stuff, if so, that would have generated additional headaches I'm
sure.  Charlie Trew

Re: Formal Methods and Exhaustive testing

Tony Lauck <tlauck@CERF.NET>
Thu, 15 Dec 1994 09:12:22 -0800
Those who build computational hardware or software have a responsibility to
ensure that their artifacts produce correct results, because these artifacts
are used in many applications, some of which are extremely critical to life
or property.  I can't imagine any valid excuse for shipping a CPU which
deterministically gives incorrect results due to a bad algorithm or logical
fault in its implementation.  Computer arithmetic algorithms and math
libraries are simple enough to permit complete verification by a combination
of formal methods and exhaustive testing.

Here's a story that illustrates the lengths to which it is possible to go.
In the late 60's I worked in the PDP-10 group at DEC.  Digital had lost a
benchmark to its then arch-rival, Scientific Data Systems.  It seemed that
the PDP-10 square root routine was too slow.  I rewrote the routine and
speeded it up by 25%, putting the new result on the master disk for
subsequent distribution.  Part of my speed up included removing unnecessary
rounding in the early steps of Newton's method.  Being concerned that the
resulting code might produce different results from its predecessor, I
tested the mantissa processing code exhaustively, verifying in each case
that the resulting value was less than one LSB off of the exact answer.  I
also tested all possible values of the exponent and sign fields.  A very
little formal work showed that the combined routine was correct.  (I would
have felt even better if I had had the several months of computer time to
test all 2^36 cases directly.)

I was prepared to swear that my new routine always gave the same answer as
the old.  As it turned out, this was NOT true.  In exactly one case my new
routine did a better job of rounding the square root to single precision.  I
found this out several years later when Mary Payne called my square root
routine "brilliant".  My rejoinder was that it was merely "lucky".  It seems
that Mary had been working to a stricter criteria than mine and wanted the
rounding to always give the closest possible value.

For a long time, Mary Payne was responsible for Computational Quality at
Digital.  She consulted in the design of processors or math libraries, or
anything else which was likely to result in bad numbers coming out of
Digital's computers.  It seems most unlikely that the Pentium bug would have
gotten past her.

Re: Mailing-list deadman switch

John Gardiner Myers <jgm+@CMU.EDU>
Sat, 10 Dec 1994 18:33:56 -0500 (EST)
As a postmaster at a large site, I have to say I have a real problem with
mailing lists which have this "must actively resubscribe" feature.

The feature assumes that all recipients of the list are live humans, who can
interpret the resubscribe message and reply.  That assumption is not always
true.  At our site, we encourage users to *not* subscribe to lists directly,
instead we prefer to gateway mailing lists into our bulletin board system.
This approach saves disk space, mail delivery time, and most importantly
administrator time dealing with expired or abandoned accounts.

When some list sends out a resubscription request, at least one reader of
the associated bboard has to forward it to an administrator, who has to
manually respond.  This is a waste of expensive staff time.  Many times, the
subscription just expires and any user who later becomes interested in the
list sees what incorrectly appears to be an inactive list.

On a different topic: after spending some time composing a reply to the
list-looping query in RISKS-16.59, including technical information as to
what the standards state various mail agents should do in various
situations.  In 16.60, I read a reply by Peter da Silva which gave
information on the topic that was in fact *completely incorrect*.  Later I
was horrified to find my name included in an editorial comment as having
given a "similar response" on the topic.

I suppose this is a RISK of RISKS; by contributing to an edited forum I
ended up having my name attached to a position I completely disagree with.
I hope the editor will post this retraction: it is my professional position
that error (and other) notifications be sent to the envelope return path as
the standards specify, that sending them to Errors-to: violates the
standards and should not be done.

   [Yes, indeed.  Sorry for the guilt by association.  I try wherever
   possible to prune items with similar messages.  Here I elided a
   little too smoothly.  Thanks.  PGN]

Re: Self-extracting emacs elisp code (Blob, RISKS-16.62)

Morgan Jones <>
Tue, 13 Dec 1994 19:26:06 -0500
And here is a good example of not RTFM'ing before sending an alarm:

>With all this talk about self extracting mail "viruses", a friend showed me
>that in emacs (which I use to read mail, along with vm) has the ability to
>self-extract elisp code.  This feature seems to be turned on by default, and
>it not only applies to mail read with emacs, but rather every file visited
>(when the feature is on, of course).

There are actually two mechanisms at work here.  First, emacs supports a
per-file variable initialization mechanism.  Whenever a file is loaded,
emacs scans the end of the file for a special section of "comments" which
provide emacs with values to set in certain buffer variables.  Enabled by
default, this mechanism only allows literal values and so does not
constitute any significant risk.

In Emacs 19, lisp forms may be included as the value for certain variables,
and a special 'eval' construct is allowed which simply evaluates its form.
By default, emacs shows you the code and asks if it should be evaluated.

The risk is that emacs is a very complicated product and generally requires
a fair amount of configuration and customization to be usable by a power
user.  When a less experienced user sees the "cool stuff" that the power
user does, he simple copies the power user's emacs configuration file.
Unfortunately, the inexperienced user cannot read the file and so picks up
many unwanted changes.  If the power user made use of the 'eval' feature, he
would probably disable the execution query; the inexperienced user would
then be unwittingly susceptible to trojan attacks.

Being the primary emacs disciple at my site, I am usually the one
responsible for propagating annoying functionality to coworkers.  To
avoid this problem, I have separated the benign functionality of my
configuration to a centrally available file for other users to
execute.  Dangerous or annoying customizations are stored in my local
configuration file which other users no longer need to copy.

Morgan W. Jones —
Algorithmics Incorporated, Toronto, Canada

RISKS demonstrates more RISKS in mailing list software

Sidney Markowitz <>
Tue, 13 Dec 1994 14:03:25 -0800
I just received something that I guess was sent directly to the RISKS
digest LISTSERV remailing address, thus bypassing the normal moderation
process of mail sent to If I'm correct, those of you not
receiving RISKS via the LISTSERV distribution did not see it.

It was an ad for some computer hardware. Some people have been sending
commercial e-mail messages to lists of mailing list addresses, ignoring the
lack of relevance of their ad to the lists' topics. That is called
"spamming" and is considered by many on the Internet to be antisocial

This particular message apparently was sent from e-mail address LIONEL
GOLDBERG <> (But read RISK #3 below!). I contacted
netcom and was told that they have an explicit policy against spamming from
their customers' accounts.

RISK #1: The LISTSERV system used by RISKS for automating list distribution
on BITNET allows this kind of bypassing of the moderator.

RISK #2: If really sent this message to RISKS and a
bunch of other mailing lists indiscriminately, complaints to can lose him his account.

RISK #3: E-mail can easily be forged. The LISTSERV software conveniently
removed all traces of the actual path that the message took before it
arrived at the list server and was redistributed, so I could not tell if
the message was even a crude forgery sent from someone other than the
account in the "From" header. So please don't jump the gun in accusing

RISK #4: The ad asks for people to send checks or money orders, no COD or
credit cards, to some unknown company for unseen equipment. Anyone want to
buy a bridge?

RISK #4.9999721: Some of the items listed are Pentiums :-)

 — sidney markowitz <>

   [Comments from too many of you to name on this, including
      some who got multiple copies, and some of whom got copies
      from lists to which they are not even subscribed.
      netcom has disabled the account.  RISKS was not the only
      list hit.

   As you all know, the BITNET LISTSERV is wide open to the world.
   I have no control over what goes gets redistributed, although
   perhaps one of its wizards will change that soon?  Perhaps
   it should have been set up that ONLY RISKS can cause E-mail to
   be distributed to the list, but that is not the way it works.
   Occasionally some overly moronic individual spams our BITNET
   readers.  Perhaps the automated server that we are trying to set
   up might induce some of you to switch over, although my system
   does not really need the added burden...  Stay tuned.  PGN]

Please report problems with the web pages to the maintainer