precedence: bulk Subject: RISKS DIGEST 19.22 RISKS-LIST: Risks-Forum Digest Thursday 12 June 1997 Volume 19 : Issue 22 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. **** ***** ANNUAL SUMMER SLOWDOWN BEGINS HERE Friday the 13th Jun at 13:13. ***** *********** Yes, I know, it's winter in AU, NZ, ZA, etc.) ****************** Contents: Washington D.C. air traffic slowed (PGN) Poorly designed train signal nearly causes crash (Martin Minow) Computer glitch slows trains (Jeremy Epstein) Cut cockpit wiring found on airliner (Matt Welsh) Company blackmails Netscape for details of browser bug (Jim Griffith) Censorship from half way around the world (Jeremy Freeman) Smith Barney customers become momentary millionaires (Jim Griffith) Texas Drivers in the Privacy Pothole (Lauren Weinstein) Largest Database Companies to Restrict Use of Personal Data (Edupage) Risks of being a spammer (Jim Griffith) Major corporation's misconfigured FTP server (John P. Wilson) 3001: Improving A Classic (Scot E. Wilcoxon) Geez Pleez Sloueez (Mark E. Ingram via Peter Ladkin) Re: When is 0 not 0? The wonderful world of the Web (Mathew Lodge, David Jones) IFIP WG 11.3 Working Conference - August 11-13, 1997 (David Spooner) CFP: 1998 Symposium on Network and Distributed System Security (Matt Bishop) CFP: The Impact of the Internet on Communications Policy (Nora O'Neil) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Thu, 12 Jun 1997 18:22:08 PDT From: "Peter G. Neumann" Subject: Washington D.C. air traffic slowed Air-traffic control around the eastern United States was seriously slowed down for nearly eight hours on 11 Jun 1997 because of a wiring error that occurred two months ago when new communications equipment was being installed. The main system at National Airport for communication with aircraft in flight broke down. Another aggravating episode occurred at Dulles International on the same day, when a man with a briefcase ran through a security checkpoint. 80 flights were delayed when police made 2,000 passengers go through metal detectors for a second time. That is a really nasty kind of denial-of-service attack, even if computer-unrelated. ------------------------------ Date: Wed, 11 Jun 1997 20:24:41 -0700 From: Martin Minow Subject: Poorly designed train signal nearly causes crash An article in the Swedish newspaper, *Svenska Dagbladet* (12 Jun 1997) describes a potentially-catastrophic train collision that was avoided by a train engineer with "good local knowledge." See with a graphic on (Note: these URL's are only valid 12 June, but the articles can be retrieved for a week by following "previous day" links.) [Translator's note: this is a very quick summary of a complex article. There are a few technical terms that I don't understand in the Swedish, and I apologize for any errors.] The main train line from the South and West of Sweden enters Stockholm on a bridge over Lake Malar that is, as I recall, at least 50 meters over the water. At the entrance, five tracks merge into the two tracks that cross the bridge. On a dark January night, a local train had previously stopped on a parallel track due to an engine failure. Another locomotive was then coupled onto that train to take it into the station. That train's engineer did not observe a lit "stop signal" before the switch leading onto the bridge, but was concentrating on the green "main signal" on the bridge itself. However, the "main signal" was lit for an oncoming express train proceeding from the South. Fortunately, the express train engineer "had good local knowledge" and realized, when he saw the local train moving, that it would merge onto his track. He warned the passengers and brought the train to an emergency stop without colliding with the local train. [The X2000 is the Swedish high-speed train, and can attain over 150 miles/hour. I would imagine that it was going at least 80 miles/hour (130 km/hr) at the time.] The incident report provides a critical assessment of the "stop signal" system, noting that rules for its placement and marking are unclear and incomplete, as well as noting that train engineers are not always knowledgeable about its function. The article's graphic notes that, while the "main signal" always shows either red (stop) or green (go), the "stop signal" is off for "go" and red for stop. Also, the "main signal" is replicated on the train engineer's console, while the "stop signal" is not replicated. From the article: "We have discovered a basic system [design] error. The track control system [this may be an incorrect translation of "regelverket"] has not been modernized and adapted to the newer technology. The people and the technology did not work well together." said Anders Lundstrom, the lead incident investigator. The investigators also noted that the "stop signal" is only used in a few heavily-trafficked parts of Sweden and is not lit in normal traffic, which results in engineers forgetting that it is there. Also, in other contexts, an unlit signal would be an error condition that means "stop." [The article also noted that, unlike "main signals," the "stop signal" is not replicated on the train's control console, making it easier to overlook.] The graphic gave me a clearer understanding of what happened. In case you want to attack it, here is a brief glossary: "rod" red "gron" green "hjaplok" assisting locomotive (pulling the local train). "X2000" express train "huvudsignal" main signal: shows either red or green, replicated in the train. "stopplykta" stop light. Shows red or nothing. Not replicated. Martin Minow minow@apple.com ------------------------------ Date: Fri, 06 Jun 1997 08:35:45 -0400 From: JEREMY EPSTEIN Subject: Computer glitch slows trains Trains on the Washington D.C. Metro system's Blue line are running 20-30 minutes behind schedule this morning, due to a "computer glitch". The computer that schedules the trains is malfunctioning, as is its backup. No word on whether the glitch is hardware or software, how often the backup computer is tested, etc. (Source: WAMU-FM) [Actually, this is becoming so common it may not even be RISKS-newsworthy any more. BART had several more bad days this week, with computer outages causing manual operation and the usual delays. PGN ------------------------------ Date: 12 Jun 1997 09:04:10 GMT From: mdw24@cl.cam.ac.uk (Matt Welsh) Subject: Cut cockpit wiring found on airliner AP via CNN's web site (www.cnn.com) reports on June 11, 1997 that "Cut wires were found underneath the cockpit of a Pan Am plane undergoing routine maintenance checks at Kennedy International Airport Wednesday, but the safety of the plane was not compromised, officials said." The remainder of the article is at http://www.cnn.com/US/9706/11/plane.wires.cut.ap/index.html (CNN Interactive URLs are almost always valid indefinitely) although as one expects from such a report there are little technical details and a lot of hot air from 'officials' trying to cool the situation down. M. Welsh, Vrije Universiteit Amsterdam. ------------------------------ Date: Thu, 12 Jun 1997 18:05:53 -0700 From: griffith@netcom.com (Jim Griffith) Subject: Company blackmails Netscape for details of browser bug In an article today, CNN reports that a Danish company has found a bug in Netscape's Communicator Suite which allows remote users to read any file stored on the hard drive of a PC web server. CNNfn reports that they and PC Magazine have verified the existence and nature of the bug. The Danish company in question, Cabocomm, stated that they will not release details of the bug until Netscape has fixed it, so I can't provide specifics. While this is nothing new, one aspect struck me as unusual. The Danish company further stated that Netscape's reward of $1000 and a t-shirt is "insultingly low" considering the severity of the bug. They have stated that they will provide Netscape with the specifics of the bug if and only if 1) Netscape provides "reasonable compensation", or 2) Netscape sends a representative to Denmark to collect the bug details. In other words, until Netscape pays up, they don't get their bug. http://cnnfn.com/digitaljam/9706/12/netscape_pkg Jim ------------------------------ Date: Thu, 12 Jun 1997 13:47:31 -0700 From: Jeremy Freeman Subject: Censorship from half way around the world Recently, I was checking out the latest news on Hotwired. I came across a story of how a controversial, previously unpublished report called the JET Report found its way on to the Internet. The report detailed how many child abuse cases that occurred in Britain's Nottinghamshire County some time ago were incorrectly identified as 'satanic child abuse'. For some reason the Nottinghamshire County Council did not want this report in the open, so they threatened the British reporter who posted the report to the Internet with court action. Not only did they threaten to sue him if he did not remove the report, they threatened to sue if he did not remove the Links to mirror sites of the report around the world. This bothered me. I believe that any information concerning the public should be made available for the public to read. Further, I despise the fact that they made the reporter take down Links to mirror sites. A link is not infringement of copyright. They used big government intimidation and scare tactics to force the burial of the report. So in protest, I mirrored the JET Report on my server and registered the page with the search engines. Not long after, I received an e-mail from Nottinghamshire County's barrister instructing me to remove the "JET Report" or face legal action on the grounds I was infringing on their copyright. Fearing a long drawn out case in British court, I removed the report and in its place put a hyperlink to another mirror site in the United States. About 5 hours later I received another e-mail explaining to me that a hyperlink to a mirror site was in-effect the same thing as putting the report on my page. The e-mail went on to say that if I did not remove the link, court action would commence without further notice. Now, my page that formerly contained the JET Report contains a detailed report of the events surrounding this incident, but not the report or any links to it. The RISKs are: Assuming one is immune from prosecution even though they reside in another country and that a judge will understand that providing a link to another site is not the same as hosting it. The site detailing these events is: http://www.jeremy.bc.ca/jetrep.htm Jeremy Freeman, Penticton, BC, Canada ------------------------------ Date: Thu, 5 Jun 1997 11:59:44 -0700 From: griffith@netcom.com (Jim Griffith) Subject: Smith Barney customers become momentary millionaires CNNfn reports that a computer glitch at Smith Barney caused half a million customer accounts to be credited with $19 million each for a brief period Wednesday night. Company representatives claim that customers did not have access to the money, and that the balances were only visible to Smith Barney brokers and any customers who happened to look at their account balances via the Internet during the brief period that the problem exists. The problem was reportedly quickly noticed and fixed. $19 million x 525,000 accounts = 9,975,000,000,000. That's $9.975 trillion, folks. Methinks someone misplaced the national debt by mistake... http://cnnfn.com/hotstories/bizbuzz/970605/smith_barney Jim ------------------------------ Date: Wed, 11 Jun 97 14:39 PDT From: lauren@vortex.com (Lauren Weinstein; PRIVACY Forum Moderator) Subject: Texas Drivers in the Privacy Pothole (PRIVACY Forum Digest V06 #08) PRIVACY Forum Digest Thursday, 12 June 1997 Volume 06 : Issue 08 Moderated by Lauren Weinstein (lauren@vortex.com) Vortex Technology, Woodland Hills, CA, U.S.A. From the PRIVACY Forum Five-Year Anniversary Issue [For the most recent issue, see http://www.vortex.com and click on "Current Edition of the PRIVACY Forum Digest".] In yet another example of "public record" data running amok, drivers in Texas will no doubt be pleased to learn that their names, addresses, birthdays, license plate numbers, and a variety of other data, is now publicly available on the Internet. And of course, broad searching capabilities based on a variety of criteria are included! No longer need the potential thief follow that luxury vehicle all the way back to a residence. No need for the sickie who harasses young women to follow his next lovely target all the way home. And that guy you accidentally cut off on the freeway? He may not have bothered you at the time, but he can come by to "visit" you later, perhaps in the middle of the night while you're sleeping. Use your imagination for more interesting scenarios. Yes, thanks to database lookups, all of these folks could apparently just copy down your license number, then look up the address and other info at their leisure. Now, that's progress! It's not clear who bears the most blame regarding the availability of this data: the state of Texas, for considering this information to be public record, or Public Link Corp. of Dallas (www.publiclink.com), for putting it on the net as a "public service" (with more to come, we're promised). While theoretically Public Link restricts access to this database to persons with a Texas driver's license (a license number is needed to establish an access "account"), procedures for reading the information directly via web URLs, bypassing the login procedures, have already been widely disseminated around the net, along with suggested "famous Texans" for lookup. And of course, account information for accessing the database via normal login is also circulating widely. When public record data just sat on index cards in the back room of the Hooterville courthouse, it represented a minimal threat to personal privacy. But as municipalities now try to convert their databases into profit centers, that same data is becoming one of the most potent threats to individual privacy, and in some cases personal safety as well. Lauren, Moderator, PRIVACY Forum ------------------------------ Date: Wed, 11 Jun 1997 09:15:14 -0400 (EDT) From: Edupage Editors Subject: Largest Database Companies to Restrict Use of Personal Data Eight of the largest database companies in the U.S., including the Lexis-Nexis on-line search service, have agreed to restrict the kinds of personal information they maintain about individuals, and to refrain from augmenting their own records with data from private marketing databases containing such information as individual's magazine subscriptions, shopping habits, and personal income. Privacy advocates have endorsed the agreement but have expressed concern that smaller database companies that did not sign on, and will continue to sell such marketing information; they also criticized the agreement for failing to provide an enforcement mechanism. (*Washington Post*, 10 Jun 1997; Edupage, 10 June 1997) ------------------------------ Date: Thu, 12 Jun 1997 17:50:11 -0700 From: griffith@netcom.com (Jim Griffith) Subject: Risks of being a spammer CNN reports that the Federal Trade Commission will crack down on spammers who advertise false claims or fraudulent offers. The FTC may fine such spammers, it may seek injunctions to bar spamming, or it may do both, depending on the offender. It is further asking industry groups for lists of known spammers, so as to better identify fraud cases. The FTC is specifically targeting two types of fraud: - Spammers who forge headers or otherwise provide false e-mail return addresses (yay!). - Spammers who make false claims or fraudulent offers. If CNN's wording is to be believed, the FTC's goal seem to be to reduce Internet traffic, rather than to prosecute fraud. The full text of the article is available at http://www.cnn.com/TECH/9706/12/junk.email.ap/index.html Jim ------------------------------ Date: Wed, 11 Jun 1997 20:14:12 -0400 (EDT) From: "John P. Wilson" Subject: Major corporation's misconfigured FTP server I set out to download some software from a major corporation's FTP server (name not given for reasons that will soon be obvious) and rather than go through the hassle of navigating through their complex web page, I fired up ftp. I assumed that the address for their ftp server was ftp.foo_corp.com, and connected as an anonymous user with no difficulty. After getting a directory listing, I noted the fact that there was about eight or so directories which looked suspiciously like usernames. A directory listing of one of these contained a .login, .cshrc, and a .rhosts file. In addition to the username directories, there was a directory labeled "research". Permissions were set so that I could have downloaded anything I liked. Risks? 1. There was probably a misconfigured DNS server which sent me to the computer I connected to rather then the actual FTP server; even if this was the correct server, there appears to have been a a fairly serious FTP configuration error and/or failure to change the FTP server from a default value. 2. Incorrect permissions were set on a directory obviously labelled "research". 3. I question the wisdom of placing any computer which contains company sensitive/proprietary information on a network which is connected to the outside world. 4. People could download saved e-mail from the user's accounts who were on this machine. These are the few that I came up with off the top of my head. The rest, "should be obvious". --John Wilson, sysadmin, Department of Education, Michigan Tech. ------------------------------ Subject: 3001: Improving A Classic Date: Sun, 8 Jun 1997 11:49:41 -0500 (CDT) From: sewilco@fieldday.mn.org In reading "3001: The Final Odyssey", I found that Clarke has used the current proximity to 2001 to update the background of "2001". There are a number of references to our society of the 1990s that had not existed when "2001" was written. Clarke gets a chance to make improvements in his thirty-year-old story, using our history to improve the history in his story. (The main story line is separate from these references, and this is not a review of the book) There also is a reference to the existence of many computing devices that are not able to deal with some date calculations. I'm not sure if Clarke is suggesting that computer programmers won't solve all date calculations even after the year 2000, or if Clarke is showing that not all date calculation problems have obvious solutions. Clarke has been noting problems with dates and researchers for a while. In 1975's "Imperial Earth" he included a speech given to the USA Congress three hundred years in the future, and reported that the speech has been added to the official Congressional Record with that future date. Scot E. Wilcoxon sewilco@fieldday.mn.org ------------------------------ Date: Fri, 06 Jun 1997 19:37:57 +0200 From: "Peter B. Ladkin" Subject: Geez Pleez Sloueez (Mark E. Ingram via Peter Ladkin) Have you ever had a nightmare in which you're flying into an airport in bad weather, and you see the purser open the cockpit door and hear her say to the captain, "Try Control-Alt-Delete"? Then you wake up, right? Well, read on. Glossary: GPS = Global Positioning System; ATC = Air Traffic Control; approach = a strictly defined and certified plan by which an aircraft approaches an airport runway and lands, even when the runway cannot be seen until the aircraft has almost landed; GPS approach = an approach based primarily on use of navigation signals from GPS. Peter Ladkin [begin message From: "Mark E. Ingram" , forwarded and mildly edited with permission. PBL] [The abstract for the report `A Human Factors Approach to Use of GPS Receivers', by Ruth M. Heron, Waldemar Krolak and Shawn Coyle, available from http://bluecoat.eurocontrol.fr/reports/ or http://www.neosoft.com/~sky/BLUECOAT says in part:] > Imagine you are about to pilot an aircraft on a GPS approach into a > busy airport surrounded by high mountains. You are being buffeted by > high winds, rain and turbulence. > > Then ATC calls for a different approach and you must re-program. Time > is of the essence, but somehow your receiver inputs are getting > scrambled and you can't figure out why. > > Finally, as you perform a critical keyboard entry to the GPS receiver, > all navigation capability is lost because the unit's operating system > crashes with the message, "Contact Factory, Contact Factory, Contact > Factory...." (This message was real, but the problem that invoked it > has long since been resolved.) [..] this problem *may* have been resolved, depending on the circumstances. It seems that the "Contact Factory" issue has only been solved *if* the unit has had its software updated during a visit to the factory. Since the manufacturer didn't issue a recall (that anybody seems to know about, anyway) and the FAA did not issue an AD, there are probably still a lot of boxes out there which haven't been fixed. Since the point of emphasizing this issue was *not* to embarrass or otherwise single out any one manufacturer, suffice it to say that if your GPS unit has a startup screen showing that its software is level 236 or lower (you know who you are), it can be prone to the "Address Error 02 Contact Factory" message. Solution - send it back to the factory. The upgrade is free. [end message from Mark Ingram] ------------------------------ Date: Fri, 06 Jun 1997 13:42:42 -0700 From: Mathew Lodge [...] Subject: Re: When is 0 not 0? The wonderful world of the Web (Turrall, R-19.21) > Netscape (and MSIE) insists however that 020 is actually equal to 16. This is actually a feature of Netscape's JavaScript parseInt() function. I originally considered that Netscape meant well when it implemented this behavior. Then I wondered why, in this day and age, anyone cares enough about input of octal numbers to code it into an integer parsing function of a relatively recent language such as JavaScript. I don't have source code to Netscape's JavaScript interpreter to check, but I expect that the implementation of parseInt() eventually ends up in some C code where something like the following takes place: int error, num; error = sscanf(line, "%i", &num); My copy of K&R "The C programming language (2nd Edition)" defines this to mean that an integer conversion of 'line' will take place; "the integer may be octal (leading 0) or hexadecimal (leading 0x or 0X)". Hence the same behavior in the I/O functions of a 90's programming language. I guess this is the old chestnut of a RISK that code will be used in a manner that the designers never envisaged. Or perhaps it is the risk of basing a new language (Java) on the less-than-solid foundations of an older one (C) ;-) The final irony is that the page in question, http://www.halifax.co.uk/mortgage/pay.html, contains JavaScript code to "validate" the user's input... Mathew Mathew Lodge, Product Manager, Cisco Systems +1 408 527 4908 ------------------------------ Date: Fri, 6 Jun 1997 08:13:04 -0400 (EDT) From: David Jones Subject: Re: When is 0 not 0? The wonderful world of the Web (Turrall, R-19.21) The real problem lies in the script that runs the mortgage calculator itself. Web browsers do not interpret any of the values typed into forms they display; all information is sent as-is, in encoded string form, to the server, where it is up to the CGI script to process it. It's highly likely that the mortgage CGI was written in Perl, or a C program that uses strtol(). This just goes to show how important it is to validate all input data, for both security and correctness reasons. ------------------------------ Date: Sun, 8 Jun 1997 11:17:34 -0400 (EDT) From: David Spooner Subject: IFIP WG 11.3 Working Conference - August 11-13, 1997 IFIP WG 11.3 Database Security 11th Working Conference on Database Security 11--13 August 1997, Lake Tahoe, California This conference provides a forum for presenting original unpublished research results, practical experiences, and innovative ideas in database security. The conference is limited to about forty participants so that ample time for discussion and interaction may occur. For more information on registration and updates on the advance program, see the IFIP WG 11.3 home page at web address http://www.cs.rpi.edu/ifip/. Registration information will be posted there in a few days. If you do not have web access, please contact David Spooner (spoonerd@cs.rpi.edu) for an e-mail version of the detailed information. ------------------------------ Date: Fri, 6 Jun 1997 15:05:45 -0700 From: bishop@cs.ucdavis.edu (Matt Bishop) Subject: CFP: 1998 Symposium on Network and Distributed System Security The Internet Society Symposium on Network and Distributed System Security, San Diego, California, March 1998 The symposium will foster information exchange between hardware and software developers of network and distributed system security services. The intended audience is those who are interested in the practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than theory. Encouraging and enabling the Internet community to apply, deploy, and advance the state of available security technology is the major focus of symposium. Symposium proceedings will be published by the Internet Society. Topics for the symposium include, but are not limited to, the following: GENERAL CHAIR: David Balenson, Trusted Information Systems PROGRAM CHAIRS: Matt Bishop, University of California at Davis Steve Kent, BBN Dates, final call for papers, advance program, and registration information will be available at the URL: http://www.isoc.org/conferences/ndss98. Matt Bishop, Department of Computer Science, University of California at Davis, Davis CA 95616-8562, sndss98-submissions@cs.ucdavis.edu Phone: +1 (916) 752-8060, FAX: +1 (916) 752-4767, The Internet Society, 12020 Sunrise Valley Drive, Suite 210 Reston, Virgina 20191-3429 USA voice 703.648.9888 fax 703.648.9887 ------------------------------ Date: Mon, 9 Jun 1997 17:06:05 -0400 From: Nora_O'Neil/FS/KSG@ksg.harvard.edu Subject: CFP: The Impact of the Internet on Communications Policy HARVARD INFORMATION INFRASTRUCTURE PROJECT THE IMPACT OF THE INTERNET ON COMMUNICATIONS POLICY First Announcement and Call for Papers Co-Sponsors: International Telecommunication Union and the Center for Law and Information Technology, Harvard Law School Cambridge, Massachusetts, December 4-5, 1997 Ms. Nora O'Neil, Project Coordinator, Information Infrastructure Project Harvard University, John F. Kennedy School of Government 79 John F. Kennedy St., Cambridge, Massachusetts 02138 USA Tel. +1 617-496-1389 Fax: +1 617-495-5776 nora_o'neil@harvard.edu ------------------------------ Date: 1 Apr 1997 (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. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, 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.22 ************************