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 13 Issue 71

Friday 7 August 1992

Contents

o "Bug" or fraud?
John Kriens
o Ship with computer-controlled ballast tanks tips over
Jon Jacky
o Bugs in microcode of CPUs [REQUEST FOR EXAMPLES]
Brian A Wichmann
o A problem with call waiting
Rick Pim
o Phone service modification
Kraig R. Meyer
o Re: Unreliable call-return phone feature...
Joe Konstan
o Re: computer scoring at olympics
Jong
Gary McClelland
o Sweet Old Things and User Interfaces
Anton Martin Ertl
o Re: Mr. C. Baggage, ...
kennykb
o Information Age course at Georgetown
Ross Stapleton
o World Conference on Network Administration and Security
Hal Pomeranz
o Info on RISKS (comp.risks)

"Bug" or fraud?

24474-kriens <decoy!jkriens@uunet.UU.NET>
Fri, 7 Aug 92 14:12:46 GMT
The following appeared in the Thursday, Aug. 7, 1992, NJ Star Ledger.

           "Bug" Backfires on Computer Consultant

    NEW YORK (AP) -- A computer consultant must pay $25,000 to a Manhattan
law firm whose computer system crashed because he put a "bug" in it.
    Donald R. Lewis hoped the bug would cause the law firm of Werner,
Zaroff, Slotnick, Stern and Askenazy to call him for repair work after the
system collapsed, according to Civil Court Judge Richard F. Braun.  Lewis was
hired in 1985 to upgrade the firm's computer system, which tracks medical
payments of auto accident victims to health care providers.  The patients,
under the state's no-fault insurance law, assign their awards to the health
care professionals.  Lewis initially estimated the upgrade would cost up to
$5,000, but the firm eventually paid him some $21,000.
    In the months that followed, Lewis periodically called the firm's
receptionist to see if the computer file had entered claim number 56789.  In
July 1986, six months after the firm made its last payment to Lewis, the
computer system shut down.  It had filed claim number 56789, Braun
said.   Lewis had put a "conditional statement" in the computer's software
which caused it to stop functioning at claim number 56789, the judge said.  The
law firm paid another consultant $7,000 to fix the problem.

  [Once again this brings up the concern of people thinking that anything that
  happens in a computer system that wasn't expected by the end users is a bug.
  I'd like a job where I got paid $7000 to remove a "conditional statement."
  John Kriens                                   jkriens@decoy.cc.bellcore.com]


Ship with computer-controlled ballast tanks tips over

Jon Jacky <JON@gaffer.radonc.washington.edu>
Fri, 7 Aug 1992 9:15:48 -0700 (PDT)
From THE SEATTLE TIMES, Wed. Aug 5, 1992, p. D1:

"Ship makes list - the hard way" by Penelope M. Carrington

F. Garcia had just rounded the corner ... yesterday when he saw the 300-foot
fish-processing ship list to its right and crash into the neighboring dry dock.
... the vessel, the Dona Karen Marie, had been leaning since early yesterday
morning.  First it listed to the left --- portside.  Then an engineer came to
fix the problem.  Workers watched as the ... ship leveled and then listed to
the right --- starboard --- into the United Marine Marketing dry dock.

Shipyard spokeswoman Ruth Nelson said something malfunctioned in the computer
that controls the water-ballast tanks of the boat when the engineer tried
to correct the original listing.   As a result, all the water in the left tank
"was swooshed down to the other side," said Nelson, who was unsure why the
boat listed in the first place.

There were no injuries, and no danger of the ship tipping over into Lake Union
because it rested against the firmly anchored dry dock.

Tacoma Boat, which built the Dona Karen Marie, was contacted to secure copies
of the original plans to the ships ballasting system.   The Seattle Fire
Department hoped to find the pipes that would pump the water back to the port
side. ... The Dona Karen Marie has been moored in the shipyard for weeks.
Nelson said she could not identify the vessel's owner.

[ I pass the scene every day on my way to and from work.  It is quite a sight
--- imagine a four-story building tipped over onto its neighbor. The ship is
tipped about 30 degrees away from vertical, resting against the wall of the
adjacent drydock.  I don't know if it would have capsized if it hadn't struck
the drydock, but it looks like it might have.  It is lucky no one was hurt. ]

- Jon Jacky, jon@radonc.washington.edu, University of Washington, Seattle


Bugs in microcode of CPUs

Brian A Wichmann <baw@seg.npl.co.uk>
Fri, 7 Aug 92 17:18:48 BST
I have a long, but unfortunately, confidential article about bugs reported to
me in the microcode of microprocessors, including those used in
`safety-critical' systems. I would like to collect further examples.

Clearly, such bugs could undermine safety-critical systems. I have a list of
such bugs, but unfortunately, many are confidential.  I should like to collect
further examples. If I get enough non-confidential examples, I will post them
to comp.risks.

Please send E-mail information to me and state whether your example should be
kept confidential or not.  Give full details, such as the microprocessor, date,
and nature of bug.  Thanks.  Brian Wichmann, National Physical Laboratory
(baw@seg.npl.co.uk)


a problem with call waiting (prompted by recent related anecdotes)

Rick Pim <RICK@qucdnee.ee.queensu.ca>
Fri, 7 Aug 1992 11:58 EST
Recently, a couple of entries attracted my attention: rex@iqsc.com (Rex Black)
talked about "Unreliable call-return phone feature...", while
CMHAM01@UKCC.uky.edu (Chuck Ham) mentioned problems associated with GTE's
Personal Secretary (where a friend had troubles without even subscribing).  I
suspect that something like my small risk has been mentioned before, but who
knows....

Last year, Bell Canada had a promotion in our area to flog (among other things)
Call Waiting.  It was mentioned in a glossy throwaway in our monthly bill that
we were having Call Waiting installed on our lines (we have two) for a free
trial period.

Shortly after this, I was at home and my S.O. [significant other] was out
curling.  The arrangement was that she would call me when she finished, I'd
pick her up, and we'd go scare up something to eat.  While waiting, I dialled
in to work and probably read news.  After a while I got occasional bursts of
line noise but ignored them - the local phone lines are sometimes noisy.  The
other phone never rang...

The other half of the story is that there was an increasingly grumpy person at
the curling club trying to find me: calling home (I wasn't there, because, of
course, the phone was ringing and not being answered), work, friends' places,
and the like.  It took a long time before she thought of using the other phone
number.

The risk is small, but annoying: with the increasing use of phone lines for
data, it is not necessarily the best decision to use a normal "ring" when a
caller dials a busy line with call waiting on it.  One should also read glossy
throwaways more carefully. :-)


Phone service modification

<kmeyer@aero.org>
Fri, 07 Aug 92 13:30:48 PDT
About a year ago, I had my long distance service switched from MCI to AT&T
without my authorization--and didn't find out until the bill came from my local
phone company, Pacific Bell.  I called AT&T who said they keep no record of
where a switch request comes from (they insisted that I must have filled out a
form, or that I told a telemarketer to switch me, etc).  They did take down an
incident report after I insisted on speaking to a supervisor's supervisor.

Pacific Bell told me that they do no verification if a long distance carrier
requests a switch on a customer's phone line; they receive a tape with phone
numbers on it and switch every number listed on the tape to AT&T.  (Pacific
Bell also wanted me to pay to switch back to MCI, which MCI ended up paying).

Kraig R. Meyer                           kmeyer@aero.org

     [This gets us back to the problem of the meaning of "unauthorized access"
     where no authorization is required, or in this case the meaning of
     "authorized access" when no authorization is requested!  PGN]


Re: Unreliable call-return phone feature...

Joe Konstan <konstan@elmer-fudd.cs.berkeley.edu>
Thu, 6 Aug 92 17:55:42 PDT
In RISKS 13.70 Rex Black relates a story of being "called back" via RETURN CALL
by a woman who believed he had made a harassing call.

This is yet another version of an old set of pranks that involve connecting
together unsuspecting phone users.  While most of us are more familiar with the
version where a prankster with 3-way calling connects together two strangers
(while listening in), I haven't heard much about people making harassing calls
while having CALL FORWARDING activated to deflect the return call.

Unfortunately, until we can tell whether a call we make is being forwarded
(which may mean until we get ISDN, or the messiah comes, I'm not sure which is
likely to come first), there is no way to prevent a prankster from deflecting
calls to another line.  Rest assured, though, that the switch does know who
placed the call, and that CALL TRACE would properly finger the prankster no
matter what forwarding was in place.
                                        Joe Konstan  konstan@cs.berkeley.edu


Re: computer scoring at olympics

Jong <jong@tnpubs.enet.dec.com>
Thu, 6 Aug 92 19:17:25 PDT
I would like to think that a user-interface problem, not judging incompetence
or favoritism, was the cause of the shocking loss by the US boxer.

In the third round of the fight, with the score tied at 2-2 (an obvious problem
right there), the German threw a punch that missed, and the American landed a
counterpunch that split the German's eyebrow open.  The German was awarded a
point!

How did this happen?  Each judge has a box with two levers, one for each boxer.
If the boxer in red lands a punch, the judge presses the left lever; if the
boxer in blue lands a punch, the judge presses the right lever.

Now: The judges watch the fighters stalk each other, circle, and throw
combinations.  They press the left lever -- no, the right!  Too late.

I think the judges all pressed the wrong lever.


Re: computer scoring at olympics (RISKS-13.69)

Gary McClelland <mcclella@yertle.Colorado.EDU>
Fri, 7 Aug 1992 10:26:46 -0600
Several RISKS contributors have correctly noted that the problem with the
computerized scoring system used for Olympic boxing is not the computer but
rather the button-pressing speed of the judges and the scoring rules that were
implemented in the program.  The computer RISK is that electronic
implementation of complicated scoring systems, systems which would not be
feasible without computers, allows scoring rules to be used whose consequences
are not well understood.  These new scoring systems often seem reasonable on
paper but turn out to have surprising consequences.  I'll bet boxing officials
were surprised (embarrassed?) to learn that all judges could score a fight in
favor of Boxer A but that the majority-rule-per-punch rule could give the
decision to Boxer B.

The larger RISK is that implementations of "electronic town meetings" and
telephone voting will allow the use of creative scoring systems for electing
candidates and making policy decisions.  Without extensive forethought, such
computerized voting systems will inevitably produce unexpected results with
more serious consequences than who receives boxing medals.

There need not be surprises.  There is a large literature in the field of
public choice on the formal analysis of voting and scoring rules.  Kenneth
Arrow won the Nobel Prize in Economics for, among other things, proving that if
there are three or more options [not a problem for Olympic boxing] then it is
impossible to have a scoring system without unpleasant surprises such as being
manipulable and producing intransitive choices.  Since then the search has been
on for finding voting systems that have the fewest problems and a large array
of analysis tools are available.  The boxing officials ought to have consulted
experts in the field of public choice as well as computer experts.  Perhaps
they did.  The boxing rules may not be all that bad; they have a remarkable
similarity to the rules NASA uses to resolve disagreements among on-board
computers and NASA did consult with the public choice experts.  However, in the
boxing case, it is easy to show that conservative judges [these may not
necessarily be the worst judges as alleged in the recent case] have a
disproportionate impact because it is more likely that their votes will be
decisive in forming the majority on any given punch.  The punchline is that
computers may allow us to get into kinds of political trouble with fancy
scoring rules that would not have been possible with paper-and-pencil systems
which are forced to be simple.

Gary McClelland Univ of Colorado mcclella@yertle.colorado.edu


Sweet Old Things and User Interfaces (Re: RISKS-13.70)

Anton Martin Ertl <anton@mips.complang.tuwien.ac.at>
Fri, 7 Aug 92 16:27:27 +0200
Ed Ravin (elr%trintex@uunet.uu.net) and Steve Summit (scs@adam.mit.edu) hope
that the next generations will have less problems with (the user interfaces of)
machines due to childhood training at Nintendos etc.

I doubt this: I notice that I become more impatient the older I get. I spent
countless hours learning the tricks of my programmable calculator. Nowadays I
am too impatient to read the manual of my video recorder. When in ten years
they force me to use ATMs, I will probably even be too impatient for learning
that, especially if there are people waiting in the line (and it does not
matter that learning the system is the fastest way to get it done). As an
analogy, we have had forms since the invention of bureaucracy, but they still
confuse us.
                    M. Anton Ertl   anton@mips.complang.tuwien.ac.at


Re: Mr. C. Baggage, ... (Geoff Kuenning)

<kennykb@dssv01.crd.ge.com>
Fri, 07 Aug 92 10:16:23 -0400
In RISKS-13.70, Geoff Kuenning tells the story of a Mr. Cabin Baggage (actually
a violoncello) having a ticket on an airline flight.  Having to ticket cabin
baggage that way is a potential RISK to a search and rescue party in the event
that the airplane crashes, since if the ticket is used, the passenger list will
show one more soul on board, and the rescuers will be looking for another
potential survivor.  It would be a tragedy if a rescuer someday lost his life
trying to find Mr. Stradivarius Cello.

I know that I've had cabin baggage successfully ticketed by United without
having to come up with a fictitious name; some reservation systems do it right.

But musicians seem to get into this type of trouble.  The duo-pianists Stecher
and Horowitz once arrived at the airport to find that the rear row of seats had
been removed from the aircraft to accommodate the stretcher -- they'd been
booked as `Stretcher patient, Horowitz!'

    [When dealing with computerized systems, we must be forewarned that we
    need to be forearmed.  But for pianists, four-armed can be four-handed
    on one keyboard or duo-piano, on two.  But the absence of seats cannot
    be forewarmed.  PGN]

       [Incidentally, since I am already drifting in relevance (too much
       flying?), John Levine (johnl@iecc.cambridge.ma.us) noted that a
       professional cellist friend of his regularly buys a seat for his cello,
       but the airlines won't let the cello join a frequent flyer program.  It
       would probably do violins to their computer system.  At any rate, this
       is certainly enough for this topic...  Thanks for your indolcence. PGN]


Information Age course at Georgetown

<"stapleton@misvax.mis.arizona.edu"@Arizona.edu>
Thu, 6 Aug 1992 15:33 MST
For those in the greater Washington DC area, I will be teaching a course in
Georgetown University's continuing education program, surveying issues
arising from our entry into the "Information Age."   The course description
is below, and it runs for eight Thursday evenings.   Contact the School of
Summer and Continuing Education at Georgetown for further information (and
forward this note to others if you like).        Ross

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

ISSUES FOR THE INFORMATION AGE

     This course will address issues of the "Information Age" for a
nontechnical audience, i.e., how computers and computer-based information and
systems are transforming the world around us.
     What does it mean to say that "information about money is as valuable as
money itself?"  Many companies do nothing more than broker information, as an
increasingly larger percentage of the U.S. economy.  But where ought the
boundary between commercial profit and personal privacy be drawn?  Lotus
Development Corp. cancelled its plans to market a database on consumers in the
face of protests from those it would have monitored, and across the U.S.
"caller ID" technology is facing severe scrutiny from all sides.
     In the wake of the failed Soviet coup, a U.S. communications company took
out a full-page ad to congratulate Soviet citizens who, "armed with nothing
more than information...saved the day."  News of the Tiananmen Square massacre
came to us out of China by way of portable satellite dishes and the fax
machine.
     Information systems are making life more efficient, but never before has
it been possible for a simple computer glitch to cause a billion dollars worth
of damage--twice in 1991 software bugs crippled large portions of the U.S.
telephone system, and a Cornell graduate student's program shut down tens of
thousands of networked computers in 1988.  [WELL, Cliff Stoll estimated 2,600
of the estimated 6,000 BSD Unix systems.  PGN]
     The legal profession is scrambling to apply yesterday's laws to new
realities, and "artificial reality" has been used in court testimony, while the
FBI lobbies to make digital telephones easier to wiretap.  What do we have to
fear from "hackers?"  Does computer crime pay?
     Readings will be provided, taken largely from the current press, to serve
as background and focus for discussion.
     Dr. Ross Alan Stapleton is a science and technology analyst with extensive
experience studying computer and information technologies in the former USSR
and Eastern Europe.
     8 sessions, Thursday evenings, 7:45 to 9:15 p.m., September 24 through
November 12, 1992.


World Conference on Network Administration and Security

Hal Pomeranz <pomeranz@nas.nasa.gov>
Thu, 6 Aug 1992 12:59:17 -0700
                           CALL FOR PAPERS
                         AND PRE-ANNOUNCEMENT
                     The 1992 World Conference On
                  Network Administration and Security
                    November 30 - December 4, 1992
                           Washington, DC

THEME: Practical solutions for cost-effective network administration and
security in a UNIX environment.

ELIGIBILITY: Network administrators, system administrators, security
administrators, technology managers, computer installation managers, and their
staff.  In addition, a limited number of places are available for staff members
from organizations that offer off-the-shelf software and hardware products that
support network management and security.

LOCATION: Ramada Renaissance Techworld Hotel, 919 9th Street NW, Washington,
D.C. 20019,  (202) 898-9000

CONFERENCE DATES: Tutorials: November 30- December 1
                  Technical Sessions: December 2- December 4

INFORMATION: For pre-registration materials, send mail to:

Program Chairman, Alan Paller, Conference Office, 4610 Tournay Road
                  Bethesda, MD 20816

or send email to paller@fedunix.org.

HOST ORGANIZATION: The Washington Area UNIX Users Group and the Federal Network
Administration Council.

CONFERENCE SPONSOR: the Open Systems Conference Board, a not-for-profit
educational organization dedicated to removing the barriers to widespread
adoption of UNIX and Open Systems.

WHY YOU SHOULD PARTICIPATE: The demands of mission critical applications are
driving the need for network innovation at an amazing pace.  New technology and
new standards promote confusion and interoperability problems while at the same
time providing much needed connectivity and increased bandwidth.  Cutbacks have
forced fewer people to provide more service with less money.

These challenges are particularly apparent and frustrating in the government
agencies (both in the US and abroad), universities, and companies which have
been in the vanguard of the move to open systems and networks of UNIX
computers.

This conference is designed to identify the current state of the art for
cost-effective network administration and security so that the techniques and
tools used by the most effective managers can be adopted by those still looking
for solutions.

Peer-reviewed papers will be complemented with invited papers plus

   "Ask the Experts" sessions where you'll find practical answers
   to your questions.

   "Best Of The Net" session where you'll learn which free programs
   available from the net are most useful.

   "Tips and Techniques" sessions in which conference attendees can
   share, in 5-minute presentations, their favorite techniques for
   solving recurring problems.  These sessions are run as moderated
   BOFs with all conference attendees being asked, in advance, to
   contribute if they choose.

   "Ask OSF" session where you can learn from the people who brought
   you DCE.

   Informal Birds Of A Feather sessions in the evening to expand the
   sharing time.  Please send your suggestions for topics with your
   registration.

In addition, the Monday-Tuesday tutorials will be taught by several of
America's top-rated instructors. Tutorial topics include TCP/IP and
UNIX Network Programming, UNIX Security, OSF DCE and DME, UNIX
Fundamentals, UNIX Internals, UNIX System and Network Administration
(Basic and Advanced courses), and Perl Programming.

                        *********************
                        ** CALL FOR PAPERS **
                        *********************

Papers are being sought for the technical conference from network
administrators, system administrators, security managers, consultants,
academics, and hardware and software developers.

You don't have to have made a major breakthrough to have your paper accepted.
The delegates will be looking for good problem definitions and practical
solutions. And your presentation does not have to be long. You may choose a 15,
30, or 45 minute time slot.

IMPORTANT DATES FOR SUBMISSION:

                  Abstracts Due: September 14, 1992
     Notification of Acceptance: October 12, 1992
        Camera-Ready Papers Due: November 16, 1992

FORMAL REVIEW: Papers that have been formally reviewed and accepted will be
presented during the conference and will be published in the conference
proceedings.  The Review Committee is composed of experts on network
administration and security along with managers of large installations and
architects from the vendor community.

Among the people invited to serve on the Review Committee are Matt Bishop
(Dartmouth), Michele Crabb (NASA Ames Research Center), Richard Stevens (author
of several best selling books on Network and UNIX Programming), Marcus Ranum
(Digital Equipment Corporation), Jonathan Gossels (OSF), and Bruce Hunter and
Rob Kolstad (well-known columnists).

The committee will decide whether your abstract addresses important
challenges (large or small), whether your approach seems promising, or
whether your abstract should be accepted for any other reason.

TOPICS: Please feel free to submit abstracts on any topic. The list
provided below may help prompt some ideas:

1.  Managing heterogeneous networks
2.  Policies and procedures on the network
3.  Security policies
4.  Network security monitoring
5.  Network monitoring and performance testing
6.  Training and education
7.  Techniques for dealing with users
8.  Networked backup schemes
9.  Distributed mail systems
10. Domain Name Service configuration
11. Distributed console access
12. OSF's DCE and DME
13. Off-the-shelf tools
14. Tools you don't like and why

ABSTRACTS: A good abstract will by 500 to 1,500 words in length and
include the following:

1. A description of the problem(s) and its importance.
2. Your solution including details of how it worked. If this is work
   on emerging technology, try to show what the expected impact will
   be.  If your solution is based on commercial hardware or software
   tools, name them.  Abstracts from vendors are welcome, but should
   not be sales pitches.
3. Data on how well it works: before/after comparisons, direct savings,
   trade-offs, etc.
4. Lessons learned and what you might have done differently.

Please also provide the following information about the author(s):
name, title, organization, daytime telephone, surface mail address,
email address (please), FAX if possible.

Finally, tell whether you want a 15, 30 or 45 minute time slot for
your presentation.

WHERE TO SEND YOUR ABSTRACTS:
        Technical Program Chairman
        Hal Pomeranz
        NASA Ames Research Center
        M/S 258-6
        Moffett Field, CA  94035-1000

Questions or abstracts (PostScript or ASCII) may be submitted via email
to pomeranz@nas.nasa.gov.

                       [Because many of our risks involve networking, it
                       seems appropriate to include this item.  On the
                       other hand, as RISKS readers, you should be prepared
                       to ask lots of nasty questions if you attend.  PGN]

Please report problems with the web pages to the maintainer

Top