Subject: RISKS DIGEST 10.10 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 1 9June 1990 Volume 10 : Issue 10 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator 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) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. TO FTP VOL i ISSUE j: ftp CRVAX.sri.comlogin anonymousAnyNonNullPW cd sys$user2:[risks]GET RISKS-i.j ; j is TWO digits. Vol summaries in risks-i.00 (j=0); "dir risks-*.*" gets you directory listing of back issues. ALL CONTRIBUTIONS ARE CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. ---------------------------------------------------------------------- Date: 16 Jun 90 14:43:00 EST From: junger@cwru.cwru.edu Subject: Risks of using commercial on-line fulltext databases 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 ------------------------------ Date: Mon, 18 Jun 90 03:58:59 EDT From: smb@ulysses.att.com Subject: computer security problems in Malaysia 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 ------------------------------ Date: Mon, 18 Jun 90 03:24:17 PDT From: joe@hanauma.stanford.edu (Joe Dellinger) Subject: canopus.stanford.edu goes nova 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... ------------------------------ Date: Mon, 18 Jun 90 13:56:07 PDT From: Pete Mellor Subject: Re: UK Hacker Goes To Jail (RISKS-10.09) 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 ------------------------------ Date: Mon, 18 Jun 90 08:12:49 PDT From: Andrew Klossner Subject: Air India votes no confidence in A320 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] ------------------------------ Date: Mon, 18 Jun 90 17:42:17 -0500 From: rdd@ccwf.cc.utexas.edu (Robert Dorsett) Originally-From: greg@cica.cica.indiana.edu (Gregory TRAVIS) Subject: A320 near-disaster (from RISKS 1-2-34) Date: 18 Jun 90 19:29:31 GMT Posted: Mon Jun 18 14:29:31 1990 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 ------------------------------ Date: Mon, 18 Jun 90 18:35:00 PDT From: arthur@pnet01.cts.com (Arthur L. Rubin) Subject: RISKS of computers in medical offices 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 ------------------------------ Date: 19 Jun 90 03:09:36 CDT (Tue) From: karl@sugar.hackercorp.com (Karl Lehenbauer) Subject: More Space Telescope Problems 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. ------------------------------ Date: Tue, 19 Jun 90 08:53:19 EDT From: whb@hoh-2.att.com Subject: Invisibly long lines 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 ------------------------------ Date: 18 Jun 90 17:22:51 GMT From: spaf@cs.purdue.edu (Gene Spafford) Subject: Water problems 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 ------------------------------ End of RISKS-FORUM Digest 10.10 ************************