RISKS-LIST: Risks-Forum Digest Monday 5 November 2001 Volume 21 : Issue 73 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 <URL:http://catless.ncl.ac.uk/Risks/21.73.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: FAA Asleep at the Control Column? (Bill Duncan) Jilted boyfriend hacked into ex-girlfriend's Internet bank account (PGN) Kids' learning game site becomes porn site (PGN) Anonymous e-mailer convicted of cyberstalking (Declan McCullagh) Sony uses DMCA against Aibo Enthusiast's Site (Monty Solomon) RU-Blue? or RU-Yellow? (PGN) DeCSS is Speech (James S. Tyre via David Farber) Risks of concentrated power and the surveillance state (Peter Wayner) Risk of monoculture and exponential false AV positives (Devon McCormick) Fake ID anyone? (Tim Rushing) Bank assets disappear, convert customers into Euro-peons (Paul van Dijken) DoS attack on Mac OS9 (Erann Gat) Conference management software reveals "hidden" authors (Michael Ortega-Binderberger) Insecure promo from American Express (Cameron Simpson) Re: ACT Election Electronic Voting (Henry Grebler) Re: TD Bank Canada system crash (Przemek Skoskiewicz) Re: Stray bomb caused by typo (James R. Cottrell Jr.) Re: Int. Conf. on COTS-based Software Systems (Kearton Rees) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Sun, 4 Nov 2001 17:15:16 -0500 (EST) From: Bill Duncan <bduncanat_private> Subject: FAA Asleep at the Control Column? A few days ago while looking through the e-mail rejection logs, I was surprised to find some e-mail blocked by virtue of being in an RBL list and coming from a host in the FAA.GOV domain. The e-mail was obvious spam, as I'd blocked the same sender (from a domain in the UK) from various other addresses. Being a new private pilot and with the recent of September events fresh in my mind, I quickly investigated. Sure enough, there was a host on their network, loaded with software from that outfit in Redmond, and happily spewing relayed mail. (I tested whether it would relay mail from anywhere to anywhere else by telneting to its smtp port.) Furthermore, to get on this exclusive RBL list, the e-mail relay must've been in operation for some time. Imagining scenarios where relaying e-mail through the FAA system might at best be an embarrassment, and at worst might be some kind of a security threat, I immediately e-mailed whatever addresses I could find on their website as well as the usual postmasterat_private etc. So far, no response, and according to my log files, I'm still rejecting spam from them. While many US Federal Government agencies are discovering the virtues of Open Source for security, I'm dismayed to find that the FAA is still using software well known for insecurities on their website as well as other hosts connected to the Internet. Getting junk e-mail relayed through the FAA might be just an annoyance, but it might also point to other security issues there. So if you get any e-mail from the FAA, be careful. It's probably just SPAM, but it might be worse. Follow-up: Mon, 5 Nov 2001 15:41:11 -0500 (EST) I didn't want to include the identifying IP address in the original submission, to protect the guilty, but it looks like they took it off this morning. I tried pinging the address and they are no longer there. The last SPAM which was sent my way from that address was at 1:15 this morning EST. Although I e-mailed about 4 addresses at the FAA, including one for emergency response, I've received no replies as yet. But I guess the message finally got through this morning. Maybe they'll take it as a wakeup call, which I didn't think they'd really need after the recent events... Here's the last log entry from my mail log, with the local address changed. I'm using Exim. 2001-11-05 01:15:18 recipients from atos.faa.gov [204.108.10.130] refused 2001-11-05 01:15:18 recipient <localnameat_private> refused from atos.faa.gov [204.108.10.130] sender=<masterdisc8745at_private> (host_reject_recipients) Bill Duncan, VE3IED http://www.beachnet.org bduncanat_private +1 416 693-5960 ------------------------------ Date: Wed, 31 Oct 2001 9:37:30 PST From: "Peter G. Neumann" <neumannat_private> Subject: Jilted boyfriend hacked into ex-girlfriend's Internet bank account After their relationship ended, Cheug Wing-hang took 420 pounds (HK?) from his girlfriend's HSBC Internet bank account. He was convicted on four counts of theft and five counts of dishonest computer access. The *South China Morning Post* reported he will be sentenced on 13 Nov 2001. [http://www.ananova.com/news/story/sm_431974.html] [Despite the lack of specificity on what kind of pounds were involved, we can assume that his girlfriend did not weigh more than 500 pounds.] ------------------------------ Date: Wed, 31 Oct 2001 10:10:48 PST From: "Peter G. Neumann" <neumannat_private> Subject: Kids' learning game site becomes porn site The Web sites at moneyopolis.org and moneyopolis.com once housed an online interactive children's game created by Ernst & Young to help youngsters in grades 6 to 8 learn about finances. Recently, E&Y gave up the .org domain, which has now become Euro Teen Sluts (TM), registered in Yerevan, Armenia. Old bookmarks beware. [Source: The Washington Post, 25 Oct 2001; PGN-ed] [I presume that this issue of RISKS will succumb to some filtering because of its mentioning the name of the new owner of the domain.] ------------------------------ Date: Wed, 31 Oct 2001 08:39:46 -0800 (PST) From: Declan McCullagh <declanat_private> Subject: Anonymous e-mailer convicted of cyberstalking A California man who used a public library computer terminal to send anonymous e-mail threats to a Michigan man has been convicted by a jury of cyberstalking. The prosecution used circumstantial evidence to prove its case, since no logs of the e-mails or computer users were kept by the library. http://www.siliconvalley.com/docs/news/depth/stalk103101.htm ------------------------------ Date: Thu, 1 Nov 2001 20:39:12 -0500 From: Monty Solomon <montyat_private> Subject: Sony uses DMCA against Aibo Enthusiast's Site Sony Dogs Aibo Enthusiast's Site Courts: The company uses a controversial law to stop owners from altering the robotic pet. Some consumers balk. Sony Corp. is using a controversial U.S. law aimed at protecting intellectual property to pull the plug on a Web site that helps owners of Aibo, Sony's popular and pricey robotic pet, teach their electronic dogs new tricks. Aibo owners are outraged, and hundreds have vowed to stop buying Sony products altogether until the company backs off. Sony has sold more than 100,000 Aibos worldwide since 1999, at prices ranging from $800 to $3,000. The dogs have spawned a community of enthusiasts who fuss over the mechanical marvels as if they were real canines. [Source: Article by Dave Wilson and Alex Pham, *Los Angeles Times*, 1 Nov 2001] http://www.latimes.com/business/la-000086726nov01.story?coll=la-headlines ------------------------------ Date: Thu, 1 Nov 2001 19:59:47 PST From: "Peter G. Neumann" <neumannat_private> Subject: RU-Blue? or RU-Yellow? The United States is changing the color of food ration packets it is dropping in Afghanistan because they are the same color -- yellow -- as unexploded cluster bombs. Gen. Richard Myers, chairman of the Joint Chiefs of Staff, said the United States will change the color of the food packets to blue. [Thanks to Mike Hogsett, from http://www.cnn.com/2001/US/11/01/gen.attack.on.terror/index.html] [Now, you will get very "blue" if you choose the yellow, and you will be "yellow" if you do not choose the blue. Watch out for the Yellow Submarine Sandwich. PGN] ------------------------------ Date: Thu, 01 Nov 2001 19:07:37 -0500 From: David Farber <daveat_private> Subject: DeCSS is Speech (James S. Tyre, from IP) [Summary: Source code is speech. Object code is not speech. PGN] >Date: Thu, 01 Nov 2001 13:02:54 -0800 >From: "James S. Tyre" <jstyreat_private> >Subject: DeCSS is Speech >> "Like the CSS decryption software, DeCSS is a writing composed of computer >> source code which describes an alternative method of decrypting >> CSS-encrypted DVDs. Regardless of who authored the program, DeCSS is a >> written expression of the author's ideas and information about decryption >> of DVDs without CSS. If the source code were "compiled" to create object >> code, we would agree that the resulting composition of zeroes and ones >> would not convey ideas. (See generally Junger v. Daley, supra, 209 F.3d >> at pp. 482-483.) That the source code is capable of such compilation, >> however, does not destroy the expressive nature of the source code >> itself. Thus, we conclude that the trial court's preliminary injunction >> barring Bunner from disclosing DeCSS can fairly be characterized as a >> prohibition of "pure" speech." > This is *not* from the Second Circuit, where we did the amicus brief. > This is from the California state court trade secrets case, DVDCCA > v. Bunner, in which the court today reversed the preliminary injunction > issued against the Defendants. PDF Opinion: > http://www.courtinfo.ca.gov/opinions/documents/H021153.PDF > James S. Tyre mailto:jstyreat_private > Law Offices of James S. Tyre 310-839-4114/310-839-4602(fax) > 10736 Jefferson Blvd., #512 Culver City, CA 90230-4969 > Co-founder, The Censorware Project http://censorware.net For IP archives see: http://www.interesting-people.org/archives/interesting-people/ ------------------------------ Date: Fri, 26 Oct 2001 08:45:55 -0400 From: Peter Wayner <pcwat_private> Subject: Risks of concentrated power and the surveillance state Federal prosecutors said Mr. Hanhardt used law enforcement computers and other databases to get information on traveling jewelry sales representatives, including itineraries and car rental information. Prosecutors said many of the thefts were from the rented automobiles. [Source: http://www.nytimes.com/2001/10/26/national/26THEF.html, *The New York Times*, 26 Oct 2001] Mr. Hanhardt was Chief of Detectives for the Chicago Police Department. His gang, which operated from the early 1980's to 1998, reportedly stole more than $5 million. This may not be the best estimate because as part of his plea bargain, he's going to pay $4.8 million and cash equal to half of the equity in his home. There were 6 people in the gang. We probably don't know the full extent of his crime spree. ------------------------------ Date: Sat, 27 Oct 2001 09:04:53 -0700 (PDT) From: Devon McCormick <devonmccat_private> Subject: Risk of monoculture and exponential false AV positives I'd like to point out two related risks: the risk of monoculture and the risk of a potential exponential increase in spurious collisions between legitimate software and anti-virus. First, I'll summarize a complaint (on a mailing list) from a consultant: a popular AV (anti-virus) software package may be disallowing operation of normal software as being possibly viral. Of course, the "safe" solution The AV chooses is to disallow some file access by the offending software. This simplistic, inflexible default is exacerbated by similar inflexibility on the part of the IT group which tends toward monoculture, admittedly in the face of overwhelming complexity. By monoculture, I mean restricted support of or interest in any software outside a narrow list of approved vendors. The consultant uses a niche product with which the IT department is unfamiliar, therefore they lack the competence to check out his claim of innocence so he must assume the burden of proof. Furthermore, he has no authority to conduct a simple test, switching the anti-virus off and on again to show that it, not his software, is the problem. The risk of monoculture is further raised by the speculation that the the AV conflict may be caused by his software directly writing files with binary data instead of using a more standard, and increasingly more common, access method such as ODBC. This leads us to the 2nd risk: (possibly) exponentially increasing AV false positives. I once had a similar problem with an AV: an optimization I was running triggered a virus warning and stopped the run. I suspected that the bit pattern of an intermediate file was matching that of a "known virus", so I shortened the inputs to the optimization by the least significant digit, thus slightly changing these intermediate values, and it ran without a problem after that. Fortunately I knew my results were not sensitive to such a small change. As in the case above, I was using specialized, niche, software. However, the other risk this illustrates is the realization that the number of false positives from AV is the product of 2 numbers: how may different signatures (indicators of known viruses) being checked and the number of different intermediate results any software may produce. Both of these factors are increasing over time. This increase may be exponential (in the loose sense) because, at first glance, this likelihood of collision resembles the Birthday Problem. This is the well-known, non-intuitive result that there's about a 50% chance that 2 people, out of a random group of 25 or 26, will share a common birthday. Similarly, the chance of a spurious AV hit depends on the product of the linear increase of the 2 factors mentioned. ------------------------------ Date: Thu, 25 Oct 2001 09:55:14 -0500 From: Tim Rushing <timat_private> Subject: Fake ID anyone? I live in Indiana and recently lost my wallet on a weekend. I was pleasantly surprised that the bank allowed me to cash a check without id or check card by punching my ATM code into the keypad at the teller's window. However, the process for actually getting my license replaced at the state license bureau was not as inspiring. Initially, I was impressed. I had gone with an expired passport (picture taken in 1986 when I was much younger and lighter), bank statement and a number of other items. When I arrived, they compared my proofs of identity against a checklist. Apparently, various items are worth between 1 and 6 points, with a valid driver's license worth 6 points and my bank statement worth 1. You need 6 points to get a driver's license issued to you. With the passport, I had 7 points. Unfortunately, the passport was only worth 3 if it was less than 2 years expired. So, armed with the list, I made another trip home and easily returned with 8 valid points. I made it past the screener to get to the person at the terminal who actually sets up the license. She also carefully checked through all my documentation, handed it back to me, turned to her computer and asked, "Name?" She even had my spell my last name. No attempt to correlate the name with the documentation and she had written nothing down from my paperwork. Now, Indiana does have digital pictures on the license, so it is possible that once she pulled it up, she had a picture of me to look at. I wasn't reassured. Once again, a great demonstration that a well-designed security system can be easily undermined in implementation. Tim Rushing [And airlines are contemplating using smart cards for fast access by passengers! PGN] ------------------------------ Date: Wed, 31 Oct 2001 22:49:12 +0100 From: "Paul van Dijken" <tapvdat_private> Subject: Bank assets disappear, convert customers into Euro-peons On 29 Oct 2001, my sister and brother-in-law experienced one of their worst nights ever. When trying to pay some bills using the Internet site of the SNS bank (one of the major banks in the Netherlands), the transactions were rejected, because no sufficient amount was available. This was strange, because normally a couple of thousand guilders (a few thousand dollar, about half) should be there. When he checked his savings, the entire amount was gone. All accounts had a zero amount. Thinking on how they should pay the new shoes for the children, etc., they lay awake all night. The next morning, my brother-in-law arrived at work in a terrible temper. When asked, he explained to his colleagues the entire story and tried to show it. To his relief, all amounts were back, but this time in euros. Apparently the bank had gone through the euro conversion that night, but failed to shutdown its website or to warn its customers. Fortunately, my brother-in-law has a strong heart. [Good thing. He needed a Eurologist, not a Cardiologist. PGN] ------------------------------ Date: Mon, 5 Nov 2001 11:51:53 -0800 (PST) From: Erann Gat <gatat_private> Subject: DoS attack on Mac OS9 This is an old RISK, but I haven't seen it mentioned here before. Macintosh OS9 comes with a "multiple user" control panel that provide password protection. Trouble is, to change a password you don't have to type in the old password again, and you don't have to confirm the new password. So a malicious user who gains physical access to the machine can render that machine useless by changing the password and shutting the machine down. You get the same result from a typo too. If what you actually typed as your new password isn't what you think you typed you're hosed. Poor Apple. They must be finding it hard to get good help these days. Erann Gat <gatat_private> ------------------------------ Date: Fri, 26 Oct 2001 00:56:30 -0700 (PDT) From: Michael Ortega-Binderberger <mikiat_private> Subject: Conference management software reveals "hidden" authors Conference paper submissions are hardly a life and death issue, but I just found a problem when submitting a paper. The ACM SIGMOD conference is in its second year of a new double blind reviewing policy to improve fairness. You register a paper, write the names of the authors in a form, but not in the actual pdf submission, which only carries the paper id. In this environment, the idea of keeping authors hidden is of some value. While registering a paper, the Microsoft conference management software http://cmt.research.microsoft.com/cmt/ told me one of my co-authors was already registered in the system, and whether I truly wanted to add him to my paper. This was my advisor, and as it turns out, another student is also submitting a paper, which is fine. But in general I could register any bogus paper, and give names of "competitors" and find who else is up to submitting papers to the conference. An interesting vulnerability given the stated aims of double blind reviewing. Michael Ortega-Binderberger, CS U.Illinois Urbana, on loan to U.C. Irvine mikiat_private, mikiat_private, mikiat_private, m.ortegaat_private ------------------------------ Date: Mon, 5 Nov 2001 21:57:39 +0000 From: Cameron Simpson <csat_private> Subject: Insecure promo from American Express Today I received an an e-mail from AmEx promoting its Online Services, with offers of a chance to win lots of reward points if I sign up. However, there are enough bogus things in this missive to make me want to check very thoroughly that this actually comes from AmEx. The first, and minor, point is the From: address: dtwnonenrollees+671692.836250193.4at_private [Numbers mangled for privacy reasons.] Looks pretty bogus, eh? I suspect that it's a bounce detector from the shape of it. [Checks... the MXs are bounce.exactis.com. and reply.exactis.com. which are pretty suggestive.] There's even a note at the bottom of the message saying "Please do not reply to this e-mail for any enquiries - messages sent to this address cannot be answered." It's only a list removal address, with apparently a 3 week(!) implementation time. The second, and major, point is the contact URL. Look at this: http://tm0.com/AmericanExpress/sbct.cgi?s=............... [I've stripped off the identifying parameters.] There's no sign whatsoever that this is a bona fide AmEx host! A whois on tm0.com says nothing useful either: Domain Name: TM0.COM Registrar: NETWORK SOLUTIONS, INC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com Name Server: NS01.LODO.EXACTIS.COM Name Server: NS00.LODO.EXACTIS.COM Updated Date: 27-oct-2001 Internic.net doesn't give an answer at all. So this would easily be a bogus domain by someone harvesting credit card information. Now, I happen to have a tool for this kind of thing and it says: GET http://tm0.com/AmericanExpress/sbct.cgi?s=......... REDIRECT(302) to http://www.americanexpress.com.au/onlineservices GET http://www.americanexpress.com.au/onlineservices REDIRECT(302) to http://home3.americanexpress.com/australia/onlineservices GET http://home3.americanexpress.com/australia/onlineservices REDIRECT(302) to http://home3.americanexpress.com/australia/onlineservices/ GET http://home3.americanexpress.com/australia/onlineservices/ REDIRECT(302) to https://www48.americanexpress.com/iestm/eoi/jsp/en_AU/logon/LogLogon.jsp?Face=en_AU&DestPage=https%3A%2F%2Fwww48.americanexpress.com%2Fen%2Fintl%3Frequest_type%3Dintl_CardsListHandler%26Face%3Den_AU and off into https land it goes. So this URL does hand off to Amex (with great inefficiency), and so the necessary degree of subversion is somewhat greater, requiring some DNS hacking. Or at least it does if my query tool goes there (in my paranoid musings I can imagine the tw0.com server only behaving suspiciously if the User-Agent matches one of the popular browsers, which my tool does not.) But how is the average user to check this? They can't. I expect I should be thankful (I'm merely surprised) that this was a plain text message; if it were HTML then recipients would have even less hint about the suspect URLs. What else to fear? The opening URL is plain HTTP, liberally adorned with presumably identifying numbers. Somewhat insecure also. If done properly, this should have been a direct HTTPS like to an obviously AmEx owned domain. There are no contact details on the e-mail except these URLs. I call AmEx customer service and the first thing they want is my card number. I'm now sufficiently soured on the whole thing that I just put the phone back down:-( The RISK? Aside from the chance this actually is a scam (which I doubt, but only after digging around a bit), this is exactly the kind of message the naive user should never respond to. Yet such practices, like M$'s loathsome practice of publishing documents as .exe files, actively encourages such laxness and complete faith in third parties. Yea, even in *unknown* third parties as in this case! This does nothing for my confidence in them, and is somewhat ironic while they're actively promoting their "blue" smartcard enhanced credit card, which somehow offers improved fraud security (in totally nebulous terms as near as I can tell so far). Cameron Simpson, DoD#743 csat_private http://www.zip.com.au/~cs/ ------------------------------ Date: Wed, 31 Oct 2001 09:57:44 +1100 From: Henry Grebler <henrygat_private> Subject: Re: ACT Election Electronic Voting (Polette, RISKS-21.72) > The 11,340 pre-poll electronic votes were supposed to have been counted just > after the polls closed at 6pm AEST but took about 90 minutes ... Give me a break! These numbers just don't add up. "11,340 pre-poll electronic votes" would not strain the resources of my $2 calculator. "discs for the eight polling stations" - in other words, 8 floppy disks - took 90 minutes to load ... because the entire population of Australia who actually cared enough to access the website - that's all 10 of us - resulted in them "getting lots of hits on our internet site". They may well have had problems, but the evidence presented does not support the conclusions. Finally, paying attention to the so-called problem of getting delayed results runs the RISK of not addressing all the real security RISKS mentioned in previous editions of RISKS. ------------------------------ Date: Mon, 5 Nov 2001 17:11:00 -0500 From: "Przemek Skoskiewicz" <przemekat_private> Subject: Re: TD Bank Canada system crash (Akerman, RISKS-21.72) > The bank's computer systems have all sorts of "redundancies" built in ... and the very next entry from PGN describes "ANOTHER SRI-wide Power Outage" due to the pressing of an incorrect button! Sometimes I feel that RISKS readers expect to live in a perfect world. A remarkable thing about the Toronto-Dominion bank failure would be if it had accepted the transactions and lost them, or erased customer data, rather than it being down for the weekend. Do we really expect to spend so much time and money designing our systems against *every* conceivable occurence? Besides an inconvenience, was the bank's downtime really such a dramatic event that it ought to have designed against random board failures? And what about the SRI's power failure? I'm sure that SRI's power backup systems are some of the best thought-through and designed systems in place, yet one press of the wrong button took them down. Does this mean that their design was an utter failure and they should start from scratch? I think that sometimes we are better off accepting such "random" occurences, not bothering too much about them and treating them as normal annoyances of modern life. Like whenever I walk out of my apartment and there are 3 empty taxis lined up in front, but whenever I actually need one, there isn't one for miles, :-( Przemek Skoskiewicz ------------------------------ Date: Mon, 05 Nov 2001 14:10:45 -0500 From: "James R. Cottrell Jr." <jxcat_private> Subject: Re: Stray bomb caused by typo (Jacobson, RISKS-21.71) I believe the submitter missed the point of the original submission. If the check digit is calculated such that transposition of two legal values (latitude 89.0 and 80.9) provides a different value, then it doesn't matter that all possible latitudes are valid. I believe this was done with bank account numbers in the 1970s to reduce/eliminate typos. Jim Cottrell jxcat_private 1-781-271-6475 ------------------------------ Date: Thu, 25 Oct 2001 14:26:57 +0100 From: Kearton Rees <Kearton.Reesat_private> Subject: Re: Int. Conf. on COTS-based Software Systems (RISKS-21.70) In Europe the UK-based Safety-Critical Systems Club (http://www.safety-club.org.uk/) has also been looking at the issues raised by the use of COTS, in this case for use in safety-critical systems - April 2001 (http://www.safety-club.org.uk/advert/CaS.html#Slides). Kearton Rees, BTexact Technologies, Adastral Park, Martlesham, Ipswich IP5 3RE, UK Kearton.Reesat_private ------------------------------ Date: 12 Feb 2001 (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 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. .MIL users should contact <risks-requestat_private> (Dennis Rears). .UK users should contact <Lindsay.Marshallat_private>. => 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 are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 20" for volume 20] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. Lindsay Marshall 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 21.73 ************************
This archive was generated by hypermail 2b30 : Mon Nov 05 2001 - 16:59:34 PST