Subject: RISKS DIGEST 16.61

Subject: RISKS DIGEST 16.61
REPLY-TO: [email protected]
Errors-To: [email protected]

RISKS-LIST: RISKS-FORUM Digest Tuesday 6 December 1994 Volume 16 : Issue 61

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

***** See last item for information on RISKS (comp.risks), disclaimers *****
***** NOTE, SRI RISKS ARCHIVE SOURCE IS MOVING SOON TO ANOTHER HOST. *****
Contents:
Lots of Turkeys (Debora Weber-Wulff)
Fun with your phone company (Russell Stewart)
Pentium + Spell-Checkers (Paul Fuqua)
Pentium FDIV bug (A. Padgett Peterson)
Re: Interesting product claim (Mathew Lodge)
Virus alert virus alert (Yehuda Berlinger)
Re: Mailing list problems... (Errors-To) (David Barr)
Mailing-list deadman switch (Steve Losen)
"Applied Cryptography" by Schneier (Rob Slade)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

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

Date: 6 Dec 1994 12:01:44 GMT
From: [email protected] (Debora Weber-Wulff)
Subject: Lots of Turkeys

The "Stars and Stripes" (a "small-town" newspaper in English for the
military communities in Europe, to which I am also allowed to subscribe in
order to read the comics every day...) reports that the payments for the
civilian employees in Germany this month were credited to the accounts of
the employees twice. Seems that the payroll tape is usually run on the 24th
of a month. Someone bright noticed that the 24th is turkey day, and ran the
tape on the 23rd. Some other bright person also ran the tape on the 25th
since the 24th was a holiday.... Suddenly they noticed that there were about
3.5 million dollars missing (good thing they have a bookkeeping system!).
The "turkeys" spent most of Saturday fussing with the system and rolling
back the second set of transactions. It is reported that the civilians are
hoping for another such windfall at Christmas...

Debora Weber-Wulff, Technische Fachhochschule Berlin, FB Informatik, 13353
Berlin, Germany [email protected] <http://sun24.tfh-berlin.de:8000/dww/>

[Beware of Tur[n]key systems. They can gobble up lots of money. PGN]

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

Date: Tue, 06 Dec 1994 14:43:08 -0500
From: [email protected] (Russell Stewart)
Subject: Fun with your phone company [foreshortened by PGN]

[Russell submitted a longish item on how his phone company cleared a
check of his for $150, but did not credit his account. To make a
long story short, he had changed his address and phone number from his
parents' home, and the $150 was credited to his OLD phone number, which
was the number that appeared on his check. His father did not notice
the credit on the home account. Apparently his phone company ignores the
number on the bill! GROAN. PGN]

In other words, that little portion of the bill that you tear off and put in
the envelope with your payment is completely useless, because they only
check the phone number ON THE CHECK ITSELF. I don't know how many phone
companies use this type of a system, but let this serve as a warning to
anyone who has recently changed address...

Russell Stewart Albuquerque, New Mexico [email protected]

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

Date: Tue, 6 Dec 94 11:40:37 CST
From: Paul Fuqua <[email protected]>
Subject: Pentium + Spell-Checkers

On December 5, the {Dallas Morning News}, not the most
technically-aware newspaper in the world, ran an article from the {San Jose
Mercury News} about the recent Pentium FDIV situation.
Unfortunately, they ran it through a spell-checker first. The company
names "Intel" and "Megatest" became "Until" and "Megadeath," which actually
puts an interesting slant on the story.
I've only ever seen one writer's byline on computer-related articles in
the DMN, so the root problem may be that no one else at the paper knows
enough to catch this obvious (to us) error.

Paul Fuqua Texas Instruments, Dallas, Texas [email protected]

[Until Megadeath Do It Part. PGN]

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

Date: Thu, 1 Dec 94 08:01:42 -0500
From: [email protected] (A. Padgett Peterson)
Subject: Pentium FDIV bug

Interlocutor: Why did they call it "Pentium"?
Mr. Bones : Because when they added 100 to 486,
the answer was 585.994257

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

Date: Tue, 06 Dec 94 12:59:28 000
From: Mathew Lodge <[email protected]>
Subject: Re: Interesting product claim (more Pentium stuff)

Mike Kenney <[email protected]> wrote
> As CPUs get more and more complex, the chance of bugs slipping through will
> probably go up. I just hope whichever company it happens to next handles
> the problem better than Intel.

When Inmos designed the T8 series of Transputers, they used formal methods
to prove that the algorithms used in the on-chip FPU were correct. I am
frankly amazed that a huge company like Intel relies solely on testing the
hell out of a new chip -- which, of course, *proves* nothing. If a small
British company like Inmos can prove an IEEE math FPU correct, why can't
Intel?

Perhaps this recent debacle will convince at least some people that formal
methods can be cheaper than mistakes.

Mathew Lodge, Software Engineer, Schlumberger Technologies, Ferndown,
Dorset, UK, BH21 7PP [email protected] (+44) (0)202 893535 x404

[We have not had any discussions on the appropriateness of formal
methods in any systems, let alone critical systems, in a long time.
Time to open up the Testing vs Formal Methods wars again? PGN]

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

Date: Tue, 6 Dec 1994 10:14:47 +0200
From: Yehuda Berlinger <[email protected]>
Subject: Virus alert virus alert

I have been inundated with virus alerts. Somehow, this virus alert has been
propagating out of control. It must be a virus in the virus alert. (Note:
I don't mean to belittle the alert, but there must be some way of controlling
its propagation. I have received it 4 times now from different sources.)

>I have just received this message and been asked to take it seriously:
>There is a virus on America Online being sent by E-Mail. If you get
>anything called "Good Times", DON'T read it or download it. It is a
>virus that will erase your hard drive. Forward this to all your
>friends.
>It may help them alot.

[I suppose you are lucky you only got 4 copies.
But it appears to be a complete hoax, as suspected
by Rob Furr <[email protected]>, who was amused at the
close timing of the AOL message and Michael Slavitch's
item in RISKS-16.60, and who added
There are idiots in the world who think it's awfully funny to cry
"Wolf" as soon as someone else notices that it's theoretically
possible that wolves exist. Rob F.
PGN]

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

Date: Mon, 5 Dec 1994 22:10:38 -0500
From: David Barr <[email protected]>
Subject: Re: Mailing list problems...

> ``A subscriber site that does not honor the "Errors-to:"

Except that "Errors-To" was introduced by sendmail, and is not in any RFC,
822 or otherwise. The 822 Police will arrest YOU for false arrest. :-)
(The Risk in assuming the most popular implementation of a protocol is The
Way Things Are. See also Return-Receipt-To:)

The correct way is to set the envelope FROM to the bounce address.
On those systems which don't have envelope addresses, it's up
to them on how to preserve the bounce address in-band -- which is where
much of the problems with mailing loops get started.

It's surprising the number of people (and therefore the number of
misconfigured mailers and gateways) which don't understand the mail
specs. However, it's understandable given that 822 and 821 are 12
years old and are probably one of the most cryptic and vague out there,
especially considering how critical they are to the Net. They really
need to be updated and clarified.

Something like "Precedence: junk" is bad, because there's never any
feedback to the system. Addresses which fail simply get tossed, and
they never get removed from the list. The list grows linearly, and you
waste more and more resources trying to deliver mail to addresses that
go nowhere anyway.

--Dave

[Also noted by [email protected] (Brian Kantor), who said,
"If you can find errors-to in RFC822, you've got better coffee than we do."]

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

Date: Tue, 06 Dec 94 11:03:26 -0500
From: Steve Losen <[email protected]>
Subject: Mailing-list deadman switch

I am a unix system administrator at the University of Virginia and we
regularly run across "abandoned" mailboxes that are growing rapidly with
messages from busy mailing lists. This is particularly troublesome over the
summer break and winter holidays. I have noticed that some mailing lists
have what I call a "deadman switch" feature, whereby the listserver
periodically sends all subscribers a message requesting that they confirm
their subscription by replying. Anyone who fails to reply gets
unsubscribed. When a user is unsubscribed in this fashion, the listserver
sends a final message with instructions for getting back on the list. I
think that some of these lists are smart enough to not send requests for
confirmation to members who have posted to the list recently. I think that
this is an excellent feature because many folks who subscribe to lists never
figure out how to get off them or never bother. Some folks get a new account
and never bother to deal with mail still coming to the old one.

I encourage anyone who runs a high volume mailing list to consider using a
deadman switch to ensure that mail is going to mailboxes that are actually
being read.

It would also help if mailing list administrators would regularly
send out a brief message with information on how to unsubscribe.

Steve Losen [email protected] phone: 804-982-4711
University of Virginia ITC Unix Support

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

Date: Tue, 06 Dec 1994 15:04:46 EST
From: "Rob Slade, Social Convener to the Net" <[email protected]>
Subject: "Applied Cryptography" by Schneier

BKAPCRYP.RVW 941012

"Applied Cryptography", Schneier, 1994, 0-471-59756-2, U$44.95
[email protected]
%A Bruce Schneier
%C 22 Worchester Road, Rexdale, Ontario M9W 9Z9
%C 605 Third Avenue, New York, NY 10158-0012
%D 1994
%G 0-471-59756-2
%I John Wiley & Sons, Inc.
%O U$44.95 800-263-1590 fax: 800-565-6802 800-CALL-WILEY
%O [email protected] [email protected]
%P 618
%T "Applied Cryptography"

For anyone who wants to study cryptography, you can save yourself a lot of time
and effort by getting Schneier's book. From the simple Caesar cipher to RSA
and beyond, there is nothing the book doesn't at least touch on. Protocols,
techniques, algorithms, and even source code are included. A "Real World"
section looks both at specific implementations and at the politics of
encryption.

Schneier notes that his work is *not* a mathematical text. It is difficult to
say how much of a shortcoming this is for any given reader, but a safe bet is
"not much". For those who do need more rigorous treatments of specific topics,
the bibliography lists almost a thousand references, all of which are
described and cited within the book text at some point.

He also states that the encyclopedic nature of the book detracts from its
readability. Not so. The work is both encyclopedic *and* readable. Schneier
has done marvelously well with what is normally a dead and dry topic. His
examples are ludicrously absurd--and therefore lucid and memorable. (He even
uses Monty Python's immortal phrase, "My hovercraft is full of eels" in one
illustration.)

As course text, research basis or just a (serious) hobbyist's reference, this
work is highly recommended.

copyright Robert M. Slade, 1994 BKAPCRYP.RVW 941012

DECUS Canada Communications, Desktop, Education and Security group newsletters
Editor and/or reviewer [email protected], [email protected], Rob Slade at 1:153/733

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

Date: 23 November 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.

ARCHIVES ARE MOVING SOON (BEWARE: THE NEW SYSTEM IS CASE SENSITIVE):
ftp unix.sri.com
cd risks

CURRENT ARCHIVES: "ftp crvax.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; "dir" (or "dir [.i]") lists (sub)directory; "bye<CR>"
logs out. CRVAX.SRI.COM = [128.18.30.65]; <CR>=CarriageReturn; FTPs may
differ; UNIX prompts for username, password; [email protected] and
WAIS are alternative repositories. See 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.

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

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

End of RISKS-FORUM Digest 16.61
************************