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
Contents
New Massachusetts password law invoked on hospital technician- PGN
Less than robust wiring designs- Tim Kolar
Fugue-by-Wire!?- James G Henderson
11 B-boards dismantled in Montreal- Mich Kabay
Re: Installing old software ...- Ted Wong
Re: RISKS of patrol-car computers- Joe Chew
Matt Raffel
"Friendly" user interfaces (Re: Searching ...)- C. Titus Brown
Re: Searching for a book in a database- Jerry Leichter
Risks of online documentation- Prentiss Riddle
Risks of online catalogs- Doug Shapter
Computer-controlled electrocution- David Karr
4th Conference on Software Risk- Lorrie Orndoff
Info on RISKS (comp.risks)
New Massachusetts password law invoked on hospital technician
"Peter G. Neumann" <neumann@csl.sri.com> Wed, 12 Apr 1995 12:49:43 PDTMark 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 <tkolar@cisco.com> Mon, 17 Apr 95 18:31:07 PDTI 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 that: > 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
Fugue-by-Wire!?
James G Henderson <James@prognote.demon.co.uk> Mon, 17 Apr 1995 21:43:05 GMTYou'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! James@prognote.demon.co.uk Program Notes Limited
11 B-boards dismantled in Montreal
"Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com> 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
offenses;
- 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
or
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 <thwong@cs.cornell.edu>
Re: RISKS of patrol-car computers (Story, RISKS-17.06)
Joe Chew <jtchew@netcom.com> 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 car. 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. --Joe
RE: RISKS of patrol-car computers (Story, RISKS-17.06)
Matt Raffel <raffelm@netcom.com> Tue, 18 Apr 1995 14:53:10 -0700The 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. raffelm@netcom.com
"Friendly" user interfaces [ Was: Re: Searching for a book... ]
"C. Titus Brown" <brown@krl.caltech.edu> 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, brown@krl.caltech.edu.
Re: Searching for a book in a database (Kraft, RISKS-17.06)
Jerry Leichter <leichter@lrw.com> Thu, 20 Apr 95 10:40:27 EDTErik 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" interface. 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 <riddle@is.rice.edu> 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: efrank@ncsa.uiuc.edu (Elizabeth Frank) > Date: Tue, 18 Apr 1995 12:54:42 -0500 > To: www-security@ns2.rutgers.edu > 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, > ftp://ftp.ncsa.uiuc.edu/Web/httpd/Unix/ncsa_httpd) > > Unfortunately, hoohoo.ncsa.uiuc.edu (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 http://www.vtls.com/docs/, 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 riddle@rice.edu -- Systems Programmer and RiceInfo Administrator, Rice University
Risks of online catalogs
<shapterd@JSC.MIL> Thu, 20 Apr 1995 11:36:02 -0400Cliff 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 shapterd@jsc.mil | dps@kryten.atinc.com
Computer-controlled electrocution (RISKS-17.06)
David Karr <karr@CS.Cornell.EDU> Tue, 18 Apr 1995 15:19:15 -0400People 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 forces? 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 (karr@cs.cornell.edu)
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 cu@sei.cmu.edu
[Lorrie Orndoff, Administrative Assistant, Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA 15213
Phone 412 / 268-3098 FAX 412 / 268-5758 Internet lao@sei.cmu.edu]
* 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.

Report problems with the web pages to the maintainer