The RISKS Digest
Volume 9 Issue 86

Monday, 30th April 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…


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

futures market shut down

Fri, 27 Apr 90 13:43:58 EDT
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

Habsheim A320 crash

Clive Feather <clive@ixi.UUCP>
Fri, 27 Apr 90 09:18:50 bst
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.
    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

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

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

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

Throttle Hitch Hits 747-400

Robert Dorsett <>
Fri, 27 Apr 90 16:27:51 -0500
>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

Re: Unattended Plane Take-off

Jan I Wolitzky <>
Mon, 30 Apr 90 09:33:53 EDT
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

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

  "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

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)

Re: Computers and names with special characters (Hoffman, RISKS-9.85)

Mike Van Pelt <mvp@hsv3.UUCP>
27 Apr 90 23:54:11 GMT
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,

inadequate documentation - truncated GPAs

"Doug Sewell" <DOUG@YSUB.BITNET>
Sat, 28 Apr 90 13:02:08 EDT
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

The return of the hacker

David B. Benson <>
Sat, 28 Apr 90 11:43:50 pdt
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.)

Indian Professors Teaching Virus Writing

Cliff Stoll <>
Mon, 30 Apr 90 01:59:14 EDT
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

--Cliff Stoll

(Not necessarily) computer parks hundreds of cars illegally

bill gunshannon <702WFG@SCRVMSYS.BITNET>
Mon, 30 Apr 90 08:21:05 EST
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

Please report problems with the web pages to the maintainer