The RISKS Digest
Volume 12 Issue 18

Tuesday, 27th August 1991

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

13 Aug 91 NY Nine Mile Point 2 Nuclear Plant Incident Reassessed
PGN
Risks to Computers from Coup Attempt
Aldis Ozols
Oil Firm Surveys for Data and a Data Interchange Format
John F Stoffel
Ada beats C++ according to the DoD
John F Stoffel
Unwarranted equivalence assumptions
Andrew Koenig
Study Recommends Earthquake Warning Network
Fernando Pereira
Re: Firefighters won't give first aid to AIDS patients
Tim Oldham
Re: Cracker charged in Australia
Richard A. O'Keefe
FAA seems misled (Re: TCAS Sees Ghosts)
Richard Johnson
Risks of CDROM publishing
Donald M. Craig
The RISKS of a national computerized entertainment ticketing network
Steve McDowell
New List: C+HEALTH (Computers and Health)
Judy Smith
Info on RISKS (comp.risks)

13 Aug 91 NY Nine Mile Point 2 Nuclear Plant Incident Reassessed

Peter G. Neumann <neumann@csl.sri.com>
Tue, 27 Aug 91 10:47:07 PDT
An AP item today, datelined WASHINGTON, noted that Federal investigators are
still trying to determine why backup systems failed at the Nine Mile Point 2
nuclear power plant in upstate New York during the 13 Aug 91 blackout, after a
25,000-volt transformer blacked out.  Cutover to the "uninterruptible power"
system's standby batteries failed.  ``The team issued a preliminary "sequence
of events" late last week, which indicated that many more systems had failed
than originally reported.''  Furthermore, the plant actually went into "scram"
(emergency shutdown), despite earlier reports to the contrary.  The plant
operators had apparently not known this at the time, because of the lack of
backup power.  The feedwater control, radio and public address system, computer
systems, and some lighting failed.  (The NRC team leader, Michael Jordan, was
quoted as saying, "Most of it was monitoring systems.  All the ones that failed
were not safety related.")

          [Good thing Jordan was not in Chicago, or there might have been
          suspicions of his having something to do with the Bulls...  PGN]


Risks to Computers from Coup Attempt

<peg!aldis@igc.org>
Sat, 24 Aug 91 16:41:57 PDT
>From Aldis Ozols, Sydney, Australia.
During the abortive Soviet coup, several data communications links remained
open.  Not all computer users were fortunate, however, as the following report
from Leningrad attests:

>NorthWest  northwest.news 6:49 pm  Aug 19, 1991
>(at p2013.f20.n490.z2.Fidonet.Org)(From News system)
>
>LENINGRAD-MOSCOW, August 19 /"NORTH-WEST" Information Agency/
> [coup progress news deleted]
>
> All fax-machines and computers at publishing houses of democratic newspapers
> "Smena" and "Nevskoye Vremya" were burnt by strong electric impulses.

            [Beware of opening (electric) charge account, and must not
            buy on impulse!  A truly shocking story.  But we now have the
            inevitability of life, death, and faxes--which transcend all
            sorts of would-be barriers, as long as they don't get fried.  PGN]


Oil Firm Surveys for Data and a Data Interchange Format

John F Stoffel <john@wpi.WPI.EDU>
Tue, 27 Aug 91 02:02:49 EST
Conoco Inc. wants to redesign the way it keeps track of names and address by
consolidating scores of files into one global name and address system. The
problem is, it does not know how to do it. In a unique approach, the $2
billion, Houston Texas based oil and gass subsidiary of E.I. du Pont de Nemours
& Co. Inc. sent out a survey to the top 108 companies on the Fortune 500 and a
majority of its competitors to garner input on whether they have ever attempted
a similar records consolidation and what suggestions they could make.  In the
survey, Conoco also asks if some of its systems personnel can visit the
corporation's sites. The project is being administered by Conoco's accounting
systems group and the Conoco Information Systems group in Ponca City Okla. So
far, the response rate has been excellent, according to Walt Drawl training
director of the accounting system group. After sending out the surveys on June
28, Conoco has received 35 responses - including some from competitors.  "We've
been getting some good information on EDI," says Drawl. Once of Conoco's
biggest concerns in file consolidation and information exchange is maintaining
data security. "Network security is one of the those monsters out there we have
to be very careful of," says Drawl. Drawl and his associates plan to release
their findings by the end of August and present them to Conoco management.

{InformationWeek July 29, 1991}


Ada beats C++ according to the DoD

John F Stoffel <john@wpi.WPI.EDU>
Tue, 27 Aug 91 01:59:58 EST
I got this from VNS (The Vogon News Service) an internal news feed from Digital
for British people working in the US.  I thought this article tied in very
nicely with the New Jersey bill trying to license programmers.  Mostly in the
way they compile and use statistics which are pretty meaningless, or do not
give enough of a break down on what kind of errors they are.

          [In general I think VOGON has no objections to reuse.  However,
          John, next time please leave their HEADERS intact...  PGN]

{ComputerWorld July 29, 1991}

                            Ada Bests C++

The US Department of Defense has released the results of four recent studies
showing that the DoD mandated programming language Ada is superior in a variety
of ways to its newer rival C++. The studies showed that "there is no compelling
reason to waive the Ada requirement [in favor of] C++", the Pentagon said.

A fifth study went beyond a look at the third generation, object oriented
languages and said the use of fourth generation languages with good development
environments and methods can boost software productivity by a factor of 10.

The studies generally found that Ada is more mature than C++, is more
standardized, is supported by more vendors and is accompanied by a richer set
of development tools. A TRW Inc. study said that Ada is about three years ahead
of C++. TRW found that Ada now offered a 35% cost advantage in development and
a 70% in maintenance over C++.  After 1994, TRW said, those figures may erode
to 10% and 30%.  However, TRW said C++ rated better than Ada in compilation and
runtime efficiency and support of object oriented design.

Carnegie Mellon University's Software Engineering Institute used a language
evaluation methodology developed by IBM in the mid-1980s and concluded that Ada
was 23% better than C++ in six categories.

CTA Inc. looked at the productivity of the two languages based on actual
projects and found Ada programmers on average produced 210 source lines per
month while C++ programmers turned out 187 lines.
      

Unwarranted equivalence assumptions

<ark@research.att.com>
Tue, 27 Aug 91 10:34:25 EDT
What do the following statements have in common?

    `We don't want any illegal drug users in our company,
     so we won't hire anyone who doesn't pass a drug test.'

    `We can't give you that loan; your credit report shows
     a poor payment history on one of your credit cards.'

    `We want to make sure airplanes that enter the country
     do so legally, so we will only allow airplanes to clear
     Customs if they have their original certificates of
     registration with them.'

    `I'm sorry, Sir; but even if you are indeed the Ambassador, we
     can't let you into the Embassy building without a proper pass.'

The obvious similarity is that they would all be supremely frustrating,
especially if made inappropriately.  Behind that, though, is that each one is
the result of a system that assumes that two things are equivalent even when
they sometimes aren't.

Not everyone who fails a drug test is a user of illegal drugs; the test might
be in error or, as happened not too long ago, the lab might have deliberately
fudged the results so that its statistics would look better.

Not everyone who turns up with a bad credit report has a reason for it;
sometimes the negative history actually belongs to, say, someone else with the
same name.

Not every airplane without an official registration certificate is illegal;
perhaps its present owner bought it only recently and is waiting for the
permanent registration certificate to arrive from the FAA (which can take many
months).

Perhaps the Ambassador was appointed only a week ago, has been outside the
country since then, and therefore hasn't had the opportunity to pick up the
pass that has been waiting for him.

All four of these examples are based on real events; all four point up an error
that is made all too often by people who should really know better.  They
reemphasize something that everyone knows who has been working with software
for any length of time: it's practically impossible to keep two separate
databases in step for any length of time.  That's true even when one of the
`databases' is reality itself.
                        --Andrew Koenig        ark@europa.att.com


Study Recommends Earthquake Warning Network (AP)

Fernando Pereira <pereira@klee.research.att.com>
Tue, 27 Aug 91 18:08:08 EDT
AP Science writer Paul Recer reports that a committee of the National Research
Council recommended the creation of automatic earthquake warning networks for
highly seismic areas. The network would take advantage of the fact that the
primary (P) wave train from an earthquake moves faster but is less destructive
than the secondary (S) wave train, and can therefore be used as the trigger for
an automated alarm system. Even relatively close to the epicenter, P waves
precede S waves by a few seconds.  Such a system could be used to lower fire
risks by shutting down natural gas and power distribution networks, to protect
computer systems by retracting disk heads, to start a controlled shut down of
factory processes, to divert aircraft, etc.  Well trained people could also
take advantage of the warning to seek shelter.

Even with the risk of false alarms that could cause blackouts and damage, the
committee recommended that such a system should be automatic to achieve the
required fast response. The system would involve a network of sensors connected
by microwave or satellite to a central computer system.

I guess we need a new Emacs function save-all-buffers-on-quake...  More
seriously, this poses all sorts of interesting RISKs issues. Does anyone know
how reliable such a system might be? I assume it would use some form of
spaciotemporal cross-correlation to discriminate real quakes from sensor
malfunction or local disturbances (big truck going by?) Are there results
relating density of sensors, network topology and probability of sensor or link
malfunction to probability of false alarm? What are the legal implications of
"alarmist" versus "conservative" decision rules?

Fernando Pereira, 2D-447, AT&T Bell Laboratories, 600 Mountain Ave,
Murray Hill, NJ 07974


Re: Firefighters won't give first aid to AIDS patients (RISKS-12.12)

Tim Oldham <tjo@its.bt.co.uk>
Tue, 13 Aug 91 14:31:23 BST
This is also the case in Britain. A piece on the (National) Radio 4 news
programme ``Today'' broadcast today 13th August described how the Police
National Computer (PNC) stores information relating to *suspected* contagious
diseases, including AIDS. This information is shown in the form of a warning
when a look-up is done. According to ``Today'', the source of the information
is never medical files but prison authorities and ``other sources'' (presumably
hearsay sources).

An example of a woman whose record showed that she had AIDS (presumably HIV, in
actual fact) when she did not was quoted. In order for her record to be
corrected she had to undergo an HIV test. The woman stated that she had been
ostracised by her friends and community because the police had displayed a
photograph of her with the word ``AIDS'' above it in the local police station.
I'm not clear whether the computer record or the photograph came first, but
there is certainly every possibility that police units will create incorrect
records and others will use these records to discriminate against people. The
police have ``apologised'' to the victim in this case.  No other compensation
seems to have been offered and it appears that she is not suing.

A police spokesman stated that such records were used to ensure that the police
take appropriate precautions when dealing with someone whose record showed that
they had a contagious disease. By law, the records should be available,
although there a number of police get-out clauses to allow them to refuse to
reveal parts of their computer records.
                                       Tim Oldham, BT Group Computing Services


Re: Cracker charged in Australia (RISKS-12.13)

Richard A. O'Keefe <ok@goanna.cs.rmit.OZ.AU>
22 Aug 91 05:16:05 GMT
Fernando Pereira cites an AP report on Nashon Evan-Chaim.  Since I know Nashon
(he was in one of my classes here last year), I thought I'd put in a word on
his behalf.  If there is such a thing as ``innocent cracking'', where someone
goes around logging into computers all round the world without any malicious
intent, for the sheer joy of exercising an admittedly reprehensible skill, then
in my opinion this is an example of it.  Based on my conversations with him, he
has exactly the kind of knowledge about security holes that you would expect a
bright CS undergraduate who isn't afraid of reading manuals to work out.  The
particular part of the quote which caught my attention was:

> Execucom Systems Corp. of Austin, Texas, where it is alleged he destroyed
> important files, including the only inventory of the company's assets.

I don't know Nashon _very_ well, but I've spoken with him quite a few
times, and it would be completely inconsistent with his character as I
know it for him to have done anything like this deliberately.  Nashon
isn't an anti-social "loner", he is quite a helpful person.  I would be
very surprised and disappointed if this charge turned out to be true.
(What company would not have a backup of their inventory, plus the paper
audit trail to bring it up to date?)

Although I do not believe Nashon guilty of any malicious intent, that is
not to say that I approve of entering systems which don't display a
``Welcome'' message for visitors.


FAA seems misled (Re: TCAS Sees Ghosts)

Richard Johnson <richard@oresoft.com>
Mon, 26 Aug 91 13:51:39 PDT
A little correction to the comments made by the FAA in Jim Horning's excerpt
from "IEEE Spectrum: TCAS Sees Ghosts"..  (By the way, thanks, Jim.)

  ...
: The FAA emphasized that the software fault did not pose a hazard.  TCAS is
: a backup system; primary responsibility for avoiding midair collisions still
: remains with the ground-based air traffic control systems.

Not quite.  TCAS is a backup system. It's a redundant backup.  Primary
responsibility for "see and avoid" is with the pilot (FAR part 91).  The air
traffic control system, with all it's eyes, ears, and radar exists to help the
pilot avoid situations that can develop into genuine emergencies.

The concept of TCAS is to give back to the pilot some of the ability to "see
and avoid" that goes with the responsibility, in an era where huge aircraft can
be atop you before you see them.  It puts an electronic eye in the cockpit with
the pilot; something to help the pilot, rather than air traffic control.

Of course, the FAA has maintained since around 1946 or so that the ONLY
effective way to maintain safe skies is through control from the ground, rather
than from the cockpit. Draw your own conclusions.  Because of this, in some
ways, TCAS and air traffic control are at crossed purposes.  TCAS gives
authority to the pilot, and ATC takes it away.

It is important to remember, that as much as the FAA likes to calm people's
fears by telling them that ATC is in "control", the rules put the pilot in the
hot seat.  The total and ultimate safety of every flight is the job of the
pilot first.  Everything else is advice.

And there are some interesting failure modes that I hope "experts" have looked
into already (faulty or missing messages, failure to notify ATC, etc.)

Richard Johnson richard@oresoft.com richard@agora.rain.com


Risks of CDROM publishing

"Donald M. Craig" <dmc@taupe.tv.tek.com>
Tue, 27 Aug 1991 15:00:50 -0700
Last weekend, interested in trying out a SparcStation draw program, I inserted
a recently arrived SUN Catalyst CDWare disk, Volume 1, in my CDROM drive and
attempted to mount it.  No luck.  After some mucking about, the disk mounted
when I specified High Sierra file format.  But none of the advertised browsers
or programs were to be seen - instead there were a number of very large MSDOS
format files.  Inside a text file, I found:

"Dear OncoDisc Customer,
Congratulations on your subscription to OncoDisc, the cancer information
service on CD-ROM!  You have chosen a unique information service that
will provide you with immediate and unlimited access to the key sources
in oncology.  We at Lippincott are pleased to have you as a new subscriber
and are sure you will find using OncoDisc very exciting and worthwhile."

The disk had Sun Microsystems Catalyst printing on the front, and the
silver lettered text on the back said: MADE BY 3M USA CR14614A 910213

My conclusion from this is that some low probability process at 3M's
CDROM pressing(?) plant permutes disk labels and contents - and that
somewhere there is an unhappy Lippincott customer.

Sigh.  Not only a computer risk, but another cancer risk as well.

Don Craig   dmc@tv.tv.tek.com
Tektronix Television Division


The RISKS of a national computerized entertainment ticketing network

Steve McDowell <mcdowell@exlog.com>
Mon, 26 Aug 91 14:06:38 CDT
Re: KJPhelan@SUNRISE.ACS.SYR.EDU, RISKS-12.15

     Back in 1985 I worked for the Ticketmaster Corporation on the then
latest-and-greatest ticket selling software. At that time, everything was done
on PDP-11's running in a fault-tolerent configuration under a Ticketmaster
proprietary operating system (a risk in it's own right).  Each data center was
then linked via leased lines into a centralized database.  I understand that
they have ported their operating system now to the VAX architecture.

     Extreme consideration was given to eliminating the risks of minimum waged
ticket sellers turning an unethical profit. They had a command set of about six
commands, most of which delt with whether the customer was paying cash or
credit. The system would generate audit reports and automatically check the
arenea map against tickets sold and the cash reported for each location each
night. If there was a discrepancy or if an unusually large number of tickets
were sold for a particular location, then the system would generate an alarm on
that location. The promoter for each event also recieved daily activity reports
from the system.

     The weak link in this system, as in all systems, is the human element.
Though it was very hard to make the computer do something that it was
programmed to believe to be unethical, things could be done. The seller could
"forget" to program returned tickets, for instance. For the most part, however,
very little trouble came from the low paid, low techno-savey, ticketsellers.

     The big risk exists in trusted accounts on the system. It could be fooled,
but only by someone with direct access. There was a general manager for
Ticketmaster in a rather large urban area who had a cocaine habit. He would
trade tickets for drugs. He would come in at three in the morning, after the
night operaters had run their nightly audit procedure, bring the system up
thinking it was some absurd date, sell himself fifty or one hundred tickets,
then run the nightly audit reports again, ignoring the alarms generated. He
could tell the computer that the seats he sold himself were available, but to
not sell them to any outlet. This went on for about three years before he was
caught by the night operators who were just trying to learn what made the
PDP-11's tick!

    The bottom line is that there is a risk, but not a risk any greater than
that of, say, the American Airlines ticket reservation system. Abuses of power
happen; very little can deter a super-user from doing what he wants to do.
Managers simply have to read the audit reports, not just file them. The
computer should do self-audits, as the Ticketmaster system does. Care should be
taken, and in the case of Ticketmaster it is.
                                                       Steve McDowell


New List: C+HEALTH (Computers and Health)

"Judy Smith" <smithj@a1.relay.upenn.edu>
Tue, 13 Aug 91 10:24:01 -0400
   [Sorry for those of you on BITNET who get two copies.  Judy double posted.]

This list is intended to promote sharing of information, experiences, concerns,
and advice about computers and health. Anecdotal evidence, media reports, and
some formal studies suggest that computer users are at risk from misuse and
overuse of computers. Eyestrain, headache, carpal tunnel syndrome, and other
apparently computer-related maladies are increasing.  And, it would appear that
colleges, universities, and other institutions have been slow to respond with
education, training, office and lab design, furniture purchasing, and other
programs that could make computing more healthful — and productive.

We welcome questions and answers; article and book reviews; hardware,
software, and furniture evaluations; approaches to influencing
institutional policy; speculation; and humor. Medical, legal, technical,
financial, aesthetic, and administrative viewpoints are encouraged. We hope
that this forum will be of interest to end users, computing managers,
epidemiologists, and policymakers.

Subscribers to this list may also wish to participate in EDUCOM's Project EASI:
Equal Access to Software for Instruction, "dedicated to assisting higher
education in developing computer support services for people with
disabilities." EASI provides information and guidance on campus applications of
adaptive computer technology. For information on EASI, contact Carmela
Castorina, CSMICLC@UCLAMVS.BITNET.

In general, C+Health will focus on individual and institutional measures for
"keeping healthy people healthy" as well as remedies for restoring temporarily
disabled people to health. We suggest that computing issues related to those
with permanent disabilities be referred to our dedicated colleagues at EASI.
Although this distinction will not always be "easy," one goal of C+Health is to
minimize the number of casualties in our increasingly computer-intensive
campuses, offices, and homes.

This list will not be moderated, at least initially, so we encourage
contributors to be succinct, to include relevant parts of messages to which
they are responding, and to append their names, titles, and institutions to
contributions. New users are welcome to send to the list a brief statement of
their experiences and interests in this topic. Unless stated otherwise, it will
be assumed that contributions represent individual opinion rather than
institutional policy.

As list owners, we look forward to your contributions to C+Health,

Judy Smith, Data Analyst, Office of Data Administration and Information
Resource Planning, University of Pennsylvania; SmithJ@a1.relay.upenn.edu.

Kimberly Updegrove, Lecturer, School of Nursing, University of
Pennsylvania; kimu@dairp.upenn.edu.

       **********************************************************
            On-line references on Computing and Health:

The following articles from campus computing newsletters are recommended for
those interested in issues of ergonomics, radiation, light and glare, work
habits and exercise, and related issues and protective measures.  Articles can
be retrieved by sending a GET FILENAME FILETYPE command to LISTSERV@BITNIC (not
IUBVM), where FILENAME FILETYPE are shown below in CAPITAL LETTERS.

COMPHEAL  DUBEY_J    Computers & Health  (Reed College; 3/91; 520 lines)
COMPHEAL  UPDEGR_D   Computers & Health: Issues & Protective Measures
                     (U of Pennsylvania; 1/91; 262 lines)
CTS       SHEEHAN_M  Carpal Tunnel Syndrome  (Indiana U; 11/90; 212 lines)
ERGONOM   UPDEGR_D   Computers Don't Belong on Desktops  (U of
                     Pennsylvania;
                     11/90; 90 lines)
ERGO      BALKITS    Workstation design  (UC Davis; 8/88; 64 lines)
PAIN      BRADLE_J   Computing Pains  (U of Houston; 3/89; 135 lines)
SFVDTLAW  UPDEGR_D   San Francisco VDT Safety Ordinance  (1/91; 146 lines)
VDT       SHEEHA_M   VDT Health Risks  (Indiana U; 11/90; 137 lines)

Thanks to Wendy Rickard-Bollentin of EDUCOM for maintaining the articles
archive of CCNEWS, from which these articles were selected.

       **********************************************************
                      Hints for using LISTSERV:

To send a message to all subscribers, address it to C+HEALTH@IUBVM (from
BITNET sites) or to C+HEALTH@IUBVM.UCS.INDIANA.EDU (from Internet sites).

For all "list management" commands below, send mail or messages to
LISTSERV@IUBVM (from BITNET sites) or (from Internet sites) mail to
LISTSERV@IUBVM.UCS.INDIANA.EDU. Do not send LISTSERV commands to C+HEALTH,
since they will be distributed to all subscribers

* To leave the list, send command, SIGNOFF C+HEALTH

* The amount of acknowledgement you receive upon completion of a mailing
operation can be changed by means of a SET C+HEALTH OPTION command, where
"option" may be either ACK (mail acknowledgement), MSGACK (interactive messages
only) or NOACK.

* Contributions sent to this list are automatically archived. You can obtain a
list of the available archive files by sending an INDEX C+HEALTH command. These
files can then be retrieved by means of a GET C+HEALTH FILETYPE command (where
"filetype" is the name following C+HEALTH in the file list) or by using the
database search facilities of LISTSERV. Send an INFO DATABASE command for more
information on the latter.

* It is presently possible for other people to determine that you are signed up
to the list through the use of the REVIEW command, which returns the network
address and name of all the subscribers. If you do not wish your name to be
available to others in this fashion, issue a SET C+HEALTH CONCEAL command.

* More information on LISTSERV commands can be found in the "General Intro-
duction guide," which you can retrieve by sending an INFO GENINTRO command.

Please report problems with the web pages to the maintainer

x
Top