The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 15 Issue 26

Saturday 13 November 1993

Contents

o Gripen crash report
Urban Fredriksson
o SAS MD-81 crash report, December 1991
Martyn Thomas
o MASS state police confuse car owners with gun carriers (NOT)
Simson Garfinkel
o Re: No change in Ada policy
Anonymous
Parnas
o Risk-happy drivers foil anti-lock brakes
Mark Brader
o _Naissance d'un virus_ soon to be published
Jean-Bernard Condat
o Re: pseudospoofing
Andrew Marchant-Shapiro
o I'm Me
Nick Szabo
o Re: anonymizing service
Karl Lui Barrus
o Re: Not so easy to be anonymous
Seth Chazanoff
o Re: Stupid language games
Dave Parnas
o Re: Networking
Phil Agre
o "Friendly Fire" in system design
Steve Taylor
o Re: Teachers Beware!
Andy Cunningham
o FBI Operation "Root Canal" Documents Revealed
Dave Banisar
o Info on RISKS (comp.risks)

Gripen crash report

Urban Fredriksson <urf@icl.se>
Sat, 13 Nov 1993 07:23:58 GMT
The Swedish Accident Investigation Board's preliminary report on the Gripen
crash on Aug 8 is presented in the air force's magazine FlygvapenNytt 3/93.
Summarily, the conclusions are:

- The only equipment malfunction before the crash was the electronic map which
  had nothing to do with the crash
- The flight control system, the engine and all other systems worked as
  specified until the aircraft impacted
- No external cause is suspected
- The pilot was properly trained and equipped
- The limits for minimum altitude and maximum angle of attack were exceeded
  insignificantly and did not have anything to do with the crash
- The manufacturer and customer knew that large and rapid stick movements
  could cause divergent Pilot Induced Oscillations, but considered the
  likelyhood of it actually happening insignificant, so all pilots weren't
  informed
- The red warning light was too late in telling the pilot that the control
  system was saturated, for him to do anything about it
- The low altitude of 270 m made it impossible for the pilot to try to regain
  control

The crash sequence started with a low speed 360 deg left turn at 280 m. The
afterburner was lit, speed 285 km/h, load 2 G, bank angle 65 deg and angle of
attack 21 deg. After finishing the turn, the control stick was moved to the
right almost to the endpoint and slightly forward. The left wing's rear
control surface rapidly went to the bottom position. The aircraft to bank to
the right 20 deg past horizontal, angle of attack decreased to less than 10
deg. In order to fast regain a horizontal wing attitude, the pilot rapidly
pulled the stick almost all the way to the left and continued to keep it
slightly forward.

This caused the control surfaces to move with their maximum deflection speed,
and as the flight control system then had little or no control surface
movement on its own to work with, the stability margin was reduced. At the
same time the alert system informed the pilot of this, and he no longer
recognized the aircraft's behaviour.

The aircraft started to roll to the left and pitch up. In response to this the
control stick was moved almost to the right endpoint and some forward. The
result was a roll to the right to 35 deg bank and a lowering of the nose to 7
deg below the horizon, whereupon the stick was pulled forcefully back and to
the left. At the same time, the artificial stability system tried to raise the
nose, which in combination with the pilot's command caused a powerful pitch
up. By this time, the control stick was fully forward, but the aircraft was
already unflyable.

>From exit of the turn until ejection the sequence took 6.2 s. The time from
when the pilot didn't recognize the flying characteristics until stall took
2.7 s, but the control system warning wasn't shown until 1.2 s before the
stall.

The cause of the crash was the misjudgements that PIO was so unlikely and that
the warning light would tell about any problems early enough for no mention of
this in the pilot's manual was necessary.


My own comments: The first crash was caused by the artificial control system
having too much authority, sometimes leading to a slight response delay to the
pilot's commands, causing PIO during a landing in gusting sidewinds. It has
been reported from other sources that the main change made to the control laws
a few weeks before the crash was to increase the pilot's authority a tiny bit.

Some doubt has also been cast on the statement that the flight control
computer worked as specified, as its log only goes a few seconds back and thus
only showed data since the pilot left the aircraft. The crash report doesn't
go into this in detail, but it is clear they had its error log to work with,
in addition to data from the "black box".

This report also clears up some things I didn't understand from earlier this
year, when it was said that maximum angle of attack was 26 deg, and at 35 deg
the rear airbrakes come out and the canard gives a full pitch down command
automatically. Obviously fly-by-wire does not have to mean you impose hard
limits on the aircraft's performance, in the Gripen case the pilot is trusted
not to exceed them.

 Urban Fredriksson  urf@icl.se


SAS MD-81 crash report, December 1991

Martyn Thomas <mct@praxis.co.uk>
Fri, 12 Nov 1993 10:11:58 +0000 (GMT)
According to Flight International, 10 NOVEMBER 1993, "an automatic
engine-control function in the McDonnell Douglas MD-81, of which the operating
airline was unaware, was a major factor in the Scandinavian Airlines System
(SAS) accident near Stockholm, Sweden, in December 1991, says the official
report into the accident"

In summary, it seems that the airline failed to detect clear ice on the wings
before takeoff. The ice broke free and entered the engines damaging the fan
stages. This caused the right engine to surge. The pilots retarded the right
throttle. The automatic thrust-restoration system ATR caused both throttles to
advance without the pilots noticing, making the surging worse in the right
engine and starting surging in the left. The surges destroyed the engines.

It seems that SAS were unaware of the ATR, which was documented but in a
section of the production flight-procedure manual dealing with noise
abatement. SAS VP Johan Juhlin is reported as saying "We did not order it.  It
was hidden in the computer. The only way to disconnect the ATR was to
disconnect the whole autothrottle system."

McDonnell Douglas say that they made SAS aware of the full capabilities of
the MD-80 when it was delivered.

The documentation has since been improved, and SAS have changed their
procedures and training to emphasise the ATR and correct anti-surging
procedures.

The ATR was designed to improve safety where an engine fails after take off
and noise abatement procedures have caused the engines to be throttled
back.

Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.
Tel:    +44-225-444700.   Email:   mct@praxis.co.uk     Fax: +44-225-465205


Massachusetts state police confuse car owners with gun carriers (NOT)

Simson L. Garfinkel <simsong@next.cambridge.ma.us>
Wed, 10 Nov 93 20:19:58 -0500
I forwarded the RISKS note about people receiving gun permit renewal notes
accidentally in Massachusetts to David Lewis, who heads the Registry of Motor
Vehicle's information technology group.  (His official title is Deputy
Registrar.)

You may remember the message:

>Date: Fri, 5 Nov 93 13:26:43 EST
>Subject: Mass. state police confuse car owners with gun carriers

>My wife received a letter yesterday from the Massachusetts state police,
>informing her that it was time to renew her "License to Carry Firearms".
>It included a renewal form that she was to take to her local licensing
>authority, the police station in our case.

This is what David Lewis had to say about it:

"It wasn't actually a tape of vehicle owners.  They got stickers confused with
people who were supposed to get food stamps.  So the people [who were supposed
to get] the food stamp books got the gun permits, and the people who were
supposed to get gun permits got food stamps.  But it wasn't the Registry this
time."

Just setting the record straight.


Re: No change in Ada policy (Eachus, RISKS-15.25)

"ANONYMOUSLY INCLUDED via Peter G. Neumann" <neumann@csl.sri.com>
Fri, 12 Nov 93 8:57:55 PST
   [This was submitted by a reliable RISKS contributor who wishes
   to remain anonymous.  PGN]

It was noted in RISKS-15.25 that industry needs to be sold on the usage of
Ada.

As far as I know, industry likes Ada well enough.  What they do not like is
the EXCLUSIVE use of Ada.  Industry has the problem of maintaining millions of
lines of working code, code that is rather well debugged, and reasonably well
documented, code that was written in what was once a DoD standard - FORTRAN or
COBOL, for example.

If the government really believes in capitalism, and if the government
believes that private industry is in business to make money, then the
government should be willing to allow industry to transition to Ada as that
makes economic good sense.  And not sooner.

What such a policy shift might discover is that there are real problems for
which Ada is not the best language.

There is a very significant difference between a policy of "Ada exclusively"
and a policy of "any assembly language you choose."  Limiting government
sponsored software to a list of government approved languages is a good place
to start; investing some r&D money (little "r" and big "D" since most of the
"research" is done) in software engineering "tools" for some "legacy
languages" (FORTRAN, COBOL, BASIC) would improve the codes written in those
older languages, and avoid the impact of a massive mandated change.  Indeed,
some of these "tools" exist; "DAVE" for FORTRAN, for instance.


Re: No change in Ada policy (Eachus, RISKS-15.25)

Dave Parnas <parnas@triose.eng.mcmaster.ca>
Thu, 11 Nov 93 22:05:19 EST
Was there anything significant in your running the expression of faith in ADA
just before the article about Groundhog day?  There are still people who seem
to believe in the latter too.

Dave


Re: Risk-happy drivers foil anti-lock brakes (Bruce, RISKS-15.24)

Mark Brader <msb@sq.sq.com>
Wed, 10 Nov 1993 19:40:28 -0500
> From the Ottawa Citizen Sunday Edition November 7, 1993
> by Brad Evenson, Citizen consumer writer
> ...
>      "After having practised the emergency stopping manoeuvres  with  anti-
> lock  brakes, drivers drove faster, had higher accelerations around a curve
> and stopped harder," a summary of the study said.
>      "If drivers choose to drive faster because they know they have greater
> control,  and  if  they  choose to follow other vehicles more closely under
> slippery road conditions, then the safety  benefit  from  anti-lock  brakes
> might be reduced or lost completely."

Okay, if this study is not misleading, then anti-lock brakes are a device
which allows faster driving and closer following in slippery road conditions,
without increasing the accident rate.  This is bad?

Mark Brader, SoftQuad Inc., Toronto  utzoo!sq!msb, msb@sq.com


_Naissance d'un virus_ soon to be published :-)

cccf <cccf@altern.com>
Wed, 10 Nov 93 11:08:44 EST
By the general secretary of the Chaos Computer Club France (CCCF), the
French translation of "The Little Black Book of Computer Viruses" will
soon be published by Addison-Wesley France (fax: +33 1 48 87 97 99).

Naassance d'un Virus (dec 1993, 237 pages, circa 98 FF).

Jean-Bernard Condat, PO Box 155, 93404 St-Ouen Cedex, France
Phone: +33 1 47874083, fax: +33 1 47874919, email: cccf@altern.com


RE: pseudospoofing (RISKS-15.25)

"MARCHANT-SHAPIRO, ANDREW" <MARCHANA@gar.union.edu>
10 Nov 93 20:07:00 EST
On pseudospoofing, there is an interesting SF-based discussion of the
potential political consequences, to be found in Orson Scott Card's
_Speaker_for_the_Dead_ (if I recall correctly, the two other sections of the
[so far] trilogy also contain some elements: _Ender's_Game and _Xenocide_).
In these books, Card describes a situation in which the political commons (not
unlike internet) is invaded by two extremely bright pseudospoofers, who,
seemingly opposed, debate each other in such a way as to manipulate the public
into going along with their schemes.  There are better writers than Card, and
the concept has probably been around for a while, but it's an interesting
execution.

Andrew Marchant-Shapiro    Depts of  Sociology and Political Science
USmail: Union College, Schenectady  NY  12308   AT&T: (518) 388-6225
INTERNET:  marchana@gar.union.edu     BITNET:  marchana@union.bitnet
(no fooling!)

  [AM-S among others reminded me that my rend(er)ing of Tom Lehrer was not
  as on the records.  "Don't write naughty words on walls IF you can't spell."
  I knew that, but (mis?)remembered a live version from the early 50s...  PGN]


I'm Me

Nick Szabo <szabo@netcom.com>
Thu, 11 Nov 93 0:28:31 PST
I'd like to assure the readers of RISKS that I am in fact a unique person,
distinct from the other names L. Detweiler listed.  Of the people on his list
I know from personal contact, all are distinct people in Real Life(tm).  Well
before his post to RISKS, L. Detweiler was provided means of personally
verifying that many of the names he listed are distinct True Names (eg phone
numbers he can call), but it doesn't seem to help.

Nick Szabo                szabo@netcom.com


Re: anonymizing service

Karl Lui Barrus <klbarrus@owlnet.rice.edu>
Fri, 12 Nov 93 09:42:55 CST
To everybody who is worried about the service anon.penet.fi:

  If you mail to an address such as an####@anon.penet.fi, you will be
  assigned an id.

  If you mail to na####@anon.penet.fi, your message will be passed along
  and you will NOT be assigned an id.

an == anonymous
na == not anonymous

It's that simple.  I mention this because it seems every other week somebody
is discovering the "risks" of this service while how to avoid the problem
altogether is never discussed.


Re: Not so easy to be anonymous (Ullman, RISKS-15.25)

Seth Chazanoff <seth@inst-sun1.jpl.nasa.gov>
11 Nov 1993 17:17:01 GMT
In RISKS-15.25, Robert L Ullmann points out that one may be able to be
identified when using an anonymous mailer through stylistic analysis
techniques. ( This is what radio intercept operators in WWII called the
senders fist. ), There is a section that I was told about on the Comparative
Literature GRE that starts _None of the following paragraphs were written by
any of the authors listed, but the correct answer is the name of the author
whose style the paragraph was written in._ The problem with this technique is
that many people may use similar enough techniques that attempting to assign a
message to an individual may be very difficult.

Recently JPL opened an anonymous newsgroup for internal gripes.  My boss's
boss came to me and said that he had noticed that I was active in that group.
( It is good to know that management is reading the group. :-)) I asked him
how he came to that conclusion and he told me that he recognized my style of
writing.  The only problem was I had not heard of that newsgroup till he told
me about it.

    Seth


Re: Stupid language games (Schroeppel, RISKS-15.24)

Dave Parnas <parnas@triose.eng.mcmaster.ca>
Thu, 11 Nov 93 22:00:44 EST
Neither Jones, nor Mellor, nor Parnas (see RISKS-15.22) was arguing in favour
of exhaustive testing in the quote picked upon by Schroeppel.  Jones was
trying to explain the complexity of software to non-programmers.  He did this
by trying to give the listeners a "feel" for the number of possible cases that
would have to be considered.  I pointed out that even though the complexity,
as described, seemed daunting, it was understated.  There is neither
theoretical, nor practical basis for focusing on control state and neglecting
data state.  The thought attributed to Daimler by Schroeppel is irrelevant
because carburetors don't have to be tested on all mixtures, just the ones
that they will encounter, and that can be controlled.  Moreover, continuity,
and known upperbounds on the derivatives of the functions describing
carburetors, limit the amount of testing that need be done.  It's this lack of
continuity that makes testing of software so difficult.


Re: Networking

Phil Agre <pagre@weber.ucsd.edu>
Wed, 10 Nov 1993 16:48:21 -0800
Richard Schroeppel <rcs@cs.arizona.edu> has taken exception to my essay on
"Networking on the Network" in Risks 15.12, stating "I do not choose my
friends based on their potential usefulness to my professional advancement.
Even a little bit."  As my essay repeatedly made clear, I am not advising
anybody on the choice of their friends, only on the development of their
professional relationships.  These are different concepts.

Heretofore, practical knowledge about how the world works has been restricted
to elites, who are so embarrassed about this knowledge that they only pass it
along in private, leaving others exposed to the Risks of untutored navigation
in the professional world, permanently wondering why they can't seem to get
anything done.  If we write down the world's unwritten rules and circulate
them on the Internet, maybe we can level the playing field a bit -- or even
change the rules.

Phil Agre, UCSD


"Friendly Fire" in system design

Steve Taylor <smt@xedoc.com.au>
Fri, 12 Nov 93 18:14:15 +1100
I've just remembered an old episode of the "Space Patrol" TV series in which
the good guys spaceship was fired on by Earth spaceport defenses, which had
been set to fire on any metals not originating on Earth.

Unfortunately in a classic design glitch, the system designers had forgotten
that many of the Space Patrol's ships had been built on Pluto, and were made
of - ahem... Plutonium.

The RISKS are obvious. Whatever they are.

Steve Taylor   smt@xedoc.com.au  Xedoc Software Development


Re: Teachers Beware! [Spera, RISKS-15.23]

"Your friendly UNIX guru" <andyc@cappsdv2.fob.ford.com>
Fri, 12 Nov 93 08:53:24 +0000
> First there was writing in the palm of the hand, then the crib sheet (or back
> of the tie or sole of the shoe or etc.), next came the programmable
> calculator, now coming to a store near you, the Newton generation.

There was an alleged incident at Reading University (England) where a student
used a laptop computer in an exam.  The exam in question was "open book" but
the rules did not forbid it's use in any exam.  After this, the rules were
tightened up and each calculator had to be "certified", as either - "non
programmable" or "programmable and memory cleared".  Certificates had to be
displayed on desks, and invigilators could request that the memory be cleared
at the start of the exam.  Any device with alphanumeric memory was prohibited.
Any calculator (even a simple 4 function credit card calculator) could be
confiscated until the end of the exam unless a certificate was displayed on
the desk.

I can't vouch for the accuracy of the incident, but I was very aware of the
rules being tightened up to the point that I had to go and buy a simple
scientific calculator to use instead of my HP-28S.  And switching from RPN to
grungy-old-horrible-notation was a total pain!

Highlighting the flaws in a set of rules isn't always a good idea - it
usually gets the rules tightened too far.

 AndyC the WB (aka Andy Cunningham)    Logica Industry / Ford Motor Company
 Phone: +44 277 253765 Fax: +44 277 253582  Net:andyc@cappsdv2.fob.ford.com


FBI Operation "Root Canal" Documents Revealed

Dave Banisar <banisar@washofc.cpsr.org>
Sat, 13 Nov 1993 08:40:25 -0500
(from the CPSR Alert 2.05)

In response to a CPSR Freedom of Information Act lawsuit, the FBI this week
released 185 pages of documents concerning the Bureau's Digital Telephony
Initiative, code-named Operation "Root Canal." The newly disclosed material
raises serious doubts as to the accuracy of the FBI's claim that advances in
telecommunications technology have hampered law enforcement efforts to execute
court-authorized wiretaps.

The FBI documents reveal that the Bureau initiated a well-orchestrated public
relations campaign in support of "proposed legislation to compel
telecommunications industry cooperation in assuring our digital telephony
intercept requirements are met."  A May 26, 1992, memorandum from the Director
of the FBI to the Attorney General lays out a "strategy ... for gaining
support for the bill once it reaches Congress," including the following:

     "Each FBI Special Agent in Charge's contacting key law
     enforcement and prosecutorial officials in his/her territory
     to stress the urgency of Congress's being sensitized to this
     critical issue;

     Field Office media representatives educating their contacts
     by explaining and documenting, in both local and national
     dimensions, the crisis facing law enforcement and the need
     for legislation; and

     Gaining the support of the professional associations
     representing law enforcement and prosecutors."

However, despite efforts to obtain documentation from the field in support of
Bureau claims of a "crisis facing law enforcement," the response from FBI
Field Offices was that they experienced *no* difficulty in conducting
electronic surveillance.  For example, a December 3, 1992, memorandum from
Newark reported the following:

     The Newark office of the Drug Enforcement Administration
     "advised that as of this date, the DEA has not had any
     technical problems with advanced telephone technology."

     The New Jersey Attorney General's Office "has not experienced
     any problems with the telephone company since the last contact."

     An agent from the Newark office of the Internal Revenue
     Service "advised that since the last time he was contacted,
     his unit has not had any problems with advanced telephony matters."

     An official of the New Jersey State Police "advised that
     as of this date he has had no problems with the present
     technology hindering his investigations."

Likewise, a memorandum from the Philadelphia Field Office reported that the
local offices of the IRS, Customs Service and the Secret Service were
contacted and "experienced no difficulties with new technologies."  Indeed,
the newly-released documents contain no reports of *any* technical problems in
the field.

The documents also reveal the FBI's critical role in the development of the
Digital Signature Standard (DSS), a cryptographic means of authenticating
electronic communications that the National Institute of Standards and
Technology was expected to develop.  The DSS was proposed in August 1991 by
the National Institute of Standards and Technology.  NIST later acknowledged
that the National Security Agency developed the standard.  The newly disclosed
documents appear to confirm speculation that the FBI and the NSA worked to
undermine the legal authority of the NIST to develop standards for the
nation's communications infrastructure.

CPSR intends to pursue further FOIA litigation to establish the extent
of the FBI involvement in the development of the DSS and also to obtain
a "cost-benefit" study discussed in one of the FBI Director's memos and
other documents the Bureau continues to withhold.

----

To subscribe to the Alert, send the message:

"subscribe cpsr 

                    
    

Please report problems with the web pages to the maintainer

Top