Text File

Subject: RISKS DIGEST 9.86 REPLY-TO: risks@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest Monday 30 April 1990 Volume 9 : Issue 86

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

Contents: Futures market shut down (Steve Bellovin) Habsheim A320 crash (Clive Feather) Throttle Hitch Hits 747-400 (Robert Dorsett) Re: Unattended Plane Take-off (Jan I Wolitzky) Re: Computers and names with special characters (Mike Van Pelt) Inadequate documentation - truncated GPAs (Doug Sewell) "The return of the hacker" (David B. Benson) Indian Professors Teaching Virus Writing (Cliff Stoll) (Not necessarily) computer parks hundreds of cars illegally (Bill Gunshannon)

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.com<CR>login anonymous<CR>AnyNonNullPW<CR> cd sys:[risks]<CR>get risks-i.j . Vol summaries now in risks-i.00 (j=0)

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

Date: Fri, 27 Apr 90 13:43:58 EDT From: smb@ulysses.att.com Subject: futures market shut down

Five New York futures markets went off the air Friday when the communications line that delivers price quotes to brokers and others around the country failed. The cause of the failure is unclear as of this writing; exchange officials blamed AT&T lines, but AT&T said that their lines were working and that the problem appeared to be at the futures exchange.

And the traders -- most of them headed for home, a decision perhaps eased by the fact that the weather here is gorgeous and it's Friday... --Steve Bellovin

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

Date: Fri, 27 Apr 90 09:18:50 bst From: Clive Feather <clive@ixi.UUCP> Subject: Habsheim A320 crash

Another article about the A320 Habsheim crash appeared in the 11-17 April 1990 issue of Flight International. This includes transcripts of the voice and data recorders of the flight.

Time: seconds part of time; times are from 12:44:27 to 12:45:41.5. N1: engine low-pressure compression ratio (%) (a good guide to engine power). CAS: calibrated air speed, in knots. V: A = radio altimeter (heights are in feet) C = captain G = ground proximity warning system (GPWS) N = noises P = copilot T = tower

N1 and CAS values are interpolated from a graph in the article. This only covers the time from 12:45:00 to 12:45:39.

Time N1 CAS V 27 T QNH Habsheim 1012 Fox Echo 984. C OK. [QNH is the altimeter pressure setting required to make the altimeter read 0 at sea level ("altitude"), and QFE is the setting to make it read 0 at airport ground level ("height").] 31 P Roger. [On radio] 32 C 984 put in 984. 34 P 984 QFE selected. 37 P Good gear is down; flaps 2. 42 C Flaps 3. 45 P Flaps 3. C That's the airfield; you confirm ? 48 P Affirmative. 51 P You see it LL01, when we get there you're at 1 nautical mile, that's right. 55 N <Gong> [nosewheel valve, according to crew] P OK. G Too low terrain. 00 35 160 04.7 N <Gong> [GPWS cutoff, according to crew] 05 35 150 05.7 A Two hundred. 10 35 150 11 P P....G.... [P....G.... is the airline's flight safety officer] 11.4 A Two hundred. 12 P G.... is going to ... eh. 14 P OK, you're at 100 feet there, watch, watch. 15 35 145 15.3 A One hundred. 19.1 A Forty. 20 35 135 23.6 A Fifty. 25 35 130 26 C OK, I'm OK there, disconnect autothrottle. [This had already been done]. 27.5 A Forty. 30 35 120 32 P Watch out for the pylons ahead, eh, see them ? 33 C Yeah, yeah, don't worry. 34 35 [Throttle position started moving from 0 degrees] 34.5 35 N <Clack, clack, clack> [power lever detents] 35 35 115 35.3 A Thirty. 36 38 [Throttle position reached 45 degrees, where it then remained] 36.2 A Thirty. 37 45 P TOGA/SRS. [Take-off go-around / speed reference system] 38 60 38.3 A Thirty. 39 75 100 P Go around track. N <Increase in engine speed> N <Noises of impact in trees> 39.9 C Sh..! 41.5 END OF TAPE

Some other notes from the article:

Air France's approved overfly height is 100 feet, and only if the runway is suitable for landing. Habsheim's runways are too short to land an A320.

The original plan was to overfly the hard runway, 02. The captain was clearly having trouble finding the runway; when he finally saw the line of spectators on the ground, he decided to overfly the grass runway 34R, without telling the copilot.

The captain was used to major airports, with 2000-3000m runways and 30m high control towers. Habsheim has a 800m grass strip and a 12m high tower. He may have been misled by a scale effect; the steep attitude of the plane would have enhanced this, and could also have made him think he was higher than the trees (which first struck the rear fuselage).

It was suggested on RISKS that there may have been a software delay in the engine controls which was not shown by the data recorder. From the voice tape, it is clear that this is not the case. A CFM56-5 engine takes about 8 seconds to spool up to full power, and the tapes are also consistent with this. N1 started to increase within half a second of TOGA (take-off go-around) power being selected, and had reached 85% when the engines began to ingest branches. Analysis of the soundtrack of a video shot from the control tower agrees with this, and shows N1 reaching 91% with "massive ingestion of branches and leaves".

Somewhere around 12:45:39 the captain's sidestick was pulled to full climb position. At this point the CAS was 110 knots, beginning to respond to engine thrust, and the height is 30 feet, steady and beginning to increase. Throttles and sticks are hard against the stops.

The first data recorder transcription suffered a misreading in the region 12:45:24 to 12:45:32, of which 4 seconds was rejected by the data checking software in the analyser. An example of errors produced was sign inversion of the aileron positions. The official report states that this "was no doubt due to an interruption of contact between the reading head and the recorded tape, caused by a fold in the tape and/or dust. The following recordings, made after cleaning and smoothing out of the tape, permitted correct reproduction of all data". This problem has been used as grounds for alleging that the data was tampered with, but it should be noted that (a) the affected area does not cover any significant events, and (b) the final transcription is internally consistent, and is consistent with videos taken by various people and air traffic control tapes. The voice recorder analysis was made with the crew's help.

Habsheim weather at 12:50: wind 330/6 knots; visibility 8km; cloud 1/8 Cu at 780m, 7/8 Sc at 1500m. The weather was unchanged since 12:20, except that the wind direction had backed from 010.

Clive D.W. Feather, IXI Limited, 62-74 Burleigh Street, Cambridge U.K. CB1 1OJ

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

Date: Fri, 27 Apr 90 16:27:51 -0500 From: rdd@walt.cc.utexas.edu (Robert Dorsett) Subject: Throttle Hitch Hits 747-400

>From FLIGHT INTERNATIONAL, April 11, 1990:

``British Airways (BA) Boeing 747-400's have experienced uncommanded inflight closure of all four throttles on six separate flights between 6 October, 1989, and 19 February, "several times" on one of these flights alone, according to formal reports. Several other airlines have suffered the same incident, Northwest reporting it first.

``Boeing believes that it has determined the cause, and appropriate auto-throttle software modifications were made available to operators on 22 February. Initial modifications to all new aircraft were reviewed in early September. Studies continue, however, in association with airlines and the UK Civil Aviation Authority.

``Boeing and BA deny reports of serious unreliability, associated mainly with the 747-400's digital cockpit avionics and computerised systems management. Boeing reports world fleet technical dispatch average in 1990 as 94.5%, and gives a February 1991 target of 98%. BA says that its fleet of seven achieved 100% technical dispatch reliability in the last week of March, and 96.5% for the last three months, quoting this as reasonable for a new type. In most of the events the power levers retarded rapidly to idle, but sometimes the reduction was partial, followed by automatic reset. Pilots reacted by dis- engaging the autothrottle and resetting power manually.

``Boeing began a study of the problem as soon as reports confirmed that a throttle closure on a Northwest 747-400 was not a freak event. The manufac- turer subsequently issued two service bulletins to -400 operators.

``All incidents have occurred in the climb or cruise, and an indicated airspeed (IAS) of more than 280 kt is believed to be fundamental to the event. If continuing experience confirms this, it means that stalling--even clean--is not a risk. Evidence indicates that the event is caused by a spurious signal to the full-authority digital engine control from the stall-management module. The "single word" spurious command says that the undercarriage is down or the flaps are at setting 1, so if the IAS exceeds the maximum speed for these configurations, the autothrottles close to reduce IAS to limiting speed, then reset to maintain it.

``The modification assumes that the fault was in the processing logic of the appropriate unviersal logic card (a printed-circuit software unit), and adopts a standard technique for reducing digital oversensitivity: there is now a delay (a few microseconds) built into the software by requiring it to receive an "eight-word" command before acting. Power spikes or other spurious commands should not produce a reaction.

``So far the latest modification has proved effective. Early corrections, though, had assumed the reaction was associated only with main-gear selection, so although software changes had reduced the incident rate, spurious flap signals continued to set engines to idle. BA has not reported any further events since February.''

Robert Dorsett, Moderator, Aeronautics Mailing List

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

Date: Mon, 30 Apr 90 09:33:53 EDT From: wolit@att.com (Jan I Wolitzky) Subject: Re: Unattended Plane Take-off

It's not a passenger-carrying plane, but Boeing's new Condor unmanned (note sexist language) aerial vehicle (UAV) should be of interest to readers of this newsgroup.

The Condor is a 10-ton, 200-ft wingspan (greater than that of a 747), high-altitude (66,908 ft), long-duration (2.5 days), twin-engine, piston-powered, autonomous (NOT remotely-piloted) plane. Boeing hopes to find buyers in the military and scientific communities interested in the plane as a sensor platform, at $20 million a pop, not including payload. DARPA has funded some of the development.

The plane is "piloted" by two Delco Magic 3 flight control computers, using inertial guidance for navigation, a microwave landing system (MLS) for takeoff and landing, and about 60,000 lines of code, mostly Fortran, with some assembly code.

"All of Condor's mission functions from takeoff to landing are stored in its computers at the start of a mission.... Communication links are provided so that the mission program can be altered in flight if necessary for safety or any other reason."

It operates autonomously within the air traffic control system (a contradiction in terms, as I see it), which has caused some concern on the part of the FAA. At its cruising altitude, it operates well above commercial traffic, but it takes 4 to 6 hours to get up there or back down. During flight tests, a chase plane was present whenever the Condor was within an airport traffic pattern. The article I read (Aviation Week & Space Technology, 132/6, April 23, 1990, pp. 36 - 38) had no word on what the chase plane's pilot's instruction were in the event of a computer malfunction, or what would happen if something failed when the chase plane wasn't around.

Jan Wolitzky, AT&T Bell Labs, Murray Hill, NJ; 201 582-2998 (Affiliation given for identification purposes only)

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

Date: 27 Apr 90 23:54:11 GMT From: mvp@hsv3.UUCP (Mike Van Pelt) Subject: Re: Computers and names with special characters (Hoffman, RISKS-9.85)

Now that has some interesting possibilites -- If the Social Security Administration still uses Univac/Sperry/Unisys computers, I ought to change my name to @FIN (the end-of-job control card). That would sure drop a large monkey wrench into the works, as there is no way to read a card that starts with those four characters. Well, maybe if you switch the card reader translation mode to EBCDIC or column binary... (Assuming they still use cards, of course, which wouldn't surprise me at all.)

There are, of course, other variations if they've switched computers.

Mike Van Pelt, Headland Technology,

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

Date: Sat, 28 Apr 90 13:02:08 EDT From: "Doug Sewell" <DOUG@YSUB.BITNET> Subject: inadequate documentation - truncated GPAs

Several years ago, we split our report-card-printing job into two jobs. Due to the way it was split, one program was 'cloned', rather than modified to determine which set of report cards was to be printed.

The fact the both programs had to be kept 'in sync' wasn't clear in the documentation. I suspect that the interface between some of the other procedures involved were also under-documented.

Some time after the job was split into two, the university got flooded with calls complaining that some of the GPAs were truncated - 3.95 and 3.13 were both printed as 3.00. The correct GPA could be determined by dividing the quality points by the hours attempted, which were both printed correctly on the report cards.

Apparently, some program maintenance affected the two clone programs. One printed GPAs correctly, the other didn't. During analysis, it was determined that the database files were correct, the permanent record reports were correct, and it was only half of the report cards that were printed incorrectly. It was necessary to reprint and remail all of the report cards.

Doug Sewell, Tech Support, Computer Center, Youngstown State University, Youngstown, OH 44555

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

Date: Sat, 28 Apr 90 11:43:50 pdt From: dbenson@cs2.cs.wsu.edu (David B. Benson) Subject: The return of the hacker

I have been throughly enjoying reading

Darrel Ince Software Development: Fashioning the Baroque Oxford University Press, 1988 ISBN 0-19-853757-3 ISBN 0-19-853758-1 (Pbk.)

which includes a chapter entitled "The return of the hacker". The particular risks discussed in this chapter and of immediate interest are in the use of spreadsheets by the computer less-than-adequately-literate. When I mentioned computerized spreadsheets to some of my colleagues, they replyed with some stories involving incorrect spreadsheet packages and also more stories of the hacking which occurs in the spreadsheet community. While the misuse of spreadsheets may be less dramatic than problems with airplanes and autos, I suspect this spreadsheet hacking may be so pervasive as to have a noticable and negative impact upon the economies of the computerized world. (Of course, the widespread and judicious use of spreadsheet packages certainly has a noticable and positive effect as well. But on RISKS we concentrate upon the negative impacts.) I would appreciate the readership of RISKS contributing a wide variety of stories about spreadsheets. These might include stories about the incorrect implimentations of constraint programming which appears to occur in all-too-many of the spreadsheet packages. These stories would also ideally be about the real-world impacts of trusting the conclusions obtained by the spreadsheet packages. (If you haven't any stories of your own, please just ask the tradespeople in the community in which you reside.)

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

Date: Mon, 30 Apr 90 01:59:14 EDT From: cliff@cfa253.harvard.edu (Cliff Stoll) Subject: Indian Professors Teaching Virus Writing

This from News Notes on America-On-Line, April 28, 1990:

Seminar Speaker Says India Should Pass Anti-Virus Legislation

Those attending a seminar last week in New Delhi urged the Indian government to consider a law to deter people from indiscriminately experimenting with viruses. A report in the Xinhua Chinese news service quoted an Indian scholar identified only as "Mahabala, chairman of the department of electronics committee on computer virus" as saying an alarming trend in the country is that some academics are teaching software engineering by creating viruses for their students to detect. Said Xinhua, "This concept of glorifying viruses designers (is) wholly destructive," adding Mahabala cited a wide variety of viruses affecting computers in India, mainly variations of viruses such as "C-Brain." Mahabala said that, instead of creating viruses as means of copy protection, software designers should come out with access passwords that are difficult to break.

--Cliff Stoll cliff@cfa.harvard.edu

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

Date: Mon, 30 Apr 90 08:21:05 EST From: bill gunshannon <702WFG@SCRVMSYS.BITNET> Subject: (Not necessarily) computer parks hundreds of cars illegally

Although this looks like a computer/operator glitch up front, it could also be an example of using the old? cliche "computer error" to cover up some shady fund raising. There was a case a number of years ago when Philadelphia sent out thousands of parking tickets also to people who had not even been in the city. The idea being if even 1% send in the money rather than fight the ticket, they show a handsome profit. My father received one and took it to the local AAA office. They were taking them to Harrisburg by the hundreds just from the NE PA area. Of course, they didn't have computers to blame so uncovering the scam was pretty easy.

It seems that computers may be capable of providing a good audit trail when desired but they are also capable of covering their tracks if that is the desired result. bill gunshannon

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

End of RISKS-FORUM Digest 9.86 ************************