Subject: RISKS DIGEST 17.06

Subject: RISKS DIGEST 17.06
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest Tuesday 18 April 1995 Volume 17 : Issue 06

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, etc. *****

Contents:
Computer crash freezes train traffic (David P. Schneider)
RISKS of patrol-car computers (Glenn Story)
Man arrested via stock-control systems (Timothy Panton)
Barcode provides picture of burglar (Sean Burns)
FDA orders recall of blood bank software (Paul Szabo)
Installing Old Software on New Systems (Bruce E. Wampler)
The state of software engineering (Jerry Leichter)
About the recent Sun "CWS" mailstorm (Mark Graff via David Lesher)
New risks in private digital cash (?)
Overnight Privacy RISKS... (Peter Wayner)
Fry-by-wire? Or just the currents of progress? (Ed Ravin)
Re: "The Satan Bugs" ()
Risks of Library Catalog Keywords (John McHugh)
Re: Searching for a book in a database (Erik Kraft)
Re: Errors in patent databases (Mark Lomas)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

----------------------------------------------------------------------

Date: Thu, 13 Apr 95 12:18:00 PDT
From: [email protected]
Subject: Computer crash freezes train traffic

>From the Orange County Register, Orange County CA, 3/29/1995 edition,
crediting "Register news services":

The article describes in 3 paragraphs the effect on train traffic of a
computer crash: "[it] froze passenger and freight trains in their tracks"
for 2 hours. 8 states in the Southeast US were affected during Monday (3/
27) evening rush hour on tracks operated by CSX Transportation. Service
was restored "under human direction".

Services that were held up included Amtrak (2100 passengers), Tri-Rail
commuters in south Florida (5000 passengers) and freight trains in
locations from Louisiana to North Carolina.

[Notes from dps: Most major railroads have reduced the number of dispatching
centers, in the trend typical of many modern businesses. For instance, UPRR
now operates all dispatching from Omaha, Nebraska, and SPRR from Denver,
Colorado. CSX can be assumed to have done the same type of consolidation.
Key elements of this move include computer displays to show the status of
tracks and traffic flow (replacing specialized "CTC" boards),
communiciations equipment (often already in plade, just a new hop). These
computers often also show the availability of equipment.

Resuming "under human direction" was probably done by the same dispatcher
staff, but using "track warrants" instead of signalling, and with locations
of trains tracked by radio rather than by the signalling equipment. This
would result in slower speeds and larger separations.

I would be interested in hearing more details of the crash and in the
backup procedures.]

/dps (David P. Schneider, Emulex Network Products)

------------------------------

Date: 16 Apr 95 10:40:00 +1700
From: [email protected]
Subject: RISKS of patrol-car computers

There was an article in the Saturday San Francisco Chronicle with the
headline, "Police Hunt Slayer of Oakland School Cop." At first glance this
appears to be yet another sad tale of inner-city violence with no relation
to computer RISKS. However, buried in the middle of the article is the
statement, "The source also said that the slain officer was found sitting in
his patrol vehicle and may have been using his patrol car computer at the
time of the shooting."

Could it be that the visual and mental concentration required to operate a
computer can constitute a potentially fatal distraction for a police
officer?

Glenn Story [email protected] [email protected] [email protected]

------------------------------

Date: Tue, 11 Apr 1995 14:25:53 +0200
From: Timothy Panton <[email protected]>
Subject: Man arrested via stock-control systems

I heard an item on the BBC radio 4 news last week that set me wondering
about stock-control systems. The story described the arrest of an alleged
supermarket blackmailer. He was arrested for planting (fake) bombs in
supermarkets. The reporter went on to say that he had been caught because
the police had been able to trace him as the owner of the shoebox used in
one of the fake bombs.

It seems to me that the police must have traced the stock number on the box
down the distribution chain using the shoemakers computer systems. Once
they determined which shop it was sold from they must have used the shop's
stock control system to determine when it was sold. In order for the police
to determine who bought the shoes (and the box) the arrestee must have used
a means of payment (e.g., credit card) that included his name.

I applaud police actions to catch a blackmailer, and I assume that there is
more evidence against him to support their case. But I can't help wondering
where all those shoeboxes I threw away are now, and who is doing what with
them?

Is there a risk here? It depends on you. If you
a) Trust the police,
b) Trust all the people who work in shops you use,
c) Have nothing to hide,
d) Will never be involved in a case of mistaken identity,
then I guess not.

Tim Panton

------------------------------

Date: Mon, 10 Apr 1995 16:47:12 CST6CDT
From: "Sean Burns" <[email protected]>
Subject: Barcode provides picture of burglar

On Friday, 7 April 1995, KNOW (the St. Paul, Minnesota, National Public
Radio affiliate) reported that a jewelry store in St. Cloud had been
burglarized. In order to circumvent the jewelry store's alarm the thief
first broke into an adjacent florist's shop. He then used a pickaxe to hack
his way through an interior wall into the jewerly store.

He looted the store at his leisure and fled leaving no prints or other
evidence behind--except the pickaxe. A sharp-eyed police officer noticed a
barcode sticker was still attached to the pickaxe. The officer took the
tool to a local hardware store and had the owner scan the code into his
register (the reporter did not say if the officer visited multiple hardware
stores). Voila! The pickaxe had been sold the day before the burglary. By
matching the time of sale as recorded in the register's database to the time
stamp on the store's video-surveillance tapes a clear picture of the
suspected burglar was obtained. At air time he had not yet been
apprehended.

Sean Burns, University of Minnesota/College of Human Ecology, 48 McNeal Hall
1985 Buford Avenue, St. Paul, MN 55108 [email protected] 612.624.3281

------------------------------

Date: Wed, 12 Apr 95 08:29:28 PDT
From: [email protected] (Paul Szabo)
Subject: FDA orders recall of blood bank software

< Abstracted from The Oregonian, 12 Apr 1995, Section B, page 1 >

Computer software used to track blood supplies in about 250 blood banks has
been recalled because of the possibility that it could allow the release of
contaminated blood.

Among the problems with the software:

* Untested blood donated by a person for his or her own use
could be release for general transfusions.

* Blood that should be quarantined while being test could remain
available for use !!if two computer users changed its
status at the same time!! <emphasis added>

* The status of a donor whose blood should not be used,
after being updated, could revert to its former status,
resulting in blood from an ineligible donor being used.

It sounds like inadequate test methods are being used to test the
software, given the classic mistake in the second item above...

The FDA caught the errors in an inspection of Informedics (which
is doing business as Western Star), the Lake Oswego, Oregon company
that produces the software.

John Torici, president of Informedics, said that his company
has about 250 clients in six countries, "and in the 12 years
we've in in the business they've processed literally millions
of units of blood and there has never been an incident of
bad blood being released as a result of our software"

Other countries don't have our tort system that makes everyone
here eager to sue. Is this a good measure of software quality,
given the obvious mistakes made above?

Does the FDA use adequate software testing methods?

Paul Szabo Portland, OR

------------------------------

Date: Wed, 12 Apr 95 13:01:41 MDT
From: [email protected]
Subject: Installing Old Software on New Systems

It can be risky to install old software on newer systems.

Among the many problems Microsoft Windows has it the problem of keeping up
with the latest device drivers. This problem is especially troublesome for
multimedia cards and drivers, which are usually installed in the
\WINDOWS\SYSTEM directory. My own system has mostly 1994 versions of system
software and drivers (but it is still Windows 3.1).

The other day, I was looking for some trivia information about the "Sound of
Music" (did it get an Oscar for best song?), and none of my usual references
had the answer. I did have a copy of Microsoft's Cinemania 1992, which I
haven't used since I got my current machine. So I thought, OK, simple, I'll
just install it to find the answer (No -- best songs are for original
scripts, not adapted -- it did get Best Scoring for Adapted Works).

I got my trivia answer, and things seemed fine, but they weren't. Because
multimedia has always been one of the big problem areas of Windows, and the
1992 Cinemania had some drivers that were "better", it seems that it blindly
took its "latest" 1992 versions and replaced the existing drivers in the
\WINDOWS\SYSTEM directory without taking into account that it might be 1995
now. (It didn't ask for any confirmation - it just overwrote!) So, the next
time I booted my system, my sound was broken. It took me a couple of hours
to diagnose the problem and get the current drivers reinstalled, and I know
what I'm doing -- pity the poor new or casual user.

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!

Bruce E. Wampler, Ph.D. ([email protected])
Adjunct Professor, Department of Computer Science, University of New Mexico

------------------------------

Date: Fri, 14 Apr 95 08:47:55 EDT
From: Jerry Leichter <[email protected]>
Subject: The state of software engineering

The following was forwarded to me through a mailing list, and I can't even
determine with certainty if the signature line at the end is from the author
or some intermediate forwarder.

The story is worth the telling, however.
-- Jerry

Subject: Good software humor: What would you do?

At a software engineering course for aspiring managers the
participants are asked: If your team of programmers/analysts
implemented airplane control software, and you were flying one day,
finding out before take-off that this plane was one of those equipped
with YOUR software, how many of you would get out?

All except one person raised their hands. The course instructor asked
the only one to have left his hand down "What would you do?"

"Stay in my seat -- if my team wrote the software for this plane, it
wouldn't move, let alone take off."

Rick Simkin [email protected] PHONE: +1 312 2664437
Frame Technology, Advanced Products Services, Chicago

------------------------------

Date: Mon, 10 Apr 1995 20:30:36 -0400 (EDT)
From: [email protected] (David Lesher)
Subject: Here's a classic...

Date: 10 Apr 1995 20:49:58 GMT
From: [email protected] ( Mark Graff )
Newsgroups: comp.security.unix
Subject: About the recent Sun "CWS" mailstorm

Last week a great many Sun customers were subjected to a torrent of mail
messages which swamped the Customer Warning Mailing list. Since quite a few
of those folks also read this newsgroup, I thought I would post this apology
and explanation here.

First, quickly, the current status is:

1. The "cws" mail alias is once again disabled. The mail cascade is over.
2. All requests to be added to or removed from the list have been logged
and will be executed before we send out the next bulletin.
3. We have reviewed the procedural errors which led to the flood of
messages and taken the steps necessary to prevent a repetition.

Now, here is a partial explanation of what happened.

I maintain a mailing list of people interested in receiving Sun Security
Bulletins. The list has thousands of addresses on it, some of which are
themselves repeater aliases. When I am ready to send out a security
bulletin, I (1) produce a mail alias from the mailing list, (2) active the
mail alias on my machine, (3) send the mail, and (4) deactivate the alias.

The deactivation step is important. It prevents mailstorms and stops
malefactors from probing my machine in an SMTP dialog to obtain a list of
bulletin recipients. This step was omitted when we sent out our bulletins
last week; so, when a recipient replied, asking to be removed from the
list--and cc'ed the "[email protected]" alias--the fuse was lit. When
others sent responses to that request to the same mailing list, the
mailstorm was launched.

In a second procedural error, the next day, no one who could deactivate the
list was watching the traffic. So what would have been an annoyance turned
into a real donnybrook. Of course as soon as the right people got the right
message the alias was deactivated, stopping the cascade of messages.

The problem was exacerbated by the fact that (appearances to the contrary) I
handle list requests manually, as a security measure. One correspondent, not
aware of this, sent several dozen "unsubscribe me" messages to the entire
list in an attempt to escape the cascade. This resulted in the creation of
thousands of additional messages.

I am responsible, and will apologize personally to as many customers as I
can. In the meantime, please understand that this was the result of human
errors and a good measure of bad luck--not a bad policy, or a lack of
interest on our part.

I would also like to express my thanks to the many people who, unaware of
the exact nature of the problem, suggested technical solutions. As of this
moment I am not planning any changes in the handling of the mailing list,
which we operated with no problems for several years before the incident
last week. We are of course reviewing alternatives.

-mg- Mark Graff Sun Security Coordinator
[email protected] [email protected] 415-688-9151

p.s. Please correspond with me directly for any further information.

------------------------------

Date: Mon, 10 Apr 1995 19:17:46 -0400 (EDT)
From: [email protected]
Subject: New risks in private digital cash

While writing an article about digital cash, a number of new risks occurred
to me. If truly safe, secure, and private digital cash can be created,
legitimate businesses will not be the only originations to avoid the
problems of transporting large amounts of cash. The classic suitcases full
of cash will be replaced by a smart card or credit transfer that will look
just like any other. To transfer a few million to an offshore bank, you
just make a call. For additional security, multiple transactions might be
sent from pay phones, cellular phones, and/or sent through an ever changing
list of dummy corporations, forwarded phones, etc. The information could be
hidden in legitimate data transfers, or just carried. After all, one smart
card will look just like any other, no matter how much money is inside. Or
the guts could be removed from the card and hidden nearly anywhere. Spies,
etc. will love this new money.

This particular risk will depend to some extent on just how private digital
cash becomes. If it is really an advanced debit card system with
encryption, privacy will depend on the ability to get a card without
supplying large amounts of personal information. If ID is required only the
criminals will have privacy. After all they don't mind lying, don't have
fixed addresses, and the risks are minor compared to those they normally
face. If the card or account numbers are tracked to deal with theft, fraud,
etc., then they will be available to the IRS etc. Of course this information
will only be available to the "proper" authorities ... and anyone who knows
who to bribe. Also since the cards or what ever, will inevitably have an
account number, public key, or other identifier, it won't be long before
someone starts connecting paid for by account xxxx and sent to address yyy,
and there goes privacy.

On the other hand, people are ingenious, and many will be highly motivated.
Black market cards and/or accounts will exist. The listed owners might even
be real, illegal aliens, little old ladies with nothing to lose, or totally
fictitious. When the cards or accounts become international, whole new
worlds of villainy open up.

The very definition of a bank may change. Most banking is already an
exercise in data processing. Without the need for a vault and tellers, the
whole thing might be run from an advanced laptop. The notion of offshore
banks might take on a new meaning, when the bank might be mobile, or
distributed over large distances and many jurisdictions.

New, unforeseen risks are also inevitable. When paper money replaced
coinage, inflation became almost inevitable. Not that many kingdoms or
countries could long resist adulterating the coinage, but I know of no paper
money that hasn't suffered inflation. One possible example of the new risks
involves check float. Entire industries exist to exploit the time between a
check being issued and when it clears. What happens when float, and checks,
go the way of the Dodo? What happens to the Swiss banking industry if
numbered accounts are no longer necessary? What happens to the IRS if
everybody effectively has a numbered account?

[Name not included in E-mail. PGN]

------------------------------

Date: Tue, 11 Apr 1995 20:55:08 -0400
From: [email protected] (Peter Wayner)
Subject: Overnight Privacy RISKS...

A common theme in this forum is how computers can create dismay out of
order. For instance, I've always considered FedEx to be far superior to the
Post Office because you their computer system tracks the packages to the
correct destination. Today's WSJ (April 11, 1995, B1) offers a story
describing how lawyers routinely subpoena FedEx for these same computerized
shipping records. The article mentions a tobacco researcher who had his
FedEx shipments subpoenaed by a tobacco company interested in his
correspondence.

Being a curious and frequent customer of Federal Express, I called up their
legal department to find out if anyone had been subpoenaing my shipping
records. This seemed to upset them because they get 300-500 subpoenas a day
and their data base just wasn't set up to look for my name. They did tell me
that they can only offer proof of delivery and copies of the airbills
generated from microfiche. These do not arrive overnight, however, because
it takes them 2-6 weeks to process each court order. Oh, they did mention in
passing that they don't keep any records of cash transactions.

------------------------------

Date: Sun, 9 Apr 1995 23:46:04 -0400
From: Ed Ravin <[email protected]>
Subject: Fry-by-wire? Or just the currents of progress? (Re: Wilson, 17.04)

> Throughout the execution, the computer's systems monitor the current,
> making sure there is no drop in power.

I am aghast -- it sounds just like the technology used in ground-fault
interruptors, those nifty gadgets that turn off the current if you you drop
a plugged-in appliance into the tub with you. But instead, this system
keeps the current on until its victim has shunted a sufficiently lethal
dose.

I suppose the lesson is that one person will always find a way to use a
technology for the exact opposite purpose that another person was designing
it for. And I suppose that computer programmers and electricians have
already build lots of systems that have already intentionally killed more
people than this electric-chair-controller will ever get a chance to do.
But dammit, is this what folks had in mind back when they were inventing
embedded controller systems, analog-to-digital converters,
silicon-controlled rectifiers and the other doodads that this execution
system must use?

Ed Ravin [email protected] +1-212-678-5545

------------------------------

Date: Tue, 17 Apr 95 10:00 xxT
From: [Another anonymized responder]
Subject: Re: "The Satan Bugs" (RISKS-17.04)

A previous anonymous poster [in RISKS-17.04] took some heat by calling the
authors of the "Satan" security software "amoral". While that point may be
arguable, how about another term that is harder to argue: "inept", or
perhaps "sloppy"?

Since the original much-heralded release of Satan, CERT has had to send out
two bulletins warning of serious bugs in the original version, and in the
succeeding version that was supposed to fix the bugs in the first version.
In each case, the bugs were of the sort that INTRODUCED security holes where
none had existed before. And of course each new version checks to see if it
can exploit the security bugs introduced by the previous version--so if you
ever stop updating you're really in for a surprise!

It doesn't even appear that the bugs were terribly obscure--it looks more
like a rush job with inadequate testing.

Great security software. If you had a secure system before starting to work
with Satan, you can end up with an insecure system afterwards. It's
difficult to think of a much less desirable scenario.

Such sloppiness in widely distributed software that is supposed to help
solve important security problems is hard to rationalize, to put things
politely.

------------------------------

Date: Sat, 8 Apr 1995 12:29:49 -0700
From: [email protected] (John McHugh)
Subject: Risks of Library Catalog Keywords

The recent discussions of typos in databases, etc. remind me of a problem
that I have noticed with the on line catalog for the library at Portland
State University. Shortly before I started my Computer Security class last
year, I decided to check the library's holdings in the area by using the on
line catalog. I was somewhat surprised when a subject search using the
subject "computer security" turned up very little. Not even Dorothy
Denning's classic book was found. Looking up a few books by author or title
and checking the index terms indicated that the appropriate search is
"access control." There does not seem to be a way to reindex entries or to
add cross references. One wonders how many searches go awry because of
counter intuitive search terms.

PSU's catalog system has another interesting "feature." It is impossible to
get out of the system. It was apparently designed for dedicated terminals
where the notion of termination or disconnection was considered
inappropriate and when you connect to it via telnet you must escape to
telnet and close the connection when you are done.

John McHugh

------------------------------

Date: Sat, 8 Apr 1995 04:29:05 -0700 (PDT)
From: [email protected] (Erik Kraft)
Subject: Searching for a book in a database (Leichter, RISKS 17.05)

Jerry Leichter had a problem finding a book which he did not know the exact
author or title. His story shows that a human can perform pattern searching
faster then a computer to find the book, but this isn't always the case.
The problem with the computer was poor database retrieval.

I had a similar experience years ago at a library looking for a book I had
seen for a few moments, but had forgotten the author, title, and catalog
number. However, I remembered the first letter of the author's last name
and the general subject. When I used the "friendly" public machines at the
library to search for the book, I had no luck. Rather than scan books in the
relevant section of the library, I went to the computer services department
and talked to a friend in the library's computer department.

By accessing the database through a "computerese" interface, I was able to
search the entire database for books within a section of the library (by a
range of Library of Congress numbers), first letter of the author's last
name, and three possible subject keywords.

The computer found two entries matching my request; one was my book.

Risks? The "friendly" interface, while increasing general use among the
public, lacks the power of a "computerese" interface. The users'
perceptions about the power and ease-of-use of computers and databases
become clouded because of an attempt to show them the power of same.

erik kraft NeXT programmer / 3do programmer [email protected]

------------------------------

Date: Wed, 12 Apr 1995 17:19:22 +0100
From: [email protected]
Subject: re: Errors in patent databases (Leichter, RISKS-17.05)

Even if you do have the correct information at hand, you are relying upon
the competence of the database designer.

A few days ago I tried to order a book. I knew the names of both the authors,
the title of the book, and the publisher. The only information I was lacking
was the ISBN.

"No problem" I thought, since most of the bookshops here in Cambridge now
have access to an online catalogue of all books on sale in the UK.

The shop assistant typed in the correct query (here I should explain that it
wasn't her fault since, by looking over her shoulder, I could see that she
typed everything correctly). The computer said that there were no matching
entries. She then tried widening the search by missing out some of the
information.

Even when asked for all books written by either author the system claimed
that nothing existed. Since I was certain of the publisher she agreed to
phone them. They claimed it didn't exist, although I knew it did since I
had reviewed it for a journal. They then found that their paper list didn't
correspond to the computer list - it was listed on paper. Given the ISBN we
checked again on the bookshop's system. Sure enough, there was the book
with all of the details as I had given them.

The book is now on order. However, if we hadn't persisted, the bookshop,
and the publisher, and the authors, would have lost a sale.

Failure to order a book may seem an unimportant problem, but it made both me
and colleagues wonder how many relational databases aren't, and what are the
consequences.

Mark

------------------------------

Date: 24 March 1995 (LAST-MODIFIED)
From: [email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.

SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S.
users on .mil or .gov domains should contact <[email protected]>
(Dennis Rears <[email protected]>). UK subscribers please contact
<[email protected]>. Local redistribution services are
provided at many other sites as well. Check FIRST with your local system or
netnews wizards. If that does not work, THEN please send requests to
<[email protected]> (which is not yet automated). SUBJECT: SUBSCRIBE
or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent]

CONTRIBUTIONS: to [email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them. Contributions will not be ACKed; the load is
too great. **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks. Anonymized mail is not accepted.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.

RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html
(Please report any format errors to [email protected])

RISKS ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.
Issue J of volume 17 is in that directory: "get risks-17.J<CR>". For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 16, J always TWO
digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>" I and J are dummy variables here. REMEMBER,
Unix is case sensitive; file names are lower-case only. <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and
password. Also ftp [email protected]. WAIS repository exists at
server.wais.com [192.216.46.98], with DB=RISK (E-mail [email protected] for info)
or visit the web wais URL http://www.wais.com/ .
Management Analytics Searcher Services (1st item) under http://all.net:8080/
also contains RISKS search services, courtesy of Fred Cohen. Use wisely.

------------------------------

End of RISKS-FORUM Digest 17.06
************************