Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 16: Issue 61

Tuesday 6 December 1994

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)

Lots of Turkeys

Debora Weber-Wulff <weberwu@tfh-berlin.de>

6 Dec 1994 12:01:44 GMT

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  weberwu@tfh-berlin.de <http://sun24.tfh-berlin.de:8000/dww/>

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

Fun with your phone company [foreshortened by PGN]

Russell Stewart <diamond@RT66.com>

Tue, 06 Dec 1994 14:43:08 -0500

  [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   diamond@rt66.com

Pentium + Spell-Checkers

Paul Fuqua <pf@islington-terrace.hc.ti.com>

Tue, 6 Dec 94 11:40:37 CST

     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   pf@hc.ti.com

   [Until Megadeath Do It Part.  PGN]

Pentium FDIV bug

A. Padgett Peterson <padgett@tccslr.dnet.mmc.com>

Thu, 1 Dec 94 08:01:42 -0500

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

Re: Interesting product claim (more Pentium stuff)

Mathew Lodge <lodge@ferndown.ate.slb.com>

Tue, 06 Dec 94 12:59:28 000

Mike Kenney <mike@wavelet.apl.washington.edu> 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  lodge@ferndown.ate.slb.com (+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]

Virus alert virus alert

Yehuda Berlinger <yehuda@jerusalem1.datasrv.co.il>

Tue, 6 Dec 1994 10:14:47 +0200

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 <rfurr@jazz.ncren.net>, 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]

Re: Mailing list problems...

David Barr <barr@pop.psu.edu>

Mon, 5 Dec 1994 22:10:38 -0500

>        ``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 brian@nothing.ucsd.edu (Brian Kantor), who said,
  "If you can find errors-to in RFC822, you've got better coffee than we do."]

Mailing-list deadman switch

Steve Losen <scl@sasha.acc.virginia.edu>

Tue, 06 Dec 94 11:03:26 -0500

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   scl@virginia.edu    phone: 804-982-4711
University of Virginia               ITC Unix Support

"Applied Cryptography" by Schneier

"Rob Slade, Social Convener to the Net" <roberts@mukluk.decus.ca>

Tue, 06 Dec 1994 15:04:46 EST

BKAPCRYP.RVW  941012

"Applied Cryptography", Schneier, 1994, 0-471-59756-2, U$44.95
schneier@chinet.com
%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   jdemarra@jwiley.com aponnamm@jwiley.com
%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 ROBERTS@decus.ca, RSlade@sfu.ca, Rob Slade at 1:153/733

Report problems with the web pages to the maintainer