precedence: bulk
Subject: Risks Digest 20.60
RISKS-LIST: Risks-Forum Digest Monday 27 September 1999 Volume 20 : Issue 60
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <URL:
http://catless.ncl.ac.uk/Risks/20.60.html>
and by anonymous ftp at ftp.sri.com, cd risks .
Contents:
Ikonos launched successfully
Computer problems foul up the Washington Metro system (Steven M. Bellovin)
Faulty aircraft collision avoidance system RISKS causing collision
(Mike Martin)
Net users "page-jacked" by pornographers (NewsScan)
Wonder when automatic toll-taker transponders will be cracked? (Jim Warren)
You don't even need a computer ... (Rob Slade)
Re: UK rail disaster (Clive Page)
9/9/99? (Joseph A. Dellinger)
The Microsoft/NSA Crypto Brouhaha (mp)
my.Yahoo.com bug/risk... (Matt Anderson)
Risk of being removed from a spam list! (Marc Salverson)
Mars Lander reprogramming
Re: Loss of Mars Climate Orbiter (Lord Wodehouse)
Re: Mars Pathfinder a failure? (Steve VanDevender)
Re: Mars Pathfinder (Ben Hines)
Re: Mars Climate Observer (Harlan Rosenthal)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Mon, 27 Sep 99 8:56:57 PDT
From: "Peter G. Neumann" <
[email protected]>
Subject: Ikonos launched successfully
The first successful launch of Space Imaging's Ikonos satellite occurred on
24 Sep 1999, from a Lockheed-Martin Athena II, following the earlier failure
on 27 Apr 1999 (RISKS-20.36 and 38) -- which has been blamed on an
electrical problem that prevented the aerodynamic payload covering from
coming off. Ikonos provides one-meter resolution, and is intended for
public consumption.
------------------------------
Date: Fri, 24 Sep 1999 14:21:59 -0400
From: "Steven M. Bellovin" <
[email protected]>
Subject: Computer problems foul up the Washington Metro system
According to the AP, the 3-year old $20M central computer system that
monitors the position of every train in the Washington, D.C., Metrorail
system failed on the morning of 24 Sep 1999. The backup involved personnel
with walkie-talkies along 96 miles of track monitoring trains. As a result,
the morning startup was delayed by half an hour.
[The cause was not identified. But this was reportedly the first time in
23 years that the start of daily service was delayed!
"A graphics generating device for Metro's finicky central computer
system froze about 3:20 a.m., sending Metro managers racing to fix it
before the scheduled start of daily service at 5:30 a.m. But they
couldn't restore it until 5:46 a.m., which meant normal passenger
service didn't begin rolling until about 6:15 a.m." -- resulting in
45-minute delays to start the day. "Last fall, the system crashed
several times during rush hour, including one episode similar to
yesterday's when computer-generated views of sections of the system were
blacked out for nearly two hours. In the 15 months after the system was
installed by McLean-based BDM International, it crashed 50 times."
Source: Computer Failure Puzzles Metro Opening Delayed, Rush Hour
Slowed, by Lyndsey Layton, *The Washington Post*, Saturday, September 25,
1999, Page B01, courtesy of Keith Rhodes; PGN-ed
http://www.washingtonpost.com/wp-srv/WPlate/1999-09/25/074l-092599-idx.html]
------------------------------
Date: Mon, 27 Sep 1999 16:08:17 +1000
From: "Martin, Mike" <
[email protected]>
Subject: Faulty aircraft collision avoidance system RISKS causing collision
The Australian Bureau of Air Safety Investigation recently made
recommendations (
http://www.basi.gov.au/rec/r19990156.htm
<
http://www.basi.gov.au/rec/r19990156.htm> ) following two incidents where
aircraft traffic alert and collision avoidance systems (TCAS) gave faulty
altitude readings.
The first case, which occurred near Hawaii in January 1998, involved a B747
and a DC8. Although the aircraft actually had 2000 feet vertical separation,
the TCAS unit in the lower aircraft reported it to be 1500 feet higher than
it actually was, presaging an evasive manoeuvre. Fortunately Hawaii air
traffic control noticed the discrepancy between the altitude reported by the
transponder and the altitude reported by the crew. Matters were then sorted
out without risk to either aircraft.
The same BASI report also discusses a more recent incident in Chinese
airspace last June, when two B747 aircraft almost collided at 31,000 feet.
Malfunctioning TCAS equipment resulted in the higher altitude aircraft
descending towards the lower one.
In neither of these cases did the crew have any on-board means of knowing
what altitude their TCAS was signalling and thus no means of realising that
it was malfunctioning.
While TCAS technology is a valuable contribution to safer skies, its
malfunction can introduce new risks. These are exacerbated when air crew
have no on-board means of knowing whether the equipment is working correctly
or not.
The BASI report on the second incident observes, "[it] placed both the
aircraft involved and all on board at very high risk... Ultimately, it was
only the 200 m lateral separation that prevented a mid-air collision, and
this separation was not provided by TCAS avoidance manoeuvres."
It later goes on to observe, "With TCAS only able to provide separation in
the vertical sense or, perhaps more importantly in this case, decrease
separation in the vertical sense, it would seem appropriate to provide
additional lateral separation. Had the aircraft in this incident each being
flying 1 NM right of track, the ensuing separation (assuming the events
would still have occurred) would have been 2 NM. Offset tracks such as this
are operated in some airspace where air traffic control may not be as
effective as desired but this incident was not caused by ineffective air
traffic control."
There has been previous discussion in RISKS about increasingly precise
aircraft navigation leading to increased risk of mid-air collision ("Air
collision RISK from increased accuracy", John Brooks, Risks 19.07).
These two incidents illustrate the reality of this.
The BASI article makes a number of recommendations aimed at reducing the
risk from faulty TCAS equipment.
Mike Martin, Sydney
[email protected]
------------------------------
Date: Thu, 23 Sep 1999 09:11:31 -0700
From: "NewsScan" <
[email protected]>
Subject: Net users "page-jacked" by pornographers
American and Australian investigators have zeroed in on an elusive
Portuguese cracker and an Australian pornography company as the perpetrators
of a fraudulent scheme to "page-jack" would-be visitors to legitimate Web
sites, such as the Harvard Law Review, and transport them to online porn
sites. The users reported that the only way they could escape was to shut
down their computers and reboot. Attempting to use the "back" or "home"
buttons merely resulted in being subjected to more pornography.
Investigators say the page-jackers were able to steal viewers by copying
legitimate Web pages and their so-called metatags, which provide key words
and code that are used to index the site for search engines. Australian
officials are considering civil or criminal charges against the company, and
a federal judge in Virginia has ordered many of the sites run by the company
off the Web, and directed the perpetrators to stop copying legitimate Web
pages. Executives at Alta Vista, which was used for the scam, say that the
search engine has taken steps to correct the problem by carefully monitoring
their index and by offering filters that can screen out pornography. (*The
New York Times*, 23 Sep 1999; NewsScan Daily, 23 September 1999, reproduced
with permission; original at
http://www.nytimes.com/library/tech/99/09/biztech/articles/23fraud.html)
------------------------------
Date: Sat, 25 Sep 1999 13:28:20 -0700
From: Jim Warren <
[email protected]>
Subject: Wonder when automatic toll-taker transponders will be cracked?
As some people know, various states' Transportation Departments and various
toll-bridge and toll-road jurisdictions have begun to deploy various kinds
of automated toll-collection systems. These involve having some kind of
transponder in or on the vehicle. This may be a small device the the driver
places near the front windshield when approaching a toll plaza. Other
systems require that the device be mounted on the vehicle, usually inside
the front grillwork.
As the vehicle approaches the toll plaze, equipment installed in the toll
plaza can sense these transponders, identifying the vehicle (or, at least,
the unique transponder) without the driver ever needing to stop or hand over
cash. Typically, drivers using these systems deposit funds, from which the
toll fees are automatically deducted as the transponder passes through the
toll-plaza sensor.
The question is: When will these devices be cracked and cloned -- just like
the massive cloning racket that is done with cell-phones?
Think it's not worth it? Think again! Remember -- Capt'n Crunch was one of
the first who was caught, prosecuted and convicted of cracking [San
Francisco] Bay Area Rapid Transit (BART) magstripe tickets, 10-20 years ago!
Of course, the risk will be greatly increased for those toll systems that
require that the transponder be permanently turned on -- rather than turning
it on only as one nears the toll plaza. Then, any cracker sitting on any
approach leading to a toll plaza should be able to trigger it and/or pick up
the transponder's id, for later cloning.
The safest toll systems will allow the driver to completely shield, or
otherwise turn-off, their transponder -- except when they are almost
actually inside the toll-plaza's vehicle-slip. (But of course, this makes
the transponders useless for law enforcement that may want to be able to
sense the transponder, far distant from the toll plaza ... for speed
enforcement and other possible covert surveillance purposes. :-)
Just another [paranoic] thought about crackers, law enforcement and the
"wonders" of technology. (Just because I'm paranoid doesn't mean that ...
:-)
jim, Jim Warren,
[email protected], GovAccess list-owner/[im]moderator/janitor
345 Swett Rd, Woodside CA 94062; 650-851-7075; fax-for-the-quaint/650-851-2814
------------------------------
Date: Thu, 23 Sep 1999 13:29:53 -0800
From: Rob Slade <
[email protected]>
Subject: You don't even need a computer ...
I hit my first carbon-based Y2K bug yesterday.
My wife was given a gift certificate for a restaurant last month (August:
you'll figure this out shortly) and we finally got around to trying out the
restaurant this week. (Quite nice.)
When the time came to pay, we presented the gift certificate. The waitperson
took it away, but returned almost immediately to tell us that it was no good:
it had expired. Sure enough, there was an expiry date: July 31st, 00.
Actually, Gloria is better at this than I am: she was the first one to figure
out what was wrong, and to explain that, obviously, the 00 stood for 2000, and
the certificate was good for almost a year yet. The waitperson still wasn't
sure about this, and went to check, but obviously got told that it was OK.
[email protected] [email protected] [email protected] [email protected]
http://victoria.tc.ca/techrev or
http://sun.soci.niu.edu/~rslade
------------------------------
Date: Fri, 24 Sep 1999 22:23:03 +0100
From: Clive Page <
[email protected]>
Subject: Re: UK rail disaster (Lyons, RISKS-20.59)
>... The train was also fitted with Automatic Train Protection (ATP),
>but this was also switched off ...
One of the accounts that I read said that the ATP could have been switched
on when this driver took over, but that it took four minutes to warm up,
during which time the train had to be stationary, and no-one wanted to make
the train late. No doubt the designers of the device thought that it didn't
matter much that it took so long to warm up (just as Microsoft doesn't have
much incentive to make Windows boot up in much less than one minute) but
clearly a device with a slow start *does* have safety implications, if it
someone has the choice of not using it in order to save time.
Clive Page
------------------------------
Date: Wed, 22 Sep 1999 17:15:23 -0500 (CDT)
From: "Joseph A. Dellinger" <
[email protected]>
Subject: 9/9/99?
The Wall Street Journal seems to have reported that 9/9/99 was a nonevent.
Yet, a relative of mine was shocked to discover $160K inexplicably credited
to their account. When they went to the bank to get it corrected, they found
a line of people already there waiting to see the bank officers. The person
in front of them in line had done considerably better: they had received
over 2 million dollars that way. The transactions had occurred on September
8, and the statement with the errors on it was printed September 9. The
bank (a well known name) "thanked them for their honesty in coming forward",
"apologized for the inconvenience", "had already fixed the problem so it
wouldn't happen again", and "advised all their customers to hold on to all
paper statements". This event (which apparently affected at least several
dozen people in a Dallas suburb) went entirely unreported in the local
media.
Was this the (mythical?) 9/9/99 bug or an unrelated fluke? I certainly never
heard of something like this happening before to anyone I personally knew!
------------------------------
Date: Sat, 25 Sep 1999 12:53:27 -0400
From: mp <
[email protected]>
Subject: The Microsoft/NSA Crypto Brouhaha (Re: Wallach, RISKS-20.58)
> Microsoft has said in public that
> this is a "backup" key, which is also believable.
Not really. Microsoft argued that a secondary key was needed in case the
primary signing key was somehow lost. This is a danger, but there is no need
to introduce a secondary key when they can just as easily keep a secure
off-site copy of the primary key. (There are good reasons to have a
secondary encrypting key, but this was a signing key.)
A secondary signing key could be useful because it could allow the primary
key to be revoked if it was somehow compromised. Unfortunately Microsoft's
system does not support key revocation. Microsoft's system does not even
inform the user which key was used to sign the CSP module.
I think a large part of the concern is due to the fact that a secondary key
makes it easier for an attacker to replace one crypto module without anyone
noticing.
------------------------------
Date: Fri, 24 Sep 1999 15:14:11 -0400
From: Matt Anderson <
[email protected]>
Subject: my.Yahoo.com bug/risk...
Recently I had an opportunity to borrow an old laptop of a co-worker for use
on a business trip. While on the trip, I used the Netscape browser (4.x) on
the laptop to access the internet. The browser was set to my co-worker's
web page, my.yahoo.com. Being a bit mischievous, I added a few things that
got displayed on his web page(He got back the latest news on the goings on
of Cricket, NASCAR, Boxing and the LPGA). My co-worker (who uses IE5.0)
discovered this right away using his new computer and changed his password.
However, I was still able to access his web page and modify his profile.
Even after an extended period of time(overnite) and with the old laptop
turned off, when I powered the laptop up and started up the Netscape
browser, I was still able to access the web page the following morning.
Needless to say, when I found out that my co-worker had changed the password
3 times and I still could access it, we recognized it as a security hole in
Yahoo's website.
We were able to recreate this repeatedly. It is rather simple. Go to
my.yahoo.com in your Netscape browser and create a yahoo account and check
the box that says remember password and id. Then exit the Netscape browser.
Now start a IE browser and go to the same URL(my.yahoo.com) and type in your
account_id and password and check the box that says remember password and
id(as a cookie). Change your password via the IE5.0 browser. Now bring up
your Netscape browser and go to the same URL(my.yahoo.com) again. You still
get into the web page.
Whether this is a combo Netscape/Yahoo problem or just Yahoo remains to be
seen. Yahoo techies basically blew us off with suggestions like "cache
retention" and proxy server page caching. But it would seem obvious to me
that both suggestions are without merit as they would imply that we should
simply get the same page back again and we were getting updated news items
and the pages would differ as we updated them. Of course it also doesn't
explain how you could add sections and delete sections of a web page and
cache memory would know how to do that.
While the risk is limited(I couldn't access his e-mail or add him to yahoo
mailing lists, however I didn't explore all the possibilities) and I also
didn't explore what possibilities existed with other websites(Amazon comes
to mind with their one-click purchase options), however, the obvious
potential is there for more malicious attacks from more mischievious
co-workers than myself. Basically, any one who grabs your cookie.txt file
can get access to your web page REGARDLESS OF HOW MANY TIMES YOU CHANGE YOUR
PASSWORD.
Any web site that assumes the identity of the user even if its only at
the surface, leaves itself more vulnerable than those that do tighter
security checks.
M@ Anderson, Chief Engineer, Hope Consulting Group, Inc. www.hopeconsulting.com
88F Jefferson Boulevard, Warwick, RI 02888 (401) 785 - 3211
------------------------------
Date: Thu, 23 Sep 1999 09:31:55 -0500
From: Marc Salverson <
[email protected]>
Subject: Risk of being removed from a spam list!
The dot com free e-mail spam from Network Solutions includes:
> If you do not wish to receive e-mail from Network Solutions, click on
> this e-mail address <mailto:
[email protected]> and type
> "remove" in the subject line.
> PLEASE NOTE: by opting to be removed from this list we will not be
> able to communicate to you, in real-time, on issues regarding your
> account.
So, what they're saying is that if they decide to set up free e-mail for you,
with an easily guessable password, they won't tell you?
Oh, what a Risk!
Marc Salverson <
[email protected]>
------------------------------
Date: Mon, 27 Sep 99 9:01:15 PDT
From: "Peter G. Neumann" <
[email protected]>
Subject: Mars Lander reprogramming
After the loss of the Mars Polar Orbiter (RISKS-20.59), the Mars Polar
Lander is being reprogrammed to report its data directly back to earth. The
Lander is scheduled to reach Mars on 3 Dec 1999. Stay tuned.
------------------------------
Date: Thu, 23 Sep 1999 20:05:00 +0100
From: Lord Wodehouse <
[email protected]>
Subject: Loss of Mars Climate Orbiter
From the reports so far, it appears that Mars Climate Orbiter flew too close
to Mars (60Km) as opposed to about 140Km. 60Km is considered 25Km below the
minimum safe height.
BBC online news has a quote from JPL:
"Yesterday, MCO was approaching the planet to pass within 140km of the
surface and all seemed okay. However, in the last six to eight hours
before the approach we saw a 100km drop and we don't understand why."
Now 100Km changes don't just happen, so the question is "Where was the error
in the calculations?" Somewhere either a tracking error or software error
has gone unoticed until too late, or the final correction burn was not as
expected.
However the knock-on of this mistake is going to be a real issue. Mars
Polar Lander and the two Deep Space 2 microprobes depended on having Mars
Climate Orbiter to relay data from them to Earth and also to relay commands
back. So "smaller, cheaper, faster" has hit a snag, which was not allowed
for. NASA will no doubt say it can recover, but with the budget cuts, this
will not be easy.
Past errors like the HST mirror, Galileo's high gain disk and the loss of
SOHO were recoverable, because either clever engineering and/or great
innovation (especially operating SOHO with no gyros at all) have proved
possible. But the demise of MCO seems reminiscent of Icarus! Too close is
always a one way ticket! --
Global Research Information Systems, Glaxo Wellcome Medicines Research Centre
Tel: +44 (0)1438 76 3222 mailto:
[email protected] (preferred)
------------------------------
Date: Fri, 24 Sep 1999 00:20:53 -0700 (PDT)
From: Steve VanDevender <
[email protected]>
Subject: Re: Mars Pathfinder a failure?
... The U.S. lost a 1993 Observer,
and more recently the Mars Rover Pathfinder (RISKS-19.49 to 56). There
have of course been some successes, with the Viking landers (1970s) and
Pathfinder (1997).]
I'm a little confused by PGN's contradictory statements regarding Mars
Pathfinder above. At least according to all the NASA statements I saw, the
Pathfinder lander lasted almost 90 days before it stopped communicating with
Earth, but had a design lifetime of only 30 days; the Sojourner rover only
needed to last about a week to meet its mission objectives but was still
working well when the lander failed, cutting off the ability to relay
communications to and from the rover. (This may very well have left
Sojourner slowly circling the lander until it too failed, as that was the
rover's programmed contingency plan if it lost communications with the
lander.) As a relatively inexpensive mission Pathfinder was intentionally
not designed to last indefinitely on the Martian surface, and it was
expected that thermal cycling would eventually fracture connections in the
lander's electronics.
While the priority inversion problem in the Pathfinder lander's software
that caused spontaneous reboots was irksome and extensively discussed in
RISKS as an example of the difficulties of real-time OS scheduling, it was
by no means fatal to the mission.
If navigational error is considered to be the most probable cause of the
Mars Climate Orbiter's loss, this will be a rare sort of failure for NASA.
I cannot recall any NASA interplanetary probe previously being lost due to
gross navigational problems, and many of those are in far more distant and
complicated environments, such as the Galileo probe's lengthy stay at
Jupiter involving many close passes to the Galilean moons and a
continuously-changing orbit. Mars Global Surveyor was even successfully
aerobraked into its desired orbit despite a greatly extended period of
aerobraking to avoid additional damage to a weakened solar array, which
required careful monitoring of its status and frequent adjustments to its
orbit for over a year.
------------------------------
Date: Thu, 23 Sep 1999 19:46:31 -0700
From: Ben Hines <
[email protected]>
Subject: Re: Mars Pathfinder
PGN said in RISKS-20.59 that the US lost the "mars rover pathfinder".
In fact, the Rover was called Sojourner. The mission and lander itself was
called Mars Pathfinder. And indeed, they did lose the signal, but after over
3 months of ground time - for a mission designed for a month long stay.
Pathfinder has never been considered a failure.
[email protected] <
http://members.tripod.com/~tunnels/>
------------------------------
Date: Fri, 24 Sep 1999 09:00:19 -0400
From: Harlan Rosenthal <
[email protected]>
Subject: Re: Mars Climate Observer (RISKS-20.59)
>>Mars has been a tough target.
That's because the Martians keep shooting things down.
------------------------------
Date: 23 Sep 1998 (LAST-MODIFIED)
From:
[email protected]
Subject: Abridged info on RISKS (comp.risks)
The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. Alternatively, via majordomo,
SEND DIRECT E-MAIL REQUESTS to <
[email protected]> with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
INFO [for unabridged version of RISKS information]
.MIL users should contact <
[email protected]> (Dennis Rears).
.UK users should contact <
[email protected]>.
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to
[email protected] with meaningful SUBJECT: line.
=> ARCHIVES are available:
ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
[volume-summary issues are in risks-*.00]
[back volumes have their own subdirectories, e.g., "cd 19" for volume 19]
or
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue].
PostScript copy of PGN's comprehensive historical summary of one liners:
illustrative.PS at ftp.sri.com/risks .
------------------------------
End of RISKS-FORUM Digest 20.60
************************
