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 15 Issue 3

Thu 9 September 1993


o Robot Disarms Man
David Fowler
o The risks of Naive Users
Amos Shapir
o The first programming errors
Jon Jacky
o Offshore Data Havens
John R. Bruni
o Re: The risks of CERT teams vs we all know
Jeff Schiller
Frederick Roeber
o Re: Lost Crime Stats
Rodney Boyd
o Into the void at the supermarket
Andrew Klossner
o Re: What Constitutes an Exhaustive Attack?
A. Padgett Peterson
o Fixing what's known to be broken
Tom Lane
o Caller ID Blocking and 911
Monty Solomon
o Bank mailing problem
Lauren Weinstein
o Technology export curbs
Mich Kabay
o Re: Security holes and risks of software like Sendmail
Marcus J Ranum
o CfP: 1994 Z User Meeting Announcement
Jonathan Bowen
o Call for Papers, Decision Science Conference
o Info on RISKS (comp.risks)

Robot Disarms Man

David Fowler <>
Sat, 4 Sep 93 00:10:18 PDT

   Police used a 3-foot, 480-pound robot to disarm a man who allegedly
shotgunned his girlfriend to death and barricaded himself inside their
apartment.  Prince George's County authorities sent the remote-controlled
robot into the apartment Thursday after police were unable in a five-hour
standoff to persuade Craig Smith, 22, to surrender.  Smith fatally shot his
live-in girlfriend Cynthia Wilkinson, 24, and sexually assaulted an
unidentified woman who was a friend of Wilkinson's, police said. The woman
jumped out a window of the second-story apartment and ran to a neighbor's home
to call police.

   After negotiations with Wilkinson broke off, police borrowed a robot that
the fire department uses to dismantle suspected explosive devices, said Sgt.
Alan Day, a police department spokesman.  Transmitting the scene by a video
camera, the robot at the direction of a fire department technician opened a
closet door. Wilkinson could be seen hiding under a pile of clothes and the
robot's mechanical claws reached out and pulled them away.

   When Smith grabbed the clothes back from the robot and began to cover
himself up again, the robot fired a high-pressure water gun to knock the
shotgun out of Smith's hands and disorient him, said a police spokesman, Cpl.
Keith Evans. Police rushed in and arrested Smith.

   The Prince George's County Fire Department bought the robot known as Remote
Mobile Investigator-9 RMI-9 for short seven years ago for $45,000.  Capt.
Victor Stagnaro, a fire department spokesman, said it was the first time the
local police had used RMI-9 to catch a suspect.

   Smith was charged with first-degree murder and sexual assault.  Evans said
that Wilkinson and Smith argued Wednesday night after she apparently told him
she wanted to end their relationship. The dispute resumed Thursday morning,
and Smith shot Wilkinson while they argued, Evans said.

[Sept. 3, 1993 The Associated Press]

The risks of Naive Users

Amos Shapir <>
7 Sep 1993 17:45:10 +0300
The following two articles were posted on a local BBS of a company I work for:
.  93/09/02 12:06  Entrance of children to our building.
Following an incident which occurred last Tuesday evening (an employee's
child switched off the UPS main electricity switch of one of the floors),
we recommend that children not be left unattended in any part of the

The best advice is to stay with the children in the lobby where
'dangerous attractions' are minimal.

We have taken precautions to avoid recurrence of similar incidents
by installing special locks on the electricity cabinets.

.  93/09/02 15:00  To those who suffered from the UPS fall

I apologize for my son, he's 20 month old, yet he needed less than
20 second on the floor to break the UPS down...

I checked the said UPS switch -- it's an emergency-shutdown type: big, red, and
located near the bottom of the control panel.  In short, conspicuous enough to
be located quickly in an emergency -- or at any time by a two-year-old kid...

Amos Shapir, The Hebrew Univ. of Jerusalem, Dept. of Comp. Science.
Givat-Ram, Jerusalem 91904, Israel, Tel: +972 2 585706

The first programming errors

Jon Jacky <>
Tue, 7 Sep 93 21:48:36 -0700
There is an interesting story in THE SCIENCES, July/August 1993: "The
Discovery of Debugging," by Brian Hayes, pps. 10 -- 13.

It describes experiences programming EDSAC, which the story says was the the
first true stored program computer, at Cambridge in 1949.

EDSAC's first three programs -- which calculated lists of squares and prime
numbers -- worked correctly the first time they were run!  This was no mean
accomplishment, in view of EDSAC's instruction set and the very rudimentary
programming tools available.

After that, it got difficult.  While cleaning his office in 1979, EDSAC
designer Maurice Wilkes came upon a thirty year old punched tape which
contained an early version of a program for calculating a table of values for
Airy's integral.  Wilkes gave a copy to Martin Campbell-Kelly, who studied it
using an EDSAC simulator.

The 126 line program contained 20 errors! Most were trivial typos or logical
errors, but one quite subtle error merely reduced precision in the fifth
decimal place.

The story quotes from a memoir by Wilkes, who recalls the exact moment when
"the realization came over me with full force that a good part of the
remainder of my life was going to be spent finding errors in my own programs."

The SCIENCES story cites an article by Martin Campbell-Kelly in ANNALS OF
THE HISTORY OF COMPUTING 14(4) 1992 and Maurice Wilkes' book MEMOIRS

- Jon Jacky, Department of Radiation Oncology, U. of Washington, Seattle

Offshore Data Havens

Sun, 5 Sep 93 16:00:59 PDT
As a reader of RISKS who combines his vocation, journalism, with his
avocation, computers, I'm writing in with a request.  In the course of working
on an assignment for one of the TV networks, I came across references to
"offshore data havens."  These are data networks, alleged to be in the
formative process, which will glean data by means fair and foul from the
world's legitimate data bases.  The implication is that formerly confidential
information, be it about individuals, corporations or governments, would seep
across networks.  The information would then be available, at a price, to
anyone who wanted it.

My questions are:

* Are "offshore data havens" actually being formed, and if so, where?
* What are the inherent problems that come to mind?  Don't be afraid to state
  the obvious; television audiences aren't experts in this area.

I'd love to see this become a topic for discussion on RISKS, but would also
appreciate (with thanks in advance) any responses sent to me directly.

Re: The risks of CERT teams vs we all know (Cohen, RISKS-15.02)

Jeffrey I. Schiller <>
Wed, 8 Sep 93 01:19:15 -0400
Let's go back and review history (briefly). The CERT teams, beginning with the
original CERT at CMU, were a reaction to the now infamous Morris Worm of 1988.
The folks who "solved" the worm problem by disassembling the worm and
generating patches for the network community, in a matter of hours, were the
university people, both staff and students.

Then, we had source code.

Today vendors are more and more making their source code unavailable, or too
expensive, or available only under untenable terms(1). Fewer of us university
people now have source code for contemporary systems. Yet the crackers out
there have all the source code they can steal, which is quite a collection. I
know, I saw it.

The network is as vulnerable today as it was in 1988... We'll see what
happens the next time!

[1] Terms for example that prohibit students from having access.

Re: Risks of CERT teams (Cohen, RISKS-15.02)

Frederick Roeber <>
Wed, 8 Sep 1993 11:02:45 GMT
> The problem with restricting information to CERT teams, etc. is that this:
> 1 - creates a techno-elite
> 2 - limits distribution far too much

And in any case, I don't think it works.  A couple years ago, I was handed the
job of running a cluster of machines at Caltech.  Through various connections
(Caltech, JPL, CERN, the HEP community, etc.) I ended up on many public and
private mailing lists for security information, without even trying.  Usually
I'd receive a half-dozen slightly different copies of the same alert, before
the sanitized CERT version went out.  (This was useful for gauging the
severity: if I only received a couple pre-CERT notes, I could probably defer
the problem; if I received ten, I had to act.)

I think the restrictions the various Response Teams give themselves serve only
to allow them to tell themselves -- and more importantly, their bureaucrats
and lawyers -- "We're doing everything possible to limit the spread of
dangerous knowledge."  Whether their efforts in this direction accomplish
anything or not is another question.

Re: Lost Crime Stats (Fernandes, RISKS-15.02)

Rodney Boyd <>
Wed, 8 Sep 93 16:08:45 GMT
According to the Globe and Mail (last Saturday, I think), the discrepancy
arose because the police counted individual offenses, whereas StatsCan counted
"incidents", which could encompass several offenses (e.g., a rape could result
in charges of assault, sexual assault, use of a weapon, etc.).


Into the void at the supermarket

Andrew Klossner <>
Tue, 7 Sep 93 13:27:02 PDT
While paying for groceries at a "pack the bags yourself" discount supermarket,
I presented a chit for a $15 credit, obtained when I returned several bags of
soda cans.  The cashier punched the cash register, and it stopped with an
alert condition.  It seems that "manager approval" is required whenever a
credit of more than $5 is entered.  At this store, the managers have long
since tired of dealing with these alerts, so they have issued manager-only
cash register override keys to all cashiers.

The cashier inserted and twisted a key, and the machine began to void
out the entire $100 transaction, item by item.

    cat food, -$0.29
    cat food, -$0.29

The cashier shrieked for help, but it was not to be had; the manager
trainee on duty that Labor Day didn't know anything more than she did.
After a minute or so, the cash register finished up and displayed

    balance: $0.00

The young lady turned to me and explained that she would have to pass
every item over the scanner again.  Unpack forty cans of cat food and
fifty jars of baby food?  I explained that this option was not
available to her, and that she had needed to devise another solution.

She proceeded to phony up a set of transactions to create a balance identical
to the one I'd had before the disaster.  Her arithmetic was none too good, so
she adjusted it by entering fictitious coupon discounts.

As I paid (the correct amount), she explained that there are *two* keys -- the
"manager" key and the "professional" key.  The latter is used only to turn on
the cash register in the morning, and to void out an entire transaction.
There is a single lock on the register, into which either key is inserted.
The two keys are hard to distinguish from each other.  And store management
keeps them on a single keyring for ease of access.

(This same store also allows forklifts in the aisles during business hours,
with employees riding the fork in violation of OSHA rules.  And they are
building a database of individual purchasing habits.  It's a wellspring of
RISK examples.)

  -=- Andrew Klossner  (

Re: What Constitutes an Exhaustive Attack? (Murray, RISKS-15.02)

A. Padgett Peterson <>
Tue, 7 Sep 93 13:19:21 -0400
>The cost of an exhaustive attack is an interesting number.  It gives us an
>upper bound for the cost of efficient attacks.  However, it is never, itself,
>an efficient attack.

What has bothered me for some time about Clipper/Capstone/SkipJack is
exactly this question and the concern that what might be an exhaustive
to some might not be what the user would think.

Consider the possibility that every person in the United States were issued
a SkipJack key - better, suppose that every possible ZIP code in the United
States were issued a key (10^9 as opposed to approx. 2.5*10^8 women, men, and
children). Next suppose that every key issued were known (not WHO they were
issued to, just WHICH had been issued). An exhaustive attack is now 10^9
trials with average success in 5*10^8 trials. At a 40 MHZ rate (common for
DSPs) this would take well under a minute for an exhaustive search.

No trapdoors, backdoors, or weak keys. Just a database of all issued keys.
In the sixties, a thief who wanted your GM car often did not have YOUR key,
they had ALL the keys (on a ring about six inches in diameter - typically
took about five minutes to find the right one).

The disclaimer here is usually one of random seeds etc but does anyone really
think that every key is going to have a unique random seed ? Or is it
more likely that the two agents will each contribute their 80 bit piece and
then a few thousand keys run off. And that the first (or last) from each batch
along with the count might be for some nameless agency ?

My belief is that the SkipJack algorithm is every bit as strong as everyone
has said it will be. The question will it really take an exhaustive attack or
will there be a "black bag" attack possible that will stem from the key
generation process. Creative accounting at work.


ps I believe in Clipper/Capstone/SkipJack & if the price is within reason
   will be one of the first to use it. Most people do not care if our
   government can listen in. Just no surprises, Teapot Domes, or fingers-
   crossed promises please.

Fixing what's known to be broken (Re: RISKS of elaborating on...)

Tom Lane <>
Sat, 28 Aug 93 19:58:25 -0700 writes:
> Now that 3 children have died and 13 more spent time in hospitals, local
> organizations are distributing safety bars for windows.

This example reminded me of an old saying in the architectural and building
trades: "Building codes are written in blood."  Every requirement that exists
in modern building codes was created to prevent a repeat of previous deaths.

Not that we should feel complacent, but the difficulty is hardly limited to
software development.  Taking shortcuts is a time-honored activity, and when
it works it has clear benefits: there's no value in making a beam 10 times
stronger than it needs to be, while there's lots of value in building a house
affordably.  The trick is to learn the *appropriate* safety factor.  Neither
safety-be-damned nor safety-at-ANY-cost is a workable approach.  But probing
the margin of what's safe tends to lead to accidents.  As long as foresight is
not 20-20, there's no way around this.

Petroski's book "To Engineer is Human" is an excellent discussion of the
technical and moral dilemmas involved here.  Required reading for RISKS folk.

Tom Lane

Caller ID Blocking and 911

Monty Solomon <roscom!monty@Think.COM>
Fri, 3 Sep 93 15:00:59 -0400
The following is an excerpt from the "Caller ID And Blocking Fact Sheet" I
received from New England Telephone.

How Does Line Blocking Work With Emergency Calls?
    If you have Line Blocking and an emergency service provider has
    Caller ID, the provider will NOT receive your number UNLESS you
    unblock your number by pressing *67 (dial 1167 on a rotary/pulse
    phone) before you call '911' or other seven digit emergency numbers.

Line Blocking and Per-Call Blocking pertain to Caller ID only.  Call Trace
and Call Return are unaffected by either Line Blocking or Per-Call Blocking.

# Monty Solomon / PO Box 2486 / Framingham, MA  01701-0405

    [I have a huge collection of messages on blocking, dialing 1, *67,
    and related topics.  I think we have peaked on those discussions,
    so I'll call a halt for a while.  Thanks to all of you who sent in
    contributions on those topics.  PGN]

Re: Bank mailing problem (Wood, RISKS-14.85)

Lauren Weinstein <>
Fri, 27 Aug 93 12:49 PDT
Kenneth Wood reported the saga of a bank that mailed letters to its 2000
wealthiest customers, all addressed to "Rich Bastard", thanks to a careless

It's worth noting that if the bank had given the mailing even a cursory check
before dropping it into the mail stream, the odds are that the mistake would
have been noticed and the mailing aborted.  Of course, one can't expect a bank
to personally inspect every envelope that churns out of their automated
systems.  But it would seem that with a relatively small mailing of such
importance (dealing with your biggest customers) a little extra checking would
have been a good investment!

The RISK is putting total faith in the system, of course.


Technology export curbs

"Mich Kabay / JINBU Corp." <>
27 Aug 93 15:05:53 EDT
From Washington Post newswire   08/27

    U.S. Acts to Ease Export Controls On Computers; Industry Officials
    Say Proposed Standard Falls Far Short of Need
    By Peter Behr,  Washington Post Staff Writer

    "The Clinton administration moved yesterday to ease Cold War-era
controls on exports of high-powered U.S. computers to the former Soviet
Bloc and other countries, fulfilling a campaign promise President Clinton
made to the Silicon Valley executives who supported him last year."

The article continues with comments on the lost sales caused by Cold War
restrictions on computer exports.  The new Commerce Decision rules allow
export of microprocessors rated at 67 Mops (million operations per second),
a big boost from the previous limit of 12 Mops.  However, multiprocessor
units are still on the forbidden list.

Sales to the former Soviet Union are still subject to approval by COCOM,
the Coordinating Committe for Multilateral Export Controls.  Apparently
some members of COCOM--Germany, in particular--are trying to link
relaxation of computer export restrictions with relaxation of
telecommunications gear.


It will be interesting to see if the long-standing assumption that export
restrictions prevent the distribution of technology to the interdicted
nations.  My reading of the DES-restriction debacle is that export controls
on high tech are a farce.  The U.S. restrictions hurt U.S. manufacturers
and are a boon for everyone else.

Michel E. Kabay, Ph.D., Director of Education, National Computer Security Assn

Re: Security holes and risks of software like Sendmail

Fri, 27 Aug 93 15:22:58 -0400
    The only conclusion I seem to be able to draw from problems like the
sendmail DEBUG hole is that more care needs to be spent designing software so
that bugs in security-critical programs CANNOT compomise the system.

    Mailers are inherently complicated things, that require privileges in
order to work. It seems to me that in designing a complex program that
requires privileges, the complex part and the privileged part should be
separated. The privileged part should be simple enough that its function can
be verified in a couple of minutes of code-browsing with a cup of cappucino.
The complex part can be as convoluted and gnarly as you wish, and can have all
the debug options its complexity requires.

    A good example of this design philosophy is anonymous FTP. There was a
pretty nasty bug recently described in the wustl ftpd, a popular
implementation that is widely used. Any user on the network could get root
access to a system running that version of ftpd. How can this happen? Because
ftpds are complicated and do lots of stuff (especially the wustl one, which is
extremely "feature heavy") - they also require privs in order to work right.
This is a deadly combination. You'll find it wherever there are consistent
security problems. A lateral thinking approach to FTP is to configure ftpd the
way we do at TIS: you do the chroot and setuid before ftpd is even invoked.

    Ideally, the worst the complex code can do to you is give you a core
dump. Ideally, the critical code should be a page or 2 of clear,
straightforward operations. If you have to comment your security critical
code, perhaps it's too complex. ;)


CfP: 1994 Z User Meeting Announcement

Jonathan Bowen <>
Sat, 28 Aug 93 15:47:38 BST
                     Notice of Meeting and Call for Papers
                          8th Z User Meeting - ZUM'94
          Organized by the Z User Group in association with BCS FACS
                               29-30th June 1994
                St. John's College, University of Cambridge, UK

                              Program committee:

Rosalind Barden, Logica, Cambridge     Jonathan Jacky, Univ. of Washington, USA
Jonathan Bowen, Oxford Univ.           Peter Lupton, IBM Hursley
Elspeth Cusack, BT                     John McDermid, York University
Neville Dean, Anglia Polytechnic Univ. Sylvio Meira, Univ. of Pernambuco,Brazil
David Duce, Rutherford Appleton Lab.   John Nicholls, Oxford Univ.
Anthony Hall, Praxis plc               Gordon Rose, Univ. Queensland, Australia
Brian Hepworth, British Aerospace      Chris Sennett, DRA Malvern
Howard Haughton, Lloyd's Register      Sam Valentine, Univ. of Brighton
Mike Hinchey, Univ. of Cambridge       Jim Woodcock, Oxford Univ.
Darrell Ince, Open Univ.               John Wordsworth, IBM Hursley

The committee of the Z User Group invites the submission of papers related to
the interests of users of the formal notation Z.  Sessions on the following
themes are planned, and papers on these topics are especially encouraged:

  *  Industrial experiences
  *  Application of Z to safety-critical systems
  *  Projects and processes for formal methods - organizational issues
  *  Z and concurrency
  *  Educational issues (an extra half-day session)

Papers for presentation and publication will be reviewed and selected by the
program committee.  The timetable for submitted papers is as follows:

  Submission of draft paper:                  1st October 1993
  Notification of acceptance:                 30th November 1993
  Final copy for Proceedings:                 31st January 1994
  Z User Meeting in Cambridge:                29-30th June 1994

A maximum limit of 20 pages is requested.  Industrial contributors may submit
extended abstracts if they prefer. Please include four copies of your
submission and indicate if you wish your paper to be considered for one of the
special themes.  The following invited speakers are planned:

  David Garlan, Carnegie-Mellon University, USA:     Z and education
  Mike Gordon, University of Cambridge, UK:          Z and HOL
  Leslie Lamport, DEC Systems Research Center, USA:  Z and concurrency
  Jim Woodcock, Oxford University, UK:               Z and MoD 00-56
  Robert Worden, Chairman of Logica Cambridge, UK:   Z and industry
  Maurice V. Wilkes, Olivetti Research (Emeritus Professor, University
    of Cambridge):  After dinner speaker on the occasion of the 45th
    anniversary of the EDSAC meeting (first European computer
    conference) held in Cambridge, June 1949, and hosted by him.

The meeting will be sponsored by BT, Logica and Praxis and is supported by
the UK BCS FACS group the European ESPRIT ProCoS-WG (8694) Working Group.

General enquiries may be directed to:
  Jonathan Bowen (Conference Chair)
  Oxford University Computing Laboratory, 11 Keble Road, Oxford OX1 3QD, UK
  Tel: +44-865-272574, Fax: +44-865-273839

Submitted papers and extended abstracts should be sent to:
  Anthony Hall (Programme Chair)
  Praxis Systems plc, 20 Manvers Street, Bath BA1 1PX, UK.
  Tel: +44-225-444700, Fax: +44-225-465205

Proposals for tutorials, tool demonstrations, publishers' stands, and
requests for information concerning local arrangements should be sent to:
  Mike Hinchey (Tutorial Chair)
  University of Cambridge, Computer Laboratory
  New Museums Site, Pembroke Street, Cambridge CB2 3QG, UK
  Tel: +44-223-334419, Fax: +44-223-334678
  Until beginning of October 1993 at DEC Systems Research Center,
  Palo Alto, California, USA, Email:

A special session on Educational Issues relating to Formal Methods (Z
in particular) is being organized for the Friday morning (1 July 1994)
after the main Z User Meeting 1994 to be held in Cambridge (29 and 30
June 1994). For further information, please contact:
  Neville Dean (Education Session Organizer)
  Applied Sciences, Anglia Polytechnic University, Cambridge CB1 1PT, UK
  Tel: +44-223-352992 ext 2329, Fax: +44-223-352979

Call for Papers, Decision Science Conference

Tue, 07 Sep 1993 17:31:43 -0400 (EDT)
Subscribers to RISKS may be interested in attending and/or presenting a paper
at the 1994 Annual Meeting of the Northeast Decision Science Conference, April
6-8, at the Sheraton Hotel and Conference Center in Portsmouth, New Hamshire.
The conference has a Business Law/Business Ethics track which last year
featured papers on the implications of the Americans with Disabilities Act for
ATM managers, and the legal implications of Expert System use.

Other tracks include:

Curriculum and Studies
Environmental Management
Finance and Real Estate
Human Resource Management
International Business
Management Science
Organization, Theory, Policy and Behavior
Operations Management
Service Management
Statistical Theory & Applications

Papers presented are also published in the conference proceedings.  All papers
must be double spaced.  Authors must submit one copy plus three additional
copies for each track for which the paper is to be considered.  Papers should
not exceed 20 pages in length.  Each copy of the paper should have two title
pages.  The first should have both the title and author information (including
mailing address); the second should have only the title.  Each submission
should include a 3" X 5" card with the following data:

1.  Author(s)
2.  Affiliation
3.  Address(es)
4.  Office and Home Phone Numbers
5.  Submission Title
6.  Appropriate Track(s)

Each submission should also include a stamped, self-addressed postcard
with the author(s) name and the title of the submission for acknowledgement
of receipt by the Program Chairperson.

Papers must be received no later than October 3, 1993.  Notifications of
acceptance will be mailed by December 1, 1993.  Accepted papers must be
typed in final condensed and camera-ready form and returned to the
Proceedings Editor by January 5, 1994.  Specific instructions will be
mailed to the authors with the acceptance letters.

Submissions are to be sent to:

Dan Reid
1994 NEDSI Program Chairperson
Whittemore School of Business and Economics
University of New Hampshire
Durham, NH  03824
(603) 862-3382

The Sheraton Portsmouth Hotel and Conference Center has provided a limited
number of rooms at the rate of $89-94/night (single) and $99-104/night
(double), plus tax.  (For reservations call (603) 431-2300 and state that you
are attending the NEDSI Meeting).  Other questions, contact chair.

Please report problems with the web pages to the maintainer