The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 13 Issue 23

Tuesday 3 March 1992

Contents

o Leap Day bug hits PC mail program
Roger H. Goun
o Software Virus Found At INTEL
PGN
o Re: Michelangelo platforms
Sean Eric Fagan
Brandon S. Allbery
o Re: RSA Laboratories announces RSAREF
Marc Horowitz
Burt Kaliski
o New Caltrans AVI spec
Phil Agre
o Re: Post Office uses only 7 characters ...
Craig Seidel
o Re: Not quite anonymous FTP
Mike Pabrinkis
o Re: More on the Airbus A320
Martyn Thomas
Robert Dorsett
Ed Hutchins
Pete Mellor
Bob Kerns perhaps
o Info on RISKS (comp.risks)

Leap Day bug hits PC mail program

Roger H. Goun 03-Mar-1992 1243 <goun@ddif.enet.dec.com>
Tue, 3 Mar 92 09:44:48 PST
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


Software Virus Found At INTEL

"Peter G. Neumann" <neumann@csl.sri.com>
Tue, 3 Mar 92 9:39:50 PST
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.


Re: Michelangelo platforms (Bontchev, RISKS-13.22)

Sean Eric Fagan <sef@kithrup.com>
Tue, 3 Mar 92 15:31:43 PST
>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


Re: Michelangelo platforms (Bontchev, RISKS-13.22)

Brandon S. Allbery KF8NH <allbery@ncoast.org>
Tue, 3 Mar 92 19:25:05 -0500
| 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...)


Re: RSA Laboratories announces RSAREF free cryptographic toolkit

Marc Horowitz <marc@MIT.EDU>
Tue, 03 Mar 92 15:17:24 EST
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


RSA Laboratories announces RSAREF free cryptographic toolkit

Burt Kaliski <burt@RSA.COM>
Tue, 3 Mar 92 13:52:01 PST
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 <rsaref-users@rsa.com>, which will
discuss issues such as the license and help us improve things. To join, send
email to <rsaref-users-request@rsa.com>.

-- Burt Kaliski, RSA Laboratories


New Caltrans AVI spec (RISKS-13.09, RISKS-13.13)

Phil Agre <pagre@weber.UCSD.EDU>
Tue, 3 Mar 92 13:00:37 -0800
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


Re: Post Office uses only 7 characters ... (Piatko, RISKS-13.21)

Craig Seidel <seidel@puma.sri.com>
Tue, 3 Mar 92 13:50:12 PST
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


Re: Not quite anonymous FTP (Rucklidge, RISKS-13.21)

<mpabrin@relay.nswc.navy.mil>
Tue, 3 Mar 92 13:43:04 EST
> 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   <mpabrin@relay.nswc.navy.mil>


Re: More on the Airbus A320 (RISKS-13.21)

Martyn Thomas <mct@praxis.co.uk>
Fri, 28 Feb 92 17:34:27 GMT
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


Re: More on the Airbus A320 (RISKS-13.19)

Robert Dorsett <rdd@cactus.org>
Fri, 28 Feb 92 13:43:58 CST
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


More on the Airbus A320 (Dorsett, RISKS-13.22)

Ed Hutchins <hutchins@cogsci.UCSD.EDU>
Fri, 28 Feb 92 18:05:49 PST
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


Re: More on the Airbus A320 (Thomas on RISKS-13.21)

Pete Mellor <pm@cs.city.ac.uk>
Fri, 28 Feb 92 19:04:24 GMT
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


Re: More on the Airbus A320 (Dorsett, RISKS-13.20)

<rwk@crl.dec.com>
Sat, 29 Feb 92 07:31:44 -0500
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!

Please report problems with the web pages to the maintainer

Top