Subject: RISKS DIGEST 13.23 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 3 March 1992 Volume 13 : Issue 23 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Leap Day bug hits PC mail program (Roger H. Goun) Software Virus Found At INTEL Re: Michelangelo platforms (Sean Eric Fagan, Brandon S. Allbery) Re: RSA Laboratories announces RSAREF (Marc Horowitz, Burt Kaliski) New Caltrans AVI spec (Phil Agre) Re: Post Office uses only 7 characters ... (Craig Seidel) Re: Not quite anonymous FTP (Mike Pabrinkis) Re: More on the Airbus A320 (Martyn Thomas, Robert Dorsett, Ed Hutchins, Pete Mellor, Bob Kerns perhaps) 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: Tue, 3 Mar 92 09:44:48 PST From: Roger H. Goun 03-Mar-1992 1243 Subject: Leap Day bug hits PC mail program UUPC/extended is a mail system for personal computers running MS-DOS. (The name is a pun on UUCP.) On Leap Day, Saturday, 29 February 1992, UUPC's UUPOLL program, which polls a remote system for mail at regular intervals, consistently hung the PC on which it was running. One workaround was to set the system clock ahead a day to 1 March. Drew Derbyshire, the author of UUPC, traced the problem to a bug in the mktime() library function in Borland C++ 2.0, which converts a time to calendar format. Drew demonstrated that mktime() will hang a PC on Leap Day, and reported the problem to Borland. As distributed, UUPC is compiled with Borland C++ 2.0, though source code is available for do-it-yourselfers. Apparently, Borland has issued a corrected version of the library function (I haven't verified this). Drew tried to warn UUPC users by mail after discovering the problem on Saturday. Ironically, many did not get the message until Sunday or Monday, when they found their PCs hung in UUPOLL. Roger H. Goun, Digital Equipment Corporation, goun@ddif.enet.dec.com or goun%ddif.enet@decwrl.dec.com, {pacbell,pyramid,uunet}!decwrl!ddif.enet!goun ------------------------------ Date: Tue, 3 Mar 92 9:39:50 PST From: "Peter G. Neumann" Subject: Software Virus Found At INTEL From the N.Y. Times News Service, 3 March 1992 (I saw it in the SanFranChron): Intel Corp. said Monday it had stopped shipping a computer network software program because some units were found to be infected with the ``Michelangelo'' virus, a program that infects IBM and compatible personal computers and can potentially destroy data. A division of Intel in Hillsboro, Ore., said it had shipped more than 800 copies of the program, called LANSpool 3.01, which inadvertently contained the virus. The virus is designed to activate on March 6, Michelangelo's birthday, and can erase data and programs if it is not detected with antiviral software. The company said it had checked its software with a virus-scanning program before shipping it, but that it had failed to detect the virus. A number of computer makers and software publishers have issued similar alerts about the Michelangelo program and a variety of companies are now offering free software to check for the virus. There are more than 1,000 known software viruses that can copy themselves from computer to computer by attaching to programs and files. ------------------------------ Date: Tue, 3 Mar 92 15:31:43 PST From: Sean Eric Fagan Subject: Re: Michelangelo platforms (Bontchev, RISKS-13.22) >Sigh... Sorry, but this is FALSE! The Michelangelo virus attacks any IBM PC >compatible computers. There is no need that they are MS-DOS machines. You can >get a 80386 and install only Xenix on it, without any MS-DOS partitions. That's a pretty amazing feat, since to do this, it would have to a) be a UNIX (or XENIX) binary, not a DOS binary, b) somehow get root access on the machine, c) figure out which device is actually the disk, and then d) munge it (d is, of course, the easiest part). Even if you run it under a DOS emulator, it is usually configured such that a DOS program cannot access any random device, or open up a disk drive (e.g.., it provides a pseudo-disk, for programs that like to just open up the disk under DOS themselves... but it cannot open up, say, /dev/root unless /dev/root available via normal permissions to the person who started the program). I think you are seriously confused about things, and I will continue to believe that until I see proof otherwise. Sean Eric Fagan ------------------------------ Date: Tue, 3 Mar 92 19:25:05 -0500 From: allbery@ncoast.org (Brandon S. Allbery KF8NH) Subject: Re: Michelangelo platforms (Bontchev, RISKS-13.22) | Sigh... Sorry, but this is FALSE! The Michelangelo virus attacks any IBM PC | compatible computers. There is no need that they are MS-DOS machines. You can Incorrect. The virus CAN affect machines that run Xenix or UNIX, but ONLY if they are booted from MS-DOS with an infected floppy disk. UNIX filesystem and program mechanisms, even on UNIXes that support "mounting" of MS-DOS floppies, will not permit the Michaelangelo virus to install itself under UNIX or Xenix. The worst that can possibly happen is that a VP/ix or DOS-Merge partition will be infected, but *if it is only used under VP/ix or DOS-Merge then the primary boot track will not be affected because VP/ix and DOS-Merge will not allow it to be accessed*. Misinformation about viruses is yet another RISK that must be considered. I've encountered an article on Usenet from someone who thought (erroneously) that ALL computers would be affected (perhaps due to the events detailed in the original RISKS submission?). This further claim that the virus can somehow install itself on computers that are never booted into MS-DOS is just as incorrect. Brandon S. Allbery, KF8NH [44.70.4.88] allbery@NCoast.ORG Senior Programmer, Telotech, Inc. (if I may call myself that...) ------------------------------ Date: Tue, 03 Mar 92 15:17:24 EST From: Marc Horowitz Subject: Re: RSA Laboratories announces RSAREF free cryptographic toolkit Lawyerspeak from hell. Two questions: >> b. The Program is to be used only in connection with a single computer. Isn't this kind of stupid in the license of a program which is fundamentally most useful in a networking environment? Or, since licenses are free, should I get a few licenses for myself, in case I happen to want to run it on multiple machines? >> d. You may not translate the Program into any other computer language. Including RTL, or assembler? Darn. Can't compile it, then. RISKS of boilerplate legalese? Marc ------------------------------ Date: Tue, 3 Mar 92 13:52:01 PST From: burt@RSA.COM (Burt Kaliski) Subject: RSA Laboratories announces RSAREF free cryptographic toolkit Good points. We'd happy to receive comments on the legal agreement, since there aren't many things like RSAREF to compare against. We were aware of the "lawyerspeak" on the number of copies; it's pretty conventional, and we don't intend to keep anyone from storing more than one personal copy for personal in a network environment. But we wanted to start with conservative language. On the issue of translating into another language, your observation "Can't compile it" is a good one ... But of course you can compile it. Let's see if we can work out some better language. I invite you to join the RSAREF user's group , which will discuss issues such as the license and help us improve things. To join, send email to . -- Burt Kaliski, RSA Laboratories ------------------------------ Date: Tue, 3 Mar 92 13:00:37 -0800 From: pagre@weber.UCSD.EDU (Phil Agre) Subject: New Caltrans AVI spec (RISKS-13.09, RISKS-13.13) Chris Hibbert (xanadu!hibbert@uunet.uu.net) is correct that I misinterpreted the AVI spec in one important way. The spec no longer calls for a VIN to be transmitted (the term VIN no longer appears in the spec) but rather the transponder's unique 32-bit code (see section 1705.5(e)(1). (I was misled by the retention of the term "AVI".) This is a significant improvement PROVIDED that transponder id's are not indexed against VIN's (or SSN's etc) when the transponders are sold or installed. The transponder is still to be fixed to the front bumper (1705.3, 1705.8), as opposed to being bought at 7-11 and kept in one's glove compartment. Whoever does the installing or collects payments will probably have enough information to register the transponder by VIN or license number. And this doesn't even count future uses of the transponders (e.g., 1702.1); future Transaction Record Formats could contain the VIN or just about anything else. Thus it is true that "The new draft doesn't leave room for an identifier of the vehicle or the driver in the communication packets", but it is also misleading. I was unclear with regard to the issue of extensibility. Earlier versions did mention the possibility of extension, but the latest is much more explicit on the subject. It is also more careful about separating out AVI-specific features from the underlying generic device. A number of people have corresponded with me about how one might implement toll collection without requiring every car to carry a transponder. My real complaint had to do with the whole notion of a "spec". Chris says that "The spec doesn't talk about [the broader process of toll collection] because it's not part of the technology being designed." But this is only true on the narrowest possible definition of "the technology being designed". More socially relevant definitions are possible. The folks proposing the Privacy Act reprinted in recent Risks issues are aware of these issues and seem sincere in their desire to protect privacy. But I am horrified by Chris' report that: Some [Caltrans folks and vendors] are willing to say that they expect "other forces" (maybe DEA or INS?) to try to make this kind of equipment usable for tracing people's movements. There may have been attempts to make this be standard equipment on new cars. The atrocious record of the DMV and the reputed attitude of Caltrans provide little comfort, and it would take a small twitch of California politics to put all the Senator Lockyers on the street in a few years. If personal tracking technologies cannot be made inherently resistant to civil liberties abuse then they should be banned. Phil Agre, UCSD ------------------------------ Date: Tue, 3 Mar 92 13:50:12 PST From: Craig Seidel Subject: Re: Post Office uses only 7 characters ... (Piatko, RISKS-13.21) It sounds like you are the victim of two human errors and one piece of odd coincidence. First, your mail carrier incorrectly decided to place that mailpiece in a change-of-address bin. Then, the change-of-address mail was passed Computer Forwarding System (CFS) where the seven digits you described were typed in. By coincidence, there was someone on your carrier's route (or the wrong carrier route was typed in) with certain address similarities who had recently moved (I believe information is maintained for 1.5 years). Finally, the person who applies the yellow label is supposed to check the name and apparently didn't. Seven digits are usually sufficient because mail typically doesn't get to the CFS unless the mail carrier is aware of an address change. Quality control at the final step was probably lacking for the typical reasons (working too fast, fatigue, boredom, etc.). Craig ------------------------------ Date: Tue, 3 Mar 92 13:43:04 EST From: mpabrin@relay.nswc.navy.mil Subject: Re: Not quite anonymous FTP (Rucklidge, RISKS-13.21) > The risk is not so much that the logs are made, but more that the service > is presented as "anonymous", leading people to believe that it actually is. By his tone and statements William Rucklidge shows himself knowledgeable about various logging techniques, both administrative and security-oriented, as found on many networked hosts, So, what bothers me? Two things... First: Network application protocols have evolved over 15 years and more. FTP has ALWAYS been a man-in-the-loop protocol. The FTP-user must use a (different on each, we pray) valid ID/PW combination on each of the SOURCE and TARGET hosts; i.e., must be able to log on or in to each host to migrate any file from SOURCE to TARGET. Various host administrations realized it would be of value for a given SOURCE host to make certain files/directories widely available, without having to register huge numbers of users. Result: ANONYMOUS FTP, in which the valid ID/PW combination on the SOURCE host only, and for a limited file or directory set, reduces to an advertised pair such as "anonymous" and "guest", or "anonymous" and "any-non-null-string", etc. The meaning of 'anonymous' here is NOT that no one logs such a transaction; rather, that the user can obtain files without being a registered user of the SOURCE host. 'Anonymous' here equates to convenient, not unidentifiable. Second: William Rucklidge implies, maybe even states, that a widely-known Internet host permitted itself to be an anonymous FTP TARGET. I hope not! However, even if the MBDF-A virus was migrated TO a TARGET host by someone using a registered ID/PW combination, that indicates a breakdown of trust at some point. Perhaps the (SOURCE or) TARGET host administrator did not know his user. Perhaps the user shared his ID/PW combination. Perhaps someone or two stole an ID/PW combo. I don't know, and my speculations are ignorant and dangerous. My point: host and network use is built upon and dependent upon trust. Trust is a fragile thing, the substrate of cooperation. William Rucklidge, writing from a host apparently at the site where the two people alleged to have spread the virus were arrested, seems to imply that 'anonymous' ought to mean unidentifiable. I hope I misinterpreted what he wrote. In any society built and dependent on trust, such as our Internet, a user should NOT want anonymity, not even as a matter of FTP convenience; surely, NEVER as a mechanism for evasion. Mike Pabrinkis, Naval Surface Warfare Center, Dahlgren, VA 22448 (703)663-7743 (AV)249-7743 ------------------------------ Date: Fri, 28 Feb 92 17:34:27 GMT From: Martyn Thomas Subject: Re: More on the Airbus A320 (RISKS-13.21) If the rate of descent was really 3,300 feet per minute, as reports suggest, then 200 ft gives 3.636 seconds before impact, assuming flat terrain. I do not have information about the terrain. Allowing two seconds to react, is this enough time to go around? I believe that go-arounds can be executed from a few feet, *if they are expected*, and if the engines have not spooled down. I wonder what the tolerance on the 200 feet is, and what the allowable delay in generating the message is? The slant angle of the beam will affect the actual height at which 200 ft is measured, unless this is corrected for. Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-225-444700. Email: mct@praxis.co.uk ------------------------------ Date: Fri, 28 Feb 92 13:43:58 CST From: Robert Dorsett To: Martyn Thomas Subject: Re: More on the Airbus A320 (RISKS-13.19) It's wrong to assume this is really a crash-alert system, like a GPWS. It's designed for use with an airliner flying a normal approach. Confused? Allow me explain! In a normal airplane, duties are divided between pilot flying and pilot-not- flying. Pilot flying flies the approach: manipulates the control column, throttle, autopilot, etc. Pilot not flying handles radios, checklists, navigation, systems, etc. During the last few minutes of the approach, he makes call-outs: decision height (when one has to go around if the runway's not in sight), and a variety of standard altitudes (1000', 500', 200', 100', 50', etc). All "above ground," as opposed to regular altimeter readouts, which are usually "above mean sea level." (exception being the radio altimeter, which always displays distance above the ground immediately underneath the sensor). I can really digress on this point, if pressured. :-) The call-out practice is intended to enhance the situational awareness of the pilot flying the airplane, as well as the crew as a whole. The exact call-outs are normally subject to airline policy and the approach being flown: some are very superficial, while others have call-outs at practically every 20 feet. During these call-outs, it is assumed the airplane would be in the "safe" GPWS envelope, since it's flying a normal flight path, presumably over level terrain at this point, and bumping into a sloping mountain isn't much of an issue. GPWS doesn't know the difference between an airport boundary and a cornfield, and it would be irritating to have a major warning every time the airplane simply passes a threshold altitude. On the A320, of COURSE, the call-outs are automated, freeing the F/O to do other things. The system makes all call-outs, including one just before touchdown, reminding the pilots to activate the thrust reversers, by yelling "RETARD!" You can bet this improves the self-esteem of the pilots. :-) So, again, this is all pretty irrelevant to the Strasbourg crash. The system isn't a warning or caution; it's just advisory. Whether we want the system to be *automated* is another question entirely, though. As stated, the practice is designed to improve crew communication. The whole idea behind call-outs is to verify that pilot A flying the airplane is thinking the same thing as pilot B, who is making the call-outs. All automated call-outs accomplish is to verify that Pilots A & B both *independently* agree that the computer knows what it's doing; they may then grow to rely upon its accuracy, and on the other pilot to cross-check his own instruments. Automated call-outs are yet another interesting new dimension on the functional social atmosphere and professionalism of the cockpit environment. Another practical consideration is that, considering the human factors problems of tape-style instruments, which provide the altitude and airspeed indications on the A320, I think it would be a good idea to keep the PNF calling out the altitudes, rather than rely on the radio altimeter computer. Especially when one considers all the approaches that DON'T have a nice, smooth field for miles around the airport, but rather are on mountains, near cliffs, etc., and will cause the radio altimeter to think it's much higher than it actually is. A human pilot could cross-check with the barometric altimeter; the computer is designed to work with the radio altimeter. As for the three seconds they may have had on the Air Inter, and what they might have done with them: who knows? If they were in a cloud, they'd be inclined to believe their instruments and continue flying the airplane, checking secondary sources for confirmatory information. And there goes the three seconds. On an airplane which is prone to spurious warnings, they'd probably ignore it, especially if they think they're at 8,000', 3000' above their target altitude, which, in turn, is a couple thousand feet above the maximum terrain elevation for the sector. And then there's the good possibility they had much less than three seconds, since, even though they were descending at 3000 fpm, they were also going forward at 180 knots or so. Pete's comment of 1 second tends to support this idea. As an aside, good pilots do not yank back on the controls and perform dramatic maneuvers every time a light goes off: more accidents have been caused by that sort of behavior than otherwise. There's an old story of an astronaut -- Gus Grissom, I believe -- who was suddenly presented with a rather dramatic array of warnings while on the pad. Rather than start flipping switches instantly, as training required, he took a second or two to get his bearings, and study the situation. In that period, the systems reset, and the warning lights went out. He's commented that if he HAD started doing things instinctively, he could have REALLY got himself into a lot of trouble. I suppose there's a moral there for systems that perform automated tasks on the basis of immediate data--and don't give the pilot the final authority to correct those mistakes, when spurious data corrects itself or is identified. GIGO rules. Just my $0.02. Robert Dorsett Internet: rdd@cactus.org UUCP: ...cs.utexas.edu!cactus.org!rdd ------------------------------ Date: Fri, 28 Feb 92 18:05:49 PST From: hutchins@cogsci.UCSD.EDU (Ed Hutchins) Subject: More on the Airbus A320 (Dorsett, RISKS-13.22) Just a comment on the function of callouts. In any airplane, automated or not, callouts on the final approach do more than ensure that both crew members share a notion of what is going on. Flying an approach is a visually intensive task for the pilot flying regardless of the weather conditions. An auditory callout by the PNF provides the pilot flying with important information in a sense modality that is not already heavily loaded. United Airlines, for example, mandates a callout at 500' above touchdown that includes the radio altitude, the descent rate, and an indication of speed relative to the target approach speed. For example, "five hundred feet, seven down, plus four" would mean seven hundred feet per minute descent rate, and four knots above target approach speed. When you are trying to pick up the approach lights in broken clouds and would like to transition from instruments to outside references, it is real nice to learn (without having to look) that you are on path, with an appropriate descent rate and a have few knots of speed over the target. If any of you find that the first recommendation of the commission report translated by Peter Mellor smells suspiciously like a commitment to a cause for this accident, you might be interested to know that Northwest Airlines began a program to develop new crew procedures for the use of flight path angle and vertical speed modes in their A320's before the latest accident happened. I think the problems have been known to airlines operating the A320 for some time. Even if it turns out that the accident was not caused by a confusion of these modes, the report acknowledges that it is an issue that ought to be addressed. Edwin Hutchins, Department of Cognitive Science, U.C. San Diego La Jolla, CA 92093-0515 ehutchin@ucsd.edu ------------------------------ Date: Fri, 28 Feb 92 19:04:24 GMT From: Pete Mellor Subject: Re: More on the Airbus A320 (Thomas on RISKS-13.21) The following is a translation of the relevant paragraphs of the interim report: The point of impact was situated at an altitude of around 800 metres on the south-west slope of "la Bloss" mountain, which rises to 823m (see map in annex 1). At this place, the ground slopes upwards. The amount of slope varies between 8 and 17%. A forest of pines about 25 metres tall covers the entire area. The distance over which trees had been damaged was about 120 metres. Measurements taken of the damaged trees allowed a rough estimate that the aircraft entered the trees at an angle of descent of about 12 degrees, with a roll inclination of the order of 18 degrees. ---End of extract The map in annex 1 is large scale, and shows very little. Obviously "slopes upwards" means upwards in the direction in which the aircraft was travelling. The flight data from the QAR approximately confirms the above estimates. The QAR was burned, and in particular the last 25 seconds worth of tape prior to impact was damaged, and had to be read by special means. The last frame that has been read so far is at impact -4 seconds. This final reading shows: Barometric altitude = 2750 ft Radio altitude = 600 ft Vertical speed = -4000 ft/min (and seems to have been increasing) Airspeed = 186 kt Bearing (cap) = 68 deg To calculate time to impact from the point at which the radiosonde reported 200ft (which it would have measured relative to the tree-tops), we must take into account the upward slope of the ground, as well as the horizontal and vertical speeds of the aircraft. The airspeed would need to be corrected for wind velocity to get ground speed. The meteorological report for the area of the crash site gives wind between 1000 and 2000 metres as north-east or east-north-east 25 to 35 kt irregular, gusting to 40 kt. Since it is nearly 7 pm, and I have a pint waiting for me in the Sekforde Arms, I will leave this calculation to somebody more dedicated, but bear in mind that the ground was uneven, so that any estimate is bound to be rough. My own finger-in-the-air guess at the time to impact is "not very long". After they heard that "Two hundred feet" announcement, the pilots wouldn't even have had time to say "Merde!", never mind do a go-around. Peter Mellor, Centre for Software Reliability, City University, Northampton Sq., London EC1V 0HB, Tel: +44(0)71-477-8422, JANET: p.mellor@city.ac.uk ------------------------------ Date: Sat, 29 Feb 92 07:31:44 -0500 From: rwk@crl.dec.com Subject: Re: More on the Airbus A320 (Dorsett, RISKS-13.20) Robert Dorsett writes: As with most crashes, the Air Inter crash was likely the result of a complex number of factors; no single protection could have "saved" the airplane. I think you mean to say that any one of a number of factors WOULD have saved the airplane. It's the COMBINATION of the factors that caused the crash. I certainly don't want to fly on anything so screwed up that it's going to crash for a whole bunch of reasons! ------------------------------ End of RISKS-FORUM Digest 13.23 ************************