The RISKS Digest
Volume 16 Issue 60

Monday, 5th 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…


Excel linked spreadsheet bug
Michael D. Crawford
Random Testing of Floating Point: Doesn't Everyone?
Robert Ayers
3 hits and you're out? (SSN use)
Geoffrey S Knauth
The Economist and E-cash
Mark Stalzer
RISKS of Going to the Movies
Keith Schengili-Roberts
Providing Good Defaults (and risks of not doing so)
Ry Jones
The PC as a RISC
Michael Slavitch
HERF Rides Eye To Eye
Winn Schwartau
Interesting product claim
Mike Kenney
Criminals 1, Consumers 0
Peter J. Denning
Re: Duplicate bridge-tournament hands
Asya Kamsky
Re: Listserv Loops
Steve Summit
Peter da Silva
Joe A. Dellinger
"Tekroids" episode of Tekwar and the perception of viri
Rob Slade
Info on RISKS (comp.risks)

Excel linked spreadsheet bug

Michael D. Crawford <>
Sun, 4 Dec 1994 02:58:46 -0800
There is a bug in Microsoft Excel for the Macintosh in which results from
linked spreadsheets are incorrectly recalculated.

A friend of mine who owns a business overdrew his company checking account
by $4,000 as a result.

Interestingly, he had a "fail-safe" system, in which his accountant
recommended which bills to pay based on the total account balances.  The
accountant recommend he pay a bill for about $2,000, then inadvertently
credited this to the balance sheet rather than debiting it.  My friend
checked the accountants work using a linked spreadsheet.  The calculation
showed that he had $4,000 more then was really available.  The unlikely
coincidence of making a manual mistake that matched a software error
convinced my friend that it was safe to write the check.

My friend can easily duplicate the bug.  Apparently the bug is being
discussed on Compuserve these days, with the word being that it only happens
on really complicated spreadsheets.  My friends spreadsheets, though, are
quite simple - one spreadsheet to tally the checking balance, one to tally
the credit card account balance, and a third to total the two accounts.

Michael D. Crawford

Random Testing of Floating Point: Doesn't Everyone?

Robert Ayers <>
Sat, 3 Dec 94 13:41:33 PST
In RISKS-16.59 Wilson P. Snyder notes "at Digital, our Alpha AXP processors
are tested using psudo-random techniques ... Random testing often finds
interesting problems that would never be found by just writing specific

Hasn't everybody done this forever?

Back in the '60s (yes that's "sixties") I watched IBM upgrade a 7090 to a
7094.  The third *day* of the post-upgrade verification was a test of the
new floating point arithmetic (a 7094 upgrade added double precision) using
randomly generated data and a fixed-point simulation of the FP for

I asked the IBM CE whether that twenty-four hours of floating-point testing
was really necessary.  He replied "Yup. I've seen the test run OK for
sixteen hours and then find a failure."


   [By the way, I have suppressed a huge influx of Intel `humor' that has
   been submitted to RISKS.  I have seen so many copies of so many different
   items on so many redistributions that it seems unnecessary to include
   them here, or to note that I have seen at least 63.999975 distinct jokes
   thus far.  PGN]

3 hits and you're out? (SSN use)

Geoffrey S Knauth <>
Mon, 5 Dec 1994 16:29:30 GMT
Last week, a friend was writing software to make credit checks as part
of a large project involving government loans to individuals.  He
returned home and told his wife we'd been using my social security
number to test the interface, with my permission.  His wife works at a
bank, and she told him he'd better not do three checks on me, or I
wouldn't get any more credit.  I was surprised to hear that a credit
check carries with it this sort of penalty.  Can anyone from the
credit industry confirm this?

  My friend was recently given a "test" SSN to use, so I shouldn't
have to worry more.

Geoffrey S. Knauth <>
Marble Associates, Inc., (617) 487-0050   CRASH-B Sprints, Cambridge Boat Club

The Economist and E-cash

Mark Stalzer <>
Tue, 29 Nov 1994 12:27:36 +0800
The 26 Nov 1994 issue of The Economist has a story on electronic money
(p.21--23). It covers some of the current attempts to create "virtual banks"
on the internet so that consumers can buy from electronic stores without
sending credit card numbers in the clear.  This is fairly mundane stuff to
risks readers, but the story moves on to the evolution of digital cash. Some
of the possibilities are interesting, such as private issuers of E-cash
(that will probably be more stable than most governments!) to a world-wide
currency (no exchanges rates and middle-people). Recommended reading if
you're curious about some of the broader issues of electronic money.

Mark Stalzer,

   [E-cashibus unum.  PGN]

RISKS of Going to the Movies

Keith Schengili-Roberts <>
Sun, 4 Dec 94 22:53 WET
Recently, my wife and I decided to go to see a movie at one of the cinemas
in downtown Toronto.  It was a rainy day, and there was a long line-up to
see the film.  I noticed that just inside the foyer of the theatre were a
couple of automatic ticket dispensing machines.  Nobody was at the machines,
save for a couple of kids who were playing with them.

I had used the automatic ticket vending machines before, and they operate
in a similar fashion to automatic teller machines.  Instead of cash, you
get film tickets. You can also buy things like popcorn and cola in the form
of tickets that you take to the concession stand.  It was my wife's treat,
so she shooed away one of the boys who was playing with one of the
machines, and proceeded to swipe her credit card in the card-reader.

Tickets began to pour from the machine.  General Admission, Senior's and
Children's tickets along with coupons for purchasing a small mountain of
popcorn and a river of cola issued from the machine, like a one-armed
ticket-dispensing bandit gone mad.  In the end my wife was charged for
approximately $375.00 of goods.  The kids who had been playing with the
machine before were nowhere to be seen, and the movie was about to begin.

What had happened was this: the kids who had been playing with this machine
had made just about every conceivable selection on its touch-screen before
my wife got to it.  Part of the reason why it must have been fun for them
to play with is because you do not have to prove your purchasing power with
a credit/bank card beforehand.  You can make as many on-screen selections
as you like, and it will merrily rack up the total charges.

While there is a screen that asks if you want to purchase all of the items
you have selected, to someone inexperienced with these types of machines,
it appeared to be a "start" screen.  A further risk was revealed when my
wife used her Credit Card with the machine.  It has it's PIN number
built-in, (convenient by highly RISK-y) so the moment she swiped the card
past the reader, it confirmed the order immediately.

In the end the staff at the theatre were very helpful, and at the end of
the movie my wife handed over her receipt from the machine, and expected to
have the charges on her credit card reversed.  Instead she was paid back in
cash directly from the box- office takings by the theatre manager.  When I
asked why, it turned out that there was no procedure between the bank that
installed the automatic ticket dispensing machines and the theatre-chain to
deal with this type of situation.  The manager said that they'd definitely
"have to look into it".  Luckily a bank was nearby and payment to my wife's
account was made before any interest charges could accumulate.

When we went back to the same theatre again recently for another movie, I
noticed a couple of changes.  A ticket-agent stood guard to make sure that
nobody played around with the machines who didn't intend to purchase
anything, and there was a large sheet of instructions placed beside each
machine.  I paid for the tickets this time, and used a bank card that does
not have a built-in PIN number.  Everything went smoothly this time: we got
the tickets we requested, and managed to zip past the rest of line and got
good seats in the theatre.

The movie was good too!

Keith Schengili-Roberts, Writer/Reviewer, The Computer Paper - Toronto Office
Canada's largest computer magazine, free, on-line at: http//

Providing Good Defaults (and risks of not doing so)

Ry Jones <>
Sat, 26 Nov 1994 22:58:27 -0800 (PST)
One of the frequently referenced style guides for programming (the Indian
Hill guide, I think) talks about the value of good defaults. The current
Slackware Linux distribution does not do so in one important area, and
I was able to 'explore' a system due to this flaw in the installation:

Slackware does not force a root password on install.

The system in question was hooked up to the internet for casual use by
someone I have known for a long time. Apparently, the two way nature
of a PPP link didn't cross the minds of the three people involved in
getting the system on the net, and they never set any passwords.

I was able to get in as root and make clear to the machine's owner
that he had no security.

I called him afterwords and we set things up much tighter, but it's
disturbing to me that neither the OS install nor the network software
install forces you to set any password.

To be sure, this is freeware, and is to be used by an experienced user
community, but it was all to easy for them to escape onto the net
without any warnings. I have noticed many linux systems on the net
that still have the default users (gonzo et al) still installed.

Good defaults, I think, would solve this.

The PC as a RISC (how could I resist 8)*

"Michael Slavitch, Consultant, (613) 781-9824" <>
Mon, 28 Nov 94 09:44:03 -0500
A. Padgett Peterson writes:

 > This is just what the world needs: self-extracting and executing E-Mail.

This was the case with several commercial (non-smtp) mail packages such as
Novell's MHS. Several years ago I was developing software for the Novell
platform (I still do when people throw money at me to do it :). I was having
problems with one of my programs.  I uuencoded the file and sent it to a, along with source, and for some reason :) the
early-version MHS mail system immediately began to self extract the file.

Unfortunately, I had given the UUENCODED .NLM (Netware Server Executable)
file a hard path (thinking that the smart engineer would see it and know
where I had installed it, and yet being smart enough not to put it in a
critical system).

Unfortunately, it had been expanded on a system by a dumb computer :) where
the NW developer also had *root* like privs, so the file would expand and be
placed anywhere in the netware file server system. Luckily the program never
loaded (although if it had been given a name of a program that was loaded
periodically life as we had known it would have ceased to exist) and I found
out about it through a *confirmation message* sent to me by the mailer.

Now think about this and remember the internet worm (this was *years*
later). I told my buddy about this by email and within a couple of weeks
there was a patch update to MHS.  I got a lot of phone calls from Novell
developers trying to figure out what I had done.

Basically, I could send a new password files to *supervisor* (NW's *root*)
and then after that set file privilages by email to my hearts content.

Let me just say that MHS doesn't do that anymore. And yes, I've tried to
break it (with permission) without success since.  But I'm a medium-smart
hacker. Some real devils out there could probably figure out a way to mess
greatly with such systems, especially now that MIME and WWW are becoming
more commonplace (what about Web-bombs using creaky web forms? It has been
done by a relatively good hacker buddy of mine in a couple of minutes).

I am distrustful of the security of any system that allows a person to place
a file without explicit authorization, as well as authentication (web forms,
FTP, and self-extracting mail). Digital sigs will keep unauthorized people
from doing dangerous things, but it won't keep authorized people from doing
things that cause stupid computers to do stupid things.


HERF Rides Eye To Eye

"Winn Schwartau" <>
Thu, 01 Dec 94 22:55:19 -0500
Connie Chung's "Eye to Eye" (ABC, 12/1/94) provided an excellent primer on
accidental electronic interference.  (My book is a pretty good source, too.
Can't resist the 'plug.') They brought into living room TV color clarity
more hard examples of EMI:

     * Children's life support systems failing by cell-phone induced EMI.
     * Defibrillators malfunctioning.
     * Wheelchairs spinning in circles from portable radio interference.
     * Airplane (727) avionics and guidance systems (both primary
       and secondary) going haywire from passenger radio.

The focus was on _accidental_ EMI events, which were low power events at
that.  Radio emissions and cell phones and such are not power intensive
devices (a few hundred milliwatts) but still can cause dramatic systemic

Obviously (for those who know my work) when intentional EMI is "turned up"
to higher power levels, the interference is increased as well.  Thus, as I
discussed in "Information Warfare," when a bad guy has the capability to
generate electromagnetic fields of a greater strength, control the frequency
and focus or aim them upon targets, we can similarly expect to see man-made
EMI events of greater intensity in greater numbers.

Bringing down financial econo-technical infrastructures (among other
targets) through electromagnetic denial of service attacks is on its way, if
it's not here already.  I am currently investigating a number of fascinating
`incidents.'  (Please let me know if you think you might have been `hit' by
either HERF Gun or EMP/T Bomb assaults.)

A while back [RISKS-16.26] I also posted in RISKS how airplane avionics
interference is caused by on board digital devices and how such
vulnerabilities could be exploited by suicidal maniacs or those of the
terrorist flavor.  I also recall a number of readers "doubting nay-sayers"
pooh-poohing such hogwash.

Take a watch of Connie. HERF is again being vindicated.

Winn Schwartau, Executive Director, Interpact, Inc.

Interesting product claim

Mike Kenney <>
Thu, 1 Dec 1994 10:11:42 -0800 (PST)
I ran across the following product description in the Shareware Express
catalog that my wife receives:

  ``COMPUTERIZE YOUR EMPLOYEE TIMECLOCK.  Save time and money.  Convert
    your PC into an employee timeclock and bring timekeeping and payroll
    tasks into the 20th century!  TIMECLOCK logs your employees "in" and
    "out" and calculates their hours automatically at the end of each
    pay period.  Unlike manual systems, it never makes a mistake ... ''

Talk about your bold statements.

But what if you run it on a Pentium? :-)

While I'm on the subject of the Pentium I would just like to toss in my
$0.02.  I don't have a problem with the fact that the chip had a bug ...
it's certainly not the first and it sure won't be the last.  I *do* have a
problem with the way Intel has handled the situation and I'm speaking as
someone who manages 3 Pentium systems.  Since I'm at a university research
lab, I had no problem getting replacements but others are not so lucky.

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.

Mike Kenney, UW Applied Physics Lab

Criminals 1, Consumers 0

Peter J. Denning <>
Thu, 1 Dec 94 09:23:59 EST
Cellular One of the Baltimore-Washington area just distributed a notice to
all customers that they have cut off roaming in the New York City area.
They say that fraud has become too serious a problem.  It is now not
possible to have your calls forwarded to you in NYC.  If you wish to make an
outcoming call in NYC, an operator will take a credit card number and
immediately bill that at rates considerably higher than the normal roaming
rates (which are in turn considerably higher than the regular cellular

The fraud is that thieves have been stealing electronic id numbers by
scanning the cellular frequencies and picking them out; they then program
those numbers in new (cheap) phones and sell them on the streets.  By the
time one finds out that someone else has cloned one's phone, hundreds or
thousands of dollars of calls will have been logged.

   [This problem is of course very widespread.  It's more like
   CRIMINALS $1B, CELLULAR ZERO.  Some countermeasures are of course
   possible, but are impeded by lack of standards, lack of exportability,
   lack of incentives by vendors, lack of customer interest in paying more,
   etc.  PGN]

Re: Duplicate bridge-tournament hands (RISKS-16.58)

Asya Kamsky <>
Wed, 30 Nov 94 14:41:09 PST
That is not what happened at all.  The bridge hands are dealt out by this
machine, and it is set to deal out the same sets of hands until someone
resets it, or puts in a new set of hands.

The machine wasn't used between the two tournaments, so it dealt out the
last set of hands that was fed into it.

Usually when hands are duplicated like this, it's the same set of hands
being used by humans, not the same set being generated by a machine.

As usual — pilot error.


Re: Listserv Loops (Klau, RISKS 16.59)

Steve Summit <>
Thu, 1 Dec 1994 12:37:39 -0800
Mailer loops have probably been around since the dawn of e-mail.  They're
often astonishing, but they shouldn't be: any time mail can be generated by
an automaton (e.g. error messages, "vacation" programs), or a single message
can spawn multiple messages (e.g.  "mail exploders" such as listserv), you
have a system with gain.  Undamped positive feedback can yield spectacular
results, but again, this shouldn't be too surprising.

Anyone writing mail software, even of a rudimentary nature, which has even a
hint of a possibility of inducing any gain, needs to be acutely aware of
these problems, and to take every step possible to reduce the opportunities
for positive feedback and to detect and damp it when (not if) it occurs.
Without taking such precautions, disastrous mail loops are a certainty; with
them, they are merely likely.  (In other words, even mail systems which were
supposedly designed to prevent loops are fairly regularly surprised when
real-world installations discover new ways to connect some pieces together
into feedback loops which manage to bypass any safeguards.)

I believe there was an article discussing this sort of thing in CACM in 1989
or 1990; unfortunately, I no longer have the reference.

Steve Summit

Mailing list problems...

Peter da Silva <>
Thu, 1 Dec 1994 13:51:49 -0600
OK. There's a number of things a list can do to prevent this sort of
problem. You are probably doing at least some of these:

    1. Stamp outgoing list mail as being "junk". I believe that
       this is in the "precedence" header. Many systems toss "junk"
       mail when it's refused.

    2. Set outgoing mail to have an "Errors-To:" address.

    3. Drop incoming mail that is marked as being "junk".

If you were doing all of these things, then the fault is due to the bouncing
software. It should really support all three (mark its mail as junk, drop
junk mail instead of bouncing it, and respond to an errors-to address), but
for it to support NONE of the three is serious brokenness.

> So — has this happened before?

Lots of times. A lot of people keep a human in the loop to prevent this
sort of error cascade. The only other thing you can do is to be totally anal
retentive about how you treat headers. The three items I listed above are
just a start.

   [There were numerous similar responses on this topic, including from (Mark W. Schumann), who added that
        ``A subscriber site that does not honor the "Errors-to:" header
        is broken and should be turned in to the RFC822 Police.''
        {WOULD THAT THERE WERE SUCH!} (Dan Zerkle), (Arthur D. Flatau),
      John Gardiner Myers <jgm+@CMU.EDU>,
      stead@seismo.CSS.GOV (Richard Stead),
      Peter M. Weiss <PMW1@PSUVM.PSU.EDU>, (Michael D. Crawford), (James Thompson).
   Thanks to all of you.  Would that all mail servers were compliant!
   The bad ones are driving me nuts.  PGN]

Re: Listserv Loops

Joe A. Dellinger <>
Fri, 2 Dec 94 18:50:57 CST
    The "vacation" command will cause the same problem, albeit it only
sends one "I'm not here" notice to the entire list before ceasing
auto-responding. As far as I know, there is no automatic way for the list
processor to detect such auto-replies, and they will occur whenever anyone
remains subscribed to a list while on "vacation".

    In 1989, in the Geophysics department at Stanford, a similar
incident involving the Bay Area Chinese Student's mailing list caused
all our departmental computers to crash. In that case someone had
simply forwarded _all_ their mail to the list processor shortly before
going on vacation. The reply addresses kept getting longer with each
round-trip iteration, until they overflowed the fixed-length field in
the Berkeley mail programs allocated for that string, causing the
mail daemon to keep running doing nothing forever. After an hour or
so there would be dozens of superuser-priority mail daemons all attempting
to run simultaneously and the machine would crash. (Our machines crashed
first because in our department we had the highest density of subscribers
to that list.)

    The moral of the story: anything which replicates itself has
the built-in potential of becoming a cancer / virus.

    Note the designers of "mail" recognized the problem and designed
in prevention against infinite mail loops, by the brute force expedient
of killing messages more than a certain number of hops old.

"Tekroids" episode of Tekwar and the perception of viri

"Rob Slade, Social Convener to the Net" <>
Sat, 03 Dec 1994 19:23:53 EST

Bill Shatner has been reading "Snow Crash" (cf BKSNCRSH.RVW)!

In tonight's episode of Tekwar, we find that police detectives, and the
hero's ex-wife, have been felled by a nasty virus.  A *computer* virus.
Call the Weekly World News.

Shatner is *much* more ambitious than Stephenson.  The "Snow Crash" virus,
in graphical representation, looked pretty much as you'd expect--snow!  The
Tekwar virus looks like a young lady.  (When she starts to open her blouse,
you get just a hint of circuitry and bright light.  Hubba, hubba!)

Oh, come now, Rob.  Don't be a spoil sport.  They can make programs that
look like text, can't they?  So why can't they make programs that look like
pictures?  Well, it is true that I have copies of the BOO programs, which
are utilities for converting binary files into a format that was only
printable characters.  I understand that there is an MS-DOS program, called
COMt, which turns COM files into *executable* forms, using only printable
characters.  (Padgett Peterson was so taken with the idea that he wrote his
Christmas card program using only printable characters.)  The "text"
programs, however, don't exactly look like a letter from Mom--they look like
strings of garbage.  Paradoxically, graphics images (realistic graphics,
that is) give you even *less* leeway, since the human eye is *very* good at
picking up anomalies.

The Tekwar virus is recovered from an imperfectly erased copy of the
graphic.  Under extrapolative recreation, the virus is virulent enough that
just looking at it will fry your computer.  (Try *that* with your average
copy of Stoned.  "Lossy" compression wins again!)  (By the way, in *that*
picture, the young lady has her shirt *on*.)

If you look at the virus, it renders you unconscious.  Fair enough: flashing
lights can stimulate epileptic seizures.  However, thereafter the virus
slowly causes *physical* degradation of your nervous system.  Oh, please.
What's the nerve equivalent of JMP?

Stay tuned *next* week, when Bill Shatner uses the I-word.  (Pay close
attention when he announces the virus is loose.)

copyright Robert M. Slade, 1994   TVTEKWAR.RVW  941201

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

Please report problems with the web pages to the maintainer