Subject: RISKS DIGEST 13.11 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Weds 5 February 1992 Volume 13 : Issue 11 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Dutch Hackers in Jail (Rop Gonggrijp) Managing Director Job Announcement for CPSR (Eric Roberts) Contribution on A320 FMSs (Robert Dorsett) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP domain folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 13, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: 8 Feb 92 17:11:17 GMT From: rop@hacktic.nl (Rop Gonggrijp) Newsgroups: comp.risks,comp.dcom.telecom,alt.security,... Subject: Dutch Hackers in Jail 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 ------------------------------ Date: Tue, 4 Feb 1992 20:06:14 GMT From: eroberts@CS.Stanford.EDU (Eric Roberts) Subject: Managing Director Job Announcement for CPSR Newsgroups: comp.risks,comp.society 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 ------------------------------ Date: Mon, 3 Feb 92 21:45:25 CST From: rdd@cactus.org (Robert Dorsett) Subject: Contribution on A320 FMSs 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 ------------------------------ End of RISKS-FORUM Digest 13.11 ************************