Subject: RISKS DIGEST 16.65
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest  Thursday 15 December 1994  Volume 16 : Issue 65

  FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
  ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** NOTE, THE SRI RISKS ARCHIVE SOURCE has moved to unix.sri.com.  *****
***** See FIRST item for further information, disclaimers, etc.       *****

 Contents:
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
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)

----------------------------------------------------------------------

Date: 15 December 1994 (LAST-MODIFIED)
From: [email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

The RISKS Forum is a moderated digest.  Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.

SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you.  BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS.  U.S.
users on .mil or .gov domains should contact <[email protected]>
(Dennis Rears <[email protected]>).  UK subscribers please contact
<[email protected]>.  Local redistribution services are
provided at many other sites as well.  Check FIRST with your local system or
netnews wizards.  If that does not work, THEN please send requests to
<[email protected]> (which is not yet automated).  SUBJECT: SUBSCRIBE
or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent]

CONTRIBUTIONS: to [email protected], with appropriate,  substantive Subject:
line, otherwise they may be ignored.  Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious.  Diversity is
welcome, but not personal attacks.  PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them.  Contributions will not be ACKed; the load is
too great.  **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks.  Anonymized mail is not accepted.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.

CURRENT ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>YourName<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.
Issue J of volume 16 is in that directory: "get risks-16.J<CR>".  For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 15, J always TWO
digits) for Vol I Issue j.  Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>"  I and J are dummy variables here.  REMEMBER,
Unix is case sensitive; file names are lower-case only.  <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username,
password; [email protected] and WAIS are alternative repositories.
See 15/risks-15.75 for WAIS info.
  To search back issues with WAIS, use risks-digest.src .
  With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html or
  http://all.net:8080 (the latter courtesy of Fred Cohen).

FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving
it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info
regarding fax delivery.  PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL
RISKS COMMUNICATIONS; as a last resort you may try phone PGN at
+1 (415) 859-2375 if you cannot E-mail [email protected] .

------------------------------

Date: Tue, 13 Dec 1994 18:56:01 -0500
From: [email protected]
Subject: No, I'm not Newt.

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. @aol.com,
[email protected], and [email protected].

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

BTW, someone else registered [email protected].

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

------------------------------

Date: Wed, 14 Dec 1994 19:09:08 -0800
From: [email protected]
Subject: Oral Hackers

John Markoff thought the following item might amuse some of you.

>From: Mark Colan <[email protected]>
>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
>saving.

------------------------------

Date: Mon, 12 Dec 1994 13:37:42 -0500 (EST)
From: Gordon Symonds <[email protected]>
Subject: Technology Under the Weather

>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.

------------------------------

Date: 13 Dec 1994 14:10:14 GMT
From: "CHARLES R TREW" <[email protected]>
Subject: WENDY'S STOCK

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

------------------------------

Date: Thu, 15 Dec 1994 09:12:22 -0800
From: [email protected] (Tony Lauck)
Subject: Re: Formal Methods and Exhaustive testing

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.

------------------------------

Date: Sat, 10 Dec 1994 18:33:56 -0500 (EST)
From: John Gardiner Myers <[email protected]>
Subject: Re: Mailing-list deadman switch

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]

------------------------------

Date: Tue, 13 Dec 1994 19:26:06 -0500
From: [email protected] (Morgan Jones)
Subject: Re: Self-extracting emacs elisp code (Blob, RISKS-16.62)

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 -- [email protected]
Algorithmics Incorporated, Toronto, Canada

------------------------------

Date: Tue, 13 Dec 1994 14:03:25 -0800
From: [email protected] (Sidney Markowitz)
Subject: RISKS demonstrates more RISKS in mailing list software

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 [email protected]. 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
behavior.

This particular message apparently was sent from e-mail address LIONEL
GOLDBERG <[email protected]> (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 [email protected] really sent this message to RISKS and a
bunch of other mailing lists indiscriminately, complaints to
[email protected] 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
[email protected].

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 <[email protected]>

  [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]

------------------------------

End of RISKS-FORUM Digest 16.65
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.