precedence: bulk Subject: RISKS DIGEST 19.78 RISKS-LIST: Risks-Forum Digest Thursday 4 June 1998 Volume 19 : Issue 78 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 http://catless.ncl.ac.uk/Risks/19.78.html Contents: Mir mortals' bum steer (PGN) Senate talks martial law and Y2K; Indian nuke-hackers (Declan McCullagh) Corporate insurance excludes Y2K (Ulf Lindqvist) The Year-2000 Muddle Continues (Andy Goldstein) Texas accent required for voice recognition in UK (Mich Kabay) Netomania (Edupage) Nielsen Rate-Hiked (Declan McCullagh) Risks of online phone books (Jeremy Epstein) NorWeb denies 999 interference (Michael A. Eccles) Re: Pager unreliability (Chris Cartledge) Re: Navy stops teaching celestial navigation (Jeff Uphoff, Geoff Kuenning, Jim Wolper) Re: Failure modes when the power fails (George C. Kaplan) Disabling Java and JavaScript isn't totally safe either (Don Byrd) Who is watching the capacity and performance needs of Java solutions? (Jerry Svigals) Referer-log security hole (Jorn Barger) globe.com vs Advertising Age passwords: spam and security problem (David Wittenberg) Re: CzERT group of hackers ravage Czech & Slovak cyberspace (Steven Slatem) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 2 Jun 98 20:18:36 PDT From: "Peter G. Neumann" Subject: Mir mortals' bum steer Over the last weekend of May 1998, a computer critical to the Mir automatic steering system failed. The cosmonauts replaced it with a new one, but they were unable to load the new one with software necessary to run the steering system, at a time when the shuttle Discovery was about to be launched to dock with Mir. Finally, on Monday 1 June, the problem was resolved (just *how* was not specified in the reports I saw), and the Discovery launch took place. Does a tear appear when Mir won't steer? Well, have no fear, the veer's not near. The cheer from here I hear is clear. It's sheer delight. You have our ear. So, quaff a kvass and hoist a beer, Let's hear it for the programmeer who caused the glitch to disappear -- and thus inspired this sonneteer. PGN ------------------------------ Date: Thu, 4 Jun 1998 14:21:28 -0700 (PDT) From: Declan McCullagh Subject: Senate talks martial law and Y2K; Indian nuke-hackers http://cgi.pathfinder.com/netly/afternoon/0%2c1012%2c2038%2c00.html time.com / The Netly News / Afternoon Line, 4 Jun 1998 The Martial Plan Think the Year 2000 problem means mere elevator snafus? Try dealing with a platoon of Marines who show up in your front yard to confiscate your hoarded lentils. Sen. Robert Bennett (R-Utah) asked the deputy secretary of defense at a hearing this morning what plans the Pentagon has "in the event of a Y2K-induced breakdown of community services that might call for martial law." John Hamre replied carefully, but none too reassuringly, "We've got fundamental issues to deal with that go beyond just the Year 2000 contingency planning. And I think you're right to bring that up." Another distressing point that came up at the Senate Armed Services committee hearing was the fact that the military directs one quarter of U.S. air traffic. "You may be flying across the country and an air traffic controller may be a military guy in certain areas as opposed to it being an FAA person," Hamre said. Although the FAA's head Y2K guru assured us this afternoon that the agency will have its Y2K fixes complete by October 1998, the military appears to be in much worse shape. And other countries? "We can be sure that there will be social unrest in many parts of the world as a result of Y2K," Bennett said. For the record, though, Bennett did say, "I am not one of those who says that Y2K will automatically produce martial law," and blamed "alarmists, extremists out there on the Internet" for unnecessary scaremongering. --By Declan McCullagh/Washington Hackistan As if the accelerating arms race on the subcontinent weren't disturbing enough, a group of hackers broke into the local area network of India's Bhadha Atomic Research Center (BARC) and copied five megabytes' worth of data, including e-mail between scientists and files from India's nuclear research program. [...] [According to an article by James Glave in WiReD News, 3 Jun 1998, James interviewed the three teenage "Milw0rm" crackers (in New Zealand and England) by Internet Relay Chat. They apparently gained control over 6 of the 8 servers in *.barc.ernet, altered the BARC Web site, and deleted many files -- in protest against the Indian nuclear testing. (The BARC is worse many bytes?) They also e-mailed some of their discoveries to James. They say they are now going to take a closer look at the Pakistanis. PGN] ------------------------------ Date: Mon, 1 Jun 1998 14:04:54 -0700 (PDT) From: Ulf Lindqvist Subject: Corporate insurance excludes Y2K I note that in their general conditions for corporate insurance policies, one of the large Swedish insurance companies (Trygg-Hansa) have made the following exclusion effective as of May 1, 1998 (my layman translation): "The policy will not cover damage, cost, legal or other liability caused directly or indirectly or connected to time-related disturbance in computer functionality." This is hardly surprising, but it is interesting to note that the exclusion specifically concerns only time-related overflow and would not for example exclude the Dow Jones 10K problem. Ulf Lindqvist, Department of Computer Engineering, Chalmers University of Tech. SE-412 96 Goteborg, SWEDEN, Currently at SRI. http://www.csl.sri.com/~ulf/ ------------------------------ Date: Sun, 31 May 1998 10:41:48 -0400 From: goldstein@star.zko.dec.com (Andy Goldstein - VMS Development) Subject: The Year-2000 Muddle Continues Yesterday I was in line at the register of a store I will leave nameless to avoid undue embarrassment. Ahead of me, a silver-haired gentleman handed over a check for his purchase. The register clerk stamped the check (getting the stamp right side up on the second try) and took the customer's vital statistics. She was puzzled when the computer wouldn't take his birth date. After a phone call and consultation with a supervisor, the man's check was approved, with the explanation that his date of birth had been rejected "because of a recent year 2000 fix". Figured it out? No further explanation was available, but I'll bet you dollars to donuts they made the old "sliding window" fix, making all dates before, say, 50, be in the 21st century. And of course the program was smart enough to not accept birth dates in the future. Morale: Having your code inspected and fixed for year-2000 compliance is no guarantee it's going to work right. ------------------------------ Date: Wed, 3 Jun 1998 17:05:18 -0400 From: "Mich Kabay [ICSA]" Subject: Texas accent required for voice recognition in UK According to an article in _The Guardian Weekly_ (May 10, 1998; p. 11), biometric authentication using voice recognition has hit a stumbling block because of trans-oceanic differences in accent. > Tagging Test Pines for Texas, by Alan Travis > A British experiment using an American device to monitor convicted > criminals to be introduced later this year has hit a snag -- the high-tech > "voice recognition" system only responds to a Texas drawl. > The Home Office scheme involves ordering offenders to carry dedicated > pagers with them to ensure check-ins several times a day. The author explains that the paroled convicts are supposed to respond to the request for check-in by phoning a toll-free number and identifying themselves. The biometric authentication system then authenticates their identity. I guess the system must also use automatic number identification to track their physical location (although auto-forwarding of calls poses an unmentioned threat to such a scheme). The problem occurred when the unnamed brand of voice recognition system failed to respond reliably to British accents. Seems the Texas company "trained" the system using only Texas drawls. One additional problem: if the manufacturers in Texas assume that all British people sound the same, they are in for a nasty surprise. I suspect that the variations of pronunciation and even of prosody in that tight little isle exceed the variations found in television-drenched America (not counting the wonderful flavours added by immigrants' accents). M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education International Computer Security Association (Carlisle, PA) [Quick-drawl artists need not apply. The AYES of Taxes are a pun us. PGN] ------------------------------ Date: Tue, 02 Jun 1998 16:49:05 -0400 From: Edupage Editors Subject: Netomania (Edupage) Reporting a study of 14 so-called Internet "addicts," psychiatrist Nathan Shapira of the University of Cincinnati says that, on average, the subjects of the study each had had five psychiatric disorders. Shapira thinks that excessive online use should be considered not as a separate addiction but as a disorder of impulse control, in the same category as kleptomania or compulsive shopping. He suggests the problem be called Internetomania or Netomania. (*USA Today*, 1 Jun 1998; Edupage, 2 June 1998) ------------------------------ Date: Wed, 3 Jun 1998 15:39:48 -0700 (PDT) From: Declan McCullagh Subject: Nielsen Rate-Hiked "Release of the prime-time television ratings has been delayed due to computer problems at Nielsen Media Research. We hope to move them by noon EDT." (according to an AP item on 3 Jun 1998) [Declan later noted that a story slugged BC-Nielsens was out by 1:12pm, and the list of primetime shows made it by 3:10pm EDT. I suppose that many folks consider the ratings even more moving than the content of the listed programs themselves. PGN] ------------------------------ Date: Tue, 02 Jun 1998 14:45:13 -0400 From: Jeremy Epstein Subject: Risks of online phone books One of our staff took off early the other day because he received an emergency phone call that a family member had been shot. But it was a false alarm caused by technology. Seems that "Cousin Patrick" was shot, and "Aunt Penny" decided to tell everyone. She did a Web search for everyone with the same unusual last name. [I don't know how wide a geographical area she searched over.] Among the hits was someone on my staff, who was unrelated, but happens to also have a Cousin Patrick and an Aunt Penny. So he got an emergency phone call, trundled off, etc. Of course this could have occurred in the "old days" too, but it's much easier to get those phone numbers now, while in the old days it would have required a trip to the library and leafing through dozens of phone books (or lots of calls to directory assistance). And as a result, people would be less likely to broadcast a warning to unknown "relatives". Other than some lost time and some frightened people, no harm was done by the mistaken identity. Jeremy Epstein jepstein@tis.com, TIS Labs at Network Associates, Northern Virginia Office +1 (703) 356-2225 Ext 106 ------------------------------ Date: Wed, 3 Jun 98 12:36:25 +0000 From: michael-a.eccles@bae.co.uk Subject: NorWeb denies 999 interference (Re: Slade, RISKS-19.74) > ... Nick Long from the Low Power Radio Association reports that > streetlamps in the Nortel trial region have been acting as highly > efficient antennae ... According to PCWEEK newspaper (2 June 98) here in the UK, NorWeb (the company Nortel and Norweb established to develop the technology has described the allegations as "fictitious and laughable". The company claim that they have been working with the UK Radiocommunications Agency which has stated "DPL (Digital Power Line) technology has not interfered in any way with any radio spectrum users." NorWeb is considering legal action against Great Circle Design, the company that made the allegations to the press. Mike Eccles Independent Safety Auditor for Software ------------------------------ Date: Tue, 2 Jun 1998 15:32:08 +0100 From: "Chris Cartledge" Subject: Re: Pager unreliability (McInnis, RISKS-19.76) > Hospitals, doctors, and other emergency personnel (and those who > depend on them) are dependent on paging systems. Many businesses are > dependent on paging systems. I would question the risk analysis of any organisation that depends for critical messages on the general use of pagers outside a well defined area. Pagers have the message sent to them once and there is no acknowledgement -- the transmission is single ended and prone to failure. In a recent test, a UK consumer magazine found as many as 40% of messages could go astray if the intended recipient was in a multi-story car park, metro station or similar location where reception is difficult. There is a more modern and reliable alternative - SMS, short message system used with mobile phones, though it may be even more satellite dependent. Chris Cartledge ------------------------------ Date: Tue, 2 Jun 1998 15:36:07 -0400 From: Jeff Uphoff Subject: Re: Navy stops teaching celestial navigation (Mannes, RISKS-19.76) >> ... midshipmen will no longer have to learn the often tedious task of >> using a wedge-shaped sextant to look at the stars and plot a ship's >> course. This statement strikes me as just a bit misleading: Celestial Navigation was--at least when I was a Midshipman at Annapolis in the late 1980's--a full-semester course; it was not just a few easily-replaced lessons stuffed inside another course. So...not only are they eliminating the Celestial Navigation course--they're planning (according to a friend of mine that currently teaches at Annapolis) on adding those "few extra lessons on how to navigate by computer" by replacing some of the lessons in *yet another* navigation course: the basic navigation course (a prerequisite for the Celestial Navigation course) that teaches voyage planning, tidal computation, triangulation fixes, etc...real bread & butter stuff for a junior officer. Jeff Uphoff - Scientific Programming Analyst, National Radio Astronomy Observatory Charlottesville, VA, USA juphoff@nrao.edu juphoff@bofh.org.uk ------------------------------ Date: Mon, 1 Jun 1998 14:06:29 -0700 From: Geoff Kuenning Subject: Re: Navy stops teaching celestial navigation (Pierson, RISKS-19.77) > I believe there are still backup satnavs, independent of GPS... I know of no backup satellite systems. There was a predecessor to GPS, but I'm pretty sure it's been shut down. There are two existing ground systems that provide near-worldwide coverage: Omega and Loran. Omega is the older, and is in the process of being retired (it was pretty unreliable already, judging from the frequent outage notices). Loran will be retired in the next few years. For some perspective, however: sextants are *not* reliable. They depend on having a reasonable clear view of both the horizon and some celestial body, simultaneously. That means that in bad weather you're stuck, sometimes for many days at a time. A flotilla steaming at 30 knots can cover a lot of ocean, and might just go aground on an island, in that interval. Even in the best conditions, sextant shots are accurate to only +/- a mile or so, making it hard to avoid (or find) that island if it's very small. In contrast, the military built GPS under the assumption that the USSR would have anti-satellite capability. You know all those missiles we have in silos? Some don't have warheads; they have spare satellites. I don't know the exact numbers, but I'd bet they can get a new GPS broadcaster online in minutes if they *really* need to. Geoff Kuenning geoff@fmg.cs.ucla.edu http://fmg-www.cs.ucla.edu/geoff/ ------------------------------ Date: Tue, 02 Jun 1998 19:34:02 +0000 From: Jim Wolper Subject: Re: Navy stops teaching celestial navigation (Pierson, RISKS-19.77) Dave Pierson suggests, probably correctly, that the US Navy does not intend to use GPS as the sole source for navigational information. However, he alludes to the Transit/SATNAV system as a possible backup system. This system was decommissioned on 31 Dec 1996. Nobody has said that the Navy intends to stop using celestial navigation ; the assertion is that it will not be taught at the very beginning of an officer's career. A typical military officer undergoes advanced training as a prerequisite to new assignments or promotion; a naval officer's training no more stops at the Naval Academy than a physician's stops at medical school. It is certainly possible that young officers will be trained in celestial navigation at sea. This might be an improvement over classroom training. Jim Wolper ATP/PhD/CFI, Associate Professor of Mathematics, Idaho State University Pilot/Instructor, Avcenter, Inc. ------------------------------ Date: Tue, 26 May 1998 16:30:32 -0700 From: "George C. Kaplan" Subject: Re: Failure modes when the power fails (Weaver, RISKS-19.76) In RISKS-19.76, Nicholas C. Weaver described various failure modes in the CS department during the power failure that hit UC Berkeley on 19 May. The entire campus network was, of course, offline during this period, and all the major network equipment was turned off to prevent damage due to surges when the power returned. When it became apparent that the power wouldn't come back before the end of the working day the network support personnel went home, leaving instructions with the skeleton operations crew to page them when the power came back on. By now we all know about that *other* little problem that afternoon. Because our pagers weren't working, we didn't hear that power had returned until someone happened to call in to work to check. So restoration of network operations took about an hour longer than it would have if Galaxy IV hadn't failed. George C. Kaplan, Communication & Network Services, University of California at Berkeley 1-510-643-0496 gckaplan@ack.berkeley.edu ------------------------------ Date: Wed, 03 Jun 1998 09:43:27 -0400 From: Don Byrd Subject: Disabling Java and JavaScript isn't totally safe either To avoid the well-known risks of Java and JavaScript--cf. McGraw and Felten's book Java Security, numerous comments in this forum, etc.--I usually leave Java and JavaScript disabled in my Browser. But this leads to another risk, namely missing something important that requires Java and/or JavaScript but where it isn't clear that they're required. A minor example: I was just looking at a Web site that boasted a link called "Privacy Statement". I clicked on it and nothing happened. I tried again; same result. I was about to give up, concluding that either they hadn't actually put a statement online yet or the server was having problems of some sort, when I noticed the status line of my browser showing the link as "javascript:mapOpen...". In experience, it is _very_ common for Web pages that depend on Java and/or JavaScript to give no indication of that, even when you try to use the dependent features. (If Java is disabled or not implemented, the browser won't recognize the tag, and will very likely display any text until . So informing the user of this situation is trivial. I don't know about JavaScript.) Don Byrd, Center for Intelligent Information Retrieval (CIIR), Computer Science Department, U. Mass, Amherst, MA 01003 1-413-545-3147 dbyrd@cs.umass.edu ------------------------------ Date: Mon, 25 May 1998 17:01:19 -0700 (PDT) From: smartcard@sprynet.com (Jerry Svigals) Subject: Who is watching the capacity and performance needs of Java solutions? For the past decade, the "conventional" microprocessor smart card had an 8 bit wide microprocessor and up to 64,000 bits of memory. The Sun Java language has been proposed as a write once, run in any smart card, application solution. it is intended to overcome the fact that most smart card vendors have an individual design and application architecture. to run the java application solution in any smart card requires the use of the java virtual machine (jvm). this is an interpretive program language which converts the java application description into the native language of the smart card being used. last december (1997), at the card tech meeting in san jose, a senior sun executive stated that performing the java application and the jvm requires more capacity and performance than available in the "conventional" microprocessor smart card. at the recent april 1998 card tech meeting, the sun executive changed his tune. it was possible to run a java application and jvm in a conventional smart card. when pressed for details he offered that the operating system and input/output portions of the application solution could be expressed in smart card native microprocessor language. use of the java application language and the jvm could then be processed in a conventional microprocessor smart card. what happen to the write one solution, run anywhere java goal. it has been quietly abandoned if you want the economics of the conventional 8 bit wide microprocessor smart card. the full solution is available by going to a higher performance, higher capacity microprocessor smart card. with the need to use a 16 bit or 32 bit wide microprocessor the cost of the smart card has increased by a factor of two or three times that of the conventional smart card. there appears to a quiet conspiracy not to disclose these facts. sun will not talk publically, unless pressed. big java fans like ibm carefully omit capacity and performance projections from their worldly pronouncements of java application and smart card architecture. the smart card vendors have mostly announced support for java - but they appear to omit performance and capacity details, even if pressed. there are serious consequences to these actions. the significant increase in smart card costs is of great assistance to those trying to delay smart card action programs. it postpones the point at which a business case may be made to proceed with smart card issue. it also forces the smart card vendors to come up with their individual native language components to support java applications. this is called an api. how long will it take to provide those components? to what specifications? what happened to the write-once, any smart card solution - at implied conventional smart card costs? Jerome Svigals Inc., 221 yarborough lane, redwood city, ca 94061 1-650 365 5920 fax 650 363 2198 smartcard@sprynet.com ------------------------------ Date: Wed, 27 May 1998 17:14:23 -0500 From: jorn@mcs.com (Jorn Barger) Subject: Referer-log security hole On 11 May, CNet reported a security hole with the "My Excite" web 'portal', where a subscriber's private ID (effectively their private password) may show up in the referer-log of the next site they visit. The article is at: ...and I doublechecked it today with "Pascal's Header Echo" at -- by pasting the Pascal URL into my Netscape Location Bar, Pascal *or anyone* will see much more in my headers than they ought: === I. Your Browser sent the following request to this server: GET / HTTP/1.0 Referer: http://my.excite.com/?uid=12345ABC654321A0 Connection: Keep-Alive User-Agent: Mozilla/4.03 (Macintosh; I; PPC, Nav) Host: echo.znet.de:8888 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8 === I've changed the "uid" to a random equivalent, but anyone who found it in their Referer-log would gain full access to my customized Excite data. I don't remember even seeing this discussed, but presumably it applies just as well if you've been browsing pornography, etc, or even looking at an HTML file in your local filesystem... it would happily deliver up the full path to that file. [Added note:] It gets worse and worse: Going to Altavista and querying "+my.excite.com.uid" turns up 200 pages, many with usable My Excite passwords. I EDIT THE NET: ------------------------------ Date: Thu, 4 Jun 1998 14:40:30 -0400 (EDT) From: David Wittenberg Subject: globe.com vs Advertising Age passwords: spam and security problem According to the New York Times 4 June electronic edition article "Marketing Mixup Raises Concerns About the Privacy of Passwords", 35000 subscribers to "Advertising Age" received unsolicited e-mail from theglobe.com. There are two concerns. The minor concern is that some of them felt spammed. The major issue is that the mail contained an invitation to a free e-mail account and provided a username/password pair. This pair was their username/password from "Advertising Age"'s web site. Some users worried that their passwords had been hacked. In fact theglobe.com was running a site for "Advertising Age", so in that sense the passwords weren't compromised directly, but why were the passwords stored in plaintext? There is also the risk of e-mailing passwords. David Wittenberg ------------------------------ Date: Wed, 03 Jun 1998 21:57:18 +0200 From: Steven Slatem Subject: Re: CzERT group of hackers ravage Czech & Slovak cyberspace (R 19 77) Herewith are the links, mistakenly omitted in the last RISKS posting, to the full story "CzERT lives on": http://www.intellitech-media.cz/public-access/nbisn/19980524-75x.htm Central & East European Hack Archive/CzERT Hack Archive: http://www.intellitech-media.cz/public-access/cee-hack-archive/czert-hack-ar chive The author (me) welcomes your comments, questions and opinions in regards to this story as well as the last posting to RISKS which contained points exclusive to that posting. - Steven Slatem, Editor-In-Chief, Networked Business & Information Security News (NBISN), IntelliTech Media, Inc. http://www.intellitech-media.cz [When including URLs in RISKS submissions, please remember to use only long-term URLs as in the case of these archival ones. TNX. PGN] ------------------------------ Date: 31 Mar 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 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 (Dennis Rears). .UK users should contact . => 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.comlogin anonymous[YourNetAddress]cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 18" for volume 18] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS ------------------------------ End of RISKS-FORUM Digest 19.78 ************************