Text File

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" <neumann@csl.sri.com> 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" <smb@research.att.com> 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" <mmartin@sbnsw.com.au> 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 Mmartin@sbnsw.com.au

------------------------------

Date: Thu, 23 Sep 1999 09:11:31 -0700 From: "NewsScan" <newsscan@newsscan.com> 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 <jwarren@well.com> 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, jwarren@well.com, 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 <rslade@sprint.ca> 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.

rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade

------------------------------

Date: Fri, 24 Sep 1999 22:23:03 +0100 From: Clive Page <clive@page.demon.co.uk> 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" <jdellinger@amoco.com> 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 <mp@the-wire.com> 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 <manderson@hopeconsulting.com> 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 <marC@undergraph.com> 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:netsolremove@integram.org> 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 <marC@undergraph.com>

------------------------------

Date: Mon, 27 Sep 99 9:01:15 PDT From: "Peter G. Neumann" <neumann@csl.sri.com> 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 <w0400@ggr.co.uk> 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:w0400@ggr.co.uk (preferred)

------------------------------

Date: Fri, 24 Sep 1999 00:20:53 -0700 (PDT) From: Steve VanDevender <stevev@efn.org> 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 <bhines@san.rr.com> 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.

bhines@san.rr.com <http://members.tripod.com/~tunnels/>

------------------------------

Date: Fri, 24 Sep 1999 09:00:19 -0400 From: Harlan Rosenthal <Harlan.Rosenthal@Dialogic.com> 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: RISKS-request@csl.sri.com 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 <risks-request@csl.sri.com> 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 <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => 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 risks@CSL.sri.com 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 ************************