The RISKS Digest
Volume 22 Issue 19

Monday, 19th August 2002

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…


Name filtering affects police officer
Fuzzy Gorilla
Massive ATM fraud after security problems due to Sept 11
Tom Van Vleck
A universal Turin machine?
Win32 API utterly and irredeemably broken
Monty Solomon
Microsoft EULA asks for root rights — again
Monty Solomon
FTC Stamps Microsoft's Passport
Monty Solomon
Keystone SpamKops
Edward W. Felten
Re: Listen to TCAS, not the controller
Peter B. Ladkin
An automation-related AIRPROX incident
Peter B. Ladkin
Info on RISKS (comp.risks)

Name filtering affects police officer

<"Fuzzy Gorilla" <>>
Thu, 15 Aug 2002 18:41:31 -0400

It is not clear that we will ever solve the problem of computerized
filtering based on "lewd" names when even humans can't get it right.

The badge of El Paso police officer Christine Lynn O'Kane (and her e-mail
address) identified her as C. O'KANE (which unfortunately looks like
'cocaine').  After leaving the force for personal reasons and later
reapplying, she was denied reinstatement on the grounds that her name was
inappropriate — despite her good service record that included an explicit
recommendation her work file supporting her reinstatement.  Although her
appeal to the Civil Service Commission resulted in her being rehired, she
has now reverted to her maiden name (Whitaker).
  [Source: Cop In Trouble Over Name, AP, 12 Aug 2002; PGN-ed]

Massive ATM fraud after security problems due to Sept 11

<Tom Van Vleck <>>
Mon, 5 Aug 2002 20:18:08 -0400
  [This is in French, but not yet reported in English.
  Translation with the help of Babelfish.  thvv]

4000 people are suspected of taking a total of $15 million in ATM overdrafts
from the NY Municipal Credit Union, whose computer system was damaged by
9/11 attacks and the phone and electric outages that followed.  The CU chose
to allow withdrawals of up to $500/day without checking.  Word got around.
One person withdrew over $18,000 in 54 transactions.

A universal Turin machine?

<"Peter G. Neumann" <>>
Mon, 19 Aug 2002 15:06:53 PDT

Seeing the number 4000 in the foregoing message from Tom Van Vleck reminded
me of an article I read 12 days ago in *The Herald Tribune* Italian edition
supplemental highlights from *Corriere della Sera* in English, 7 Aug 2002:
Police probe credit card scam.  Turin police obtained a cigarette-pack-sized
machine that been used by an up-scale restaurant to make about 4000
perfect-copy credit cards from cards used by customers, including mag
stripes.  The Clone Arranger Strikes Again.  (The Shrewd of Turin?)

Win32 API utterly and irredeemably broken

<"monty solomon" <>>
Mon, 19 Aug 2002 12:44:53 -0400

Thomas C Greene in Washington, 7 Aug 2002

Windows might possibly be the most insecure piece of viral code ever to
infect a computer, according to Chris Paget who's found a fascinating hole
in the Win32 Messaging System which he believes is irreparable, and which
he posted to the BugTraq security mailing list.

The research leading to this discovery was inspired by MS Veep Jim Allchin,
who testified to the effect that if flaws in the Windows Messaging System
were sufficiently understood, national security would be deeply compromised,
CRUISE missiles would be launched remotely, and /bin/laden would most likely
find some novel way of raping your daughter with his big bad mou Paget has
brought at least some of Allchin's fears to fruition ...

Microsoft EULA asks for root rights — again

<Monty Solomon <>>
Sun, 4 Aug 2002 23:03:51 -0400

Andrew Orlowski in *The Register*, London, 2 Aug 2002

An addition to Microsoft's End User Licensing Agreement has alarmed
*Register* readers.  Windows XP Service Pack 1 and Windows 2000 Service Pack
3 contain a new condition which asks you to allow Windows to go and install
future updates.  "You acknowledge and agree that Microsoft may automatically
check the version of the OS Product and/or its components that you are
utilizing and may provide upgrades or fixes to the OS Product that will be
automatically downloaded to your computer," is the new bit you'll be
interested in.  ...

FTC Stamps Microsoft's Passport

<Monty Solomon <>>
Fri, 9 Aug 2002 18:05:42 -0400

FTC Stamps Microsoft's Passport

Yesterday Microsoft settled a complaint by the Federal Trade Commission that
its Passport user-ID service had violated its own privacy policy and was
insufficiently secure. Almost every outlet featured the story prominently,
and the Wall Street Journal e-mailed one of its infrequent Technology Alerts
yesterday after the FTC/Microsoft conference call.  ...

Keystone SpamKops

<"Edward W. Felten" <felten@CS.Princeton.EDU>>
Fri, 16 Aug 2002 09:45:06 -0400

I recently set up a web site at  It's a weblog
containing my commentary on various issues.  Earlier this week, my ISP shut
off the site, because the site had appeared on a list of "spammers"
published by an outfit called SpamCop.

Apparently, this happened because one person, whose identity I was not
allowed to learn, had sent SpamCop an accusation saying that he had received
an unwanted e-mail message, which I was not allowed to see, that did not come
from me but that did mention my web site.  On that "evidence" SpamCop
declared me guilty of spamming and decreed that my site should be shut down.
Never mind that I had never sent a single e-mail message from the site.
Never mind that my site was not selling anything.

Naturally, I was not allowed to see the accusation, or to learn who had
submitted it, or to rebut it, or even to communicate with an actual human
being at SpamCop.  You see, they're not interested in listening to
complaints from spammers.

With help from my ISP, I eventually learned that the offending message was
sent on a legitimate mailing list, and that the person who had complained
was indeed subscribed to that list, and had erroneously reported the message
as unsolicited.  Ironically, the offending message was sent by someone who
liked my site and wanted to recommend it to others.  Everybody involved (me,
my ISP, the person who filed the complaint, and the author of the message)
agreed that the report was an error, and we all told this to SpamCop.
Naturally, SpamCop failed to respond and continued to block the site.

Why did my ISP shut me down?  According to the ISP, SpamCop's policy is to
put all of the ISP's accounts on the block list if the ISP does not shut
down the accused party's site.

Note the similarities to the worst type of Stalinist "justice" system:
conviction is based on a single anonymous complaint; conviction is based not
on anything the accused did but on favorable comments about him by the
"wrong" people; the evidence is withheld from the accused; there is no
procedure for challenging erroneous or malicious accusations; and others are
punished based on mere proximity to the accused (leading to shunning of the
accused, even if he is clearly innocent).

Note also that the "evidence" against me consisted only of a single unsigned
e-mail message which would have been trivial for anyone to forge.  Thus
SpamCop provides an easy denial of service attack against a web site.

The only bright spot in this picture is that our real justice system allows
lawsuits to be filed against guys like SpamCop for libel and/or defamation.
My guess is that eventually somebody will do that and put SpamCop out of

  [By the way, there is more discussion of this incident on my blog site at

Re: Listen to TCAS, not the controller (Morell, Risks 22.18)

<"Peter B. Ladkin" <>>
Thu, 15 Aug 2002 11:38:00 +0200

In RISKS-22.13, Bob Morell discusses the midair collision on 1 Jul 2002 over
Southern Germany, in which a Bakshirian Airlines Tupolov 154, operating as
BTC 2937, collided with a DHL Boeing 757-200, operating as DHX 611, although
both were using ACAS II-compliant collision-avoidance systems, namely
Honeywell TCAS II Version 7 systems [1] (TCAS is "kit"; ACAS II is the
international designation for a requirement which TCAS II Version 7

Morell is right in saying that more comment is due on this accident.
However, his comment is misleading, particularly because of its superficial
plausibility.  Most misleading of all is the title suggestion that the crew
of BTC 2397 (BTC CRW) should have listened to TCAS rather than the
controller.  To the contrary, their cognitive model may well have been such
that prioritising the controller's advisory over the Resolution Advisory
(RA) from TCAS would have been the most rational decision to make, as I note

An extended version of my comment is available as "ACAS and the South German
Midair", RVS-Occ-02-02, on

First, a brief explanation of how TCAS II avionics operates [2,3]. TCAS II
broadcasts signals on the radar-interrogation frequency, and receives
responses from other aircraft's transponders. A Mode C transponder is a
device which responds to radar beams of a certain frequency with information
on the aircraft's identity and its "pressure altitude" - the altitude at
which it would be flying in an "international standard atmosphere" at the
measured outside air pressure. Additionally, the Mode S transponder used
with TCAS II may receive and transmit messages, a facility used essentially

TCAS II gives two types of advisories, Traffic Advisories (TAs) and
Resolution Advisories (RAs). It displays the approximate relative position
and separation of conflicting traffic visually on a display screen, and
announces the advisory via simulated voice. TAs alert a crew to the presence
of a potentially conflicting aircraft (determined by presence within a
specified volume of surrounding airspace), and attempts to predict
time-to-go to collision (TTG). When TTG reaches a certain threshold, a TA is
generated; when TTG reaches a lower threshold, an RA is generated upon
negotiation with the other aircraft's TCAS II, if it is so equipped. A TA is
just a warning; pilots are not expected to manoeuvre in response to a TA. An
RA is an advisory to climb, or to descend. An algorithmic negotiation
between the TCAS II avionics on both aircraft ensures that one aircraft of a
TCAS-II-equipped conflicting pair receives a climb RA and the other a
descend RA.

Morell speculates whether BTC CRW made a "mistake" or not, and suggests that
the descent decision and action "if the reports on the Russian training are
correct, was not, technically speaking, a mistake on the pilot's part...."

It is not clear to me what Morell's concept of a "mistake" is. First, any
pro forma operational suitability of BTC CRW's actions is determined by
German aviation law and associated approved procedures in German airspace,
not by any "Russian training". Second, in private correspondence, Morell
suggested that the RTC CRW action was "obviously" a mistake, since the two
aircraft collided. I don't know what it would mean for the action to be a
mistake, but at the same time not to be "technically speaking" a mistake.
Besides, the criterion offered is clearly insufficient: DHX CRW action led
just as inexorably to the collision, but it would be anachronistic to refer
to this action as a "mistake".

I feel such speculation about possible pilot error without a careful
analysis of the interactions in the cockpits, as contained on the cockpit
voice recorder (CVR), is unwarranted. The CVR often provides the only means
of assessing the quality of CRW decision making, and in this menage a trois
equipes in which four of the five participants are dead, I think such
analysis is essential.

Morell says, astoundingly, that "TCAS is a highly tested system with a
flawless record", apparently not counting this midair as a failure. On the
contrary, the TCAS avionics were a causal factor in this accident: had
neither aircraft been so equipped, the accident would not have happened (DHX
CRW would have maintained altitude as cleared; BTC CRW would have descended
as cleared and as they did; the aircraft would have missed each other by

The TCAS system, like most complex systems which depend essentially on human
action, does not have a "flawless record", even previous to this
accident. There are significant operational issues with previous TCAS
versions (such as 6.02 and 6.04a), which remain (while reduced) with TCAS II
Version 7. Eurocontrol training materials say that TCAS "... cannot
eliminate all risks of collision. Additionally, as in any predictive system,
it might itself induce a risk of collision" [4, p17].  The Eurocontrol ACAS
Operational Evaluation indicates a substantial history of false positives
("unnecessary RAs") [5]; the latest version, Version 7, shows a "40%
reduction in unnecessary RAs" [6].

False positive RAs are not merely a nuisance; in dense traffic areas, which
is where RAs are most likely to be generated, manoeuvres in accordance with
RAs disrupt ATC planning and generate immediately an unanticipated higher
workload for a controller, which can be a safety risk when a controller is
operating near the limits of higher capacities. There has been a significant
rate of "nuisance" advisories, and one can anticipate pilots' reactions to
the system crying "wolf" too often.  Lincoln Labs apparently reported that
that over 50% of RAs occurring in U.S: airspace are ignored [5, Section 5.3,

Such operational issues arise with, for example, "stacks" of aircraft
queuing for approach to an airport in instrument meteorological conditions,
and in the European Reduced Vertical Separation Minimum airspace, introduced
this year between Flight Levels 290 and 410 (between 29,000 ft and 41,000 ft
in an "international standard atmosphere").  In both of these cases,
aircraft are operating as cleared with only one thousand feet of nominal
vertical separation. Altitude measuring equipment is allowed to be up to +/-
64 ft deviant in RVSM airspace, and altitude reporting equipment reports in
either 25ft or 100ft increments. Two TCAS-equipped aircraft operating as
cleared may well "see" each other separated by less than 850 ft, sufficient
to generate a "nuisance" TA. Add effects of turbulence, or of a
non-perfectly executed levelling off manoeuvre at a new cleared altitude
("bump up" or "bump down") and a "nuisance" RA can easily be generated [7].

One should not identify an ACAS II-compliant system with the TCAS II Version
7 avionics alone.  The avionics influence an aircraft's flight path only
through the crew's decisions and actions.  The procedures which crew are
advised to follow, and their understanding of the situation (their
"cognitive model") are essential components of the ACAS system.  Not only
that, but it is possible for misleading controller advisories to alter the
cognitive model of one or more of the crew involved, indicating that the
controller's role must be considered in any safety analysis of ACAS

Facts already available concerning the July 1 midair collision highlight
certain difficulties with ACAS operation, namely that ACAS does not handle
some three-aircraft conflicts well. Consider the situation engendered by the
circumstances on July 1.

We may assume that BTC CRW and DHX CRW knew that there were only two
ACAS-equipped aircraft involved in the conflict. This information would be
displayed; BTC CRW would see DHX at their 10 o'clock position (60 degrees
left of straight ahead). However, at 23:25:03, 7 seconds after the first RA,
BTC CRW were informed by air traffic control that there was conflicting
traffic at their 2 o'clock position (60 degrees right of straight ahead)
[1].  This aircraft was not on their display - indeed was not there; the
controller's advisory was a cognitive mistake. BTC CRW is now faced with the
following situation: there is a conflict with traffic painted by TCAS at
their 10 o'clock position and also with non-painted traffic at their 2
o'clock position. Their cognitive model poses a three-aircraft conflict
situation. (One of these aircraft is a "ghost" but they do not know it.)

The importance of this scenario does not depend on what did or did not
happen in the accident on July 1. We may find out from CVR and other
evidence, or we may not, what BTC CRW's cognitive model actually was. The
importance lies in that it is an ACAS scenario whose components have
actually occurred, and therefore it must be analysed as part of a safety
assessment of ACAS.

Let me use "Aircraft A" for the DHX-similar aircraft, "Aircraft B" for the
BTC-similar aircraft, and "Aircraft C" for the aircraft at Aircraft B's 2
o'clock position. Since TCAS is not painting Aircraft C, Aircraft B CRW can
suppose that Aircraft C will not be involved in any RAs. It is hard to say
what cognitive model Aircraft A CRW have, since they might not have heard or
assimilated the controller's mistaken advisory to Aircraft B CRW. So I shall
not consider their cognitive model. Aircraft B CRW do not know whether the
controller is in contact with Aircraft C or not, although it might be
reasonable to suppose so. ATC has issued a descent instruction to Aircraft B
to take Aircraft B out of conflict with Aircraft C. Further, Aircraft B have
received an RA to climb. They can conclude that the RA was negotiated with
Aircraft A, since their TCAS display is painting Aircraft A as the
"intruder", and that Aircraft A has received a descent RA.

There is a clear strategy for Aircraft B CRW to follow when both
controller's advisory and RA agree. They follow it. They then come to be in
further trouble only if Aircraft A manoeuvres in the reverse sense to their
presumed RA.  However, a dilemma is directly posed if the controller's
advisory and the RA do not agree in sense. One rational strategy could be
termed "better the devil you know".  Aircraft B CRW can follow the
controller's advisory to avoid Aircraft C, and attempt to use the TCAS
display information to acquire Aircraft A visually and avoid it. They could
also attempt to reduce speed to give greater TTG until conflict with
Aircraft A.

Risky as this is, I see no more rational strategy available to Aircraft B
CRW.  Not even this meagre strategy is available if they are in Instrument
Meteorological Conditions.

The manoeuvres of BTC CRW on July 1 are consistent with this strategy, which
violates the oft-repeated advice to pilots not to manoeuvre contrary to an
RA. I suggest on the basis of this scenario that this advice is not
universally applicable. Indeed, the benefit of ACAS in this situation to
Aircraft B is in knowing roughly where Aircraft A is - a benefit provided
equally well by TCAS I, which does not generate RAs at all.

I believe this scenario shows that it is illusory to imagine that better or
more uniform training will resolve ACAS operability problems.  Before
solutions can be trained, we first need a solution, and I doubt there is one
for this scenario based on ACAS technology.  I refer to my extended note for
other cases, involving three ACAS-II equipped aircraft, for which it is also
unclear to me that a solution exists.

Peter B. Ladkin, University of Bielefeld,


[1] Bundesstelle fuer Flugunfalluntersuchung, Presseinformation,
Zusamme nstoss am Bodensee (available also in English), reviewed July
28th, 2002,

[2] Mitre Corporation, Center for Advanced Aviation System Development
(CAASD), Traffic Alert and Collision Avoidance System,

[3] Honeywell, Inc. Advanced Collision Avoidance Systems, at

[4] Eurocontrol, ACAS II Training Manual, Version 2, available from -> Projects -> ACAS -> Training Materials
-> Training Manual Version 2, May 2000.

[5] Eurocontrol Experimental Center, European ACAS Operational
Evaluation, Final Report, Eurocontrol Experimental Centar Report
No. 316, July 1997, available at -> Documents -> (Search) Final Report 316
-> Reports for the Year 1997 -> 316.

[6] Mitre Corporation, Center for Advanced Aviation System Development
(CAASD), Traffic Alert and Collision Avoidance System,

[7] Eurocontrol, ACAS II Operations in the European RVSM Environment,
Project ACTOR, available from -> Projects -> ACAS -> Training Materials
-> Brochure f11, 2 August 2001.

An automation-related AIRPROX incident

<"Peter B. Ladkin" <>>
Thu, 15 Aug 2002 16:07:31 +0200

On 2 Oct 2000, there was a loss of separation (an AIRPROX incident in
jargon) on the North Atlantic Track E from Europe to North America between
an Airbus A330 and an Airbus A340 aircraft. The aircraft were operating
under Reduced Vertical Separation Minima (RVSM), in which high-altitude
aircraft may use a nominal vertical separation of 1,000 ft from each other
for their operations instead of 2,000 ft, which has been standard. RVSM had
been introduced for trials on the North Atlantic track system, and was
introduced in European airspace in January 2002. RVSM depends essentially on
participating aircraft using Airborne Collision Avoidance System (ACAS)
equipment. Both incident aircraft were using Traffic alert and Collision
Avoidance System (TCAS) Version 6.04 avionics.

I shall describe the incident briefly, omitting some salient observations
made in the report. Since the report is about eleven A4 pages of prose and
data, I recommend reading it in full [1].

The A340 was cleared at Flight Level (FL) 360 (the altitude at which the air
pressure is the same as that at 36,000 ft in an International Standard
Atmosphere), and the A330 at FL 370. The A330 was roughly abeam and slowly
overtaking the A340, when the aircraft encountered clear air turbulence,
described by the A340 captain as severe.

The A340 entered a "zoom climb", and went up to FL384, some 2,400 ft above
its assigned FL and 1,400 ft above the FL assigned to the A330.  Both
aircraft had been receiving Traffic Advisories (TAs) on each other for some
minutes before the incident, and during the incident received TCAS
Resolution Advisories (RAs); the A340 was advised to descend and the A330 to
climb. The A330 captain said that the A340 passed through his FL, some
200-300ft to his left, before he had time to react to the RA. The maximum
rate of climb of the A340 during the incident was recorded to be some 6,000

At the time the first RAs were issued, the aircraft were likely separated by
some 800 ft, and the RAs were "nuisance" RAs due to the turbulence, as
described in [2]. The A340 had not begun its zoom climb. About ten seconds
later, though, the A340s flight control system captured "alpha prot", and
the A340 commenced its climb. "Alpha prot" is a value of a flight parameter
known as the "phase-advanced angle of attack" which triggered a change from
the "normal" flight control law in the Airbus fly-by-wire control system to
the "angle of attack protection" law, or AoA law. When both control
sidesticks remain neutral, AoA law attempts to maintain the angle of attack
(inclination of the aircraft's wing to the air it is flying through; the
major parameter used in controlling lift in flight) at the value it has at
the point of reversion. One may presume that the turbulence encountered had
momentarily increased the angle of attack to a high value at the time that
alpha prot was captured.

Right before alpha prot was captured, the A340's airspeed briefly rose above
its "limiting value" of 0.86 Mach (0.86 times the speed of sound at that
altitude), due to the turbulence encounter. This triggered a Master Warning,
and also disconnected the autopilot. The Fault Warning Computer prioritises
warnings, and the autopilot disconnect warning was suppressed for about six
seconds in favor of the Master Warning. It is surmised that the crew may not
have registered the TCAS RA because of the interference of the other
warnings. The crew responded right away (within five seconds) to the Master
Warning by reducing thrust.

The investigation suggests that, because of the fluctuations caused by the
turbulence, the reversion from normal law to AoA law would likely not have
been sensorily detected. Furthermore, this reversion is not possible under
autopilot control. It is likely that the crew then had, for up to six
seconds, no obvious reason to judge that the aircraft was operating in AoA

The investigators say that "Such was the vigor of the A340's climb in AoA
law, the aircraft could well have climbed through FL 363 (thus provoking a
TCAS RA with revised software version 7.0) in a very short time, even if the
crew had applied nose-down sidestick as soon as they heard the (delayed)
autopilot disconnect warning. The climb to FL 363 would have been sufficient
to generate a TCAS RA in any adjacent aircraft at FL 370 but, if the
intruder aircraft continues its climb, there can be no guarantee that an
aircraft directly above it could respond in sufficient time to avoid a

The incident raises the issue of operations under RVSM. The investigators
recommended suggested that such an incident is relevant to the safety case
being made at that time for the introduction of RVSM in Europe. The incident
shows that that a combination of a turbulence encounter, automated flight
control, and RVSM could prove deadly, with or without improved versions of

Peter B. Ladkin, University of Bielefeld,


[1] U.K. Air Accidents Investigation Branch, AAIB Bulletin 6/2001,
Ref. EW/C2000/10/2,
<A HREF=""></A>

[2] Eurocontrol, ACAS II Operations in the European RVSM Environment,
Project ACTOR, available from
<A HREF=""></A> ->
Projects -> ACAS -> Training Materials
-> Brochure f11, 2 August 2001.

Please report problems with the web pages to the maintainer