The RISKS Digest
Volume 10 Issue 10

Tuesday, 19th June 1990

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

Risks of using commercial on-line fulltext databases
Peter D. Junger
canopus.stanford.edu goes nova
Joe Dellinger
Re: UK Hacker Goes To Jail
Pete Mellor
Air India votes no confidence in A320
Andrew Klossner
A320 near-disaster
Gregory Travis via Robert Dorsett
RISKS of computers in medical offices
Arthur L. Rubin
More Space Telescope Problems
Karl Lehenbauer
Invisibly long lines
Wilson H. Bent
Jr.
Water problems
Gene Spafford
Info on RISKS (comp.risks)

Risks of using commercial on-line fulltext databases

<junger@cwru.cwru.edu>
16 Jun 90 14:43:00 EST
        Nearly twenty years ago a full text electronic database of legal
opinions named OBAR was released upon the world.  Each word (except for common
ones like `the' or 'is') in each opinion included in the database was placed in
an inverse file with a pointer to where that word appeared in the database.
This allowed for rapid on-line boolean searching for cases containing certain
specified terms.  Thus a search for "cat and (dog or hound)" would produce a
list of all opinions in the database in which the word `cat' appeared together
with the word `dog' or the word `hound' (or both).  This OBAR system has grown
over the years into the Lexis system (including the Nexis collection of
newspaper and magazine articles) run by Mead Data Central which is the largest
fulltext documentary database in the world.

        I have always assumed that the two major risks associated with
using this system are: 1.) the fact that a document might not have been
entered into the database or, if it was entered, that it might have been
entered incorrectly and 2.) the tendency of a user who found a bunch of
documents (that seem to be what is wanted) to assume that _all_ the
relevant documents had been found.  Type II errors--documents found that
are not what one wants, i.e., false positives--are easy to spot on Lexis
and similar systems, but type I errors--documents that should have been
found, but weren't--simply don't show up in a search.

        On last Wednesday, however, I realized that I had been rather
naive.  On that day I ran a bunch of searches in the United States
Supreme Court Library on Lexis each of which was in the form:
"ENTITLEMENT and DATE(BEF 1/1/19x0) and DATE(AFT 12/31/19y0)" where
y=x+1.  Each of these searches should have produced a list of all the
opinions of the United States Supreme Court during a particular decade
that contained the word `entitlement'.  (Actually, since the date field
in the Lexis database contains the date of argument as well as the date
of decision, there would be some overlapping of the cases in the various
lists, but this is easily adjusted for.)  But that is not what I got.
Instead I got identical lists for the 1940's and 1950's and both of
these lists contained the same documents--which were, to make thing's
worse, opinions handed down in the 1980's.

        I reported this to one of our research librarians who tried to
make the same searches and got the same results.  She then phoned Lexis's
customer representatives who in turn made the same searches and got the
same results.  The customer representatives thanked our librarian for
brining this interesting situation to their attention and promised to
phone her back.

        And they did phone her back quite promptly.  It seems that Lexis
had installed new searching software back in May sometime and that this
new software has a bug in it when doing date delimited searches.  They
hope that it will be fixed in a couple of weeks.

        I suppose I was lulled into a false sense of complacency because
I have used this system for over 20 years and because its boolean
searching capabilities have always seemed to me too primitive to be
buggy.  But now I wonder how many lawsuits have been won or lost--or how
many law review articles have contained worthless data--because of
defects in the searching software rather than the user's searching
strategy.

        This particular example involved Lexis, but now I worry also
about its competitor Westlaw and about all the other textual databases
such as Dialog.  Have similar problems ever arisen with the many on-line
scientific databases?

Peter D. Junger--Case Western Reserve University Law School--Cleveland, OH


computer security problems in Malaysia

<smb@ulysses.att.com>
Mon, 18 Jun 90 03:58:59 EDT
According to the AP, a newspaper in Malaysia reports that a bank
executive ``cracked'' the bank's computer security system, and
transferred money from some clients' accounts to his own.  The loss
was discovered by an audit, and he had made himself conspicuous by
buying several expensive new cars.  The executive allegedly looted
$1.5 million.

                                            --Steve Bellovin


canopus.stanford.edu goes nova

Joe Dellinger <joe@hanauma.stanford.edu>
Mon, 18 Jun 90 03:24:17 PDT
    Saturday night someone exiting an office 60 feet away from mine
discovered the hallway full of acrid fumes; they ran choking down the stairs
to get away. They called Stanford Health and Safety, who came with air-sampling
meters and identified my office as the source. By this time the whole building
reeked; people were getting headaches from the fumes. The Health and Safety
people thought the fumes smelled like bromoform, a common chemical used in
analyzing rock samples that we've had problems with before when a fumehood
malfunctioned. But there are no fume hoods on my floor, which perplexed them.
(No windows either, even though we're on the 4th floor; Stanford's red tile
roofs take precedence over student offices having windows. The extremely poor
air circulation on our floor is a continual cause of complaints from the
students here.)

    Since it was my office I was called at home; they were trying to
puzzle out how dangerous chemicals could be getting into my office. Fortunately
we were able to point them on the right track immediately: the source of the
toxic fumes was my Color Sun 3-110 monitor! How were we so sure? Because the
same thing happened a year previously to a similar Sun monitor on our floor!
That time it wasn't on a weekend, so the building circulation was in higher
gear, and the building happened to be empty so when people arrived most of the
fumes had dispersed. Still, last time that office was unuseable for a couple
of days. This time, a day after the event my office still gives me a headache
within a minute or two of entering, and makes my eyes sting. The Health and
Safety people carted my Sun monitor away in a sealed plastic bag used for
carrying "hazardous material"!

    Stanford Health and Safety was quite concerned about this incident.
There are a LOT of Sun workstations around here. They've never heard of this
happening before, and want to find out more about this "risk of workstations".
So:
    1) Has anybody else out there had this happen? Since we only have
about 15 Suns, and it's happened to two of them now, it seems it must be
pretty common. But if that's true why hasn't Health and Safety heard of this
happening at Stanford before? Is it just because we have such bad ventilation
here? Perhaps the computer scientist types who have most of the workstations
on campus never work with dangerous chemicals, so they always just open the
windows and forget about it?
    2) What IS that nasty chemical? Health and Safety take anything that
gives near instant eye burn and headaches VERY seriously. Will I have bury
all my books in a toxic waste dump?

    Too bad, and I was just learning to type slowly enough so that my
Sun keyboard wouldn't go "click" and eat a random character or two every other
sentence...


Re: UK Hacker Goes To Jail (RISKS-10.09)

Pete Mellor <pm@cs.city.ac.uk>
Mon, 18 Jun 90 13:56:07 PDT
With regard to the imprisonment of Nicholas Whiteley for 4 months, and the
Computer Misuse Bill currently going through parliament, it is worth noting:

- Whiteley was convicted on four charges of malicious damage to property.
  This offence has nothing specifically to do with computers: you can be
  charged with the same thing for breaking down the fence of the local swimming
  pool (as a colleague of a friend of mine found to his cost after he decided
  to go for a midnight swim after a party).

- The provisions contained in the Computer Misuse Bill would not have assisted
  in his detection or conviction. It is possible that the charge sheet could
  have been made longer: separate charges of i) unauthorised access,
  ii) unauthorised access in furtherance of a more serious crime (i.e. damage),
  and iii) the damage itself. Whether this would have attracted a more severe
  sentence is doubtful. The prosecution claimed that the cost of the damage
  was 25K pounds sterling. If that amount was believed by the court, and it
  still led to four months only, it is difficult to believe that the addition
  of the ancillary charges would have caused the judge to take a more serious
  view of the case.

- It is also difficult to see how the amendment proposed by Emma Nicholson,
  to increase police powers of telephone surveillance, would have assisted
  in his capture.

Far from indicating the need for new anti-hacking laws with tougher sentences
and more loosely-defined offences, this case goes to show that where hackers
actually do damage, the existing laws are adequate, and that the main problem
is, and will remain, that of catching them.
                                                     Pete Mellor


Air India votes no confidence in A320

Andrew Klossner <andrew@frip.wv.tek.com>
Mon, 18 Jun 90 08:12:49 PDT
Air India ran an ad in the Wall Street Journal: they're trying to sell
all their purchased A320s and sublease their leased A320s.

  -=- Andrew Klossner   (uunet!tektronix!frip.WV.TEK!andrew)    [UUCP]


A320 near-disaster (from RISKS 1-2-34)

Robert Dorsett <rdd@ccwf.cc.utexas.edu>
18 Jun 90 19:29:31 GMT
This is from the French science biweekly "Mon Dieu"  Translated and reprinted
without permission:

"TOULOUSE,
French aviation authorities here admitted to a near-disaster which occured
about a month ago aboard an Airbus A320 jetliner.  The controversial aircraft
with its 'fly-by-wire' flight controls has been the subject of intense
controversy since its introduction.  The manufacturer, a consortium of
European interests, has steadfastly maintained the aircraft's inherent safety
over other aircraft, largely as a result of the computerized controls which
limit inputs from the pilots to ensure they are always compatible with
the current aerodynamic state of the plane.  Pilots and other pundits have
argued that these same safeguards can severely limit the crew's options
in emergency conditions.  Additionally, they argue that the increased
faith placed in the on-board computers leads to crew complacency and
inattentiveness.

"The incident in question took place while the aircraft, a British Airways
plane, was at cruise between New York and Fairbanks.  The co-pilot was
apparently entering new navigational data into the craft's INS (Inertial
Navigation System) when he misstyped a code.  The INS came back with
'Invalid PIN number selected' and returned the craft's weight and balance
data to the astonished crew.  'We tried several more times," exclaimed
Reginald Dwight, the Captain, 'and every time it was the same thing.  On
the third try it said "Access violation, contact your credit institution if
you believe there is an error."  At that point all the plane's controls
froze and it refused to respond to our commands.  We didn't know what to
do, so we got on the radio."

:British Airway's mechanics were equally dumbfounded and decided to call
French mechanics.  France's Aerospatial is the prime contractor for the
aircraft.  'The French were totally rude to us,' stated an unnamed
BA mechanic. 'They stated the problem was our fault and that "the pasty
little Englishman probably had too many meat pies and Guiness".'  'It wasn't
until we told them that Jerry Lewis was aboard the flight that they became
concerned.'

"French mechanics traced the problem to the ATM-6000 INS computer, which was
a modified version of a computer used in the United States for bank
transactions.  'Essentially, the INS decided that the co-pilot was trying
to rip-off someone and locked the controls.'  French authorities then assured
the English crew that the system would automatically remove the restrictions
at the start of the next banking day.  'We told them that we would be in the
sea by then!' exclaimed the frustrated copilot, Nigel Whitworth.

"A French team, headed by Bertrand Swatboutie, determined that manual control
of the plane could be re-established if a crewmember went back to the
tailcone and operated the elevators manually.  The rudder is linked by
backup cables to the cockpit and with the crewmember operating the
elevator they determined they would have enough control.  'There is nothing
wrong with ze plane,' exclaimed Swatboutie, 'that a little pinch in the
rear will not cure.  Just like a woman.  If these English souffres knew
anything about women, they would never have had to call us in the first
place.'

"The plane was able to safely land at Denver's Stapelton airport, where the
craft was repaired and all crewmember's credit histories reviewed."

DISCLAIMER: I used to live in France and some of my best friends are...
            never mind.
--
Gregory R. Travis                Indiana University, Bloomington IN 47405
greg@cica.cica.indiana.edu       Center for Innovative Computer Applications
N5457E, C-172


RISKS of computers in medical offices

Arthur L. Rubin <arthur@pnet01.cts.com>
Mon, 18 Jun 90 18:35:00 PDT
        Recently, my wife was taken to a local hospital (which shall
remain nameless) for uncontrolled bleeding after a cut in the kitchen.
(She seems to be fine now, but the cut required 3 stiTches.)  While we
were waiting to see the doctor on duty, we saw a man wearing a
stethoscope coming in the admitting room to try to fix the printer
used to print admission and insurance forms.  We later found out that
he was the doctor seeing patients that day for the emergency room.
Another patient waiting had a possible concussion.

The risks are obvious.

Arthur L. Rubin, PO Box 9245, Brea, CA 92622


More Space Telescope Problems

Karl Lehenbauer <karl@sugar.hackercorp.com>
19 Jun 90 03:09:36 CDT (Tue)
The June 18th issue of Aviation Week and Space Technology has a half-page
article on two problems the Hubble Space Telescope has been having.

One problem is that some RAM used by the fine guidance system is being
scrambled when the telescope passes through the South Atlantic Anomaly,
a region representing a "dip" in the Van Allen Belts that has been
known to be hazardous to spacecraft electronics for decades.  This happens
for a ten minute period during every 98-minute orbit.  The NASA deputy
project manager of the HST, Jean Olivier, said that they had evaluated
the radiation effects very carefully, but that they had apparently
miscalculated.

The data in the RAM is supplied, according to the article, by the
telescope's Rockwell Autonetics DF-224 general purpose computer.  The
magnetic core memory used by the Rockwell computer is not considered to
be susceptible to disruption by radiation.  Olivier said that the Rockwell
computer can be programmed to refresh the RAM ten times a second, with the
result being that a completely new set of parameters in the fine guidance
sensor electronics would be calculated every five seconds, thereby eliminating
the problem.

The second problem is with the telescope's solar arrays.  Analyses done in
Europe and the United States sugest that the poles that hold the solar
arrays in place, called bistems, bow under a 50F degree temperature gradient,
causing the ends of the arrays to move about ten inches, resulting in their
oscillating for up to six minutes.  Olivier said that the solution is to
program the spacecraft's magnetic torquers to apply counteracting forces.


Invisibly long lines

<whb@hoh-2.att.com>
Tue, 19 Jun 90 08:53:19 EDT
I don't know if this counts as a Risk or not, except for programmers
(such as myself) who occasionally fall into the trap of "Nobody'll
ever need a line longer than N characters."

In RISKS-FORUM Digest Volume 10 : Issue 02, the following paragraph
appears:

--- Begin included paragraph ---
Although what have come to be called the "Chirac flight" and the "Habsheim
affair" are the two facts most known to the public, the first year of operation
of the A320 has been marked by numerous incidents which have directly called
into question certain systems on the aeroplane. Often badly received by the
first crews qualified on this aircraft, and sometimes vigorously denied by the
technical directors of the launching companies, these incidents lead one to ask if the manufacturers and the certification authorities have not proceeded a
little too quickly.
--- End included paragraph ---

Those of us looking at that on an 80-column screen see nothing wrong,
but I chanced to be using a wider screen and saw that the line which
begins "technical directors" actually wraps around to the next on-screen
line and ends with "not proceeded a" - a total of 155 chars + newline.

No, my editor of choice had no trouble with it, but I can think of
several programs which do text handling which would.

Wilson H. Bent, Jr.     ... att!hoh-2!whb (whb@hoh-2.ATT.COM)
AT&T - Bell Laboratories    (201) 888-7129


Water problems

Gene Spafford <spaf@cs.purdue.edu>
18 Jun 90 17:22:51 GMT
Story 1.
I don't have a newspaper citation for this story — I heard it on the
phone last night while talking with a friend in Atlanta.

It appears that in north Fulton County, Atlanta, a water main broke
inside one of the pumping stations.  The resulting flood damaged 4 of
the main pumps and they had to be taken offline.  The area was without
normal water pressure for a few days, and some places were completely
without water.

The Risk?  Well, the computer center where they have the machines
running the Avail ATM network for Atlanta was in that area.  And they
evidently depend on the public water system for cooling (either the
building or the machines themselves — it wasn't clear to my friend
from the news reports).  The center had to be shut down until normal
water service was restored, thus "un-Availing" ATM customers
throughout the Atlanta area.

Story 2.

At 4am on the 7th of this month, a 14" water main broke in one of the
service tunnels here on campus.  Unfortunately, it broke in a tunnel
connected to the campus computing center (conveniently located in the
basement of one of the buildings).  What happened next was nasty.
In the words of George Goble of our ECN staff:

> I heard there was eventually 2-3' of water down there, about 500,000 Gal,
> more than the city swimming pool. Gives a new meaning to "floating point
> overflow", and "source pool", etc.  Water came in so fast, it went up at
> 1-2" per min, and the mech equipment room (with 100HP motors for air
> handling, etc) became submerged while in operation.. no more motors!
> 480V running around everywhere, 12KV in the (flooded) tunnels!
>
> There were reports of Macintoshes and PC's starting to submerge, and
> water blowing out the fans, and fire/smoke coming out the power supplies.
> Floor tiles were floating down the hallway, until they bumped into
> something, releasing trapped air, and sank.  There was a pallet or
> two of water softener salt stored in the basement also, I heard some
> PC's had only the plastic remaining, as the salt/corrision had eaten
> away the metal.  Early on, someone said they saw an elevator which
> had stopped at the basement, go up one floor, open its doors, and
> 3' of water poured out on ground floor.

The service tunnels out of that building were also flooded, and helped
carry the water into the basements of nearby buildings.  That's good,
in one sense, or the water would have gotten much deeper in the
computing center.

Then, to make the whole situation even better, the folks who were
pumping stuff out used gasoline powered pumps that filled the entire
Math/Science building with carbon monoxide leading the police to
cordon off the building and prevent anyone from getting to their
offices.  This included the Math & Stat departments, the math sciences
library, and the Dean and his staff.

Amazingly enough, some of the networks and machines were up and in
normal operation by the end of the weekend.  This was good, because
the networks coming into campus are routed through that complex.

Luckily, our CS computer room is on the 2nd floor of another building,
and our ECN computer center is across campus.  Other sites, similarly
isolated were also unscathed.


Morals:
1.  Basements are not the best place to keep your computers
2.  Depending on outside water (or lack thereof) to keep your machines
running can be a mistake.
3.  If you do pipeline processing, be sure to check for overflow!

Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  spaf@cs.purdue.edu   uucp:   ...!{decwrl,gatech,ucbvax}!purdue!spaf

Please report problems with the web pages to the maintainer

x
Top