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 17 Issue 7

Thurs 20 April 1995


o New Massachusetts password law invoked on hospital technician
o Less than robust wiring designs
Tim Kolar
o Fugue-by-Wire!?
James G Henderson
o 11 B-boards dismantled in Montreal
Mich Kabay
o Re: Installing old software ...
Ted Wong
o Re: RISKS of patrol-car computers
Joe Chew
Matt Raffel
o "Friendly" user interfaces (Re: Searching ...)
C. Titus Brown
o Re: Searching for a book in a database
Jerry Leichter
o Risks of online documentation
Prentiss Riddle
o Risks of online catalogs
Doug Shapter
o Computer-controlled electrocution
David Karr
o 4th Conference on Software Risk
Lorrie Orndoff
o Info on RISKS (comp.risks)

New Massachusetts password law invoked on hospital technician

"Peter G. Neumann" <>
Wed, 12 Apr 1995 12:49:43 PDT
Mark L. Farley, 34, of Lowell, was arrested on 9 Apr 1995.  Working as an
orthopedic technician in the Newton-Wellesley Hospital, he allegedly
accessed a former employee's computer account to search through 954
confidential files of patients (mostly young females) for telephone numbers,
which he then used to make obscene calls.  (He had pleaded guilty in 1984 to
raping an eight-year-old girl in Erving.)  He is apparently the first person
to be charged under a new Massachusetts statute that makes it a criminal
offense to use someone else's password to gain access to a computer system.
He is also accused of stealing hospital trade secrets, and making obscene or
annoying telephone calls — apparently from the hospital.  [Source: Hospital
Worker Charged under New Massachusetts Password Law By MATTHEW BRELIS, *The
Boston Globe*, 12 Apr 1995.]

  [Health-care records are increasingly the subject of privacy concerns,
  because of their rampant abuse.  This case has caused quite a stir in
  the Boston area.  PGN]

Less than robust wiring designs

Tim Kolar <>
Mon, 17 Apr 95 18:31:07 PDT
I just received this peach from a friend at a local multi-million dollar
computer company (after their phone was busy all day).  They recently had
some layoffs, but frankly it sounds like their problems started long before

> My phone isn't really busy.  There's a little problem at ******* today.
> They were doing some facilities work in one of the labs and
> accidentally set off the earthquake detector.  Since earthquakes tend to
> set off the indoor sprinkler system, the earthquake detectors shut off
> electrical.  This lab happened to share some wiring with the phone system,
> and nobody knows how to reset it.  This is one of those little gaps that
> got left with the layoff.

The Risks of not having detailed instructions for disaster recovery are
apparent.  The question of why a lab is sharing power with the main phone
system is a sub-Risk left for the student.

While I'm at it, just why would you design an earthquake detection system
that didn't require two or more significantly separated points for
verification?  Local shocks from people dropping heavy objects are
relatively common...

-Tim Kolar  cisco Systems


James G Henderson <>
Mon, 17 Apr 1995 21:43:05 GMT
You've heard of Fly-by-Wire? well what about Fugue-By-Wire! The UK New
Scientist magazine, 15 April 1995, reports that Notre Dame's organ is not
suitable for concerts following a two year restoration costing =A31.3
million (Pounds Sterling) in which six computers were installed to relay the
organist's instructions from the manuals (keyboards) and pedals to the organ
pipes.  The cathedral's administrator has cancelled all concerts as a series
of malfunctions, including `memory failure', has caused the organ (as he is
reported as saying) `to suddenly stop working. It takes five to ten minutes
to get it going again. This is too stressful for the organists who never
know when it will happen'! It is still used for Mass, however, as when it
`crashes' a small organ fills in the unintented silence.  JS Bach should
have been warned that his `Toccata & Fugue in D Minor' would be too `memory
intensive' for organs of the future! Program Notes Limited

11 B-boards dismantled in Montreal

"Mich Kabay [NCSA Sys_Op]" <>
20 Apr 95 13:12:03 EDT
Eleven Electronic Bulletin Board Systems Dismantled
(From A Royal Canadian Mounted Police news release)

Montreal, April 12, 1995 - Seventeen searches conducted in the Greater
Montreal area by the Copyright Investigations Unit of the Montreal RCMP
Federal Enforcement Section put an end to the operation of eleven
electronic bulletin board systems (BBS).

Since 6 o'clock this morning, 75 RCMP members have been dismantling bulletin
boards specialized in circulating copyrighted Canadian software such as Le
Correcteur 101, CorelDraw, Winfax PRO, as well as products developed by
Audodes [Autodesk?], Borland, Clark Development, DataStorm, Disney, IBM,
Lotus, Microsoft, Windows 95, Mustang Software, Novell, Playboy,
Quarterdeck, Sierra, Symantec and many other firms.

Computers and peripherals worth more than one hundred thousand dollars were
seized, along with millions of dollars of pirated software.

This is the most important operation of this kind yet in Canada against
illicit bulletin board systems.

About 15 persons will appear in court at a later date to face charges
under the Copyright Act which sets out severe penalties for offenders:
-   6 months and/or $25,000.00 per count for summary conviction
-   2 years and/or $1,000,000.00 per count for indictable offenses.

.... [invitation to press conference 95.04.11]....

-  30  -

Resource person:

Sergeant Serge Corriveau
Federal Enforcement Section
Tel. (514) 939-8307


Constable Gilles Deziel
Community Relations Section
Tel. (514) 939-8308


_La Presse_, the largest newspaper in the greater Montreal area, published a
news story about the raids on 13 Apr 1995 (translation and summary by MK):

    Major Strike by the RCMP in the InfoBahn
    [Gros coup de la GRC dans l'inforoute]

    by Eric Trottier, La Presse

    The RCMP has decided to do a little house-cleaning in the
    joyously anarchic world of the electronic highway.

    Thanks to a computer-science infiltration operation, the
    federal police yesterday dismantled 11 bulletin boards that
    were trafficking in tens of thousands of software packages
    around the world.

    "It's the first time we have been able to implement this type
    of penetration of BBSs.  Even in the U.S., the most important
    dragnet of this type has so far only allowed the dismantling of
    six BBSs at a time," said Sergeant Serge Corriveau to La Presse
    shortly after the investigators completed more than a dozen
    penetrations and seized more than C$200,000 [U$140,000] of
    computer equipment.

Key points from the article:

o   News of the raid spread rapidly through the Internet;

o   The 11 BBSs were involved in large-scale fraud in N.America
    and Europe.  Subscription fees of C$30-C$50 per month allowed
    participants to download copies of proprietary software at will.

o   "Everything available legally on the market was offered by these
    BBSs," said Sgt Corriveau.

o   Some of the more audacious BBSs offered beta copies of Windows95.

o   There are about 700 BBSs in the greater Montreal area; the RCMP
    estimate that three-quarters of them traffic in stolen software.

o   Some of the BBS have become virtual flea markets of pornography,
    bomb-making instructions, and details of how to succeed at suicide.

o   In one of the shut-down systems, stolen goods and illegal assault
    weapons were advertised for sale.

o   It has taken a year to infiltrate the BBSs; some officers had to
    wait up to four months to gain entrance to the inner areas of the
    boards they were investigating.

o   The raids involved 75 officers in Montreal, Outremont, Repentigny,
    Longueuil, Saint-Amable, and the St-Jerome area.

o   The BBSs shut down are:  Notice, Twins, Red Alert, Perfect Crime,
    Beyond Corruption, Line-Up, Wolf Pack, On the World, Restricted Area
    and Necromancer Mecon.

o   Most had about 6 telephone lines for full-time access, serving
    100-250 clients, with some in Europe.  The larges, Notice, had
    350 clients who each paid $50/month, for an untaxed revenue of
    C$210,000 per year.

o   The police estimate that 11 to 15 criminal hackers will be
    indicted as a result of the raids.  They each face fines of
    C$25,000 to C$100,000.

M.E.Kabay,Ph.D., Mgmt Consultant, LGS Group Inc. (Montreal, QC);
Director of Education, Natl Computer Security Assn (Carlisle, PA)

Re: Installing old software ... (Wampler, RISKS-17.06)

Ted Wong <thwong@CS.Cornell.EDU>
Tue, 18 Apr 1995 15:03:53 -0400
>The RISK — don't forget today's news is tomorrow's history.  While
>Microsoft might have been trying to be helpful in 1992, they forgot that
>someone just might use it in 1995.  All very irritating!

Of course not. Everyone would have switched to Win 95 by then...

Maybe there is a RISK here. Suppose a software developer finds problems in
some current version of a program, but instead of sending out an immediate
bug-fix (with all its attendant negative publicity), elects to wait until
the next major version release before including the fixes. If this release
is then delayed, are users then left using broken software for longer than
is necessary?

Ted Wong, Computer Science, Cornell University <>

Re: RISKS of patrol-car computers (Story, RISKS-17.06)

Joe Chew <>
Tue, 18 Apr 1995 19:23:08 GMT
>Could it be that the visual and mental concentration required to
>operate a computer can constitute a potentially fatal distraction
>for a police officer?

Depends on the situation.  It would be foolish to begin using the computer
when you knew you were in a tactical situation that demanded keen awareness
of your surroundings.  However, a cop who spent his entire shift worrying
about being ambushed by someone with a high-powered rifle would, I should
imagine, have a brief, ineffective, possibly even dangerous career en route
to a psych disability.

But perhaps there is a risk, related to the way a computer sucks your
attention into a black hole where space and time have little meaning.  A cop
who pulls over into some secluded area to finish up his paperwork might well
face a less absorbing task that lets him monitor what's going on outside the

There's a RISK much more probable than getting ambushed, though.  I became
aware of it while watching "Cops" on the bread-and-circuses dispenser one
night. Our hero was driving along a city street at a pretty good clip while
in a complete heads-down mode, using the computer.  Had there been a bicycle
or baby buggy in front of the car, the screeching noise from underneath the
axle would've been his first clue that something was wrong.


RE: RISKS of patrol-car computers (Story, RISKS-17.06)

Matt Raffel <>
Tue, 18 Apr 1995 14:53:10 -0700
The story relating to the murder of an Oakland Cop, who was slain while
using in car-computer, brings another "interesting" RISK to mind.

Since the cop was murdered while using the computer, it is safe to assume
that the cop was properly signed into the system, when he died.  The
criminal could have used the computer to access police files, perhaps alter
them, or otherwise infiltrate the system and violate the integrity of the
computer system.

Matthew Raffel  Interactive Software Development, Inc.

"Friendly" user interfaces [ Was: Re: Searching for a book... ]

"C. Titus Brown" <>
Tue, 18 Apr 1995 13:49:31 -0800 (PDT)
In response to Erik Kraft's message about the lack of power inherent to many
"user friendly" interfaces:

This sort of thing happens quite frequently; it's one of the reasons why I
won't touch Window & Mac machines, while I love UNIX.  The typical problem
is that it's much easier to implement a "computerese" interface (which
requires little design) than to design & implement a worthwhile
user-friendly interface *that has the same flexibility*.

The risks?  Building software upon software that doesn't allow complete
flexibility!  Eventually *something* is going to break, and if low-level and
flexible configuration/command ability isn't available, the only person
who's going to be able to fix it will be the original programmer.

Perhaps some advice: build the graphics interface to critical utilities on
TOP of a flexible command-line system, not concurrent with it.

[obRisks: since I don't deal with inflexible user interfaces any more, I don't
 have any recent examples of this sort of thing.  The most relevant one I
 can think of is the (old?) NeXTStep graphical system manager interface.
 Once I deleted the NetInfo database, and (after browsing the manual pages
 in single user mode for several hours) had to reinstall the entire system.
 It's virtually impossible to change the system using the command-line
 utilities. ]

Titus Brown,

Re: Searching for a book in a database (Kraft, RISKS-17.06)

Jerry Leichter <>
Thu, 20 Apr 95 10:40:27 EDT
Erik Kraft responds to my comment about the advantage of "human search" of
available computer search techniques in finding a book in a library listing
by describing a similar problem he had, which he was able to solve by talking
to a friend at the computer center and gaining access to the "computerese"

Curiously, when I first described my problem to a friend who uses the same
library, he pointed out that the programs involved provided two interfaces:
The "easy to use" hierarchical menu system meant for customers, and the
higher-powered system meant for librarians.  The particular search I needed
could, indeed, have been done fairly easily from a librarian's terminal.

But this illustrates another aspect of the same risk.  Most people don't have
friends at the computer center, or even know librarians who will let them use
the "privileged" interface.  The only interface available to them is the
"public" interface, which in the interest of ease-of-use by a population who
have no reason, time, or desire to "learn about this fancy computer stuff",
has been deliberately limited in its capabilities.

I recall a discussion I had a number of years back with Alan Perlis.  (Alan
was a wonderful person with a very broad range of interest and insights, so
this isn't as odd as it will sound.)  I had just been trying to buy a wood
trash can.  I couldn't find any - just cheap metal and cheap molded plastic
"fake wood".  I commented that technological advances sometimes lowered the
quality of the products one could find.  Alan's response was that, no, I was
looking at it wrong.  Pre-technology, most people could only afford to buy
low-quality versions of a product; the reasonably well off could buy
higher-quality versions.  Technology - particularly automation - made it
possible to raise the quality of the cheap stuff.  This eliminated both the
older forms of the product: The real junk was no cheaper to produce than the
better post-technology product so couldn't compete; and the former
"reasonable quality" was now much more expensive, and only a bit better.
Often, a new "super-high-quality" stratum came into being as well - where
"quality" often really means "snob appeal" - but at much, much higher
prices.  (Sometimes this already existed and simply continued; sometimes
not).  For the relatively less well off, technology provides better products
for equal or less cost.  For the very well off, it makes little difference.
But there is a range in the middle who actually lose ground.

We are seeing a similar effect in these library interfaces.  For the vast
majority of people, who rarely use the library systems and have no need to
do anything sophisticated when they *do* use them, they are a clear step
forward.  Those people who are "wealthy" by virtue of having special access
and knowledge at worst break even, and often gain.  But there are those in
the middle for whom the new technologies are a step backward.  Library
systems are not alone - those of us who, for example, are used to writing
command files or shell scripts to accomplish sophisticated things find GUI
interfaces frustrating.  More and more systems are "sealed" - at least Mr.
Kraft's friend in the library computer center could give him access to a
low-level interface.  What happens when the only access is through a Web
server that no one can log onto?  You get the services it chooses to give
you, period.

-- Jerry

Risks of online documentation

Prentiss Riddle <>
Thu, 20 Apr 1995 08:58:49 -0500 (CDT)
I've long been a bit disturbed by the trend toward distributing software
without documentation, instead referring the user to online documentation at
a WWW site.  Here is an example of how this arrangement can go wrong:

Forwarded message:
> From: (Elizabeth Frank)
> Date: Tue, 18 Apr 1995 12:54:42 -0500
> To:
> Subject: re:ncsa security problems
> A new version of 1.3 with several security patches was
> released last week.  (version httpd_1.3R+ on our ftp server,
> Unfortunately, (where our documentation
> is located) was hit by lighting and will not be back in
> service for a couple of days.  This only affects our documentation,
> the patched code is on the ftp server which is still working.

Note that there is a mirror of the NCSA documentation at, but it is not clear that either VTLS or NCSA
have made a commitment to keep the mirror up to date (nothing at the
VTLS site mentions version httpd_1.3R+).  This highlights another risk
of online documentation: without a careful versioning scheme, it is
easy to find oneself fetching documentation for a different version of
the software than the code at hand.

-- Prentiss Riddle
-- Systems Programmer and RiceInfo Administrator, Rice University

Risks of online catalogs

Thu, 20 Apr 1995 11:36:02 -0400
Cliff Stoll makes an excellent critique of online catalogs in his new book
_Silicon Snake Oil_. He enumerates many of the criticisms that contributors
to RISKS have discussed.

I recently ran into a problem with the online catalog for the library where
I work. Asking to see the card catalog, I was told that it was 2-3 years out
of date. The online catalog that replaced it accessed classified information
and was therefore unavailable for general use. The librarian had to perform
the search for me. Since I was looking for a specific book, it was not a
problem. On the other hand, if I was doing more general research, I would
have been stymied.

Doug Shapter |

Computer-controlled electrocution (RISKS-17.06)

David Karr <karr@CS.Cornell.EDU>
Tue, 18 Apr 1995 15:19:15 -0400
People seem upset by the use of a computer to control an electric chair.
While I agree that electrocution is horrifying, nobody has identified the
computer-related risk.  The claimed "risk" seems to be that computers and
other electronic devices are being used to kill.  But how do the inventors
of those gadgets feel about the fruits of their labor being used by military

The obvious actual risk is that the computer might make more mistakes
than human executioners, or might make worse ones.  But the human
executioners apparently already have a record of botched executions,
so a proper assessment would have to weigh the risks on both sides.

Of course a better solution might be to do away with electrocutions
altogether, but that debate doesn't concern the use of computers.

-- David A. Karr (

4th Conference on Software Risk

Lorrie Orndoff <lao@SEI.CMU.EDU>
Wed, 19 Apr 1995 13:26:48 EDT
    *        CALL FOR PARTICIPATION           *
    *      4th Conference on Software Risk        *
    *   Theme:  Current Successes and Future Directions   *
    *          November 6-8, 1995             *
        *         Monterey, California            *

You are invited to participate in the 4th SEI Conference on Software Risk,
November 6-8, 1995, in Monterey, Calif. The conference will include plenary
sessions, formal presentations, invited panel discussions,
birds-of-a-feather (BOF) meetings, and SEI Risk Program tutorials.  Vendor
exhibits will also be offered.

* Theme *

The theme of the conference is Current Successes and Future Directions.

Significant progress in the development and application of software risk
management techniques by government agencies, contractors, and vendors has
occurred since the 3rd SEI Conference on Software Risk.  We ask you to share
your field experiences, results, and lessons learned from using and applying
these techniques.

We request presentations and BOF topics that include:

* Applying Technical Performance Measurement to risk management
* Measuring the return on investment in risk management: quality or cost
* Making informed decisions in conditions of uncertainty
* Learning from sharing risks across domains
* Adapting existing risk management methods to your organizational culture
* Managing people: risk takers and risk avoiders
* Managing the risks of using COTS

* Participation options *

Presentations - individuals or teams interested in making a 45-minute
presentation (including questions and discussions) must submit a 2000 to
3000 word abstract and a brief biography.  Abstracts must describe, not just
list, the topics covered.  Preference will be given to submissions that
demonstrate results of the application of risk management in software
development projects.

Birds-of-a-feather - individuals or teams interested in conducting a two-hour
BOF discussion Tuesday evening must submit a description (including an outline
of the topics covered) and a brief biography.

Exhibitions - organizations or individuals interested in exhibiting their
risk-related products and services or experimental tools must contact Carol
Ulrich for more information.

* Important dates *

June 23, 1995       Extended abstracts and BOF descriptions due
July 17, 1995       All accepted presenters have been notified
September 11, 1995  Camera-ready copy of final abstract, slides, and BOF
            materials due

* Benefits to participants *

Individual presenters or presentation teams are entitled to one waived
registration fee.

Birds-of-a-feather leaders will be provided with a classroom setting; the SEI
will reproduce materials for attendees.

Exhibitors may have the opportunity to present a 10-minute overview of their
risk-related products and services or tools to the conference attendees prior
to the exhibit.

* Send submissions to: *

Carol Ulrich, Conference Chair, Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA  15213

Phone 412 / 268-3624   FAX 412 / 268-5758   Internet

 [Lorrie Orndoff, Administrative Assistant, Software Engineering Institute
 Carnegie Mellon University, Pittsburgh, PA 15213
 Phone 412 / 268-3098   FAX 412 / 268-5758  Internet]

* Program committee *

Barry Boehm, USC Center for Software Engineering
Robert Charette, ITABHI Corporation
Richard Fairley, Software Engineering Management Associates, Inc.
Yacov Haimes, University of Virginia Center for Risk Management of
  Engineering Systems
Ronald Higuera, SEI
Richard Murphy, Deputy Chair, SEI
John Salasin, ARPA
Carol Ulrich, Conference Chair, SEI

The SEI is a federally funded research and development center sponsored by the
U.S. Department of Defense and operated by Carnegie Mellon University.

Please report problems with the web pages to the maintainer