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 21 Issue 94

Monday 11 March 2002

Contents

Runaway remote-controlled coal train
PGN-ed from Dan Swinehart
LED lights can reveal computer data
NewsScan
Yet another case of a program changing your input
Vassili Prevelakis
Loosing It's Grammer Skill's
Greg Searle
.org.au, .gov.au, .edu.au domain hijacking through lax security
Grant Bayley
Amendment to add life prison terms for reckless hacking
Len Lattanzi
The computing battlefield
Jon P
Military palmtop will direct air strikes using WinCE
David Wagner
The next step in malicious spam
Joe Faber
The RISK of ignoring permission letters
Timothy Knox
Re: Air Transat Incident, Aug 24, 2001
Peter B. Ladkin
Re: Malfunction shuts down ... amusement park ride
Stanislav Meduna
Re: PayPal's tenuous situation
Max
Info on RISKS (comp.risks)

Runaway remote-controlled coal train

<"Peter G. Neumann" <neumann@csl.sri.com>>
Mon, 11 Mar 2002 11:57:53 PST

Operating with a less-than-a-year-old remote-controlled system, a runaway
train plowed through NIPSCO's Michigan City Generating Station on the
morning of 7 Mar 2002, hitting another locomotive before the second
locomotive's engineer narrowly jumped to safety.  The unmanned eastbound
diesel-electric engine, known as Big Blue, was pushing six coal cars when it
approached the coal drop-off area at about 30 m.p.h. at 7:15 a.m.  However,
the train (in excess of 1.5 million pounds, including the coal) did not
respond to radio controls and smashed through the enclosed thaw shed and
coal rotary dumper, before smashing into the other train, Old No. 12.  (Big
Blue should have been going only about 1 mph for the last 100 yards entering
the dumper.)  The impact sent the other train through a fence, uprooted a
bumper post, and ripped up track.  A spokesman blamed it on a switch
malfunction.  But the system was supposedly designed so that if the
remote-controlled engine receives no signal, its brakes should automatically
engage.  Employees reportedly said that the system was not designed for the
engines currently in use.  Two other accidents occurred in the past month.
Also noted was what sounds like a serious lack of receptivity from NIPSCO in
responding to safety complaints from the workers' union over the past four
or five years.  [Source: No injuries in power station crash, by Jeff Tucker,
*The News Dispatch* (thenewsdispatch.com), 8 Mar 2002, PGN-ed, contributed
to RISKS by Dan Swinehart.]


LED lights can reveal computer data

<"NewsScan" <newsscan@newsscan.com>>
Thu, 07 Mar 2002 09:19:26 -0700

Scientists in the U.S. and the U.K. have found a way to remotely eavesdrop
on a computer by monitoring the flashes of LED lights on electronic
devices. Optical signals from the light-emitting diode lights found in
computer modems and keyboards can be captured with a telescope and processed
to reveal all the data passing through the device, says Joe Loughry, a
computer programmer at Lockheed Martin. "It requires little apparatus, can
be done at a considerable distance, and is completely undetectable. In
effect, LED indicators act as little free-space optical data transmitters,
like fiber optics without the fiber." Loughry says the most vulnerable
devices are equipment used in low-speed, long-distance networks, such as
ATMs (automatic teller machines). Corporate LANs and home Internet
connections are generally not susceptible to the spying technique.  Loughry
says his interest in LEDs dates back to his days in graduate school: "I was
working very late one night and waiting for a long file transfer to complete
and I was just staring at these lights on the front of the modem and started
to wonder if there was anything there." Loughry recommends locating
equipment away from windows, putting black tape over the LEDs or
deactivating when not in use. (Reuters 7 Mar 2002, NewsScan Daily, 7 Mar 2002)
  "http://story.news.yahoo.com/news?tmpl=story&cid=581&u=/nm/20020307/tc_nm/tech_snooping_dc_1"
  http://story.news.yahoo.com/news
    ?tmpl=story&cid=581&u=/nm/20020307/tc_nm/tech_snooping_dc_1


Yet another case of a program changing your input

<vassilip@dsl.cis.upenn.edu>
Sun, 10 Mar 2002 07:18:39 -0500 (EST)

I was entering grades in an Excel spreadsheet and realized that although in
my notes I had a mix of A's and A-'s, the spreadsheet had changed all the A
grades to A-'s. Why?

I was entering grades looking at my notes and not the screen. So I typed A-
followed by ENTER, then A at which point Excel suggested A- as a possible
input.  Without looking I pressed ENTER, thus entering A- instead of A.

This only works if the longer input precedes the shorter in the original
list (i.e., the list you are typing from), since if there is ambiguity about
the suggestion, Excel shuts up.

Next time I think I will use vi.


Loosing It's Grammer Skill's

<"Greg Searle" <greg_searle@hotmail.com>>
Wed, 6 Mar 2002 13:17:20 -0500

It seems that with the advent of cheap publishing technology such as the
Web, e-mail, and the laser printer, anybody can publish an electronic
article or print up hundreds of signs.  This has created an accelerating
downhill trend as to the quality of the print material that we are exposed
to every day.  Back in the old days when only professionals with expensive
equipment could create signs, flyers, and the like, these materials were
proofread by skilled experts before they were published.  The occasional
error in grammar or spelling was very rare.  Now, with the average Joe being
able to mass-create signage and flyers easily, there is no professional
between Joe and the printer to protect us from Joe's bad grammar.

For example, a local taxi company has printed bumper stickers and signs that
boldly state on every single taxi, "Driver's Wanted".  Tell me, what of such
a driver do they want?  Signalling skills?  Sure, I know what they really
mean, but this error is now so common as to be annoying.  How often do you
see something like, "loose those extra pounds" exclaimed from a cheap ad?
I'd rather get rid of them altogether, thank you, instead letting those
pounds run loose.

Many businesses lose potential customers before they even make them, because
of stupid mistakes in their literature, and they often wonder why.  Who
wants to do business with a company that can't even get its documents right?
To a business looking to hire out some work, sloppy errors on a potential
contractor's literature are telltale signs that something else may be wrong
at that business, and are a cue to look elsewhere.

Lax proofreading standards are becoming more common as corporations look
toward the bottom line, and want to save a buck.  Why hire an expensive
publishing company to compile and print your manuals, when an internal
employee can hand a disc to Copy Cop and turn out a few hundred nicely-bound
copies?  The end result is a lot of lower-quality documentation.  I took a
Java class recently, and the training agency's course documents were riddled
with stupid errors.  Some of these were even in the code examples.  This is
supposed to be a professional training agency.  They need to train their
documentation department on higher proofreading standards.

English is defined by its common usage over an extended period of time.  Are
we doomed to accept bad grammar as the official standard?  Sure, computers
make publishing easier, but the integrity of our language is at risk.


.org.au, .gov.au, .edu.au domain hijacking through lax security

<Grant Bayley <gbayley@ausmac.net>>
Wed, 6 Mar 2002 22:45:52 +1100 (EST)

A colleague of mine recently came across a disturbing lack of security in
the recently set up AUDA/AUNIC Registration Services for all .org.au,
.gov.au and .edu.au domain names.

To cut to the chase on what the problem is, as of 6th March, 2002, you could
enter any .org.au, .edu.au or .gov.au domain, any NIC handle and any
password, and the system would accept, redelegate and makes the changes live
in an average of less than 10 minutes.  It didn't even check the password at
all.

No doubt the hole will have been plugged by the time this makes it into
RISKS, and no doubt any genuinely radical and unauthorised changes will have
been reversed, but the scope of this vulnerability should be obvious.

Feel like picking up all the Web traffic and e-mail for your favourite
federal law enforcement or communications intelligence agency for maybe 12
hours? (afp.gov.au or dsd.gov.au)?  Perhaps an entire state? (nsw.gov.au)

Scary.  Very scary.

Yet another indictment of the flimsy DNS system on which we all rely.


Amendment to add life prison terms for reckless hacking

<Len Lattanzi <Len.Lattanzi@Migration.com>>
Wed, 6 Mar 2002 11:27:15 -0800

>From SANS NewsBites Vol. 4 Num. 10, 27 Feb 2002
Life Sentences Proposed for Reckless Hacking

  A US House subcommittee voted unanimously to propose lifetime jail sentences
  for hackers who knowingly attempt "to cause death or serious bodily injury"
  through electronic means.
    http://www.wired.com/news/politics/0,1283,50708,00.html

What should the punishment be for recklessly allowing remote access to
critical machinery and data?


The computing battlefield

<"Jon P" <cjmail@charter.net>>
Wed, 06 Mar 2002 17:59:25 -0500

On 5 Mar 2002, National Public Radio aired a segment talking about the
effort to put technology onto the battlefield.

  "Anthony Brooks of the WBUR program "Inside Out Documentaries," reports on
  efforts by the United States Army to create a lighter more streamlined
  fighting force.  Soldiers at Fort Lewis in the state of Washington are
  developing an "Interim Brigade Combat Force," which would have the agility
  of light infantry, combined with some of the punch of heavy armor. The
  idea is to make the force deployable anywhere in the world within 96
  hours."
  http://search.npr.org/cf/cmn/cmnpd01fm.cfm?PrgDate=03%2F05%2F2002&PrgID=2

The most chilling quote comes from an executive officer talking about how
battlefield data is distributed and presented to soldiers in Humvees and
armored vehicles: "We use nothing but Windows NT systems, that are hardened,
to provide HTML products, which are nothing but homepage products, to
disseminate the information via regular Internet protocols."  (At 5:05 into
the audio segment at http://www.npr.org/ramfiles/atc/20020305.atc.02.ram)

Gives new meaning to "Blue Screen of Death".

The full documentary report is available at
http://insideout.wbur.org/documentaries/reshapingmilitary/


Military palmtop will direct air strikes using WinCE

<David Wagner <daw@cs.berkeley.edu>>
Sun, 10 Mar 2002 00:05:00 -0800 (PST)

*New Scientist* is reporting that the US military is planning to deploy
palmtops for ground troops to use in transmitting targeting information for
air strikes and the like.  The application software will be running on top
of Windows CE.

  http://www.newscientist.com/news/news.jsp?id=ns99992005


The next step in malicious spam (From Dave Farber's IP)

<Joe Faber <joefaber@alumni.princeton.edu>>
Sat, 09 Mar 2002 11:28:46

I'm used to ignoring spam, but this morning I woke up to find that I
received no fewer than three 160K+ .exe attachments in my inbox purporting
to be from Microsoft.  They were from the "Microsoft Corporation Security
Center" and used "Internet Security Update" as their subject heading.  The
e-mail explains that the attached patch is the "5 Mar 2002 Cumulative Patch
that eliminates all MS Outlook/Express as well as six new vulnerabilities"
[sic].  It goes on to list some of the specific vulnerabilities and system
requirements.  They even provide a link to a Microsoft security Web site
(where I couldn't find any mention of the patch).

Aside from the issue of mailing 3 copies of a 160K attachment, I can't begin
to think of the trouble this might cause with the number of people running
Windows who would just think that this is benevolent Microsoft looking out
for them and would promptly open the attachment.  I'm no spam hunter, but I'm
keeping the e-mails around should anyone want to see the header information.

For IP archives see:
http://www.interesting-people.org/archives/interesting-people/

  [Bogosity alert!  This kind of seemingly helpful message could easily be
  used to do enormous damage.  Although some of the alleged vulnerabilities
  are legitimate, the message itself is indeed a hoax, as noted subsequently
  in various media -- including Dave Farber's IP, to which Ari Ollikainen
  contributed an article by Robert Vamosi, Gibe worm poses as a Microsoft
  update, ZDNet Reviews & Solutions, 6 Mar 2002.  BEWARE!  Always book a
  gift (Trojan) horse in the south.  PGN]


The RISK of ignoring permission letters

<Timothy Knox <tdk-freshmeat@thelbane.com>>
Sun, 10 Mar 2002 01:53:14 -0600

I received the following e-mail recently. The subject certainly sounded
encouraging: We request your permission (presumably to start sending me
spam). Great, thought I, I can just ignore this, and they will go away.
However, when I got to the last sentence of the main paragraph, I found
that their idea of requesting permission differs from mine. It reads:

If you do not wish to have HelloDirect.com contact you via e-mail, please
click the link below and your name will be deleted from our e-mailing
lists immediately.

This is NOT requesting permission. This is warning you that by NOT
responding, you are implicitly consenting to them sending you spam. With
UCITA, this might even become legally acceptable (like click-wrap licenses).

Finally, note how they try to play it cool in the last paragraph, talking
about how I 'requested' to be notified of special offers. This is an
outright lie. The e-mail address they sent to was only ever given to one
Web site, which is a company that does order fulfillment for some other
software companies. I did NOT give that company permission to send me ANY
special offers (I always decline), so this is a lie. I don't know if the
software fulfillment folks sold my address, or if they had their database
illegally copied, or if this address was harvested years ago (it has been
inactive for that long) and just now used.

 - --------------- Begin Forwarded Message ----------------
Subject: Hello Direct requests your permission.
Date Sent: Friday, 8 March 2002 10.09
From: Hello Direct <welcome@MT.DIRECTQLICK.COM>
To: tdk+dr@VUSHTA.COM

For over 14 years, Hello Direct has been recognized and respected as the
leading resource for telecom products, solutions and information.
HelloDirect.com is seeking your permission to send you up-to-date
information on current industry news, cutting edge telecom products and
services, special offers and product reviews via its electronic newsletter,
The Newswire. All of this valuable information delivered efficiently and
electronically, to your e-mail inbox!!! If you do not wish to have
HelloDirect.com contact you via e-mail, please click the link below and your
name will be deleted from our e-mailing lists immediately.

http://mt.directqlick.com/u/?e=tdk+dr@vushta.com&pn=4002152103-C

Sincerely,

Your friends at HelloDirect.com

****Hello Direct respects your privacy. This message was delivered to you
because you requested previously from another website to be notified of
special offers from preferred partners like Hello Direct.

  - ---------------- End Forwarded Message -----------------


Re: Air Transat Incident, Aug 24, 2001 (Johnson, RISKS-21.93)

<"Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>>
Wed, 06 Mar 2002 11:05:44 +0100

Whatever the status of the recent press commentary, John Johnson's brief
account of the Air Transat incident [RISKS-21.93] is misleading in various
respects, and I think it appropriate to set the record straighter.

Johnson says:
    Apparently, [...] a "computer program" incorrectly reported a fuel leak
    as an "imbalance".  To correct the "imbalance" the "computer program"
    diverted fuel from a good tank to the tank that was leaking thus both
    tanks were emptied.

First, the "imbalance" report was not "incorrect". A fuel leak in the main
fuel tanks, in the engines, or in between, on this model aircraft can lead
to a fuel imbalance warning. In circumstances such as this, a fuel
imbalance warning can be the first sign of a fuel problem. That a fuel
imbalance warning can be sign of a leak is specifically noted in the
relevant section of the operating handbook. Section 2.09, "Abnormal
Procedures", under "Fuel Imbalance" says, first "Caution: Do not apply this
procedure if a fuel leak is suspected. Refer to FUEL LEAK procedures."

Second, digital avionics systems are not just "computer programs". They
have many independent, dedicated programmable digital components.
There are over ten interconnected digital systems on this aircraft which
deal with the fuel, most of which are duplicated for redundancy. These
systems contain programmed digital hardware.

Third, the systems involved in reporting a fuel imbalance are not
identical with the systems involved in transferring fuel, although the
major digital component, the Fuel Control and Monitoring System (FCMS),
is involved in both. The FCMS is not a "computer program". It is two
dedicated digital computers.

Fourth, fuel transfer between imbalanced tanks has been de rigeur in heavy
aircraft for a half century, and automated in new designs for a quarter
century now. The automation mostly saves pilots a lot of work and worry.

Fifth, the leak was not in the wing tank, but on the engine itself.

All of this information has been publicly or semi-publically available since
the incident over six months ago.

Some more background.

The A330 is a twin-engined aircraft. Its main fuel tanks are in the
wings, as on most aircraft. Engines burn fuel at differential rates
simply because of individual differences. Such differential fuel burn
means that there is more fuel on one side of the aircraft than the
other after a while, which unbalances the aircraft. It is inefficient to
correct this by aerodynamic control inputs; the standard procedure
in large aircraft for the last half-century has been to transfer fuel
between tanks to regain balance. Since the late 1970's, new aircraft
have been designed to perform such transfers automatically or
semi-automatically, and such aircraft have been in service since the
early 1980's. On the A330, this control is performed by the Fuel Control
and Monitoring System (FCMS).

The fuel leak was on the engine, upstream of the control and monitoring
of the fuel burn. On a non-leaky system, integrating the fuel burn since
engine start ("total fuel burn"), and adding this quantity to the measured
fuel in the tank ("fuel on board"), one should obtain the same figure as
measured in the tanks at engine start ("ramp fuel"). All these quantities
are available continuously to pilots of all transoceanic aircraft, and it
has been good practice since transoceanic flying began to perform this
standard check. On earlier generation aircraft, this was the main method
of detecting a fuel leak.

The fuel leak was caused by a break in a fuel supply line on the engine,
itself caused by chafing of the line, which in turn was enabled by
improper installation of the engine. Why the engine had been improperly
installed is a non-trivial matter with no apparent computer involvement.

The major question is why the pilots did not detect the fuel leak earlier
than they did. Another question is as follows. Suppose the pilots had
discovered the fuel leak at the earliest possible moment; suppose,
further, that it had occurred at the most inopportune moment (at their
furthest point from suitable landing, which was allowed to have been as
much as two hours flying time away). Would the information available to the
pilots have enabled them, even in theory, to attain a suitable landing site
anyway without running out of fuel? You could shut down an engine and
isolate a leaking tank, maybe even transfer fuel away from a leak, but most
pilots are reluctant, for good reason, to shut down a working engine at
night over ocean, especially when they do not possess complete information
about the situation (in-flight real-time analysis of such a problem is
notoriously difficult and unreliable).

Concerning the first question, in September 2001, shortly after the
incident, I saw two ways in which presentation of information made
available to the pilots in such a case could be improved, and presented
these ideas to colleagues, the manufacturer, and the Bluecoat 2001
conference.  However, information available already in October showed that
the features that concerned me played either no role, or at most a very
minor role, in the incident. I should note that the fuel system automation
makes available to pilots (and investigators) much more, and more accurate,
information about the fuel state of the aircraft than is available on
aircraft with lower levels of automation.

The second question concerns the practice of flying over water significant
time away from suitable landing. So-called Extended Range Operations, or
ETOPS, permission is granted to airlines for specific aircraft and crew,
depending on the demonstrated reliability of equipment, personnel and
maintenance. The incident aircraft was operating under "120-min" ETOPS,
allowing it to fly up to 120 minutes away from a suitable landing site.  The
maintenance snafu caused Air Transat's ETOPS permissions to be
prophylacticly reduced to 60 minutes. The incident itself caused some to
question the very basis of ETOPS, not just its assessment, along the lines
which I indicated above. After an initial flurry of worry, the issue has all
but disappeared from the aviation technical press. However, it is still
unclear to me whether it can be satisfactorily answered.

Finally, whatever their performance during the earlier phases of the
incident, the crew glided their aircraft, without engines, at night,
some 85 nautical miles (98 statute miles, 156 km) to an essentially
perfect "dead stick" landing on an aerodrome they had never seen before,
a US military base. It was the world's first dead-stick landing of a
fly-by-wire aircraft, and a significant achievement.

Besides the passengers and their family, safety engineers also have a
lot to thank the crew for. Had the aircraft and crew been lost, either
in the ocean or on a landing attempt, almost all the information needed
to reconstruct this highly significant incident and learn from it would
also have been irretrievably lost.

ETOPS or no ETOPS, running out of thrust on a modern airliner is just
not supposed to happen. The lessons to be learned from this incident
are incomparably rich, and in many ways unique. Thank heavens, and
skillful pilots, that no one was hurt.

Peter B. Ladkin Faculty of Technology, University of Bielefeld, Germany.


Re: Malfunction shuts down ... amusement park ride (RISKS-21.93)

<Stanislav Meduna <stano@meduna.org>>
Wed, 6 Mar 2002 21:13:01 +0100 (CET)

I work in the area of process control systems. The systems capable of BSOD
(blue screen of death) are normally *not* used to control safety critical
parts of a system. These functions are usually implemented in the
programmable logic controllers, which are hard-realtime systems with much
less ways to crash. The traditional operating systems are used for the
higher level controlling, data storage and human-machine interface.

Software-based PLCs using e.g. NT (often with some realtime extensions) as a
underlying system do exist, but I doubt that they are used where safety of
humans is at risk. Nobody with a sane mind would risk that, regardless of
the claims of the vendors of these extensions that a realtime task continues
to run or at least performs a clean shutdown in the case of BSOD (but can be
technically completely messed up due to a runaway third-party driver).

The article doesn't mention how much faster the wheel was turning.  My
speculation is that maybe the controlling computer did indeed instruct the
wheel to turn too fast, but then a safety task in the PLC kicked in and
halted the machine. This is how these things are supposed to work - the
event was probably not really a "safety scare", as the BBC titled it.

Stanislav Meduna


Re: PayPal's tenuous situation (Jonas, RISKS-21.92)

<<max7531@earthlink.net>>
Thu, 21 Feb 2002 14:14:16 +0000

After using PayPal to buy something, I learned something. I recently made a
direct purchase from a web site through PayPal.  After it became clear that
the transaction would not take place, I issued a complaint through PayPal's
complaint service.  Not being satisfied at the short explanation of the
complaint process, I decided to give them a call to see where I stood.
After much cajoling, the operator told me that the person I transferred
money to had had her account frozen due to a fraud investigation! Of course,
PayPal never prevented her account from continuing to receive money after it
had been frozen. When questioned further, the operator said that it was
PayPal's policy to allow frozen accounts to continue to receive funds so
they could continue to payoff claimants!  It seems that PayPal has a
fundamental flaw in the way it "protects" users. With normal credit cards,
the credit card company must guarantee the transaction to the merchant,
since he takes a risk by accepting a flimsy piece of plastic instead of cash
for his valuable merchandise. With PayPal, the opposite should be true. They
need to protect the buyer, since the money is paid before she receives the
goods.  I can see how millions of dollars in fraud could be committed by
exploiting this flaw (as long as PayPal is willing to reimburse complaint
issuers. :)I'm still waiting on resolution, but I have no fear. Since I made
the payment with an actual credit card, I plan on challenging the purchase
through them if PayPal's response is unsatisfactory.  Must have been
something I read on RISKS about layered security.)

Please report problems with the web pages to the maintainer

Top