RISKS-LIST: Risks-Forum Digest Saturday 19 January 2002 Volume 21 : Issue 87 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.87.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: Exploding chips: Would you like to be fried with that? (Rob Slade) Hospital tells elderly men they're pregnant (Arthur Goldstein) Automated Debit: "There's nothing we can do to stop it." (Carl Fink) Even unscientific elections get rigged (Jeremy Epstein) The risks of standards and validators (Lindsay Marshall) Buffer overflows and other stupidities (Earl Boebert) Windows update server glitch (Mike Hogsett) An outrageous violation of privacy (Fred Cohen) Risks of Internet Reconfigurable Logic (John Gilliver) Linked DMV databases and biometrics on driver's licenses (Ben Rosengart) Facial recognition technology doesn't work (Nick Brown) Honolulu speed camera risk: mainly human error (Dan Birchall) AOL Buddy-Hole fix has backdoor (Robert Andrews) Reinventing snake oil: compression (Jeremy Epstein) Re: Airplane takes off without pilot (Paul Nelson) Re: Software glitch grounds new Nikon camera (Nickee Sanders) Re: Kaiser Permanente exposes medical record numbers (Geoff Kuenning) Re: ING bank debits wrong sum from accounts (Paul van Keep) REVIEW: "Counter Hack", Ed Skoulis (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Thu, 17 Jan 2002 08:58:01 -0800 From: Rob Slade <rsladeat_private> Subject: Exploding chips: Would you like to be fried with that? From NewsScan Daily, 17 January 2002: > EXPLODING CHIPS COULD FOIL THIEVES > Researchers at the University of California in San Diego have developed a > way to blow up silicon chips using an electric signal -- Now, at this point I was willing to dismiss this as the stuff of fiction. You all know how computers in books and movies always "blow up real good" when the bad guy plants a virus or something in them. However: > an innovation that could be used to fry electronic circuitry in devices > after they're stolen or fall into the wrong hands. The American spy plane > that was impounded in China last year is an example where such technology > would have proven handy in destroying its secret electronics systems. OK, this make a bit more sense. Obviously these are chips that are specifically designed to blow up once they receive a certain signal. At this point, though, you start to think about what kind of signal that could be. And, could it be counterfeited? > Similarly, if a cell phone were stolen, the owner could alert the wireless > carrier, which would send a signal to trigger a small explosion in the > phone's chip, rendering it useless. The techniques uses a small amount of > the oxidizing chemical gadolinium nitrate applied to a porous silicon > wafer. (New Scientist 16 Jan 2002) > http://www.newscientist.com/news/news.jsp?id=ns99991795 OK, I am definitely certain that, if I need to get a new cell phone from now on, I am *definitely* not going to carry it in my pants pocket. The RISKS, as have been frequently noted here, are obvious. (If we could get them to use those chips in pacemakers, wouldn't that just make a killer application, Peter?) rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade [I normally delete all trailer quote. But this one from another message from Rob is rather fascinating: A modern US Navy cruiser now requires 26 tons of manuals. This is enough to affect the vessel's performance. -- `New Scientist' article on the paperless office PGN] ------------------------------ Date: Fri, 11 Jan 2002 04:19:19 +0000 From: arthur.goldsteinat_private Subject: Hospital tells elderly men they're pregnant The Chesterfield and North Derbyshire Royal Hospital admitted on 10 Jan that it had mistakenly sent computer generated letters to 30 patients, including six elderly men, telling them they were pregnant. The system operator was blamed for choosing the wrong option (instead of informing them that their operations had been postponed). [Reuters, 10 Jan 2002, PGN-ed] http://news.excite.com/article/id/65168 |oddlyenough|01-10-2002::11:30|reuters.html [SPLIT URL] ------------------------------ Date: Wed, 16 Jan 2002 14:02:08 -0500 From: Carl Fink <carlat_private> Subject: Automated Debit: "There's nothing we can do to stop it." A Georgetown, TX man who had arranged for his water bill to be automatically debited from his bank account alertly noticed that his monthly bill was for over $21,000. (If he hadn't noticed, the debit would have happened, causing him to bounce multiple checks before the error was corrected.) When he told the city of the problem, "They said there was absolutely nothing they could do to stop the automated debit, and it was out of their hands." Their solution was to send a city employee with a check for $21,000 to reimburse their customer! http://www.austin360.com/statesman/editions/tuesday/metro_state_1.html Risks? Lack of sanity checking on a new billing system springs to mind. Lack of any way to correct errors is also quite prominent. Carl Fink, Manager, Dueling Modems Computer Forum http://dm.net/ carlfat_private ------------------------------ Date: Wed, 9 Jan 2002 16:28:26 -0500 From: "Jeremy Epstein" <jepsteinat_private> Subject: Even unscientific elections get rigged ZDNet is doing a poll on whether J2EE or .NET is more important for Web services. Although it's a totally unscientific poll, they've set things up to try to detect (and stop) ballot stuffing. It seems that Microsoft hasn't understood the concept, and employees are trying to vote repeatedly, including automated voting. http://news.zdnet.co.uk/story/0,,t269-s2102244,00.html The risk of believing unscientific polls is nothing new, but the combination of electronic polls that can be stuffed with the herd mentality that may influence buying greatly increases the risks. [*The Register* noted that 21.5% of the respondents said they would use .Net, 46% Java -- until a surge of votes came in from microsoft.com, some of which were apparently stimulated by internal MS e-mail saying "PLEASE STOP AND VOTE FOR .NET!". PGN] ------------------------------ Date: Fri, 11 Jan 2002 13:16:36 -0000 From: "Lindsay Marshall" <Lindsay.Marshallat_private> Subject: The risks of standards and validators This week I ran a page of the RISKS Web site through the W3 html validator, as I do on a regular basis -- it keeps me clean and legal. It complained that I didn't have a charset specification, so I added one as it suggested. This appears to cause some netscape 4.7 browsers some problems -- I had complaints that the text was vanishingly small, and also that it was vastly increased in size. Presumably a typeface selection that is hard-wired somewhere, and that nobody is told about. Anyway, I've taken out the charset setting for the moment. http://catless.ncl.ac.uk/Lindsay [Lindsay runs our UK redistribution and the excellent RISKS Web site -- for both of which I am most grateful. I'm delighted to take the opportunity to thank him once again! PGN] ------------------------------ Date: Mon, 14 Jan 2002 10:07:55 -0700 From: Earl Boebert <boebertat_private> Subject: Buffer overflows and other stupidities "I used to be disgusted, now I try to be amused." -- Elvis Costello "What a stupid robot." -- Marvin the Paranoid Android In my view, attempts to close the buffer overflow vulnerability through software or compiler tricks are doomed to one degree of failure or another because you're trying to program around a stupid processor design. Certain contemporary processors actually host a Pantheon of stupidities, consisting of a Greater Stupidity and two handmaiden Lesser Stupidities. Greater Stupidity: Read access implying execute access. Any piece of data that the processor can be tricked into loading into the command register immediately becomes code. This is a stupidity of such breadth and depth that it comes with an event horizon. Lesser Stupidity I: Segmented addressing that isn't. Let's say you have an addressing scheme consisting of segment number plus offset. This raises the question of what to do when, in executing code, block moves, etc., the offset gets counted up to maximum length plus one. Smart answer: take a fault. Dumb answer: set offset to zero and count up one in segment number. Lesser Stupidity II: Brain-dead stack design. If you enumerate the design space of dynamic storage management, you may realize that one actually has to *work* to produce a stack design so dumb that overflow attacks are possible. Here are four classes of designs that are immune to the vulnerability: 1. Descriptor stacks. The only thing that goes in the stack are addresses, preferably with a bounds value attached. Overflow a buffer and at worst you clobber the heap. Penalty: one level of indirection, which (The Horror! The Horror!) may cause your dancing pigs to dance slower than the other guy's. Possibility: can be fitted transparently to existing processor designs, assuming anybody cared. 2. Stack per protection domain. This assumes you can find the perimeters of your protection domains. Also slows down dancing pig displays because of copying parameters from stack to stack. 3. Separate control and data stacks. CALL/RETURN works the control stack, PUSH/POP works the data stack. Doh. 4. Error-checking stacks. A whole raft of options, including "shadow stacks" with checksums, return addresses protected with trap bits, etc. etc. So, if it's all so straightforward and well known, why hasn't some vendor or other fixed it? Answer: the dancing pigs have won. [Ah, yes. Earl is tacitly recalling the good old days of Multics (beginning in 1965) and its progenies (SRI's object-oriented Provably Secure Operating System design 1973--1980, and the Honeywell/Secure Computing Corporation type-enforced systems), all of which took care of this problem and so many others so long ago. But with today's badly designed bloatware, the dancing pigs are increasingly becoming 700-pound porkers that can barely move around the pigsty without massive memory and processing power, and whose pigpen could not even contain them if they were in reality Trojan pigs. PGN] ------------------------------ Date: Tue, 15 Jan 2002 14:48:14 -0800 From: Mike Hogsett <hogsettat_private> Subject: Windows update server glitch A glitch in Microsoft's server software has left some users unable to download important security patches and other fixes for Windows software since last Thursday. http://www.cnn.com/2002/TECH/internet/01/15/microsoft.security.server.ap/index.html http://www.cnn.com/2002/TECH/internet/01/15/ microsoft.security.server.ap/index.html [SPLIT] ------------------------------ Date: Sun, 13 Jan 2002 10:27:20 -0800 (PST) From: Fred Cohen <fcat_private> Subject: An outrageous violation of privacy I just saw a piece on MSNBC where they prominently featured the face of a man who helped someone out of the WTC on 11 Sep 2001 -- and just because they don't know who the man is, they have created a composite picture of him and posted him as if he were a wanted man on the national news. Now I understand their desire to make human interest stories go, but I think it is outrageous to take the image of a person and smear it all over national TV, creating a manhunt for someone, when all the person did was to help someone else out in a public place. If I were this man, I would sue them for as much as I could get and do all I could to try to recover what semblance of privacy I might barely still have left after being exposed on national TV without my permission. Is this all we have left of our privacy? Fred Cohen http://all.net/ Fred Cohen & Associates tel/fax:925-454-0171 Sandia National Laboratories 1-925-294-2087 University of New Haven ------------------------------ Date: Tue, 08 Jan 2002 16:40:35 +0000 From: john.gilliverat_private Subject: Risks of Internet Reconfigurable Logic ... "For example, IRL (Internet Reconfigurable Logic) means that a new design can be sent to an FPGA in any system based on its IP address." (From Robert Green, Strategic Solutions Marketing with Xilinx Ltd., in "Electronic Product Design" December 2001. Xilinx is a big manufacturer of FPGAs.) For those unfamiliar with the term, FPGA stands for field-programmable logic array: many modern designs are built using these devices, which replace tens or hundreds of thousands of gates of hard-wired logic. The RISKs involved are left as an exercise to the readers ... J. P. Gilliver, BAE SYSTEMS Advanced Technology Centre, West Hanningfield Road, GREAT BADDOW, Essex, CM2 8HN, UK +44 1245 242133 ------------------------------ Date: Wed, 9 Jan 2002 17:38:14 -0500 From: Ben Rosengart <ben+risksat_private> Subject: Linked DMV databases and biometrics on driver's licenses *Time Magazine* is reporting that the federal Department of Transportation, by instruction of the Congress, is working to link together the states' driver databases, and also to introduce biometric security on drivers' licenses. http://www.time.com/time/nation/article/0,8599,191857,00.html RISKS include false arrest due to database screwups, abuse for personal reasons by government personnel, abuse by the government itself, all the RISKS known to be associated with biometrics, disclosure of the databases to the public, and probably much, much more. ------------------------------ Date: Wed, 9 Jan 2002 11:38:39 +0100 From: Nick Brown <Nick.BROWNat_private> Subject: Facial recognition technology doesn't work An article by the ACLU at http://www.aclu.org/issues/privacy/drawing_blank.pdf reveals that a highly-publicised facial recognition system has been quietly dropped by law enforcement officials in Tampa, Florida, following a large number of false positives (including males identified as females, and vice versa) and a total of zero matches against known criminals, leading to zero arrests. Aside from the already-discussed civil liberties RISKs of such systems, it seems we need to add the possibility that the taxpayers may not be getting value for money, with or without their knowledge (the withdrawal of this kind of thing tends to be done with rather less media coverage than its introduction). One wonders if this will have any effect on plans to introduce such systems into airports to "detect" terrorists. Nick Brown, Strasbourg, France ------------------------------ Date: Wed, 9 Jan 2002 22:52:58 -1000 From: Dan Birchall <djbat_private> Subject: Honolulu speed camera risk: mainly human error After much debate, and general wailing and gnashing of teeth from those who like to drive fast, the powers that be here in Honolulu have a private contractor operating cameras to photograph vehicles which speed or run red lights. After the license number, time, and location of the violation are verified, a citation is mailed. In their first day of operation, the cameras caught 927 speeders. http://starbulletin.com/2002/01/03/news/index1.html However, more than 80% were unenforceable due to human errors in operation of the cameras - poor aim, inaccurate location recording, etc. http://starbulletin.com/2002/01/08/news/index4.html On the bright side, people do seem to be speeding less since the cameras started working. http://danbirchall.com/ ------------------------------ Date: Wed, 9 Jan 2002 12:19:10 -0400 From: "Robert Andrews @ PrivacyExposed.com" <Robertat_private> Subject: AOL Buddy-Hole fix has backdoor "A member of w00w00, the security enthusiasts who first reported the AOL Instant Messenger (AIM) games request vulnerability, has alerted users that a fix the group recommends has its own backdoor. Apparently, the AIM Filter by Robbie Saunders which w00w00 had recommended is infected, group member Jordan Ritter disclosed on the Bugtraq mailing list late Tuesday. "At the time, Robbie Saunders' AIM Filter seemed like a nice temporary solution. Unfortunately, it instead produces cash-paid click-throughs over time intervals and contains backdoor code combined with basic obfuscation to divulge system information and launch several Web browsers to porn sites," Ritter wrote." [...] Thomas C Greene, *The Register* http://www.theregister.co.uk/content/4/23596.html ------------------------------ Date: Wed, 9 Jan 2002 16:13:31 -0500 From: "Jeremy Epstein" <jepsteinat_private> Subject: Reinventing snake oil: compression Snake oil is on the rise. Latest to join the fray is Zeosync (www.zeosync.com), which announced on 7 Jan 2002 that they have new algorithms that can provide 100:1 lossless data compression over "practically random" data. (What they mean by "practically" isn't defined.) Lots of criticism and proofs that it's impossible in Slashdot http://slashdot.org/article.pl?sid=02/01/08/137246&mode=thread and elsewhere. So far the algorithms haven't been given, except to provide the single longest stream of buzzwords I've seen in a long time. The one part that says it might not be 100% snake oil is that they have a Fields' Prize winner as one of the participants. The risk here is that they've added enough buzzwords to the announcement that some people might actually believe it. The media doesn't seem very skeptical, which they should be. Reuters quoted David Hill, an analyst with Aberdeen Group as saying "Either this research is the next 'Cold Fusion' scam that dies away or it's the foundation for a Nobel Prize. I don't have an answer to which one it is yet." Others have been much more willing to figure out which way it's going. Remember the 1999 story about the 16-year-old Irish girl whose new form of cryptography would revolutionize the world? ------------------------------ Date: Mon, 7 Jan 2002 15:20:53 -0600 From: pnelson@sauer-danfoss.com Subject: Re: Airplane takes off without pilot (Klein, RISKS-21.84) There are many aircraft which have no starters (or electrical system, for that matter)- commonly antique or classic small, one- or two- place planes like the 1947 Aeronca Champ that was the subject of this item. There are well-known safety precautions which go along with starting them- one of the oldest is that there should be someone in the cockpit with feet on the brakes, operating the magneto switches and throttle while a second person "props" the plane to start it. (The classic shouts "CLEAR!", "CONTACT!", "SWITCH OFF!", "BRAKES", "THROTTLE BACK AND CRACKED!" come to mind.) If a plane like this is to be started by one person, the accepted precaution is to tie the tailwheel to a stationary object, turn the fuel OFF so that only the small amount in the carburetor bowl is available, and then make CERTAIN that the throttle is only cracked open a small amount. I've started my 1946 Cessna 140 in this manner many times when the battery happened to be run down. All that being said, incidents like this still happen when people try to take shortcuts. It shouldn't have happened! Paul Nelson, Senior Engineer, Sauer-Danfoss Company, Ames, IA 515-239-6614 ------------------------------ Date: Wed, 9 Jan 2002 12:10:32 +1300 From: Nickee Sanders <njsat_private> Subject: Re: Software glitch grounds new Nikon camera (Gillett, RISKS-21.85) Our first digicam was also a Kodak. When the battery voltage was low enough (and it happened suddenly), the camera would simply stop responding to *any* user actions whatsoever. It didn't even do a power down. The only way to clear this condition was to take the batteries out for a number of hours; after this, on insertion of fresh batteries, the camera would power down and then could be powered up again. The first time this happened it was pretty scary. One minute we were snapping away; the next minute the camera was frozen, with the lens fully extended (and thus the lens cap wouldn't stay on it). The local service reps knew nothing of this error condition and could only offer to send it to Australia (from New Zealand) for servicing, which would take several weeks. We figured out by trial and error how to solve it ourselves. Nickee Sanders, Auckland, New Zealand ------------------------------ Date: Mon, 14 Jan 2002 13:09:28 -0800 From: Geoff Kuenning <geoffat_private> Subject: Re: Kaiser Permanente exposes medical record numbers (Debert, R-21.86) J. Debert writes about an insecure Web page at http://www.kponline.org. It happens that my best friend works for Kaiser Permanente's IT department, so I forwarded the message to her. As a result of discussions and exploration, I think that the alleged risk does not in fact exist. The claim was that medical-record numbers were being exposed during the signon process. However, in viewing the source of the referenced Web page, it appears that the "sign on" button makes an https (SSL) connection. Thus, although the "padlock" icon in the browser is unlocked, anything sent from that page is in fact sent using SSL. I have recommended that Kaiser change their main page so that it forwards the browser to an SSL equivalent, solely so that the padlock icon will appear locked. I think that the true RISK is not in Kaiser's Web page, but rather in the browser. The "padlock" icon reflects not whether the page SENDS information securely, but rather the fact that the page was FETCHED securely. This disconnect between what is shown and what is expected has been raised recently by Jeff Mogul in the converse direction: a page that had the padlock proceeded to send information insecurely. The first problem (apparently insecure page is actually secure) can be patched around with the forwarding kludge I mentioned above. The second can be handled by the user to some extent (certain browser settings can warn you when you transition from a secure page to an insecure one). However, the true problem is in browser design. The "padlock" icon should be associated with a LINK, not a page. Regardless of how it was fetched, if a page contains both secure and insecure links, the lock should be shown as unlocked and should lock only when you mouse over a secure link. Only if all outgoing links from a page are secure should the padlock be permanently displayed in its locked form. Geoff Kuenning geoffat_private http://www.cs.hmc.edu/~geoff/ ------------------------------ Date: Wed, 9 Jan 2002 11:04:45 +0100 From: Paul van Keep <paulat_private> Subject: Re: ING bank debits wrong sum from accounts Several people have pointed out that I was wrong in my statement about disproving a 10000 euro cash withdrawal would be tough. Banks have a sane upper limit on the amount of cash you can withdraw from an ATM, even at your own branch. That limit is somewhere below 2000 euro. A 10000 euro ATM transaction is therefore totally impossible. Paul van Keep ------------------------------ Date: Mon, 14 Jan 2002 07:34:47 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Counter Hack", Ed Skoulis BKCNTRHK.RVW 20011023 "Counter Hack", Ed Skoulis, 2002, 0-13-033273-9, U$49.99/C$75.00 %A Ed Skoulis %C One Lake St., Upper Saddle River, NJ 07458 %D 2002 %G 0-13-033273-9 %I Prentice Hall %O U$49.99/C$75.00 800-576-3800 416-293-3621 %P 564 p. %T "Counter Hack" Chapter one, as in many texts, is an introduction to the book, but is unusually important in this case. First, Skoulis lays out the philosophy behind the work. While the text of the book does concentrate on attacks, the author points out that invaders already have other sources of information. Further, Skoulis proposes that a detailed, complete, and integrated examination of representative samples of classes of attacks will provide an outline of defensive measures that can protect against a wide variety of assaults. A second point in this introduction is a brief examination of the character of attackers. Skoulis does point out that those who attempt to penetrate computer and communications security do so from a diversity of motivations and skill levels. However, he does tend to overstress the participation of "professional hackers," proposing that industrial espionage, terrorism, and organized computer crime activities are common. Certainly such campaigns may become common, making the need for pre-planning even more important, but the vast majority of endeavors we are seeing at present are amateur efforts. Finally, the introduction recommends the establishment of a computer security test laboratory, which is an excellent idea for any large corporation, but probably is not within the financial, personnel, or educational reach of even medium sized businesses. Chapter two provides a background in TCP/IP for the purposes of discussing networking offence and defence. There are frequent forward references to later sections of the book that deal with network attacks. The material could, however, have been condensed somewhat to emphasize those aspects of the protocols that are closely related to security. UNIX and Windows (NT and 2000) are similarly covered in chapters three and four, and, again, the text could be tightened up by focusing on safety factors. Chapter five points out the ways in which people can obtain data in order to direct and mount an attack. While the content is informative, and there are a few suggestions for restricting the release of such intelligence, the defensive value of the text is limited. The information gathering process continues in chapter six with war dialling and port scanning. Defences against application and operating system attacks are covered a bit better than in most "hacking" books (there are descriptions of buffer overflow detection tools), but the protective value of chapter seven is still questionable. Chapter eight examines network sniffing, scanning, spoofing, and hijacking. Denial of service is covered well in chapter nine. Various examples of malware are described in chapter ten. Chapter eleven deals with the means used to hide an attack. A number of scenarios are created in chapter twelve. Chapter thirteen describes some resources for keeping up with the latest computer vulnerabilities. Recently there has been a flood of books to the security marketplace, all based on the premise that if you know how to attack a system, you will know how to defend it. Skoulis has done a better job than most, but the thesis is still unproven. Yes, knowledge of the details of an attack does help you fine tune your defence. Yes, providing specifics of an example of a class of attacks does help you consider a protective mechanism that might work against a whole class. Yes, Skoulis does recommend safeguards for most of the attacks listed. But taking a crowbar to a padlock still doesn't teach you locksmith skills. copyright Robert M. Slade, 2001 BKCNTRHK.RVW 20011023 rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ 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.87 ************************
This archive was generated by hypermail 2b30 : Sat Jan 19 2002 - 11:35:13 PST