Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
Karsten Sohr at the University of Marburg has discovered another serious security flaw in Microsoft's Java Virtual Machine. A bug in Microsoft's bytecode verifier allows the construction of code sequences that illegally cast values of one Java type to values of another unrelated type, in violation of Java's typing rules, without detection by Microsoft's verifier. A malicious applet can exploit this flaw to breach the JVM's security, and can then proceed to do anything it wants to do on the victim's computer. For example, a malicious applet might exploit this flaw to read private data, modify or delete files, or eavesdrop on the user's activities. Dirk Balfanz and I, at Princeton University, have constructed a demonstration applet that exploits this flaw to delete a file. All recent versions of Microsoft's JVM for Windows appear to be vulnerable, so users of recent versions of Internet Explorer are affected by this flaw. A malicious applet could also be embedded in an e-mail message read using Microsoft Outlook or Eudora. Users of other JVMs, browsers, and email readers are generally not affected. (Thanks to Reliable Software Technologies for their help in testing on various platforms.) We have reported this flaw to Microsoft and they are working to address it. For more information, contact Karsten Sohr (sohr@mathematik.uni-marburg.de) or Edward Felten (felten@cs.princeton.edu, phone (609) 258-5906). Edward Felten, Secure Internet Programming Lab, Dept. of Computer Science Princeton University
The latest head-on collision occurred at the same Signal 109 near Ladbroke
Grove in Western London as the collision that occurred two years ago (almost
to the day). The previous accident occurred when one driver was looking
downward and somehow missed two Red signals. The latest accident was also
attributed to a driver missing a Red signal, this time the driver of a
commuter train that crashed with a high-speed intercity train from
Cheltenham. The train had an Automatic Train Protection System, but it was
switched off because it was ``not operational''. Its operation might have
helped, although it reportedly would not by itself have prevented the
accident. A new Train Protection Warning System had been scheduled to be
installed at Signal 109 in December 2003, along with many other places.
[Source: *The New York Times*, 9 Oct 1999, which noted at least 70 deaths
and 64 people unaccounted for.]
[Owen Hopkins noted that 8 trains have run past this signal in the past
6 years. Signal 63 has an even worse record. Comments also from
Jonathan Pritchard... With the breaking up of British Rail, there is no
one organization left to rail at? PGN]
[CORRECTION: My statement that the previous accident involved the
same signal is INCORRECT. It will be corrected in the next issue. PGN]
[Second correction: The number of deaths was incorrectly reported.
See RISKS-20.68. PGN]
There's a fascinating article in the 12 Oct 1999 *Wall Street Journal* about how a flaw in a TCAS (Traffic Alert and Collision Avoidance System) nearly caused a crash, rather than preventing one. On 28 Jun 1999, a British Airways jet and a Korean Air jet nearly collided when the latter's TCAS unit told the pilot to climb. The Korean Air plane was 2000 feet below the British Airways plane; however, the pilot was told that it was in fact 400 feet *above* it. That's too close, so the pilot was advised to climb. And that, of course, almost induced a collision. Part of the problem was with a circuit that sends the plane's altitude to the TCAS system and to the transponder. The circuit uses an 11-bit code over a parallel connection; a single-bit error, which occured in testing, would correspond to a 2400 foot difference in altitude — precisely the error here. (The article also notes that on a previous flight, the crew of this plane was advised that their transponder was giving the wrong altitude.) The British Airways jet, though, had a TCAS system that noticed an instantaneous jump in the altitude of the other plane. Since that's impossible, the bad readings were properly ignored, which in turn meant that there was no warning to the crew. When the TCAS system finally did detect that the other plane was climbing towards it, it could only say tell the pilots to dive, since the other plane was climbing. But that, according to the article, was precisely the wrong thing to do. The Korean Airways jet's TCAS system does include a comparator circuit to verify the altitude reading. Due to a wiring problem, however, that circuit was silently disabled; there is no warning to either pilots or mechanics of this condition. And the faulty altitude reading occurred when engineers left the air-data computer "on for a long time and added extra electrical power". The article closes by noting that the only thing that saved the two planes was marginally inaccurate navigation, and that if GPS-based systems were in use, the planes would have collided head-on.
On the afternoon of 30 Sep 1999 and continuing to the next day, dispatchers at the California Highway Patrol's San Diego communication center started receiving cellular 911 calls from Nevada, with callers reporting accidents at local Nevada street name unfamiliar to the dispatchers. When they finally figured out what was happening, calls were transferred back to the Nevada Highway Patrol for redistribution an appropriate dispatcher. Apparently, the problem was at the Nevada switching center for Sprint PCS and Pacific Bell. [Source: *San Diego Union-Tribune*, 2 Oct 1999, PGN-ed]
The U.S. National Centers for Environmental Prediction (NCEP) lost their
Cray C90 supercomputer in a fire, as reported in
http://www.ncep.noaa.gov/director/supercomputer/
Weather prediction runs have moved to slower backup machines. They are not
being run as often and are not looking as far in the future. "There is no
objective basis for making forecasts at the 8-14 day range, and no further
messages of forecasts will be issued until model guidance at that range
again becomes available."
Andrew Klossner (andrew@pogo.wv.tek.com)
Massive computer crashes have repeatedly forced California agencies to turn away customers for driver's licenses, food vouchers and other services. The Highway Patrol suddenly had difficulty checking criminal records. Child Protective Services could not get quick access to abuse files. For two days Glendale's DMV office had to process driver's license renewals manually. And one consulting firm clocked 19,000 minutes of intermittent outages in the first half of 1999. Some cars were impounded because computer records incorrectly showed licenses had expired. The Women, Infants and Children program reported a severe drop in participation, and had to return $5.7 million in unspent Federal funds. There were lots of long lines. [Source: PacBell Blamed for Failures of State Computers By VIRGINIA ELLIS, *Los Angeles Times*, 4 Oct 1999 http://www.latimes.com/HOME/NEWS/STATE/topstory.html; PGN-ed]
The fiber-optic cable cut by a gas-company employee 30 miles east of Cleveland, Ohio, disrupted Internet traffic nationwide for almost 12 hours on 29 Sep 1999. On the good side, here is a quote from *PCWeek*: ``As bad as it was, [Vaughan] Harring [a spokesman for GTE Internetworking] said it might have been worse without the redundancies most ISPs have built into their networks. "This was a significant cut. If something of this size happened a year ago, it would be more than degraded service.... We'd be talking about a hard outage." '' [<http://www.zdnet.com/pcweek/stories/news/0,4153,1017468,00.html>, PGN-ed.]
>From http://www.space.com/news/spacestation/iss_metric_991005.html Space Station Immune to Metric Mishap, NASA Says By Daniel Sorid, 05 Oct 1999 The International Space Station will not fall victim to the measurement units problems which ruined the Mars Climate Orbiter, according to a NASA spokesman. In the early 90s, engineers put together a so-called interface control document, which identifies the use of metric or English units for every piece in the station, according to NASA spokesman Dwayne Brown. "This is not a new issue for us," Brown said. "It's so well documented that we don't have that problem." The document also shows where metric and non-metric units interact with each other, and calls for the development of adapters that standardize the units. "Engineers got together and said, 'Here's the piece of hardware. Let's see where they interconnect.' If we've got a metric piece and an English piece, that will show up very clearly in the document." [...] There's one little problem with this theory: Mars Climate Orbiter had an interface control document too. (JPL is ISO9000 certified! We have documents for everything.) It was obviously not enough to save MCO; why should it be any different for ISS? Most accounts in the press make the MCO disaster sound like a massive breakdown in communications, with one group of people doing everything in Metric and another doing everything in English units, and no one talking to anyone else for months on end. I was told this morning by a member of the MCO team that this is not true. Everyone knew that everything was supposed to be Metric across the board. The problem was a single number in the software that was accidentally entered incorrectly. The exact same thing has happened on at least one previous mission, but the problem was caught before it became a news story (that is, before we drove the spacecraft into a planet.) Regular readers of RISKS will no doubt be shocked — shocked! — by these revelations. Erann Gat <gat@jpl.nasa.gov> [Usual disclaimers]
At the Library of Congress, where I work, the ATM network for the LC Credit Union was down for most of a week, with typed fliers pasted to the ATMs blaming the outage on Floyd-related flooding in New Jersey, and saying that we were one of a number of institutions which were affected by this. I was mildly surprised to see nothing about this in RISKS, but I found the following in a Y2K Usenet newsgroup (version below lifted from www.deja.com): > <> Forum: comp.software.year-2000 > <> Thread: Detailed reports on Floyd-EDS glitch > <> Message 8 of 9 > > Subject: Detailed reports on Floyd-EDS glitch > Date: 1999/09/27 > Author: John Denver <jd@howdyfolks.org> > Posting History Post Reply > > The following articles were found in the Bergen County Record. Glen > Rock, NJ is located in Bergen County. > > (9/23/99) Floyd struck a hub linking 23 centers > > From the article: > "Banks whose data lines fed into the local phone system via the > Rochelle Park hub lost their ATMs. A large facility down the street > owned by Electronic Data Systems Corp. also flooded, disrupting > service to their network of 8,000 ATMs across the country. Those > troubles were largely unrelated to the phone company's problems." > > Also, see: > (9/26/99)Dress rehearsal for Y2K distress: Can millennium match Floyd? > http://www.bergen.com/news/ytkrg199909262.htm > > Apparently, hearings are being conducted today (9/27) on this > fictitious unconfirmed problem: > "These questions could be raised in regulatory proceedings against the > company, as well as at a meeting Monday involving phone company > officials and U.S. Sen. Frank R. Lautenberg, D-N.J., and U.S. Reps. > Steve Rothman, D-Fair Lawn; Marge Roukema, R-Ridgewood, and Bill > Pascrell Jr., D-Paterson." > > Oh yeah, and a search for "Rochelle Park" at EDS.com yields... nothing. [I noted in RISKS-20.58 that my Maryland course on survivable systems had survivability problems in the second and third lectures (lightning and Floyd, respectively. Here is an update. For the fourth lecture (I was at SRI), the students in the classroom had intermittent video failures, attributed to ISDN lines still being flaky after the hurricane. For the fifth lecture, the classroom had audio only. The problem was eventually traced to the aftermath of the lightning strike three weeks earlier: the PC reboot had not included some updates for the video configuration. Mercifully, the sixth lecture was uneventful. So, only two of the six lectures failed to exhibit self-referential survivability problems. PGN]
Steve Wildstrom points out (in Risks 20.61), that ActiveX has been a thorn in Microsoft's side, which is certainly true. He seems to suggest, however, that *all* of Microsoft's problems boil down to problems in ActiveX, which is *not* true. Together with colleagues at Princeton and Xerox PARC, we recently found a bug in Microsoft's Java VM (see Risks 20.55) that would let an attacker compromise the VM, irrespective of the target's ActiveX settings. Historically, it seems bugs have been found throughout Microsoft's systems, ranging from TCP/IP fragment reassembly (e.g., "the ping of death") through Microsoft's Web services, such as the recent HotMail privacy incident. While I would certainly enjoy seeing Microsoft reinvent their ActiveX architecture in favor of something that provided reasonable security guarantees (and, heaven forbid, portability across operating systems), that would only be the first step on the road ahead for Microsoft. Dan Wallach, Rice University
Mike Martin reported on the problems with Tokyo taxicabs caused by the August GPS rollover (Risks-20.55). Aviation Week reports (Oct 4, p32) that US DoD systems also had problemswith weapons systems, even though the situation had been anticipated. "...the fault lay in the way the Pentagon's two primary mission planning systems, the Air Force Mission Support System AFMSS) and the Navy's Tactical Aircraft Mission Planning System, were providing the data to weapons systems." The mission planning tools provide, amongst other things, the approximate location of the GPS satellites to a weapons system GPS receiver so that the receiver can avoid large-sweep searching for the satellites. Some receivers work with 16-bit week data; the satellites and mission planners rolled over; and the different formats caused "conflicting data sets" and thus problems, according to AvWeek. "Short-term fixes...include editing the missions planning data manually, having the receivers find the satellites unaided or downloading the almanac data directly from the satellite, which takes about 13 min. The likely long-term fix is a software modification to AFMSS and TAMPS, which is considered cheaper than modifying weapons systems hardware." Peter Ladkin http://www.rvs.uni-bielefeld.de University of Bielefeld, Germany
Microsoft's May 1999 Service Pack 5 (SP5) was supposed make Windows NT 4.0 ready for Y2K. However, so many bugs arose that fixes have been included in SP6, which has been in beta since July. There are problems with the Net User command line security utility for setting log-in times, with real-time clock dates when not in a daylight-saving time zone, and with multiprocessor kernels, another problem with Outlook Express, etc. The problems are considered minor. Problems with other systems are also noted. [Source: NT Stung Again by Y2K Bug, Joseph McKendrick, 22 Sep 1999 <http://www.entmag.com/displayarticle.asp?ID=9239933447PM>, PGN-ed]
[Keith sent in a Reuters item noting that Iraq is has decided to avoid the costs of Y2K upgrades, and may have to shut down production for the new year instead. Many of their computers are reportedly old process controllers. Keith comments that with Iraq and Venezuela both lagging in Y2K fixes, it could be an expensive millennium for many drivers. PGN-ed]
> The Federal Bureau of Investigation says that some of the > Y2K-related programming fixes that were undertaken by > foreign contractors may contain malicious code. [...] > Such code could contain "time bombs" set to detonate at > some future date, [...] And how, exactly, would that be any different from the code that was there before ? (-: JdeBP
Intrigued by the headline "'Self-destruct' e-mail offers virtual privacy" (http://www.usatoday.com/life/cyber/tech/review/crg441.htm), I did some more investigating. Disappearing Inc. (http://www.disappearing.com/) has few technical details on its web site, but the general idea is that by using their plug-in two people can send and receive encrypted messages with the added feature that the key is held by Disappearing Inc. Anytime the recipient wishes to read the message, they must authenticate themselves to Disappearing Inc. in order to retrieve the key. Disappearing Inc. logs all accesses to the key and destroys the key at the end of its life span. Disappearing Inc. claims that once the key is destroyed the message can never be read again, and thus the message has effectively self-destructed like a Mission:Impossible assignment. While it is possible (although sadly, unlikely) that Disappearing Inc. has implemented this system using an appropriate mix of good authentication scheme, strong encryption algorithm, secure key generation, high level of site security, and secure key transmission it doesn't really matter. All Disappearing Inc. offers is a variant of third party key escrow and nothing more. The problems with key escrow have been well documented. By forcing users to go across the network to retrieve a key (which may have already expired) every time they want to read a locally stored message, it is a certainty that users will instead simply cut and paste any message worth reading again into a plaintext file outside the control of Disappearing Inc.'s encryption. The potential problems with this scheme are too many to list here, and my opinion is that users should cut out the middle man and use a package like PGP instead. Brad Arkin, Software Security Group Reliable Software Technologies
By the way, Brian Fitzpatrick's item in RISKS-20.61 about Linux being banned from a company for silly reasons reminds me of another anecdote in Feynman's books. From memory: Filing cabinets at Los Alamos were provided with combination locks, but these were seriously flawed; a person who had physical access to the cabinet while it was open could subsequently discover the combination and open it in a few minutes. Feynman identified this security risk and informed the people in charge... who responded by ordering all people with such cabinets *that Feynman had had physical access to* to change their combinations!
[Erwin Mascardo <mascardo@admin.assurenet.com> posted the following to rec.humor.funny. (It's in their archive at <http://www.netfunny.com/rhf/jokes/99/Sep/expedia.html>.)] My wife recently went on a business trip, and in filling out her expense report, she noted that she could claim the mileage to and from the airport. My first attempt at using MapQuest to calculate the distance failed, so I tried Microsoft Expedia Maps. After the shock wore off, my only regret was that my wife couldn't really claim this mileage figure, as we had no way to prove that we'd spent 9 days driving to Newfoundland and back. Highlights from the Microsoft-generated directions follow: Summary >From: Laurel, Maryland To: Baltimore-Washington International Airport, Maryland Driving Distance: 5865.1 miles Time: 9 day(s) 3 hour(s) 22 minute(s) Driving Directions Time Instruction 0:00 Depart Laurel, Maryland 1:01 Entering Delaware 1:17 Entering New Jersey 3:24 Entering New York 3:51 Entering Connecticut 5:51 Entering Massachusetts 7:29 Entering New Hampshire 7:44 Entering Maine 12:20 Entering New Brunswick 20:20 Take the North Sydney-Argentia Ferry 34:32 Entering Newfoundland 36:35 Turn left onto Local road(s) (4543.1 mi) 219:22 Arrive Baltimore-Washington International Airport, Maryland I guess when Microsoft asks "Where do you want to go today?" that *how* you get there isn't always important... (A subsequent attempt at MapQuest gave the correct figure of 16.5 miles.) [Forwarded to Risks by Mark Brader]
This one was posted to rec.humor.d, the followups-to-jokes group, by Bill
Seurer <BillSeurer@vnet.ibm.com>. Some misformatting in his posting is
fixed in this copy. --Mark Brader]
X-no-archive: yes
Erwin's wife wasn't the only one to get misdirected. I wonder if Microsoft
owns that North Sydney-Argentia Ferry?
Here is the trip Expedia proposed for a brother of one of my buddies. I
left off the compass directions and mileage parts. Do note that 14 hour
ferry ride, too!
Summary
> From: Hastings, Minnesota
To: Saint Charles [St. Charles], Minnesota
Driving Distance: 6758.6 miles
Time: 9 day(s) 17 hour(s) 30 minute(s)
Driving Directions
Time Instruction
0:00 Depart Hastings, Minnesota
0:03 Entering Wisconsin
1:47 At I-94 Exit 88, turn right onto I-94
2:41 Go onto I-90
4:51 Entering Illinois
6:40 Entering Indiana
7:01 At I-80 Exit 16, bear left onto I-94
7:29 Entering Michigan
10:42 At I-94 Exit 204A, turn right onto SR-39
10:46 At I-75 Exit 41, turn left onto I-75
10:55 At I-75 Exit 47, turn right onto SR-3
10:56 Turn right onto W Grand Blvd
10:57 Entering Ontario
10:57 Bear left onto S-3
11:04 Turn left onto S-2
11:06 Bear right onto S-3B
11:08 Bear left onto S-401
18:50 Entering Québec
18:50 Go onto C20
19:31 Bear left onto C720
19:37 Turn right onto S-134
19:40 At Longueuil, turn left onto C20
23:39 Bear right onto TC-185
24:39 Entering New Brunswick
24:41 Bear left onto TC-2
28:10 Go onto S-695
28:20 Turn left onto S-710
28:31 Turn left onto TC-2
28:35 Turn right onto S-112
29:17 At Salisbury, turn left onto S-106
29:46 Bear right onto TC-2
30:04 Entering Nova Scotia
30:06 Turn right onto TC-104
30:51 At Wentworth Centre, turn left onto S-246
31:02 Bear right onto S-256
31:42 Turn right onto S-6
31:44 At Pictou, bear right onto TC-106
31:50 Go onto TC-104
32:03 Bear right onto S-4
32:05 Go onto TC-104
32:08 Go onto S-4
32:14 Bear left onto TC-104
32:19 Bear left onto S-4
32:28 Bear left onto TC-104
33:01 At Mulgrave [Port Mulgrave], go onto TC-105
34:23 At Sydney Mines [Sidney Mines], bear left onto S-223
34:27 At North Sydney, turn left onto Local road(s)
34:29 Take the North Sydney-Argentia Ferry *CHECK TIMETABLE*
48:40 Take the Local road(s)
48:41 Entering Newfoundland
48:44 At Freshwater, go onto S-100
49:14 Bear right onto TC-1
49:41 Bear right onto S-13
49:54 At Bay Bulls, turn right onto S-10
50:43 Turn left onto Local road(s) (SE 4543.1 miles)
233:30 Arrive Saint Charles [St. Charles], Minnesota
Bill Seurer, Compiler Development, IBM Rochester, MN
Bill_Seurer AT us.ibm.com Bill AT seurer.net http://www.seurer.net/
France Info radio reported today (1999-10-06) that an investigation into police racism has been started in a small French town after a citizen, visiting the police station, observed a slogan with racist overtones scrolling across the screen of a PC on a desk in the reception area. The officer responsible for the PC claimed that the reference to "melons" (a French racist term of abuse, but also a legitimate word for the round fruit which has the same name in English) referred to his daughter's passion for harvesting said fruit. Regardless of the plausibility or otherwise of that statement, the RISK is clear: your screen saver message, scrolling away in bright mauve 24 point type, and quite possibly the only thing moving to catch people's attention, might say more about you than, say, a poster inside your locker ever could... Nick Brown, Strasbourg, France. email address updates : @coe.int replaces @coe.fr for more information, http://dct.coe.int/info/emfci001.htm
Please report problems with the web pages to the maintainer