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 19 Issue 36

Weds 3 September 1997


o Korean Air Accident in Guam in retrospect
Peter B. Ladkin
o Tamagotcha!
Mich Kabay
o Autodialing retaliation
Tom Dowdy
o Re: "semper fidelis"
Daniel P. B. Smith
o Re: Hacking Risks, paying for tracking you down
Steven Bellovin
o Re: USC 47:227
John R. Levine
Keith Calvert Ivey
o Re: SET Risks
Mark Baker
o Re: Direct action to "sting" the junk e-mailers
Miranda Mowbray
o Re: Cockpit data wiped by RF interference?
Ian Cargill
John Pettitt
o Re: Solar storm warnings
Barry Margolin
o Re: Risks of believing the obvious, though impossible
Mark Brader
o Re: Tcl 8.0 Y2K Risk
Ethan L. Miller
Lloyd Wood
Jeff Anderson-Lee
o Info on RISKS (comp.risks)

Korean Air Accident in Guam in retrospect

"Peter B. Ladkin" <>
Wed, 03 Sep 1997 19:32:50 +0200
On 6 Aug 1997, at a time estimated from radar data and cockpit voice
recorder (CVR) timing as 01.42:30, Korean Air Flight 801, a Boeing 747-300
crashed into a hillside very near the Nimitz navigation beacon on approach
to the airport at Agana, Guam.  Although the accident has little obvious
relation to computer failures (except for the failure noted by Steve
Bellovin in RISKS-19.29), the procedure that the aircraft was supposed to be
following has error-detection properties which it may be interesting to
discuss using such vocabulary.  Virtually nothing specific can be said at
the moment about causes.

The media carried stories that the glide-slope transmitter (GS) was out of
service at Agana; also that a radar system called the Minimum Safe Altitude
Warning (MSAW) system was discovered to have a software bug, which prevented
it from warning the Agana Tower controller, with whom the plane was in radio
contact, that the aircraft was too low to make the approach safely.  The
MSAW system is integrated into the software running the Agana tower
controller's radar screen, but the system itself is located at Andersen AFB,
some 10nm (nautical miles, about 11.5 statute miles) beyond the end of
Runway 6L at Agana.

Two facts are salient.  First, the GS is not a part of the approach
procedure that the aircraft was cleared to fly (the `localiser-only ILS').
The pilot was required to know before leaving Korea, and evidence in the
cockpit corroborated that he knew, that he would not be using the procedure
which requires the GS (the `full ILS').  Second, the procedure flown does
not rely on any local radar at all being available, let alone MSAW.  Thus
concentrating on these two features would miss the point of an accident
explanation, which is to clarify how the aircraft failed to fly according to
a procedure which is designed to be safe to fly, and to all current
understanding is so, for all suitably-equipped aircraft, including not only
the B747 but many small four-seat Cessnas and Pipers.  The equipment
required to complete the approach safely has been the basis of flight radio
navigation for the second half of the 20th century.  A brief introduction to
this radio navigation may be found in my article `Traditional Aviation Radio
Navigation: An Introduction' at

The aircraft impacted the hillside well below the altitude of the top of the
radio beacon sitting on this hill, 724ft.  The aircraft was required to be
at 1,440ft altitude at this point.  One big question is: why was the
aircraft over 700ft lower than it should have been?

Maybe the pilot thought he was higher than he in fact was (this apparently
happened with the Aeroperu accident - Ladkin, RISKS-18.59).  However, the
pilot had received the correct barometric data for the barometric altimeters
(the so-called `altimeter setting'); the altimeters were recovered after the
crash and were stuck at an altitude-indication roughly consistent with the
altitude of impact.  Furthermore, the aircraft was equipped with a recent
model Ground Proximity Warning System (GPWS), an AlliedSignal Mark 7, which
measures altitude by bouncing a radio signal vertically off the terrain
below the aircraft.  According to the CVR, this provided voice-synthesised
altitude callouts of 1,000ft, 500ft and 100ft from terrain, as well as
warnings of `sink rate, sink rate' and `minimums, minimums'.  The crew was
said by the NTSB to have been relatively quiet on the CVR, which is not what
one would expect if they had recognised and were attempting to deal with an
unusual flight condition (one would expect at least an announcement from the
pilot flying of a change in status or intention).  Weather conditions are
being looked at, with a view to determining if there were unusual conditions
such as windshear.  There were reported to be some moderate-intensity rain
showers on the approach path.  Moderate-intensity showers are usually not
indicative of potential windshear conditions, which are usually associated
with thunderstorms, and a witness on the hillside very near to the crash
said it was not raining on that hill at that time.  Windshear did not seem
to be a prime suspect during the early stages of the investigation.

The particular positions (`fixes') on the ground that the aircraft on the
localiser-only ILS 6L approach is required to identify are three: the Final
Approach Fix (FAF), which is 1.6nm before the VOR, which the aircraft must
pass at 2,000ft altitude and then descend to 1,440ft; the VOR itself, which
the aircraft must pass at 1,440ft and then descend to 560ft, and the Missed
Approach Point (MAP), at which the aircraft must `go around' (make an
immediate climb to altitude and turn to fly back to a specific `fix') if the
runway or surrounding lights are not clearly in sight.  All these three
fixes at Agana are redundantly indicated by the equipment aboard an
aircraft, were this equipment to be used in a standard manner, so the
procedure in effect incorporates error-detection of one navigation
instrument failure (see ILS-article reference below).  Since the procedure
requires a go-around on detection of any instrument anomaly, it is therefore
fail-safe providing it is followed rigorously and there aren't correlated
multiple navigation-instrument or -signal failures.  One would expect the
investigation to try to answer the question whether these conditions were

Had the aircraft passed the FAF at the required indicated altitude (on the
altimeters), and had the indicated altitude been approximately correct, the
aircraft would have had to have flown a descent gradient (`glide path') of
over 7.7 degrees to arrive at the impact point.  Such an angle of descent
would be dangerously steep (this is between two and three times the expected
glide-path angle), and the rate of descent at typical approach speeds would
have been between 1,800 and 2,200 feet per minute, which would be
dangerously high at this point in an approach.

In conclusion, the localiser-only ILS procedure assumes correct barometric
altimetry, and provides one-failure error-detection along with a safe
go-around manoeuver should this situation arise.  It does not require GS or
MSAW.  The GPWS provides some detection of incorrect barometric altimetry
when this errs in the unsafe direction (when the aircraft is lower than
pilots think - higher is of course safe, although equally incorrect).
Pilots were provided with altitude callouts from the GPWS which were
consistent with their actual situation and inconsistent with flying the
approach according to procedure (the 500ft callout should normally happen
well *after* the VOR, as depicted on the approach chart that the pilot had
selected in the cockpit).  However, earlier-model GPWS's were subject to
false positives, and Nimitz Hill has a reputation for generating GPWS
false-positives also.

It is far too early in the investigation to speculate on what caused the
crash.  A number of `working hypotheses' (to put it *very* politely) have
been advanced both in public and in private.  So far, I have not seen one
which is more-or-less consistent with the facts that are public so far.
This itself is reason for caution - either some of the `facts' are
misleading, or the accident will be very hard to explain.

Readers interested in the details of the approach procedure may find them in
an introductory article I wrote entitled `Flying an ILS or Localiser Approach
-- An Example' <>.

The NTSB said early on that the crash has `all the earmarks of' controlled
flight into terrain (CFIT).  This is a description of an accident type,
rather than an explanation of how it happened, but there are nevertheless
often commonalities to accidents of a certain type.  Over half of all deaths
in commercial jet aircraft accidents in the late 80's/early-to-mid 90's were
CFIT.  The risk of CFIT on non-precision approaches such as the
localiser-only ILS 6L into Agana has been estimated by research by the Dutch
NLR (National Aerospace Lab), published by the Flight Safety Foundation, to
be of the order of five times as great as the risk with precision approaches
(such as the `full ILS').  The NTSB said that CFIT accidents usually involve
some form of human error.

Reducing the number of CFIT accidents has been a priority for aviation
safety organisations in the 1990's.  Readers interested in more background on
CFIT, as well as why the Agana crash is a strong candidate as a CFIT
accident, may be interested in my article `Controlled Flight Into Terrain:
What Is Being Done?' <>,
as well as the Flight Safety Digest 15(4/5), April-May 1996, which contains
the Dutch report, at

Peter Ladkin, Universitaet Bielefeld, Postfach 10 01 31, D-33501 Bielefeld,
Germany  +49 (0)521 106-5326/5325/2952


"Mich Kabay [NCSA]" <>
Wed, 3 Sep 1997 09:49:46 -0400
An article in this morning's _Globe and Mail_ in Canada reports on an
unexpected side-effect of the craze for electronic pets [e.g., Tamagotchi,

> Teachers seek humane gag as virtual pets enter classrooms
> BY KIM HONEY, *Globe and Mail*
> As thousands of children return to school with virtual pets in their
> pockets, teachers are wondering how to silence the electronic lambs
> without being held responsible for their deaths.

It seems that many children develop strong attachments to their e-pets and
can be seriously upset when their "babies" "die" due to lack of attention.
Neglected e-pets also cause a problem in class by beeping incessantly until
they "die."  Teachers at some schools are warning parents that e-pets are
inappropriate toys for children to bring to school.  Such toys "have already
been banned from some classrooms in China, Hong Kong, Thailand, Taiwan,
Singapore, the Philippines and Britain."

[Comment by MK:  Some parents and others argue that taking care of e-pets
is good training for life and teaches good values.  If playing with this
particular class of electronic game influences children's values, what then
might we expect from children's exposure to hours a day of the pervasive
violence and crudity of video games and television programming?]

M. E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education
National Computer Security Association (Carlisle, PA)

Autodialing retaliation

Tom Dowdy <>
Wed, 03 Sep 1997 11:24:42 -0700
Re: people being called by loos, banks, vending machines...

For reasons such as this, here in the US, it is illegal to autodial a number
more than N times (I can't recall the value of N, but it is fairly small, on
the order of 5 or 6 times) without some sort of human behavior to restart
the process.  Apparently, the phone company here in California takes this
illegal-ness rather seriously:

About 5 years ago, my phone here at work was the target of phones calls on
the order of one every two minutes.  There was enough clicking on the line
to cause my voicemail to actually record 5 minutes of nothing for each such
call, and it overflowed after 64 entries (nice small limit, that :-) ).
Needless to say, I wasn't very happy about this, nor were my coworkers (who
heard this ringing for 2 hours before I got in from the weekend).

It took a while to get a trace, but once it was done, the offending line was
found to be an ATM machine.  I couldn't ever get the name of the bank, but
the PacBell employee did inform me that they contacted said bank informing
them of the problem.  After two days went by with no action (ie, I was still
getting phone calls, no return calls by the bank to PacBell, denying that
the problem was theirs, etc) PacBell cut ALL phone lines to and from this
bank (some 50 odd lines).  The employee said "we figure they'll respond
pretty quickly now."

The Risk: if you do autodialing, better know the law!

Tom Dowdy, Apple Computer MS:302-3KS, 1 Infinite Loop, Cupertino, CA 95014

Re: "semper fidelis" (RISKS-19.35)

"Daniel P. B. Smith" <>
Sat, 30 Aug 1997 19:17:54 -0400 (EDT)
The nearest spelling checker at hand, ClarisWorks, offers "simper,"
"temper," "swampier," and "semipro" for "semper," and "fiddles" and
"Fidel is" for "fidelis".  (No kidding, capitalized and with the internal
space.)  If I deliberately misspell it as "fideles" then "fiddles" is
the only suggestion...

Daniel P. B. Smith

  [I had tacitly assumed that the incorrect "fideles" had been corrected to
  "fiddles" (a single-letter substitution), rather than the farther-away but
  correct "fidelis".  PGN]

Re: Hacking Risks, paying for tracking you down (Perillo, RISKS-19.35)

Steven Bellovin <>
Fri, 29 Aug 1997 21:07:13 -0400
The federal statute can certainly be construed as covering the victim's
expenditures -- it speaks of "causes loss or damage to one or more other
persons of value aggregating $1,000 or more".  (Note also that the
threshhold appears to be $1,000, not $5,000.)  Some state laws are are
clearer -- California's computer crime statute make an explicit distinction
between direct losses and reasonable expenses to assess the damage and
repair it.

A more interesting question is how valid the calculations are in this
(or any) case.  There's a long history of bogus numbers, such as the
famous E911 case, where an improbably high figure was attached to the
value of the purportedly stolen document.  It was later discovered that
it was for sale for about $13.

  [E911: Steve is referring to the Craig Neidorf case,
  RISKS-10.65,11.39,11.62,13.86.  PGN]

Re: USC 47:227 (Kabay, RISKS-19.34)

John R. Levine <>
30 Aug 1997 05:21:27 -0000
This argument comes up a lot in the spam wars.  Yes, if you read that part
of the statute literally, the definition of a fax would include many
computers, and the FCC has ruled that a computer with a fax modem is a fax
for the purposes of the law.

But it's extremely unlikely that a court would hold the existing statute to
cover junk e-mail, much though we wish they would, because the intent of the
Congress was quite clear, to regulate faxes, not to regulate e-mail.  That
sort of literalism is not popular in legal circles because it leads to silly
results, e.g., "if your computer has a printer and/or scanner, sorry, we
sent you this spam by mistake."  The law also requires that all faxes
contain the sender's phone number, which means that if e-mail is a fax, 99%
of all e-mail is illegal due to lack of phone number.

I have heard rumors that there may be a court in Washington State that was
willing to stretch 47 USC 227 to cover e-mail, but I've been unable to pin
down details, and in any event, until a case like that is appealed it has
little precedent value for other courts.

The Congress certainly could regulate e-mail similarly to faxes, which is
what bill H.R. 1728 does.  It's supported by many organizations including
ISP/C, CAUCE, and Experian (the credit bureau formerly part of TRW).  Visit for more info.

The risk here: although the law has a certain amount in common with
software since both try to express algorithms, we propeller-heads
shouldn't make the mistake of expecting the parallels to go too far.

John R. Levine, IECC, POB 640 Trumansburg NY 14886 +1 607 387 6869, Village Trustee and Sewer Commissioner,,

Re: USC 47:227 (Thompson, RISKS-19.35)

"Keith Calvert Ivey" <>
Sat, 30 Aug 1997 13:25:08 -0400
If it's true that an e-mail message counts as a fax under USC 47:227, then
almost all e-mail is illegal, not just the junk, since the law also requires
that the telephone number of the sending fax machine be included on *all*
faxes (other things are required as well, some of which would seem to be
impossible to do in e-mail).

Phaedrus discussed the issue in RISKS-18.62

Keith C. Ivey, Washington, DC

Re: SET Risks

Mark Baker <>
Tue, 2 Sep 1997 10:42:31 -0400 (EDT)
I thought RISKS readers, especially those involved in the development of
secure electronic payment systems, would be interested in a paper entitled
"Weaving a Web of Trust" by Adam Rifkin and Rohit Khare.

IMO, it does a superb job of outlining the risks involved with not managing
trust issues up front in the design and implementation of software systems
being deployed on public networks.

Mark Baker, Ottawa Ontario CANADA  Java, CORBA, Agents, Beans

  [The paper is in the World Wide Web Journal, an issue subtitled
  Web Security: A Matter of Trust, Summer 1997, vol 2, no 3.
  The entire issue is full of interesting contributions (including
  a published version of the report of the 11 cryptographers and
  computer scientists noted in RISKS-19.17,19).  PGN]

Re: Direct action to "sting" the junk e-mailers (RISKS-19.34)

Miranda Mowbray <>
Wed, 3 Sep 1997 13:36:22 +0100
In RISKS-19.34, reports the anti-junk-e-mail tactic of
including e-mail addresses at the Federal Communications Commission and USPS
in your .sig.  The idea is that spammers who use lists of e-mail addresses
compiled by sifting Usenet News articles will find themselves spamming these
organizations.  Max Stern pointed out that if this works it will be adding
to junk mail, and will cause harassment of the individuals whose e-mail
addresses you add to your .sig.  Another possibility is that it won't work
because of the current capabilities of spam tools.

Two of the software tools currently on sale for automatically collecting
e-mail from the net are designed not to collect any addresses that end .edu
or .gov.  All the addresses suggested in Max Stern's posting end .gov.
Another tool on sale for the same purpose is designed not to collect any
addresses whose username is postmaster, webmaster, abuse, or root.

The risk of these capabilities in spam tools is that the people who have
most influence on spam-related policy decisions will receive much less spam
than the rest of us.

Miranda Mowbray, Hewlett Packard Laboratories Bristol

Re: Cockpit data wiped by RF interference? (Imran, RISKS-19.34)

Ian Cargill <>
Wed, 27 Aug 1997 07:55:26 +0100
Wait a minute.  Is there any *actual evidence* that a cell-phone was
responsible?  The fact that there were several cell-phones in operation
seems irrelevant.  For example, last time a bulb blew in my house, there was
a car driving past my house.  I have heard of similar occurrences.
Conclusion: Driving a car past a house creates a risk of a light bulb

As another post pointed out, if cell-phones are so dangerous to in-flight
computers, how come I have never had a problem in an office with 20-30
computers of all types and at least a dozen cell-phones??  Are in-flight
computers less resilient than Intel/MS boxes!!!!!!!

Unless someone can demonstrate a causal link, there is a very serious RISK
of give-the-dog-a-bad-name and automatically blaming cell-phones (or
laptops, etc) for other really serious problems which don't get properly

Given my experiences so far in life, I would be much more ready to blame a
computer failure on the computer hardware/software than the poor, maligned

Does anyone know of any studies that show evidence that cell-phones can do
what they are acussed of.  Has anyone actually done such a study?

Ian Cargill  CEng MIEE  Soliton Software Ltd.

Re: Cockpit data wiped by RF interference? (Imran, RISKS-19.34)

"John Pettitt" <>
Wed, 27 Aug 1997 15:10:45 -0700
There are a couple of issues here, the first reason not to use cell phones
in flight is that the 8/900 Mhz signals quite close to the frequency ranges
used by DME (Distance Measuring Equipment) that forms part of the navigation
system.  The presence of a 3W transmitter close to the receiver may swamp
the front end of the receiver and prevent or degrade signal reception.  The
second reason is that a cell phone used is flight is seen by cells for many
miles and ties up frequency space on every cell that can see it (line of
sight is a long way from 30,000 feet).

FM radios are not allowed because they tend to re-radiate at a frequency
equal to the tuned frequency plus the local oscillator which happens to come
out in the 115 to 125 mhz region used for aircraft navigation and
communication.  Again a stray signal may block say an instrument landing
system from being received.

Computers have a different problem - the RF shielding is never as good as it
could be once the machine leaves the factory, since they are full of square
wave signals which include every odd harmonic (to infinity in a perfect
case) they tend to radiate mush of a wide range of unpredictable

Are these risks high? probably not but given the current trend towards
flying into mountains do you want to chance it?

John Pettitt  EVP & CTO  CyberSource Corporation

Re: Solar storm warnings (RISKS-19.35)

Barry Margolin <>
Fri, 29 Aug 1997 23:28:26 -0400
I believe solar storms are a stream of charged particles, not
electromagnetic radiation.  They don't travel at the speed of light, so it's
quite possible for a radio signal to get here ahead of them.  The damage is
done by the radiation that these particles emit when they arrive.

Since light takes about 5 seconds to travel a million miles, and the system
is purported to give us an hour (3600 seconds) warning, I'm guessing that
the particles are traveling at about 1/700 light speed.

What I was curious about when I heard the story is: what are we supposed to
do during that hour?  Given a couple of days warning before a hurricane you
can tape your windows and/or evacuate.  How do we protect against a solar
storm, and can those protections be put up in an hour?

Barry Margolin,  BBN Corporation, Cambridge, MA

  [We received more mail on this point than ever before in the 12-year
  history of RISKS.  Thanks to all who responded, much faster than the
  solar flares could reach us.  PGN]

Re: Risks of believing the obvious, though impossible

Mark Brader <>
Tue, 2 Sep 97 16:11:44 EDT
| I read an article today about a solar study satellite launched into
| a gravi-stationary orbit around the Earth at the point where Earth
| gravitation and Sun gravitation are equalized ...

Not even close to equal, actually: the Sun's gravity at that position,
called L1, is about 40 times the Earth's.  If the Earth was not present,
an object in the satellite's orbit would go around the Sun once every
51 weeks or so.  The significance of the L1 point is that the Earth
contributes *just enough* of a pull to slow down that period to exactly
1 year, creating a fixed relationship of Earth, Sun, and satellite.

| The satellite is to study solar winds, flares, and particle streams.
| The article proclaimed the satellite would "give us a one hour warning of
| solar storms that would otherwise not be available ..." [But how is this
| possible if the solar radiation, like the radio from the satellite,
| travels at the speed of light?]

Because it doesn't.  The radiation of concern in this case is not
electromagnetic, but streams of charged particles.  A moving charge
generates a magnetic field, and the powerful effects of a solar storm can
lead to large distortions in the Earth's feeble magnetic field.  The streams
do indeed travel at nearly 1,000,000 mph, but this is only 1/700 of the
speed of light; so the one-hour warning is quite right.

Kathy A. Svitil wrote a 1-page article on this in the June "Discover", p.36.

Mark Brader,

Re: Tcl 8.0 Y2K Risk

"Ethan L. Miller" <>
Tue, 2 Sep 1997 10:04:26 -0400 (EDT)
> years 00-38 are treated as 2000-2038 instead of 1900-1938).

The problem applies *only* to people who decide to *input* two-digit years
(such as 2 Sep 97).  This isn't a Y2K problem per se because it can happen
at any time, and has been going on for years in Tcl and many other systems
-- witness the many stories of 105-year olds being sent info on
kindergarten).  Tcl/Tk is no worse (or better) than other code in this

AFAIK, all dates converted in this way (or any other) are stored internally
as Unix integers.  Of course, they're subject to the well-known Y2038
problem when Unix passes 2**31 seconds since Jan 1, 1970 (but that's a
different story).

Prof. Ethan L. Miller, U of Maryland Baltimore County, CSEE Dept,
1000 Hilltop Circle, Baltimore, MD 21250  +1 410 455-3972

Re: Tcl 8.0 Y2K Risk (Miller, RISKS-19.36)

Lloyd Wood <>
Tue, 2 Sep 1997 16:48:46 +0100 (BST)
> Lloyd> "There are also a few other minor incompatibilities in Tcl 8.0
> Lloyd> and Tk 8.0: [..] 2.2-digit years are now parsed differently by

(that's Point Two: 2-digit years, before anyone with 2.4 children gets
 any funny ideas.)  [2.2 spaced out!?  PGN]

> The problem applies *only* to people who decide to *input* dates with
> two-digit years (such as 2 Sep 97).

In other words, all users. (Users do the darnedest things.)

> This isn't a Y2K problem per se because it can happen at any time,

as do Y2K problems; note previously-reported problems with future
expiry dates. Variable product lifetimes mean that a Y2K problem will
occur at any time.

> and has been going on for years in
> Tcl and many other systems - witness the many stories of 105 year olds
> being sent info on kindergarten).

so _that's_ why they call it 'second childhood'!

> Tcl/Tk is no worse (or better) than
> other code in this respect.

Changing expected behaviour and going against user assumptions that
have been built upon prior experience is an even bigger risk than Y2K, IMO.

Handling the input unexpectedly before it gets to the script is
dangerous - compare with the previously-discussed Javascript tendency
to treat numbers with leading zeroes as octal, for instance.

(Incidentally, the Javascript Date object has its own problems - e.g.
in 1.0 'You cannot currently work with dates prior to 1/1/70' and this
legacy problem will eventually catch someone.)


Re: Tcl 8.0 Y2K Risk (Wood, RISKS-19.35)

Jeff Anderson-Lee <jonah@EECS.Berkeley.EDU>
Tue, 2 Sep 1997 09:22:57 -0700 (PDT)
Because most of the Unix world still uses 32-bit timestamps in the range
1970-2038, this is perhaps much less of a RISK than it seems at first.  The
real RISK is that not much will be done about that until at least 2035.

Furthermore, Solaris 2.5.1 defines time_t as a C "long" which is currently 4
bytes.  When 64-bit operating systems finally catch on there will be a lot
of code to change when "long" becomes 8 bytes, while the data on disk is
still only 4.

On another note, Java seems to be limited to the Unix date range (1970-2038)
even though it is a new language defined near the end of the century.

Jeffrey Anderson-Lee
System Manager, Digital Library Project, University of California, Berkeley

Please report problems with the web pages to the maintainer