RISKS-LIST: Risks-Forum Digest Friday 13 June 2003 Volume 22 : Issue 76 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://www.risks.org as http://catless.ncl.ac.uk/Risks/22.76.html The current issue can be found at http://www.csl.sri.com/users/risko/risks.txt Contents: Huge backlog, Seasonal slowdown beginning soon Challenge to 'challenge-response' users: Be Careful! (NewsScan) Phantom voting in Israeli Knesset (Ed Ravin) Student hacks school, erases class files (PGN) Canadian firearm registration system overwhelmed by traffic (swabsox via Declan McCullagh) Sea King Helicopter crash - fire control system deployment failure (Stuart Lynne) Computer glitch causes traffic lights malfunction (Teemu Leppänen) Risks of trusting CORRECT dive computers and tables (Daniel P.B. Smith) Electric utility direct-debit fiasco (Jonathan Kamens) Incremental insecurity (Paul Wexelblat) Re: ATM time sync (David Lesher) Re: University of Calgary to teach virus writing (Nicholas Weaver, Dan Bornstein) Denial of Service via Algorithmic Complexity Attacks: Crosby-Wallach (Monty Solomon) REVIEW: "Mission Critical Security Planner", Eric Greenberg (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 09 Jun 2003 10:01:34 -0700 From: "NewsScan" <newsscanat_private> Subject: Challenge to 'challenge-response' users: Be Careful! EarthLink has begun offering its 5 million subscribers "challenge and response" technology set up to send a "challenge" to any message from an unknown source, requiring that source to "respond" (and thereby supposedly proving it's from a human being rather than a spammer or pornographer). But many people who hate spam are saying the cure is worse than the illness; anti-spam consultant Steve Adkins warns, "It's sufficiently tempting that people will use it and will not realize all the bad things that will begin happening. Challenge-response is very, very unfriendly and rude to legitimate senders of e-mail." [AP/*Seattle Post-Intelligencer*, 9 Jun 2003; NewsScan Daily, 9 June 2003] http://seattlepi.nwsource.com/business/125638_spamtech06.html [Note: If you sign up for challenge-response, then say goodbye to NewsScan Daily. (The NewsScan editors)] [And say goodbye to RISKS also (unless you set up an alias address for RISKS issues that does not challenge. (We will never reveal it.) PGN] ------------------------------ Date: Wed, 4 Jun 2003 17:44:15 -0400 From: Ed Ravin <eravinat_private> Subject: Phantom voting in Israeli Knesset An investigation is going on in the Israeli Knesset (Parliament) on how votes are being cast on behalf of parliamentarians who are absent from their seats. It seems that electronic voting has problems even in a controlled environment like the floor of a parliament... Knesset probe fails to reveal who voted in Likud By Gidon Alon, Haaretz Correspondent A special committee set up by Knesset Speaker Reuven Rivlin, has failed to discover which MK was responsible for voting in place of Likud MK Inbal Gavrieli, who was not present in the Knesset plenum during a debate concerning the new budget plan, even though computer records indicate a vote was cast from her seat. Israel Radio reported several Likud MK's saying they had observed MK Yehiel Hazan (Likud) voting on Gavrieli's behalf. The vote was conducted electronically. The incident follows another case of double voting, in which MK Michael Gorlovski (Likud) admitted to having voted on behalf of another Likud MK, Gilad Erdan, also during the vote on the economic plan. http://www.haaretzdaily.com/hasen/pages/ShArt.jhtml ?itemNo=300587&contrassID=1&subContrassID=7&sbSubContrassID=0&listSrc=Y ------------------------------ Date: Thu, 12 Jun 2003 08:35:00 -0400 From: neumannat_private Subject: Student hacks school, erases class files A 17-year-old student in a networking course was arrested for breaking into his school's computers and erasing folders of other members of the junior class at Marion High School, near Rochester NY. He apparently was sniffing passwords with keylogging software. [The school's fix for this is to have students change their passwords every 60 days, and force them to use passwords with a ``combination of letters, numbers, and at least one special character''. Whoopee! That sure solves the problem! Sure stops the sniffer, which could be getting the new passwords as they are entered!!! PGN] http://www.cnn.com/2003/TECH/internet/06/10/school.hacked/index.html [One of our correspondents suggested that perhaps his charges will claim that his keylogging software is in the WMD category, and ask for a life sentence. PGN] ------------------------------ Date: Fri, 06 Jun 2003 09:43:26 -0400 From: Declan McCullagh <declanat_private> Subject: Canadian firearm registration system overwhelmed by traffic >Date: Fri, 6 Jun 2003 08:41:33 -0600 >From: swabsox <swabsoxat_private> >To: Declan McCullagh <declanat_private> >Subject: ITBusiness.ca > >Gun registry backfires after system exceeds capacity: > > The CFC's IT woes really aren't that different from any other government >department's, said Wendy Cukier, president of the Toronto-based Coalition for >Gun Control. She noted that government projects are frequently plagued by >things like budget and capacity issues, but the amount of vocal opposition to >the gun registry and made the CFC a flashpoint for controversy. > >"The system was built on the assumption that it would have something like >a 10% error rate and instead the error rate was 90 per cent. Some of that >was because of the complexity of forms and some of that was deliberate" said >Cukier, who's also a professor of information technology management at >Ryerson University. "You'd be hard-pressed to find another program that faced >such extensive efforts to undermine it." > >http://www.itbusiness.ca/index.asp?theaction=61&lid=1&sid=52538 ------------------------------ Date: Wed, 4 Jun 2003 21:24:27 -0700 From: Stuart Lynne <slat_private> Subject: Sea King Helicopter crash - fire control system deployment failure An article in today's *National Post* related that, when a Sea King helicopter crashed on the deck of a Canadian Forces Iroquis destroyer earlier this year, the first two fire control systems failed and only the third finally worked. The article does not say why the first system failed, but the second failed because of an obviously (well, perhaps in hindsight, obvious to RISKS readers) poor design of the operators console: An operator in the control room then pressed a button to active the second system. Nothing seemed to happen. He pushed the button again and again -- a total of six times -- but nothing happened. The operator "was not aware of the fact that as he repeatedly depressed the button to active the AFFF system, he was actually starting and stopping the system with every alternate push," a report from the subsequent technical investigation sayes. It also notes none of the indicator lamps on the system's console were working, so they did not light up when the button was pushed. And the crew may not have known about a 30-second delay from the the system is activated to the time the fire suppressant reaches the hose nozzle... 1. Poor design of a critical system. A toggle or second switch to disarm would have been a better choice perhaps. 2. Poor maintenance apparently leaving a critical system usable but not apparently so when the operator wanted results right now. 3. Poor training so that the operator did not know what to expect when activating the system. Kudos that they did have a third fire control system that apparently was deployed successfully. Stuart Lynne <slat_private> Belcarra, Embedded Linux USB Software 604-461-7532 ------------------------------ Date: Sat, 31 May 2003 11:25:24 +0300 (EEST) From: Teemu Leppänen <teemulepat_private> Subject: Computer glitch causes traffic lights malfunction In Oulu, Finland, computer glitch in central "traffic lights controlling" computer caused traffic jams in city centre at 9am friday morning. The computer transferred back to year 1991 and to night time (they did not specify exact date and time), meaning some of the traffic lights were in "night mode" and signaling "ignore me". Problem was solved in 90 minutes, but the original cause of the glitch remains yet unknown. Authorities say this was the first glitch ever experienced by the tax payers, also admitting there has been "minor" ones before. Seems that the police was not used to guide the traffic instead. No accidents were reported, hence no need to clear the way for the emergency medical teams.. perhaps with system which state is unknown, even requiring reboot, or having technicians trying to fix the issue at the same time. Original article (in Finnish) http://plus.kaleva.fi/html/JTpage321980.html ------------------------------ Date: Fri, 30 May 2003 23:15:39 -0400 From: "Daniel P.B. Smith" <dpbsmithat_private> Subject: Risks of trusting CORRECT dive computers and tables Craig S. Bell submitted a note about dive computers with an alleged software defect. Without minimizing the seriousness of the issue, or excusing the alleged behavior of the manufacturer, I think there is another RISK as well. The actual physiology and physical chemistry of decompression sickness isn't understood precisely. The models used to calculate dive tables and those used in dive computers are rough. http://www.theage.com.au/articles/2002/12/11/1039379882081.html cites a Dr. Gregory Emerson as saying, of decompression sickness, "We kind of know why it occurs but we still don't really understand why some people get it and other people don't." A manual I downloaded from http://www.uwatec.com says that "Aladin Pro Nitrox uses a new decompression calculation model known as the ZH-L8 ADT. This model uses eight compartments or 'tissue' groups with nominal half time periods from 5 to 640 minutes." In another place, however, they make the disclaimer "decompression modeling is an inexact science, and of necessity must be based at least partly on certain unproven assumptions." (I interpret this to mean that their "eight-compartment ZH-L8 ADT model" can be regarded as an educated guess). But even if the model were perfect, it would not be perfectly accurate unless there were a way to measure the size of an individual diver's tissue "compartments." The manual makes no reference to any way of matching the device to the body characteristics an individual diver. There is no way to enter percentage of body fat, for example, let alone the other seven tissues incorporated n the model. And nitrogen is soluble in fat. A person with more body fat will absorb more nitrogen while breathing compressed air at depth, and release more of it on ascent. Thus, if two divers follow identical dive plans, their computers will indicate the same results--but the diver with more fat will be at greater risk for decompression sickness. Uwatec's manual has a disclaimer for this, too: "each diver will vary in his or her susceptibility to decompression sickness. Not only that, but each individual diver's own susceptibility may vary from day to day." These disclaimers need to be taken seriously. A sufferer from decompression sickness http://www.photo.net/travel/diving/decompression-illness says he was told that "85% of people treated for decompression illness were diving within limits imposed by tables or a dive computer (i.e., most people struck by DCI are following the rules)." Dr. Emerson in the article cited above noted scuba divers can suffer from decompression sickness even if they religiously follow diving tables. A sample chapter from a 1997 book by Lawrence Martin, MD, http://www.mtsinai.org/pulmonary/books/scuba/sectiong.htm goes into considerable detail, but the bottom line is that "For a given individual, [decompression sickness] is unpredictable." How do divers behave? The article Bell cites about about the allegedly defective computers, http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2003/05/25/MN309974.DTL says that a pair of divers who "surfaced... then checked their computers to make sure another dive was safe. 'I look at Mitch's computer and look at mine,' said Iazdi in his throaty Portuguese accent. 'I say, "We're good."'" Dive computers have the intrinsic RISK of false precision. They do calculations with great precision that simulate sophisticated models and take care of dozens of details. Unfortunately, the correspondence between the models and reality is crude. Even without software flaws, divers are subject to the RISK of believing something must be true just because it's a "computer" that said so. ------------------------------ Date: Tue, 20 May 2003 20:58:09 -0400 From: Jonathan Kamens <jikat_private> Subject: Electric utility direct-debit fiasco Yet another direct-debit horror story.... Knowing that I was going to be out of town when my next electricity bill came due, and not wishing to worry about having enough money in my checking account to cover it while on vacation, I telephoned my electric company (NSTAR) and asked them to suspend direct debit until further notice. They agreed, and indeed, the electricity bill which arrived while I was on vacation said "please pay this bill" instead of "your account will be debited on <date>." Upon my return, I sent the electric company a check and then telephoned them and asked for direct debit to be resumed as of my next bill. I was assured that payment for the bill which arrived while I was on vacation would not be debited from my account. Two weeks later, when my next bill arrived, I discovered that the payment was, in fact, debited from my account. Thus I had paid twice for the same bill, and NSTAR was holding onto over $100 of my money to which they were not entitled. As luck would have it, I didn't bounce any checks because of this, but I could have done so easily. An additional wrinkle is that despite the fact that the total amount due on the new bill was less than the overpayment, the bill still claimed that they would be taking money from my checking account, apparently because when they received my overpayment, they applied all of it as an NSTAR credit and none of it to the supplier half of the bill (I use a third-party electricity supplier). I contacted the electric company by E-mail and asked them to return the money to me. First, they said that they could only refund the difference between the debit and how much I owed on the new bill, despite the fact that the amount on that bill was not actually due for two more weeks. When I responded that this was unacceptable, they agreed to refund the entire debit amount, but said that it would take two to three weeks for a check to be issued. I said that, too, was unacceptable -- they had no right to that money in the first place, and they should immediately either reverse the debit or issue me a check and send it via overnight delivery. They refused. I instructed them to immediately and permanently disable direct debit on my account. I also informed them that I would not be sending any money in response to the new bill, because I had a credit balance greater than the total amount owed, and it was up to them to ensure that the appropriate amount was transfered from that balance to the third-party supplier. They responded that this would happen correctly as a matter of course, i.e., that even though my bill told me to pay the third-party supplier balance, I didn't really need to do so. This is not the first time that the amount due given on my NSTAR bill was different from what they actually debited. There are many risks here, including: * It should be impossible for their billing system to debit an account to satisfy an unpaid balance after sending the customer a bill instructing him to pay the bill manually. Other utilities in my area get this right. If the bill they send you says "please pay," then you need to pay it, regardless of whether you activate direct debit between when you receive the bill and when it is due. * It should be impossible for their billing system to tell the customer that an amount will be debited automatically and then, with no prompting from the customer, debit a different amount or no amount at all. Putting it another way, the bill that gets sent to the customer should be correct (what a concept!). * The billing system should have safeguards in place to automatically detect double payments and bounce them to a human for handling (e.g., contacting the customer and/or sending a refund for the overpayment). * They should have procedures in place for reversing unauthorized debits promptly. The only things preventing them from doing this are bureaucracy and an inadequate billing system. It is unreasonable for them to allow these to get in the way of promptly returning money that they stole from customers. * The billing system should know how to reconcile credit balances with monies owed to third-party suppliers. ------------------------------ Date: Fri, 30 May 2003 20:04:43 -0400 From: Paul Wexelblat <geezerat_private> Subject: Incremental insecurity (Re: Cohen and Weiss, RISKS-22.75) RISKS-22.75 had a couple of entries that illustrate another RISK: * ISP resets password to an easily guessed one (Dawn Cohen) * Sensitive data on Web sites reflects lack of security awareness (Rick Weiss) They point out the insidious problem of secure systems spontaneously becoming insecure through no action of the user. This means that, no matter how safe and secure any service that has your info may be now, tomorrow they may change their system or be bought out -- as illustrated in the two cases above. What are the chances that either of these outfits will be either willing or able to remove the compromised data? ...and what are the odds that complaints of violation of privacy statements will be met with a claim that the "privacy statement" includes a term equivalent to "we reserve the right to make any change we want to to these terms at any time without notice"? ------------------------------ Date: Tue, 3 Jun 2003 10:01:40 -0400 (EDT) From: David Lesher <wb8fozat_private> Subject: Re: ATM time sync (RISKS-22.73) The arrest of the wrong party based on defective "money machine" timestamps has also occurred in the District of Columbia. From memory, there was brutal murder and the victim's card had been used after the time of death. The ATM camera's photo got wide play on TV and in the newspapers. The person pictured surrendered with his attorney AND the receipt from his girlfriend's card; he had used it with her permission. Despite that evidence and an alibi; he was still jailed for about a week before the US Attorney would relent. I would think there would be the potential for substantial civil litigation against the bank, the ATM network and the machine manufacturer in these cases. Judgments often have the effect of spurring correction of the design errors...(Another RISK, perhaps -- {system} validation by verdict?) ------------------------------ Date: Fri, 30 May 2003 17:44:47 -0700 From: Nicholas Weaver <nweaverat_private> Subject: Re: University of Calgary to teach virus writing (Brunnstein, R-22.75) I have to strongly second Klaus Brunnstein's comments in comp.risks concerning http://www.cpsc.ucalgary.ca/News/virus_course.html As a researcher who has analyzed existing worm strategies and developed novel strategies (warhol worms, metaserver worms) and plausible defenses, I find the notion of actual virus and worm writing as part of the educational and research process both abhorrent and of effectively NO value. For evaluating propagation behavior, simulation, "on-paper" evaluations, and analysis of previous worms can tell us effectively all we need to know: How worms and viruses spread, how they interact with many existing and possible defenses, and some requirements (such as automatic reactions) required to build robust defenses. Simulation predicted the possibility of very fast worms and many of the requirements for automated defenses. Paper analysis insures that I will never run KaZaA myself (the recent vulnerability could be used to take out all supernodes in probably less than <2 minutes). And analysis gives us a treasure-trove of what works well for malicious coders, such as how to cross firewalls and enter local Windows domains. There are some surprises which come up, such as Slammer/Sapphire's speed, but these are second-order effects. Sapphire was still a scanning worm, so automated defenses which could stop a 1 hour scanning worm should stop a Sapphire-esque worm. Likewise, there are numerous other techniques (Hitlisting & permutation scanning, topological, metaserver) which can create worms that spread to all vulnerable hosts in roughly the same timeframe. Likewise, to evaluate the defenses themselves, existing attacks can often been used as long as the defense hasn't been pre-trained. For worms which exploit security vulnerabilities, such as Code Red, these are no longer threats, as effectively all vulnerable machines have been patched and effectively all of the remaining machines are infected. And, if existing attacks, paper design, and simulation are all insufficient to evaluate a defense-mechanism, the best solution is to create daemon programs which run on test machines and who's behavior (eg, system calls, network communication) MIMICS the behavior of a worm when communicating with other copies of the program, as such program can not spread beyond the test machine. There is room for a good course on malicious code and defenses, but it need not, and should not, include construction of self-propagating programs (worms or viruses). I do not need to write worms to understand the problem, construct, and evaluate defenses. Nicholas C. Weaver nweaverat_private ------------------------------ Date: Fri, 30 May 2003 16:37:06 -0700 From: Dan Bornstein <danfuzzat_private> Subject: Re: University of Calgary to teach virus writing (Brunnstein, R-22.75) I'm willing to give the U of C the benefit of the doubt here. Many years ago I had a lot of fun writing programs for a game called Core Wars. The idea of the game (for those unfamiliar with it) was that your program and an opponent's program get loaded into a single "core" and the goal is for your program to subvert the other one such that the only threads of execution left are ones that your program initiated. This was (a) educational, (b) fun, and (c) arguably a helluva lot like virus-writing. I don't think writing code for Core Wars games is immoral, nor do I think it should be illegal; and I'd be hard pressed to tell you the difference between doing that and writing any other code for use in a controlled, quarantined computing environment, such as is proposed for the course. [When I was at Bell Labs in the early 1960s, there was a version of core wars that ran on the IBM 70x machines. Doug McIlroy, Vic Vyssotsky, and perhaps Bob Morris will certainly remember that one. PGN] ------------------------------ Date: Sat, 31 May 2003 10:22:56 -0400 From: Monty Solomon <montyat_private> Subject: Denial of Service via Algorithmic Complexity Attacks Denial of Service via Algorithmic Complexity Attacks Scott A. Crosby <scrosbyat_private> Dan S. Wallach <dwallachat_private> Department of Computer Science, Rice University We present a new class of low-bandwidth denial of service attacks that exploit algorithmic deficiencies in many common applications' data structures. Frequently used data structures have ``average-case'' expected running time that's far more efficient than the worst case. For example, both binary trees and hash tables can degenerate to linked lists with carefully chosen input. We show how an attacker can effectively compute such input, and we demonstrate attacks against the hash table implementations in two versions of Perl, the Squid web proxy, and the Bro intrusion detection system. Using bandwidth less than a typical dialup modem, we can bring a dedicated Bro server to its knees; after six minutes of carefully chosen packets, our Bro server was dropping as much as 71% of its traffic and consuming all of its CPU. We show how modern universal hashing techniques can yield performance comparable to commonplace hash functions while being provably secure against these attacks. http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003/index.html http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003.pdf ------------------------------ Date: Tue, 3 Jun 2003 12:00:58 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Mission Critical Security Planner", Eric Greenberg BKMSCRSP.RVW 20030330 "Mission Critical Security Planner", Eric Greenberg, 2003, 0-471-21165-6, U$35.00/C$54.95/UK#25.95 %A Eric Greenberg %C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8 %D 2003 %G 0-471-21165-6 %I John Wiley & Sons, Inc. %O U$35.00/C$54.95/UK#25.95 416-236-4433 fax: 416-236-4448 %O http://www.amazon.com/exec/obidos/ASIN/0471211656/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0471211656/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0471211656/robsladesin03-20 %P 416 p. %T "Mission Critical Security Planner" In the introduction, Greenberg claims that his book provides guidance on how to do quantitative security planning without calculations (which sounds somewhat self-contradictory) using a new technique he calls impact analysis (which doesn't sound too different from business impact analysis). A technical background is said to be unnecessary, the process is worksheet based, and the target audience is security managers. Chapter one says that protecting information is not exact (a statement that doesn't seem to fit well with the worksheet approach). Random security topics include planning, intruders, and a risk analysis example which is, ironically in view of the introduction, more computationally intensive than most. An overview of planning, in chapter two, majors on the minors. Policies are not discussed until twenty five pages into the material, and then the emphasis is on very specific areas like exit (termination of employment) procedures, leaving huge topics uncovered. Twenty eight security elements are listed, and all are important, but almost all are either over-vague or over-specific. Chapters three and four introduce the worksheets themselves. Sixteen topic areas have four sheets each, dealing with the technical, lifecycle, business, and "selling to management" aspects of the themes, while other domains may have only a single sheet. The questions listed may be helpful as reminders to address certain aspects which are often overlooked, but the odd and arbitrary structure is confusing, and the real work is definitely left as an exercise to the reader. A description and analysis of PKI (Public Key Infrastructure), in chapter five, is vague and weak, and contains much unrelated material. Chapter six is a recap of the book, along with a simple list of threats. While the advice in the book is not wrong or misleading, and many important and useful points are buried throughout, poor organization, a lack of consistent depth, and gaps in topical coverage ensure that the text would only poorly repay the investment of time spent studying it. Certainly it should not be used as a major guide to structure the security planning process. copyright Robert M. Slade, 2003 BKMSCRSP.RVW 20030330 rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: 30 May 2003 (LAST-MODIFIED) From: RISKS-requestat_private 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 e-mail requests to <risks-requestat_private> with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomoat_private . If Majordomo balks when you send your accept, please forward to risks. [If E-mail address differs from FROM: subscribe "other-address <x@y>" ; this requires PGN's intervention -- but hinders spamming subscriptions, etc.] Lower-case only in address may get around a confirmation match glitch. INFO [for unabridged version of RISKS information] There seems to be an occasional glitch in the confirmation process, in which case send mail to RISKS with a suitable SUBJECT and we'll do it manually. .UK users should contact <Lindsay.Marshallat_private>. => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => 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 risksat_private with meaningful SUBJECT: line. => ARCHIVES: http://www.sri.com/risks http://www.risks.org redirects you to the Lindsay Marshall's Newcastle archive http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., 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/ . http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/ ==> 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 22.76 ************************
This archive was generated by hypermail 2b30 : Fri Jun 13 2003 - 16:27:46 PDT