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…
DUTCH POLICE ARRESTS HACKERS
The facts
At 10.30 in the morning of monday the 27th of January 1992 Dutch police
searched the homes of two hackers. In the city of Roermond, the parental home
of the 21-year old student H.W. was searched and in Nuenen the same happened to
the parental home of R.N., a Computer Science engineer, age 25. Both were
arrested and taken into custody. At both sites, members of the Amsterdam Police
Pilot Team for computer crime were present, alongside local police officers and
representatives of the national organisation CRI (Criminal Investigations
Agency). Both suspects were transported to Amsterdam. The brother of one of the
suspects was told the suspects could receive no visits or mail. All of this has
happened more than one week ago and the two are still in jail as we write this.
The charges
A break-in supposedly occurred at the bronto.geo.vu.nl site at the VU University
in Amsterdam. This UNIX system running on a SUN station (IP 130.37.64.3) has
been taken off the net at least for the duration of the investigation. What
happened to the actual hardware is unknown at this time.
The formal charges are: forgery, racketeering and vandalism. The police
justifies the forgery part by claiming that files on the system have been
changed. The vandalism charge is valid because the system had to be taken off
the net for a period of time to investigate the extent of the damage. By
pretending to be regular users or even system management the hackers committed
racketeering, the police says.
Both suspects, according to the Dutch police, have made a full statement.
According to a police spokesman the motive was "fanatical hobbyism".
Spokesperson Slort for the CRI speaks of the "kick of seeing how far you can
get".
`Damages'
According to J. Renkema, head of the geo-physics faculty at the VU, the
university is considering filing a civil lawsuit against the suspects. "The
system was contaminated because of their doing and had to be cleaned out. This
cost months of labour and 50.000 guilders (about US$ 30,000). Registered users
pay for access to the system and these hackers did not. Result: tens of
thousands of guilders in damages." Renkema also speaks of a `moral
disadvantage': The university lost trust from other sites on the network.
Renkema claims the university runs the risk of being expelled from some
networks.
Renkema also claims the hackers were discovered almost immediately after the
break-in and were monitored at all times. This means all the damages had
occurred under the watchful eyes of the supervisors. All this time, no action
was taken to kick the hackers off the system. According to Renkema all systems
at the VU were protected according to guidelines as laid down by CERT and
SurfNet BV (SurfNet is the company that runs most of the inter-university
data-traffic in The Netherlands).
What really happened?
The charge of `adapting system-software' could mean that the hackers installed
back-doors to secure access to the system or to the root level, even if
passwords were changed. New versions of telnet, ftp, rlogin and other programs
could have been compiled to log access to the networks.
What really happened is anybody's guess. One point is that even the CRI
acknowledges that there were no `bad' intentions on the part of the hackers.
They were there to look around and play with the networks.
About hacking in general
In the past we have warned that new laws against computer crime can only be
used against hackers which are harmless. Against the real computer criminals a
law is useless because they will probably remain untraceable. The CRI
regularly goes on the record to say that hackers are not the top priority in
computer crime investigation. It seems that hackers are an easy target when
`something has to be done'.
And `something had to be done': The pressure from especially the U.S. to do
something about the `hacking problem' was so huge that it would have been
almost humiliating for the Dutch not to respond. It seems as if the arrests
are mainly meant to ease the American fear of the overseas hacker-paradise.
A closer look at the charges and damages
The VU has launched the idea that system security on their system was only
needed because of these two hackers. All costs made in relation to system
security are billed to the two people that just happened to get in. For people
that like to see hacking in terms of analogies: It is like walking into a
building full of students, fooling around and then getting the bill for the new
alarm-system that they had to install just for you.
Systems security is a normal part of the daily task of every system
administrator. Not just because the system has to be protected from break-ins
from the outside, but also because the users themselves need to be protected
from each other. The `bronto' management has neglected some of their duties,
and now they still have to secure their system. This is not damages done, it's
work long overdue.
If restoring back-ups costs tens of thousands of guilders, something is
terribly wrong at the VU. Every system manager that uses a legal copy of the
operating system has a distribution version within easy reach.
`Month of tedious labour following the hackers around in the system'. It would
have been much easier and cheaper to deny the hackers access to the system
directly after they had been discovered. `Moral damages' by break-ins in other
systems would have been small. The VU chose to call the police and trace the
hackers. The costs of such an operation cannot be billed to the hackers.
Using forgery and racketeering makes one wonder if the OvJ (the District
Attorney here) can come up with a better motive than `they did it for kicks'.
If there is no monetary or material gain involved, it is questionable at best
if these allegations will stand up in court.
As far as the vandalism goes: there have been numerous cases of system
management overreacting in a case like this. A well trained system-manager can
protect a system without making it inaccessible to normal users. Again: the
hackers have to pay for the apparent incompetence of system management.
This does not mean that having hackers on your system can not be a pain. The
Internet is a public network and if you cannot protect a system, you should not
be on it. This is not just our statement, it is the written policy of many
networking organisations. One more metaphor: It's like installing a new
phone-switch that allows direct dial to all employees. If you get such a
system, you will need to tell your employees not to be overly loose-lipped to
strangers. It is not the callers fault if some people can be `hacked'. If you
tie a cord to the lock and hang it out the mail-slot, people will pull it. If
these people do damages, you should prosecute them, but not for the costs of
walking after them and doing your security right.
Consequences of a conviction
If these suspects are convicted, the VU makes a good chance of winning the
civil case. Furthermore, this case is of interest to all other hackers in
Holland. Their hobby is suddenly a crime and many hackers will cease to hack.
Others will go `underground', which is not beneficial to the positive
interaction between hackers and system management or the relative openness in
the Dutch computer security world.
Public systems
If you are not a student at some big university or work for a large
corporation, there is no real way for you to get on the Internet. As long as
there is no way for some people to connect to the net, there will be people
that hack their way in. Whether this is good or bad is besides the point. If
there is no freedom to explore, some hackers will become the criminals that
government wants them to be.
"Our system is perfectly secure !"
(and if you prove it's not,
we'll have you put in jail)
Felipe Rodriquez (felipe@hacktic.nl) & Rop Gonggrijp (rop@hacktic.nl)
Rop Gonggrijp (rop@hacktic.nl), editor of | fax: +31 20 6900968
Hack-Tic Magazine (only on paper, only in Dutch) | VMB: +31 20 6001480
The best magazine for staying in touch with the | snail: Postbus 22953,
the Techno-Underground. Mail to info@hacktic.nl | 1100 DL Amsterdam
National nonprofit organization working on issues concerning the social
implications of computing technology seeks managing director to assume
responsibility for overall organizational administration. Responsibilities
include management of administrative staff and volunteers; preparation of
reports; membership development campaigns; financial management; coordination
of CPSR offices and chapters; developing organizational materials; and
strategic planning. Experience desired in similar positions. Strong
communications skills required. Computer and budget experience strongly
preferred. Commitment to the peaceful and productive use of technology.
Position requires an active self-starter who wants to help develop an exciting
organization. Located in Palo Alto, California. May include periodic travel.
Salary $32,000-$38,000, with benefits, depending on experience. Send resume in
confidence to
CPSR, Managing Director Position
P.O. Box 717
Palo Alto, CA 94302-0717
(415) 322-3778
cpsr@csli.Stanford.EDU
It's apparent that some people don't have a clear idea of how the A320's
automation is set up. This has been a problem with net discussions for the
past couple of years, but it's not getting any better. There have been
numerous comments attributing what are clearly flight management problems to
the electronic flight control system (FBW): given the notoriety of the A320
(and its FBW) in the academic community, it has been assumed that other
problems are unique to it. Many are not.
Following is an attempt to explain what flight management on the A320 is, how
it differs from FBW, and how it compares to other airplanes (such as the 757).
Issues pertaining to the Strasbourg crash appear about 2/3 through. A glossary
for the (necessary) alphabet soup follows at the end. Manufacturers each tend
to use their own proprietary jargon; in light of that, I've tried to keep the
discussion as generic as possible.
First, the physical concept of "autopilot" is obsolete on the A320. Instead,
Airbus uses a "Flight Management and Guidance System" (FMGS). A more generic
term for this is a flight management *system* (FMS). Note the emphasis on
*system*.
An FMS is a way to accomplish four major goals:
o Control the flight path of an airplane, in four dimensions,
from takeoff to landing.
o Make sure that this is done as profitably as possible.
o Provide high-level services to flight displays and other
systems.
o Eliminate many of the "book-keeping" roles in the operations
environment, traditionally performed by a flight engineer.
An FMS has many components, the most important of which are:
1. A Flight Management Computer (FMC). This does all the thinking. It
derives data from many sources, such as air data computers. On the A320, many
input services are partially integrated into the FMS proper. An A320 has two
FMCs.
2. Inertial Reference System (IRS) units. These are what Inertial Navigation
Systems (INSs) have evolved into; when combined with an FMC, they lead to more
features, and are more reliable. They provide position information to the FMC.
The FMC has the capability of automatically tuning in VORs and DMEs and
verifying the aircraft location, thus correcting for en route precession error
in the IRS. There are three IRSs on the A320.
3. A Control Data Unit (CDU). This lets the pilot enter a variety of abstract
data, such as the flight number, what the intended route of flight is,
preferred cruising altitudes, navaids and fixes to use, etc. The FMC is able
to relate all this to an internal database of airports and navaids, and provide
a number of convenient features. Using this--as well as features which amount
to being a glorified performance calculator-- the pilot can sketch out a
relatively profitable trip. There are normally two CDUs on the A320, one for
each pilot.
As the first of many asides, at least one recent poster has implied that the
FMS interface is similar to that of an INS, which it isn't. The pilot
generally does not deal with lat/long numbers, so the potential for a KAL 007
sort of mismanagement is minimal: he deals with gate numbers and four-digit
ICAO mnemonics for the airport at hand (but mistakes are still quite common).
Some airlines have card readers that feed everything in automatically: the
pilot need only verify the flight plan. This process, too, is different from
the INS. The user does not normally view the navigation product of the FMS
through lat/long readouts on the CDU. Instead, a navigation display shows a
plan view of aircraft position, in a variety of scales and formats. The use of
the CDU is required when any changes to various types of abstract data are
made.
4. A Flight Control Unit (FCU). This is what confuses a lot of people. The
FCU is where the autopilot interface used to be in older airplanes, such as the
747-200. It looks a lot like it as well. It is used for selecting short-term
features of the FMS, especially heading hold, altitude capture, rate of
descent, and autothrottle. The FCU's similarity to an old-fashioned autopilot
interface is intentional, but, again, it's just an interface to the FMS. This
concept is extended to other input devices in the cockpit. The frequency
selectors on the radio panels, for instance, serve as user-friendly input
mechanisms for the FMS.
Autopilots (until the advent of FMSs) traditionally have been structured
around the pilot commanding short-term actions, which the autopilot then
faithfully executed. This frees the pilot to adopt a more supervisory role: he
can deal with ATC, systems, track weather better, etc. It is also generally
less fatiguing than hand-flying. Airbus classifies traditional autopilot
management as "selected" control.
FMSs also provide such short-term capability (via the FCU). But the FMS can
be set to meet all the waypoints and clearance altitudes *automatically*,
without any significant interaction needed from the pilots on the CDU or FCU.
Airbus classifies this as "managed" control.
In effect, with a properly set-up FMS, the pilot can plan a flight from takeoff
to landing. After lining up the airplane on the runway, he can just turn loose
the FMS, which then flies the airplane, requiring minimal crew interaction.
The system can then take the airplane through a category III landing (700 feet
runway visual range). Of course, air traffic control is rarely so obliging, so
en route modifications must be made to the stored flight plan.
This is all done with the presumption that the FMS will figure out and use the
absolutely cheapest way to fly the airplane. Even a 1% waste of fuel can cost
an airline tens of millions of dollars a year. The main problem with
"profitability" is that ATC is not geared to handle FMS-equipped airplanes, and
its actions soak up a lot of the "saved" money. It is not clear whether this
situation will change in our lifetimes.
FMSs are here to stay: but the design of interfaces are a major point of
contention among many pilots. Mention "automation," and they don't think EICAS
or FBW: they think FMS. While many features have been added at the hardware
level in the last ten years, the CDU interface has changed hardly at all. A
significant criticism--and the most persistent--is that, since any changes to
an airplane's clearance (the route of flight ATC has approved for it) require
changes to the internal flight plan, and since this requires use of the CDU,
thus leading to a heads-down posture, safety can be affected: the pilots are
not able to practice "see and avoid." In addition, it requires a SIGNIFICANT
refocusing of one's attention and attitude, from flying the airplane, to
dealing with an unfriendly user interface. It therefore helps put pilots even
further out of the loop. This increases workload, but workload can increase
even more in terminal environments, where frequent changes to clearances are
common (a terminal environment is the airspace where aircraft are being routed
to or from a nearby airport). Many airlines have restricted CDU use under
18,000'; still more under 10,000'. In such cases, the airplane is flown with
the FCU, or, occasionally, even by hand (!).
Balanced against the CDU interface problem is the high degree of "situational
awareness" the overall system provides, when one isn't fiddling with the CDU.
The FMS provides a number of output services, including navigation
information:, the FMCs are the heart of navigation services. One can therefore
look at one's navigation display, and see a graphic spatial representation of
heading, track (calculated path across the ground), nearby alternate airports,
where one will be when one completes a climb or descent, what VORs the airplane
is using, where the fixes are, etc. This sort of thing is pretty popular with
pilots. But the quality of the derived data products is dependent on the
quality of data in the system: thus, there's a tendency to try to keep as much
of the display "valid" as possible, which lends to excessive CDU interaction.
On the issue of "authority," it is important to note that the pilot must
explicitly requests FMS services. The FMS is "on" all the time; but it only
*controls* the airplane when the pilot wants it. Whether executing a stored
flight plan, or selecting short-term features, the PILOT holds the ultimate
authority over the operation of the system. If, after the FMS is engaged, it
performs unsatisfactorily, the pilot can just "click it off" (disengage it).
There are at least three ways to accomplish this (a switch on the sidestick,
buttons on the FCU, or, as a very rare last resort, a circuit breaker). After
disengagement, the pilot simply flies "manual" (although "manual" in the A320
is still filtered by numerous computers, and still an artificial construct).
The capacity to disconnect assumes the pilot is "in the loop," and is aware
that a problem (whatever its cause) exists, to the point of applying corrective
action in time. Cockpit interruptions, heads-down postures (CDU interaction or
systems diagnostics), fatigue, or checklists can affect this capability.
Another factor is the WILLINGNESS to disconnect: a significant problem is that
pilots tend to wait too long before clicking off a system; they can become
over-dependent on automation.
It is unlikely that faults in FMS design could logically migrate to the FBW
computers, or vice versa, barring *possibly* a significant electrical system
failure. There are elaborate safeguards to protect against completely
off-the-wall instructions, but a more insidious, higher-level (but erroneous)
command within parameters would simply be quietly executed by the receiving
system. It is impossible, as one person recently suggested on sci.aeronautics,
for the *FBW* to "freeze" the airplane into some arbitrary navigation maneuver,
such as a holding pattern (that tale, repeated at least twice in the last
couple of years, is taking on the form of an Urban Legend).
The important point to note about all of this is that the FMS has NOTHING
WHATSOEVER TO DO WITH FLY-BY-WIRE. It is at least a couple of levels "higher,"
from the systems integration perspective, than the FBW service. FMSs are used
in virtually all modern airliners, such as the 757, 767, 737, MD-11, MD-80,
A310, A300-600, and, yes, the A320. Pick an airliner manufactured since 1982,
and it'll probably have a cockpit designed around an FMS control concept,
regardless of whether it has glass displays, FBW, or both.
Of particular interest, recently, has been the A320 FMSs "vertical navigation"
functionality. In what follows, "autopilot" should be regarded as a synonym
for "FCU," with the understanding that it's just a high-level interface to the
FMS, using a subset of FMS features, and can be "clicked off."
A few people have been saying things like "altitude can't be set on the
autopilot." That is incorrect. The A320's altitude selector is located on the
right side of the FCU. Not only can the user set the altitude to fly, but can
also set the rate of climb that the airplane should fly at in order to achieve
it. The latter can be achieved three ways:
1. By pressing an "Expedite" button, located under the altitude-selector
window. This will make the airplane reach the desired altitude as FAST as
possible, using either maximum climb attitude and climb thrust, or flight-idle
and maximum airspeed.
(With the following two modes, one can either select a capture altitude, or let
the airplane fly "free." The distinguishing feature between the modes is a
simple push-button.)
2. By simply dialing a value into the vertical-speed selector. For example, if
one wishes to fly 3000 feet per minute up, the user just dials in 3000 fpm.
3. By flying a flight path angle (FPA). This is an angle the airplane's
flight path will make with the ground. The intended use of this feature is
rather obscure (other advanced aircraft do not support it), but apparently one
application is for use in conjunction with nonprecision approaches to airports.
A non-precision approach is one that does not include vertical guidance: the
airplane is vectored in a manner such that it reaches a "final approach fix"
pointed in the right direction relative to some sort of navigation aid, then
flies down to a minimum descent altitude. It then flies toward the airport
until it sees it, and can land visually, or is compelled to try again (or
divert to an alternate). An ILS, in comparison, provides vertical guidance
from the final approach fix down to the ground, even in very marginal
visibility. A normal ILS (or visual) approach angle is 3.0 degrees; a
non-precision approach is too complex to categorize briefly. The point has to
be made, though, that FPA is one of the strangest features in the A320: the
airspace system isn't really set up to let the pilots use it effectively.
On the A320, in a rather dubious interface, the FPA mode and vertical-speed
mode share the same selector. The way vertical speed is set is to dial in a
TWO-digit number. So 30 = 3000 feet per minute up; -30 = 3000 fpm down. There
is no additional feedback--like a couple of extra zeroes-- to indicate one's
dialing in "3000." The SAME selector, and the SAME indicator, are used to set
"flight path angle." So 30 would then equal a flight-path command of 3.0
degrees down. The difference between the two modes, as said before, is the
push of a button, and an easy-to-overlook decimal point. The A320 uses a
liquid-crystal display, with fixed numeric elements, to display all of the FCU
indicators.
So, say one wishes to fly a 3.0 degree flight path. This is the normal slant
range between a "final approach fix" and an airport. This would give one a
descent from 700 to 900 feet per minute, and the computer would automatically
adjust the aircraft's attitude to maintain a glide path, if the pilot lowers
flaps, commands a change in airspeed, etc. But there's a clear potential for
disaster if this mode is *confused* with "vertical speed" mode. How
significant is this? If one is 3000' above the ground, and sets a 3.0 degree
flight path, one would contact with the ground in four minutes. If one
accidentally engages vertical speed mode, instead, one will contact in sixty
seconds. All this is a tad bit simplified, to relate it to normal
"straight-in" approach angles: the let-down portion of a non-precision approach
would require an even steeper angle (4.0 degrees), with similar consequences
should modes be confused.
I am interpreting union comments on the Strasbourg crash as suggesting this
type of mode confusion may have contributed to the crash. In this case, the
FPA mode may have been used in response to an enroute descent air traffic
control clearance. When the airplane crashed, it was descending at some 2300'
per second, according to one source. The angle of descent between the two
transition points the airplane was cleared to fly was 2.28 degrees (from 9000'
to 5000', over 19 statute (?) miles).
Similar theories about the FPA mode abounded after the Bangalore crash, but
proved unfounded (instead, a more complex pattern of FMS mismanagement
emerged). The British pilots' union, though, early on cited the poor interface
as one that needed to be improved, in a report dated July 1988, a few months
after the airplane was introduced into service:
"4.2. Glareshield Flight Control Unit. Despite the LCD labelling
on the FCU, and the FMA annunciation on the PFD, it is still
possible for pilots to commence an approach in the wrong vertical
mode, i.e., vertical speed rather than flight path angle. Under
pressure, the tendency is merely to look at the figures one is
selecting, and the figures themselves look almost identical in both
modes. The selection of FPA merely adds a decimal point. I have
seen a non-precision approach commenced with the selection of
3000 fpm instead of 3.0 and the result was quite exciting. The FCU
figures in FPA mode should be made to look quite different - e.g.
the figure after the decimal point in small font."
An important point is that automatic control of the airplane can lead to a
mismanaged energy state, just as manual control can. The FBW protections in
the A320 are designed to provide high-speed, loaded, and slow-speed
protections. It does nothing to stop the pilot from managing the airplane in
such a manner that it gets dangerously close to an obstruction (the ground)
without enough energy--or even too much energy--to pull out of danger. This is
what Airbus claimed happened with the crashes at Habsheim and Bangalore, with
the pilots flying manually and dealing with the FCU, respectively. Airbus's
Bernard Ziegler's "black holes": energy states the airplane could not recover
from.
Airbus is faced with the contradictory problems of "protecting" against gross
incompetence (safety issues which IT defined as problems, and which its
marketing people ran away with), without being able to "protect" from the types
of mismanagement their own extreme, and unrealistic, protections appear to
engender. Far from changing its interface, it long ago froze it, for use in
its newest aircraft, the A330 and A340, thus assuring commonality in
training--and theoretically ensuring a market share among airlines who have
bought heavily into the A320. But I digress. :-)
If nothing else, I hope I've made the point that FBW is NOT equivalent to
flight management. FBW computers are relatively simple and straight-forward in
design and purpose: FMSs are fairly complex software/hardware packages. The
correct functioning of them is important (especially when used in certain
ways), but not as ESSENTIAL as the FBW system.
In addition, note that the A320's automation includes many more services than
just FMS-derived and FBW: there are various mechanisms to display and control
systems information, warning and caution computers, etc. It's also important
to note that the A320's cockpit design concept (with the exception of
sidesticks and throttle management) is fairly close to that of other airplanes
in production or development at this time (747-400, 777, MD-11, etc). FMS is
not unique to the A320, although its actual integrated environment (as with all
the airframe vendors) is proprietary and unique.
Irritating Jargon:
ATC Air Traffic Control autothrottle A mechanism for controlling
aircraft speed from the autopilot.
CDU Control Data Unit
DME Distance Measuring Equipment/station.
EICAS Engine Indication and Crew Alerting System.
FBW Fly by Wire.
FCU Flight Control Unit.
fix A geographic point, designated by the FAA as a reference point.
Used in navigation and routing by ATC.
FMC Flight Management Computer.
FMGS Flight Management and Guidance System.
FMS Flight Management System.
IFR Instrument Flight Rules.
ICAO International Civil Aviation Organization.
ILS Instrument Landing System.
INS Inertial Navigation System.
IRS Inertial Reference System.
KAL Korean Airlines.
PFD Primary Flight Display
VOR VHF Omni Range.
Robert Dorsett rdd@cactus.org UUCP: ...cs.utexas.edu!cactus.org!rdd
Please report problems with the web pages to the maintainer