RISKS Forum mailing list archives
Risks Digest 24.46
From: RISKS List Owner <risko () csl sri com>
Date: Sun, 5 Nov 2006 14:33:25 PST
RISKS-LIST: Risks-Forum Digest Sunday 5 November 2006 Volume 24 : Issue 46 ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <http://www.risks.org> as <http://catless.ncl.ac.uk/Risks/24.46.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: Recent RISKS hiatus (PGN) Widespread European power failure (PGN) Rail network faces unlimited fine over 16 safety breaches (Scott Peterson) VCR gets wrong time as DST ends (Steve Golson) Three of Australia's major railway routes are blocked (M. Hackett) Computer failure causing A320 PA not to work... (James Hughes) SSE delay and failures reported (Martyn Thomas) Regulating Search Engines? - Calif. Initiative For Internet Privacy (Lauren Weinstein) Several backlogged items from Lauren Weinstein (PGN) Electronic voting blamed for Quebec municipal election 'disaster' (Dan Hurley) Re: More on A380 delivery delays (David Smith) Re: A380 design software incompatibility costs 4.8 billion euros (Ed Prochak) REVIEW: "Writing Secure Code", Michael Howard/David LeBlanc (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Sun, 5 Nov 2006 11:12:24 PST From: "Peter G. Neumann" <neumann () csl sri com> Subject: Recent RISKS hiatus I always regret long gaps between RISKS issues. However, the past two weeks involved attending OOPSLA in Portland OR (with a widespread power failure that triggered evacuation of the entire Convention Center and surrounding area, apparently including stoppage of the light rail system) and the ACM CCS06 in Alexandria VA, along with staying in contact with various activities at work. In both conferences, hotel wireless systems were massively overloaded by the plethora of participants' laptops, with repeated network crashes and process vanishings that made Net access extremely challenging. Herewith is an attempt to catch up with the RISKS backlog. ------------------------------ Date: Sun, 5 Nov 2006 13:17:12 PST From: "Peter G. Neumann" <neumann () csl sri com> Subject: Widespread European power failure A high-voltage transmission line was shut down over a river to enable a presumably large ship to pass. This is preliminarily being attributed to a propagating outage that affected something like 10,000,000 people in Germany, France, Italy, Austria, Belgium and Spain. [Source: Danna Avsec, Power failure hits Europe, Associated Press, 05 Nov 2006; PGN-ed, TNX to Lauren Weinstein for noting this one.] http://www.wkyc.com/news/news_article.aspx?storyid=58868 Somewhat ironically, my keynote talk at the ACM CCS 06 included discussions on network-propagating outages in power and telephony, how they keep recurring despite efforts to avoid them, and how they might be prevented. ------------------------------ Date: Wed, 01 Nov 2006 08:20:36 -0800 From: Scott Peterson <scottp4 () mindspring com> Subject: Rail network faces unlimited fine over 16 safety breaches NETWORK RAIL faces an unlimited fine after admitting partial responsibility for one of Britain's worst rail disasters, The company, which owns and operates the entire rail infrastructure, admitted health and safety breaches relating to the accident in October 1999 at Ladbroke Grove. Thirty-one people died and 400 were injured when a high-speed intercity train crashed into a local service in West London during the morning rush hour. Network Rail Infrastructure admitted at least 16 infringements at Blackfriars Crown Court, in London. Relatives of three of the victims attended the 20-minute hearing. The charge referred to inadequate signal sighting distances and the obscuring of part of a signal. Other parts of the charge mean that the company has admitted that it failed to ensure the convening of a signal- sighting committee after equipment was installed in 1995, and also after six incidents when signals were passed when red between 1996 and 1998. In addition, it did not carry out "adequate risk assessments" or investigations following them. [Source: Nicola Woolcock, *The Times* (London), 1 Nov 2006] http://www.timesonline.co.uk/article/0,,200-2431601,00.html#cid=OTC-RSS&attr=Law ------------------------------ Date: Mon, 30 Oct 2006 09:51:36 -0500 From: Steve Golson <sgolson () trilobyte com> Subject: VCR gets wrong time as DST ends My Samsung VCR automatically sets its clock using XDS time signals which are broadcast in my area by WGBH, our local PBS station. The VCR clock has correctly followed DST on and off for years. Yesterday morning after Daylight Savings Time ended, the clock was "automatically" set to the wrong time, and it read two hours early. Turning the VCR on and off had no effect. This morning the clock was still wrong. I unplugged the VCR, and when I plugged it back in it displayed "Auto" as it searched the channels for the XDS time signals. Eureka! we have the correct time today. See also RISKS-17.73, 20.83, 20.95. Other DST mixups: my new Day-Timer diary for 2007 gives the wrong DST start/stop dates. Steve Golson / Trilobyte Systems / +1.978.369.9669 / sgolson () trilobyte com Consulting in: Verilog, Synopsys, patent analysis, reverse engineering ------------------------------ Date: Fri, 3 Nov 2006 16:03:30 -0800 From: "M. Hackett" <dist23 () juno com> Subject: Three of Australia's major railway routes are blocked I am amazed at the number of Australia's single-track rail lines. In the bigger scheme of rail transport in Australia, important lines should all be double-tracked. It is one thing for NZ to have so many single-track rail lines, as NZ geography can be unduly harsh for the railroad builder. Canada has this problem to a lesser extent -- as the US rail infrastructure can always be used to route around any multiple trans-Canada rail snafu. Canada's rail choke points need to be eliminated, but the central government has not coordinated this yet. Probably some 30,000 kms of heavily used rail need to be replaced in the next decade in Canada -- but I don't see Ottawa trying to fix this problem either. See also http://en.wikipedia.org/wiki/Centralized_traffic_control http://en.wikipedia.org/wiki/Railway_signal http://en.wikipedia.org/wiki/Railway_signaling A huge North American rail safety issue: Dark Track -- tracks without any safety signaling. Canada still has some [due to an incomplete Australian like routing centralization], but the US has literally 'several million KMS' of Dark Track. On a joules/gram basis -- rail is still in many ways more energy efficient than road transport. The irony here is that [ideally] coal-steam engines are at best 10% thermodynamically efficient. Desil-electric trains manage to only stay in the [still dismal] 30% range thermodynamically. Max Power, CEO http://HireMe.geek.nz/ *Derailments cause rail chaos* Three of Australia's major railway routes are blocked this morning because of derailments. The Sydney to Melbourne railway line is blocked between Junee and Cootamundra in southern New South Wales after a collision between a truck and a freight train last night. Wagga Wagga police say the truck driver was free of the rig before the train hit and no one was injured. The Olympic Highway is closed near the site and the railway line is expected to be blocked until midday. In outback South Australia seven derailed freight wagons have been blocking the track near Tarcoola since Wednesday. The line is an important route between the east coast and Perth, and Adelaide and the Northern Territory. Today's Ghan service from Adelaide to Alice Springs has been canceled and freight deliveries have been delayed indefinitely. Yesterday, three rail services were cancelled, leaving hundreds of travelers stranded in Perth, Alice Springs and Adelaide. Rail traffic in all directions has been delayed. The Australian Rail Track Corporation expects to clear the line by Sunday. For more news visit ABC News Online at http://www.abc.net.au/news Catch up with the latest arts and entertainment news in the ABC News Online blogs Articulate http://www.abc.net.au/news/arts/articulate/ and The Shallow End http://www.abc.net.au/news/arts/theshallowend/. ------------------------------ Date: Sat, 21 Oct 2006 13:17:53 -0700 From: james hughes <James.Hughes () Sun COM> Subject: Computer failure causing A320 PA not to work... [Video] I was on UA 914 from SFO to IAD on October 16th 2006 occupying seat 1B. This is an A320 with a plaque that reads it is the 500th airbus built, with the names of the people that accepted the plane from Airbus to United. At FL39 approaching Denver, the weirdest thing happened. It was like a 'B' horror movie. All of a sudden all the lights in the cabin, including things like seat belt lights, smoking light, call buttons etc. started randomly flashing. The audio system went bonkers also changing channels, alternating static and music, etc... The attached video was taken with my palm cell phone. While this is looking forward, it was even weirder in the back with all the flashing lights. In the video you can see the lights flashing and the flight attendant trying to get into the cockpit. The PA system flight attendant to cabin and cockpit to cabin did not work. I suspect communications to the cockpit was a problem to judging on how the flight attendant was constantly "ringing the bell" to get the flight crew to open the door... This went on for 10 minutes. The plane did not descent, turn or otherwise, and even though Channel 9 was not coming through clearly, the chatter on the radio was normal. After it was over, the pilot said later that he was trying to turn off the evacuation alarm(!) which he said was unbelievably loud and sounding in the cockpit (although I did not hear it). He explained that he had never heard this in flight before (good thing) and this was something that they heard in training. During that 10 minutes he had been in contact with the UA maintenance people. The explanation was that the passenger control system had failed. He said it was the system that controls the "creature comforts" in the back of the airplane including the lights and toilets (and a bit more I might add! I am a little surprised that the PA, and crew to cockpit communications can be so easily trashed.) The pilot claimed to have been flying the A320 for 8 years and was taken totally off guard by this. My kudos to the crew for taking care of this. False alarms are at least distracting, which can contribute to larger issues. At the end the video, unbelievably, a passenger just had to get up and go to the bathroom really bad. I told him to sit back down, but after the end of the video he went anyway, right in the middle of this mess. [Video omitted here. Contact Jim to view it. PGN] ------------------------------ Date: Wed, 25 Oct 2006 10:15:04 +0100 From: "Martyn Thomas" <martyn () thomas-associates co uk> Subject: SSE delay and failures reported CRESTCo is the Central Securities Depository for the UK market and Irish equities, and operates the CREST system, which provides settlement facilities for a wide range of corporate and government securities, including those traded on the London and Irish Stock Exchanges.. CREST also settles money market instruments and funds, plus a variety of international securities. In September 2002, Crestco merged with Euroclear, which provides similar services in other European countries. The merged group decided to develop a single settlement engine (SSE) to unify their technology. Financial News Online reported on October 16th that "Euroclear was due to deliver the first phase last year but it did not go live until May". After the UK Crest system was integrated with the SSE in August, "the platform has suffered from blocked messages, systems instability and slow settlement". The problems have apparently led to a delay in the launch of a system for the Government bonds market that was due on October 23rd. The October Newsletter from Crestco (available online at http://www.crestco.co.uk/news/newsletters/newsletter-oct2006.pdf) describes the problems in some detail. "On Tuesday, 29 August 2006, a small communications issue between CREST and the SSE late in the afternoon generated a substantial number of error messages. This blocked communication between the systems and effectively halted settlement for a period of time. Although settlement was re-started shortly after 17:00, the result of the delay was that UK banking deadlines were pushed back to around 19:15, with major banks only able to close their systems and process client accounts after 20:00. Additionally, although GBP collateral management processing was fully completed, EUR and USD collateral management (delivery by value (DBV)) events were not run. The issue was caused by a configuration error that was magnified on 29 August 2006 as a result of that date being the record date for coupon payments on a very large number of gilts." Other reported errors include: "Errors in the automatic splitting processing resulted in securities positions not being split and settled efficiently, leading to clients intervening to assess and manage their securities positions interactively. Unfortunately, the manual splitting process has been running much slower than it should, due to software locking and contention issues similar to those affecting DBV processing. The errors relating to automatic splitting were not identified in testing. However, it is also the case that the erratic problem of settling splits in the wrong order has been difficult to replicate in test scenarios, although CRESTCo understands why it happens. The locking problems that impacted manual splitting were not spotted in performance testing and, even if present, did not negatively impact overall settlement rates, which are higher than in CREST production. Software changes for the automatic splitting issue are now in place. CRESTCo is also working to improve the performance of the manual splitting process. As with the issue affecting DBVs, this primarily involves tuning and balancing the system carefully, a process that was underway at the time of launch but requires further refinement in the live environment." I recommend reading the newsletter, which gives an unusually frank description of a private-sector project that has had significant problems. ------------------------------ Date: Wed, 4 Oct 2006 13:01:47 -0700 From: Lauren Weinstein <lauren () vortex com> Subject: Regulating Search Engines? - Calif. Initiative For Internet Privacy Greetings. CIFIP - California Initiative For Internet Privacy (http://www.cifip.org ) -- is a public effort launched in October 2006 to explore the desirability and possible implementation of voluntary and/or mandated approaches toward improving a range of Internet-related privacy issues. The possibility of legislative actions, including particularly the potential placing of a voter initiative on the 2008 California ballot dealing with search engine data retention and privacy, are important initial facets of this project. CIFIP has been founded by Internet veteran Lauren Weinstein, who is based in Los Angeles. Major Internet search services based in California such as Google and Yahoo! (AltaVista), plus other similar firms with substantial physical facilities located within the state, are routinely collecting vast amounts of data from those persons who conduct searches or perform other operations on these companies' systems. This data frequently includes the details of the searches (that is, the search keywords themselves), connection-related data that can be used in most cases to identify the source of those searches, and other information potentially subject to both internal or external abuse. Much of this data is intensely personal in nature. Our search requests cover a vast range of topics, including medical and other sensitive queries, business and other research, and for most of us a whole host of searches relating to our personal information, interests, desires, dreams, fantasies, and even fears, among other topics. The outrage over AOL's recent publishing of a vast cache of users' search data served to demonstrate the sensitivity of this data in dramatic fashion ... For more information, including announcement and public discussion lists, etc., please see: http://www.cifip.org Thank you for your consideration. Lauren Weinstein <lauren () vortex com> Tel: +1 (818) 225-2800 http://www.pfir.org/lauren Co-Founder, PFIR People For Internet Responsibility - http://www.pfir.org Co-Founder, IOIC International Open Internet Coalition - http://www.ioic.net Moderator, PRIVACY Forum - http://www.vortex.com Lauren's Blog: http://lauren.vortex.com DayThink: http://daythink.vortex.com ------------------------------ Date: Sat, 4 Nov 2006 15:54:52 PST From: "Peter G. Neumann" <neumann () csl sri com> Subject: Several backlogged items from Lauren Weinstein Several additional earlier items from Lauren Weinstein have accumulated during the recent hiatus. To catch up with the backlog, it seems appropriate to steer you to the original documents rather than include them here, especially if there is already subsequent discussion on Lauren's site. Microsoft Plans For Automatic Hobbling of "Pirated" Vista Systems http://lauren.vortex.com/archive/000194.html Google and Monopolies http://lauren.vortex.com/archive/000195.html Click Fraud, Google, and Telepathy http://lauren.vortex.com/archive/000196.html ------------------------------ Date: Wed, 25 Oct 2006 10:39:06 -0700 From: "Dan.Hurley" <Dan.Hurley () gov yk ca> Subject: Electronic voting blamed for Quebec municipal election 'disaster' http://www.cbc.ca/canada/montreal/story/2006/10/25/voting-results.html?ref=rss ------------------------------ Date: Fri, 20 Oct 2006 09:55:17 +0100 From: "David Smith" <d.smith () fnc co uk> Subject: Re: More on A380 delivery delays (Ladkin, RISKS-24.45) So isn't the real culprit the developer of CATIA who decided to change the file format? If this a Microsoft product wouldn't we all be blaming Bill Gates? This reminded me of a problem many years ago with the Alsys Ada Compiler. The company that I worked for used V4 of the Motorola 680x0 compiler on Sun 3/60's, 3/80's etc. Everything was fine until Alsys "upgraded" the compiler to V5. Suddenly the applications that were being developed would no longer work. After much investigation it was found that Alsys had decided that V5 would use the first page of memory for it's own purposes when the compiled/linked code was executed. We had been using the first page as a vector table. (Well, that is how I remember it, it was a while ago) The only solution was to move from Sun/3 hosts to Sun SPARCstation hosts, but as the target was 68040 based and, I think, the V5 compiler had not been validated for such cross development, this was not an option. This was very nearly the deathknell of one particular product, an Integrated Health & Usage Monitoring System (I-HUMS). Whose fault was it? - Alsys for changing the way the compiler compiled? - Us for using a particular memory architecture? - Sun for developing the SPARC processor? David H Smith, Frazer-Nash Consultancy Limited, Stonebridge House, Dorking Business Park Dorking, Surrey RH4 1HJ UK Tel: +44 (0) 1306 885050 ------------------------------ Date: Sat, 21 Oct 2006 16:14:22 -0400 From: "Ed Prochak" <edprochak () gmail com> Subject: Re: A380 design software incompatibility costs 4.8 billion euros Date: Wed, 4 Oct 2006 09:46:48 +1000 From: "mike martin" <mke.martn () gmail com> Subject: A380 design software incompatibility costs 4.8 billion euros Bloomberg has reported that the wiring problems that have delayed A380 deliveries yet again are related to incompatibility between versions of CAD software being used: http://bloomberg.com/apps/news?pid=20601109&sid=aSGkIYVa9IZk&refer=ex...<http://bloomberg.com/apps/news?pid=20601109&sid=aSGkIYVa9IZk&refer=exclusive> ... engineers in Germany and Spain stuck with an earlier version of Paris-based Dassault Systemes SA's Catia design software, even though the French and British offices had upgraded to Catia 5. That meant the German teams couldn't add their design changes for the electrical wiring back into the common three- dimensional digital mock-up being produced in Toulouse, [Charles] Champion [former head of the A380 program] says. Efforts to fiddle with the software to make it compatible failed, meaning that changes to the designs in the two offices couldn't be managed and integrated in real time, he says. ``The situation worsened when construction and tests of the first A380s generated demands for structural changes that would affect the wiring. The changes in configuration had to be made manually because the software tools couldn't talk to each other.'' Catia file formats changed between version 4 and version 5. An initiative has now begun to standardise software tools across the program. <end quote> This incompatibility seems an excuse to me. Surely the French division when upgrading from version 4 to version 5 of the CAD software had available conversion software. Given that such software exists, why did they not use it to integrate the German changes into the central design? It would not have been "realtime", but it would have shown the incompatibility quickly. Ed Prochak, Magic Interface, Ltd. ------------------------------ Date: Fri, 27 Oct 2006 08:50:21 -0800 From: Rob Slade <rMslade () shaw ca> Subject: REVIEW: "Writing Secure Code", Michael Howard/David LeBlanc BKWRSCCD.RVW 20060910 "Writing Secure Code", Michael Howard/David LeBlanc, 2002, 0-7356-1588-8, U$39.99/C$57.99 %A Michael Howard %A David LeBlanc %C 1 Microsoft Way, Redmond, WA 98052-6399 %D 2002 %G 0-7356-1588-8 %I Microsoft Press %O U$39.99/C$57.99 800-MSPRESS fax: 206-936-7329 %O http://www.amazon.com/exec/obidos/ASIN/0735615888/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0735615888/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0735615888/robsladesin03-20 %O Audience a Tech 2 Writing 1 (see revfaq.htm for explanation) %P 477 p. + CD-ROM %T "Writing Secure Code" The introduction states that the purpose of the book is to teach application designers (and particularly .NET developers) to design, write, and test application code in a secure manner. Part one addresses the contemporary security situation. Chapter one reviews the need for secure systems. The text is so supplemented by notes, comments, text boxes, and sidebars that it becomes difficult to follow at times. However, ultimately it does have a lot of interesting material that would be useful for those who have to make a case for secure coding practices and processes. Designing secure systems, in chapter two, provides a solid list of secure strategy principles along with details and discussion of them, although much of this deliberation is restricted to "war stories" which are interesting but not always useful. The content makes the point that the mere addition of security technologies does not always make for secure applications, which point is not supported by the inclusion, in the latter part of the material, of a huge list of security technologies. Part two turns to secure coding techniques. Chapter three details that old standard and nemesis, the buffer overflow. Unfortunately, most of what is provided is limited to code demonstrating that various types of buffer overflows exist, and some contentions in regard to specific C language instructions that should not be used. Code for access control list use on Windows NT4 and 2000 is reviewed in chapter four. Code, but not design, for running with least privilege occupies chapter five. Chapter six is again concerned primarily with source code for cryptographic operations, although limited to pseudorandom number generation (paying insufficient attention to seed values), key management, and miscellaneous topics. Further functions involved with encrypting confidential information are in chapter seven. Chapter eight turns to canonical representation, although the discussion is narrowly confined to filenames and issues of traversal. Part three concentrates on network-based application considerations even though network connectivity and access has been given as the reason to pay attention to secure coding in the first place. Chapter nine looks at the possibility of port hijacking, and the design of applications in order to work cooperatively with firewalls. Securing the use of RPC (Remote Procedure Calls), ActiveX, and DCOM (Distributed Common Object Model) is covered well in chapter ten, with concepts as well as code and good explanations (although I know for a fact that accessing dcomcnfg on XP is *not* as easy as the authors want to make out). Chapter eleven lists some denial of service (DoS) attacks and generally suggests limiting the resources available to applications. Most of the advice on securing Web-based services, in chapter twelve, boils down to advice not to trust the client, and various examples of malformed input are described. Part four contains special topics. Chapter thirteen details .NET functions and operations related to security, but also provides valuable guidance in regard to appropriate (and inappropriate) use. Testing of secure applications gets a review of standard procedures, in chapter fourteen, but the material does not provide an abstract overview of assessment concepts that could be used to find all possibilities of weakness. Installation procedures, in chapter fifteen, could have been useful, but is probably the most Windows specific and least practical section of the entire work. Chapter sixteen is a bit of a grab bag, but contains worthwhile tips and principles to follow (mostly in order to avoid common security pitfalls). Appendices are usually extraneous material, sometimes added merely to pad out the page count of a book. However, the essays included at the end of this volume could be quite helpful. There are the ten immutable laws of security and the ten immutable laws of security administration, which have become famous in their own right, and have spread through the Internet, as well as a list of dumb excuses given for not doing security properly. Overall, the book contains much that can be of use for those who wish to develop code that is secure and resistant against bugs and flaws that may open the application to attack. However, there is also a good deal that is irrelevant and not helpful, and a number of issues that could have useful have not been included (such as development methodologies, design strategies, and testing issues). copyright Robert M. Slade, 2006 BKWRSCCD.RVW 20060910 rslade () vcn bc ca slade () victoria tc ca rslade () computercrime org http://victoria.tc.ca/techrev/rms.htm ------------------------------ Date: 2 Oct 2005 (LAST-MODIFIED) From: RISKS-request () csl sri com Subject: Abridged info on RISKS (comp.risks) The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. The mailman web interface can be used directly to subscribe and unsubscribe: http://lists.csl.sri.com/mailman/listinfo/risks Alternatively, to subscribe or unsubscribe via e-mail to mailman your FROM: address, send a message to risks-request () csl sri com containing only the one-word text subscribe or unsubscribe. You may also specify a different receiving address: subscribe address= ... . You may short-circuit that process by sending directly to either risks-subscribe () csl sri com or risks-unsubscribe () csl sri com depending on which action is to be taken. Subscription and unsubscription requests require that you reply to a confirmation message sent to the subscribing mail address. Instructions are included in the confirmation message. Each issue of RISKS that you receive contains information on how to post, unsubscribe, etc. => The complete INFO file (submissions, default disclaimers, archive sites, copyright policy, etc.) is online. <http://www.CSL.sri.com/risksinfo.html> The full info file may appear now and then in RISKS issues. *** Contributors are assumed to have read the full info file for guidelines. => .UK users should contact <Lindsay.Marshall () newcastle ac uk>. => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => SUBMISSIONS: to risks () CSL sri com with meaningful SUBJECT: line. *** NOTE: Including the string "notsp" at the beginning or end of the subject *** line will be very helpful in separating real contributions from spam. *** This attention-string may change, so watch this space now and then. => ARCHIVES: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i] <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue. Lindsay has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r <http://the.wiretapped.net/security/info/textfiles/risks-digest/> . ==> PGN's comprehensive historical Illustrative Risks summary of one liners: <http://www.csl.sri.com/illustrative.html> for browsing, <http://www.csl.sri.com/illustrative.pdf> or .ps for printing ------------------------------ End of RISKS-FORUM Digest 24.46 ************************
Current thread:
- Risks Digest 24.46 RISKS List Owner (Nov 05)