The Risks Digest

The RISKS Digest

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 59

Weds 30 November 1994

Contents

o The IRS knows "everything about you that we need to know"
John Sullivan
o RISKs of electronic ticketing on buses
Rhys Weatherley
o Why You Need a UPS For Your Bread Machine
Curtis Jackson
o Listserv Loops
Richard Klau
o NYNEX touts Credit Card authorization over Cell Phones
Paul Green
o Re: Iowa phone switch
Matthew Charles Wetmore
o Re: Reasonably Large Water Bill
L. P. Levine
o Risks on TV: Eye-to-Eye-to-RFI
Jan I. Wolitzky
o British Telecom "hacker" article was a hack!
Sidney Markowitz
o The risks of media hack reports
Rob Slade
o Re: Pentium FDIV bug
Wilson P. Snyder II
Peter da Silva
Ron Heiby
Dale R. Call
Andy Grove via Richard Wirt
o Info on RISKS (comp.risks)

The IRS knows "everything about you that we need to know"

<sullivan@geom.umn.edu>
Wed, 30 Nov 1994 13:02:17 -0600
I read this paragraph from Wired in EDUPAGE (listproc@educom.edu)
and found the implications disturbing:

IRS PLANS GOLDEN EAGLE TAX RETURN
The project manager for the Internal Revenue Service's Document Processing
System described the "Golden Eagle" return, in which the government would
automatically gather all a person's tax info and then compute the tax. "If
I knew what you've made during the year, if I know what your withholding
is, if I know what your spending pattern is, I should be able to generate
for you a tax return. I am an excellent advocate of return-free filing. We
know everything about you that we need to know. Your employer tells us
everything about you that we need to know. Your activity records on your
credit cards tell us everything about you that we need to know. Through
interface with Social Security, with the DMV, with your banking
institutions, we really have a lot of information ... We could literally
file a return for you. This is the future we'd like to go to." (Wired,
Dec.'94, p.174)

-John Sullivan   sullivan@geom.umn.edu

   [For info on receiving EDUPAGE, see RISKS-16.58.  PGN]


RISKs of electronic ticketing on buses

Mr Rhys Weatherley <rhys@fit.qut.edu.au>
Mon, 28 Nov 1994 09:46:06 +1000 (EST)
The Brisbane City Council's bus service here in Australia is in the process
of introducing an electronic ticketing system on all buses.

The old system used a bunch of "ticket pads" of different denominations:
the driver would rip off a ticket from the right pad (you'd hope! :-) ),
punch a hole in it, collect your money, and then give you the ticket.

The new system replaces the pads with a console which has a number of
buttons for the denominations together with a printer to print the
tickets.  There are also two green boxes just inside the door in which
commuters can insert the new magnetically encoded weekly and monthly bus
tickets to have them checked.

I have yet to get my first magnetic monthly bus ticket so I can see how easy
it would be to reprogram it, but I'm fairly confident that with the right
equipment it is doable.  For purely educational purposes of course.  :-)
RISK #1.  I'm also interested in seeing if there is any identifying
information on the cards permitting tracking of a person's movements.  RISK #2.

The other day a schoolkid was waiting at my bus stop, and due to various
stuff-ups in the scheduling, he was forced to catch my bus rather than the
normal school bus.  During peak hour my bus is a full fare bus, but of
course the kid only had money for a half fare on him.  In such cases, some
drivers are complete mongrels and won't allow the kid on, but most will
grumble a bit and then let the kid on for a half fare.

The driver stared at his console for a few seconds and then said
(paraphrased) "There is no way to override this thing.  Looks like you get a
free ride today" and let the kid on for nothing.  The console had
automatically detected peak hour and disabled the half fare ticket buttons.

RISK #3 is fairly familiar: while enforcing "the rules" can be a good idea,
sometimes it is necessary to override them for reasons of human kindness.

RISK #4 is that if an override button was provided, the console might log
the fact and the driver might get in trouble (and then again, it might not:
I don't know anything about the internals of the consoles yet).  At least
with the free ticket, no trace is left for the bus inspectors to whinge
about. :-)

More information on the magnetic tickets as it comes to light ...

Rhys Weatherley, Queensland University of Technology, Australia.


Why You Need a UPS For Your Bread Machine

<cjackson@adobe.com>
Wed, 30 Nov 1994 00:27:33 GMT
In order to more closely stick to a self-imposed lowfat diet, I finally
broke down and bought a bread machine -- easy quick bread with no added fat.
I was so pleased with the machine that I bought my breadophilic mother one
and lugged it across the country to her house last week.

They were short on counter space in the kitchen, so they put the machine on
a side-table and plugged it into an outlet that was activated by a wall
switch that also controlled a light in the room. (I think you can guess what
is coming next, and, yes, I did warn them. They said it was only a temporary
placement and they'd remember.)

Sure enough, in the middle of the bread machine's 4-hour cycle, my
stepfather turned off the light in the room (and thus removed power from the
bread machine). I noticed this some indeterminate time later.

Problem #1: The bread machine has no NVRAM. So I had no idea whether it had
been through only its first rise, or through a first rise, punchdown ("gas
squeeze out"; this was a Japanese machine), and second rise.

Problem #2: The machine has a dough setting that will allow you to make
dough, but not bake the dough. But there is no setting that says, "I already
have dough, I just want you to bake it."

Problem #3: Neither my stepfather nor I had ever baked a loaf of bread by
hand. Not once in our lives. And bread is quite a bit more sensitive to time
and temperature than most other simple food items.

Luckily, I had also purchased a bread machine cookbook for my mother that
suggested that one make a loaf of bread by hand first to get a feel for the
process, then proceed to using the machine. I used the book's baking
time/temperature settings and ended up with an edible loaf of finished
product. But, had we not had that book....

Curtis Jackson  cjackson@mv.us.adobe.com


Listserv Loops

Richard Klau <klaurich@uofrlaw.urich.edu>
28 Nov 1994 21:30:27 GMT
Along with Erik Heels (The Legal List), I own a list for law students
discussion law & technology (StudentLawTech).  We have just weathered a
particularly disturbing incident, and would like some feedback on what has
been done in the past with issues like these.

The facts, as near as we can tell, are these: a user set his e-mail system
to refuse mail from the list.  The system generated a refuse message for the
sender to notify the sender that the message had not been read.

Since the list was the sender, this refusal notification was sent to the
list.  Because the e-mail system did not stamp the message with a
"mailer-daemon" or some other appropriate flag, the list did not filter it
out.  The refusal notification was sent to the list.

Because the original user was not set to nomail (opting, instead, to do this
at his level, rather than at the list level), he received the refusal
notification.  This notification in turn produced a notification of its own.
The loop was started, and multiplied exponentially.

The system was not fully corrected until Saturday night, a full three days
after the loops had begun.  While we can't be sure, we think the total
number of these looped messages prior to the fix on Saturday was near 1000
messages to each subscriber.

Needless to say, many have unsubscribed from the list.  In addition,
countless law students are now faced with the annoyance of having to delete
mass quantities of mail.  Most worrisome, of course, are those that pay for
incoming e-mail.

So -- has this happened before?  If so, what systems were involved?  How was
the situation remedied?  What were the consequences?

Any advice is very welcomed.  Replies by e-mail are preferred, but I will
monitor this list.

Thanks for your help!

Rick Klau, Co-owner, StudentLawTech@Listserv.Law.Cornell.edu


NYNEX touts Credit Card authorization over Cell Phones

<Paul_Green@vos.stratus.com>
Tue, 29 Nov 94 17:43 EST
>From the September/October 1994 (Vol 9, #5) issue of "Accessability", a
newsletter that came with my most recent statement for my cell phones.
Reproduced without permission.  The flyer generally contains the typical
marketing hype about ways to use your cell phone "more productively" (i.e.,
run up a bigger bill).  The following anecdote is quoted in its entirety.

AIRTIME - Your Cellular Success Stories

Greg Maida
Herkimer, NY
     "We are in the craft business, and we use our NYNEX Mobile cellular
phone to transmit credit card charges.  This has saved us a lot of brief,
because we are able to get credit card approvals within about 30 seconds.
The cellular phone gives us the convenience of a phone at any locations and
enables us to offer more purchasing options to customers."

***

What can I say?  Why worry about sending your credit card over the
Internet, when this vendor will send it out over radio waves for you!

Just to add a little irony to this whole discussion, in the very same
newsletter, on the facing page, appears the following "tip":

     "Remember to lock your cellular phone!  You will reduce the risk of
incurring fraudulent calls if you phone is stolen.  Don't consider this
precaution an inconvenience.  Lock your phone whenever you park your car
with a parking attendant.  If your phone can be removed, we recommend
carrying it with you when you leave the car unattended."

The only word that springs to mind here is chutzpah!

PG

     [accessability
     Marcia Williams Cromer, Editor
     NYNEX Mobile Communications
     2000 Corporate Drive
     Orangeburg, NY 10962
     (c) 1994 - All Rights Reserved]


Re: Iowa phone switch (RISKS-16.58)

Matthew Charles Wetmore <mwetmore@polyslo.csc.calpoly.edu>
Mon, 28 Nov 94 17:33:46 -0800
  Phone systems do not exist in a vacuum, nor is restarting them as simple
as flipping a switch.
  In this case, there'd be diagnostics to make sure that nothing actually
*was* burned out.  Then reloading the phone database and configuration
information.  The information might include special features with each phone
for caller ID, forwarding numbers, voicemail options, et cetra.  Next comes
routing information from the various neighborhood multiplexors to the central
office.  Last, but not least, you have to convince any other computer system
you are connected with (long distance carriers, billing computers, ...) that
your system is alive and well again.

>Lessons: First, this failure seems to be a perfect example of the fact that
>grounding problems are notoriously difficult to diagnose.  Second, I suspect
>that nobody involved in the design of modern ESS systems would have guessed
>that it would take 2 hours to restore service after the fault was repaired.

  "You get what you pay for," may be the case here.  A "small" town with one
system has all or nothing failures.  New York, on the other hand, can shunt
calls over to other offices while one is restoring.
  Multiple redundancy is the most common "solution" to make a system fault
tolerant.

  These are only the technological factors...  A human factors:
  A new system having been recently installed: how many trained technicians
did they have on hand, well versed in the new system lore?  There's a fair
chance a technician from the system manufacturer had to race out, and this
accounted for a bulk of that time.

Matthew C. Wetmore -- ACM, c/o CSc Dept., California Polytechnic State Univ,
San Luis Obispo, CA  93407   -- USA         mwetmore@galaxy.CSc.CalPoly.EDU


Re: Reasonably Large Water Bill (Politte, RISKS-16.56)

"Prof. L. P. Levine" <levine@blatz.cs.uwm.edu>
Sun, 27 Nov 1994 09:09:46 -0600 (CST)
Some years ago I received a water bill from the Village of Shorewood in
Wisconsin that was about 30 times too large.  In my case also the
problem was due to a failed repeater that mounted on the outside of my
house and was delivered an electrical pulse each time 100 cubic feet
of water was registered by the actual meter in the basement.

The system had been installed over ten years ago and had (apparently)
been missing pulses from the very first.  No one had noted the slight
decrease in billing until the system finally had a hard failure and
reported no water use during a quarter-year.  When the new repeater
was installed it was manually set to agree with the water meter in the
basement (Wisconsin folks are smarter than they are in Missouri) and
therefore included all of the "ticks" missed over a ten year period.
They all appeared on the next bill.

Since we had, in fact, used the water that was billed there was no
question we should pay. What was in doubt was just how much.   Water
rates had increased substantially during the period because of the
inclusion of sewer costs within the water bill during recent years.
Negotiation with the village over the question "how much water was used
when" settled the issue.

What's the risk?  New machinery will soon enable more and more utility
billing to be done automatically.  Many of these systems will depend on
repeaters for their data collection with the true numbers still
available on more conventional meters located on site.  My hundred
dollar water bill will seem small compared to the complexity of just
which owner/renter used the missing electricity after failed meter
systems are fixed and their meters updated.

Prof. Leonard P. Levine, Computer Science, University of Wisconsin-Milwaukee
   Box 784, Milwaukee, WI 53201 levine@cs.uwm.edu 1-414-229-5170


Risks on TV: Eye-to-Eye-to-RFI

<wolit@library.mt.att.com>
Mon, 28 Nov 94 10:50:50 EST
This week's "Eye-to-Eye with Connie Chung" is scheduled to include a segment
on radio-frequency interference risks.  I was interviewed by one of her
crews, demonstrating an automatic cardiac defibrillator being messed up by a
public-safety band walkie-talkie.  Other examples reportedly include an
electric wheelchair being spoofed by a cellular phone, aircraft instruments
confused by PCs, etc.  I haven't seen any of the tape yet, so I don't really
know whether I want to be announcing this, but it's likely to be of interest
to participants of this forum.  Thursday night, 1 Dec 1994, CBS, 10pm EST.

Jan I. Wolitzky, AT&T Bell Laboratories, 600 Mountain Avenue, Room 3D-590
Murray Hill, NJ 07974-2070 USA   1 908 582-2998  wolit@library.att.com


British Telecom "hacker" article was a hack!

Sidney Markowitz <sidney@taurus.apple.com>
Tue, 29 Nov 1994 19:36:24 -0800
   [Thanks to sidney@apple.com (Sidney Markowitz) for letting me see
   copyrighted Newsbytes material, which I have starkly abstracted.  PGN]

Steve Fleming, the reporter noted in RISKS-16.58 as responsible for the
article on the "hacking" of BT's Customer Service System (CSS), has admitted
that he himself was the unknown Internet hacker.  ``Instead of gaining
unauthorized access to the BT computers, he actually worked for a lengthy
period of time (three months, according to Newsbytes sources) and was
required to access the CSS computer system as part of his job.  "I didn't
realize how sensitive the information was, but I was horrified how easy it
was to get into the system," he is quoted as saying in the London Observer
newspaper.''  Fleming may be prosecuted.


The risks of media hack reports (BT and the Queen)

"Rob Slade, Social Convener to the Net" <roberts@mukluk.decus.ca>
Sun, 27 Nov 1994 03:30:22 EST
in re: Mathew Lodge's posting in 16.58:

I was wondering if this was going to make it into RISKS.  I saw a TV report
on the story (a re-use of an NBC story of the BBC story, apparently).  There
was the mention of the Internet, there was the use of the word "hacker", but
there was, technically, no security system "breaking".  Social engineering,
definitely.  Stupidity, beyond question.  Loss of confidentiality, loss of
privacy, yes, and again, yes.  But no hacking, cracking or phreaking.  Indeed,
since the original informant is still unidentified, the word "hacker", even
in its most debased usage, is extremely suspect.

The risks as I see it, is that once again the public is being led to believe
that evil and powerful "hackers" can invade even the most highly protected
inner sanctum of one of the worlds best secured telecom systems.  In reality
the "keepers of the keys" have simply left the doors wide open.

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


Re: Pentium FDIV bug [random testing]

Wilson P. Snyder II (DTN 225-5592 HLO2-3/C8) <snyder@ricks.enet.dec.com>
Mon, 28 Nov 94 17:38:23 EST
Can't speak for Intel, but at Digital, our Alpha AXP processors are tested
using psudo-random techniques which do exactly that.  Random testing often
finds interesting problems that would never be found by just writing
specific tests.  (The genetic algorithm folks can give lots of data on why
this is so.)  To implement the random method though, you have to code a
entire simulation of the results that the CPU will produce.

Unfortunately, as readers of this group will appreciate, occasionally the
template that describes the correct response, or limiting the range to test
will be itself in error.  (Comparing a transistor model to a bad software
model is a good example of the first kind of error.)  Even if all is set up
perfectly, I've seen cases where it took several weeks to expose a bug.


What are the odds Intel would pick this phrasing at random?

Peter da Silva <peter@nmti.com>
Mon, 28 Nov 1994 09:43:03 -0600
The problem I have with Intel's handling of this is the use of the word
"chance", as if there was a random factor involved, that a calculation
will work right one time and fail the next so you can just run it again and
get the right result. Of course no such thing is true, but that's the
impression Intel's (deliberately?) spreading.

Also, people hear about a "1 in 10^10" chance and think it refers to some
statistical probability that their system will have a problem, rather than
a measure of the proportion of inputs that will (consistently) produce an
invalid response. For programs that require double precision calculations
and involve arbitrary input the "chance" of that program hitting the bug
approaches unity.

Nope... Pentium Bingo isn't a game of chance at all.


Re: Pentium FDIV bug

Ron Heiby <heiby@falkor.chi.il.us>
Mon, 28 Nov 1994 21:52:12 GMT
The chairman of the Computer Science Department at Hope College (when I was
attending, and probably still), Herbert Dershem, told one of my early CS
classes that, "any idiot can write a very fast sort routine, if it doesn't
have to put the elements into the correct order." (That may not be an exact
quote, but pretty close.)

It looks like intel has figured out that they can write a very fast
floating point unit, if it doesn't have to produce the correct results!

Ron


Re: Pentium FDIV bug

Dale R. Call <dalec@ibeam.jf.intel.com>
Wed, 30 Nov 1994 10:52:33 -0800
For more information on the Pentium FDIV bug, and Intel's response, take a
look at our corporate presence server (www.intel.com):

http://www.intel.com/about-intel/press/andy-msg.html

This message was also posted on various net newsgroups.

Dale R. Call, Intel Architecture Labs


My Perspective on Pentium - AGS

<[several anonymous sources]>
27 Nov 1994 19:31:21 GMT
Andy Grove has asked me to post the following for him. Since it is the
weekend and we are out of the office, I am posting from my home system.

Richard Wirt
Director SW Technology
Intel Corp


This is Andy Grove, president of Intel.  I'd like to comment a bit on the
conversations that have been taking place here.

First of all, I am truly sorry for the anxiety created among you by our
floating point issue.  I read thru some of the postings and it's clear that
many of you have done a lot of work around it and that some of you are very
angry at us.

Let me give you my perspective on what has happened here.

The Pentium processor was introduced into the market in May of '93 after the
most extensive testing program we at Intel have ever embarked on.  Because
this chip is three times as complex as the 486, and because it includes a
number of improved floating point algorithms, we geared up to do an array of
tests, validation, and verification that far exceeded anything we had ever
done. So did many of our OEM customers.  We held the introduction of the
chip several months in order to give them more time to check out the chip
and their systems.  We worked extensively with many software companies to
this end as well.

We were very pleased with the result.  We ramped the processor faster than
any other in our history and encountered no significant problems in the user
community.  Not that the chip was perfect; no chip ever is.  From time to
time, we gathered up what problems we found and put into production a new
"stepping" -- a new set of masks that incorporated whatever we corrected.
Stepping N was better than stepping N minus 1, which was better than
stepping N minus 2.  After almost 25 years in the microprocessor business, I
have come to the the conclusion that no microprocessor is ever perfect; they
just come closer to perfection with each stepping.  In the life of a typical
microprocessor, we go thru half a dozen or more such steppings.

Then, in the summer of '94, in the process of further testing (which
continued thru all this time and continues today), we came upon the floating
point error.  We were puzzled as to why neither we nor anyone else had
encountered this earlier.  We started a separate project, including
mathematicians and scientists who work for us in areas other than the
Pentium processor group to examine the nature of the problem and its impact.

This group concluded after months of work that (1) an error is only likely
to occur at a frequency of the order of once in nine billion random floating
point divides, and that (2) this many divides in all the programs they
evaluated (which included many scientific programs) would require elapsed
times of use that would be longer than the mean time to failure of the
physical computer subsystems.  In other words, the error rate a user might
see due to the floating point problem would be swamped by other known
computer failure mechanisms.  This explained why nobody -- not us, not our
OEM customers, not the software vendors we worked with and not the many
individual users -- had run into it.

As some of you may recall, we had encountered thornier problems with early
versions of the 386 and 486, so we breathed a sigh of relief that with the
Pentium processor we had found what turned out to be a problem of far lesser
magnitude.  We then incorporated the fix into the next stepping of both the
60 and 66 and the 75/90/100 MHz Pentium processor along with whatever else
we were correcting in that next stepping.

Then, last month Professor Nicely posted his observations about this problem
and the hubbub started.  Interestingly, I understand from press reports that
Prof. Nicely was attempting to show that Pentium-based computers can do the
jobs of big time supercomputers in numbers analyses.  Many of you who posted
comments are evidently also involved in pretty heavy duty mathematical work.

That gets us to the present time and what we do about all this.

We would like to find all users of the Pentium processor who are engaged in
work involving heavy duty scientific/floating point calculations and resolve
their problem in the most appropriate fashion including, if necessary, by
replacing their chips with new ones.  We don't know how to set precise rules
on this so we decided to do it thru individual discussions between each of
you and a technically trained Intel person.  We set up 800# lines for that
purpose. It is going to take us time to work thru the calls we are getting,
but we will work thru them.  I would like to ask for your patience here.

Meanwhile, please don't be concerned that the passing of time will deprive
you of the opportunity to get your problem resolved -- we will stand behind
these chips for the life of your computer.

Sorry to be so long-winded -- and again please accept my apologies for the
situation.  We appreciate your interest in the Pentium processor, and we
remain dedicated to bringing it as close to perfection as possible.

I will monitor your communications in the future -- forgive me if I can't
answer each of you individually.

Andy Grove

Please report problems with the web pages to the maintainer

Top