RISKS-LIST: Risks-Forum Digest Friday 17 August 2001 Volume 21 : Issue 60 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.60.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: Heart-device recalls (PGN) Runway incursions (Andres Zellweger) Cingular wireless goes down in heat wave (PGN) Swisscom Mobile breaks down for 10 hours (Andre Oppermann) Marines face charges in Osprey records falsifications (PGN) Woman stalked by Michigan cop via police databases is murdered (Declan McCullagh) Video crypto standard cracked? (Monty Solomon) Free hotel reservations canceled (Steve Bellovin) Interstate car tags to be photographed and tracked (Steve Holzworth) Hacked caller ID? (Andrew Hilborne) Risks of letting MS not-so-Hotmail do your junk filtering... (Michael Loftis) GPS-guide in car going nuts? (Martin Schulze) The risks of not verifying e-mail addresses (Doug Winter) Re: Mixing advertising and credit-card activation (Sam Garst, Joel Garry) REVIEW: "The Internet Security Guidebook", Juanita Ellis/Timothy Speed (Rob Slade) Dependability and "Open Source" development (Cliff Jones) CFP2002: Call for Proposals (Lance J. Hoffman) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Thu, 16 Aug 2001 9:35:51 PDT From: "Peter G. Neumann" <neumannat_private> Subject: Heart-device recalls A study from Brigham and Women's Hospital in Boston in the JAMA reports that, over the ten-year period ending Dec 2000, 42 recalls and 10 safety alerts were issued for pacemakers and implantable cardioverter defibrillators (ICDs, as In Cheney, Dick) involving more than 520,000 devices. Over 600,000 Americans have pacemakers and 150,000 have ICDs, so that represents a remarkably high percentage. However, only a small fraction of the recalled devices were actually defective. If recall recommendations were followed, the study estimates that 36,000 devices would have been replaced. Only a few deaths were attributed to malfunctions. Advisories are increasing, but that is attributed to increased manufacturer vigilance and richer information output by the devices. [Source: article by Kenneth Chang, *The New York Times*, 15 Aug 2001, Natl. Edition A12; PGN-ed] ------------------------------ Date: Wed, 15 Aug 2001 10:54:24 -0400 From: Andres Zellweger <azellwegat_private> Subject: Runway incursions A 14 Aug 2001 Reuters item, New glitch for US system to avoid runway collisions, talks about more delays in the long promised FAA Runway Incursion System -- due to ``excessive false alarms''. This raises an interesting dilemma for designer of such safety systems. The state of the art in runway incursion systems is not good enough to detect all potential incursions without a relatively high level of false alarms. One could tune the system to have false alarms at an ``operationally acceptable'' level, but the likelihood of missing some potential incursions increases. Critics argue that one should not be implemented a system that misses some potential incursions because air traffic controllers would become dependent on the system instead of using it a safety net. Therefore, they argue, there might be more incursions than if controllers were doing their job properly without the system in place. Others (and I fall in this camp) think that, with proper training, controllers will not be lulled into a false sense of security, and safety can be increased when a safety net that is not perfect is present. I don't think that any air traffic controller takes his/her job of separating aircraft less seriously because of TCAS! Andres G. Zellweger, PhD, NASA code R, 300 E St, SW, Washington, DC 20546-0001 1-202.358.0544 azellwegat_private [The chairman of the relevant House subcommittee on aviation suggested that the FAA should take the time to get it right. (The program is already six years behind schedule.) Runway safety is an increasing with more near misses, including one at Dallas in May 2001. LAX and O'Hare each had five near misses from 1997 to 2000. PGN-ed] [This morning's news reports noted a new runway crossing near-miss, preliminarily blamed on air-traffic control. PGN] ------------------------------ Date: Fri, 10 Aug 2001 14:17:48 PDT From: "Peter G. Neumann" <neumannat_private> Subject: Cingular wireless goes down in heat wave A little reverse Rube Goldberg: The heat wave in the DC area caused a power outage, the backup batteries failed, and the automatic system that should have cut over to the backup generator also failed, resulting in disruption of cell-phone service to 301- and 202-area Cingular Wireless customers. The failure of a single switch that was supposed to transfer from batteries to generator power (which was designed to operate autonomously for at least a month) was apparently the ultimately limiting factor. But the generator ran fine! [Source: Associated Press article by Derrill Holly, AP 10 Aug 2001; PGN-ed] ------------------------------ Date: Sun, 12 Aug 2001 13:03:15 +0200 From: Andre Oppermann <oppermannat_private> Subject: Swisscom Mobile breaks down for 10 hours On Friday, July 27th 2001, the whole Swisscom Mobile GSM network, serving 3.3 million customers (70% market share in Switzerland), broke down for 10 hours from approx. 12:30 until 22:30 GMT+0200. Two independent software errors in the primary and backup network signaling processors (the SS7 network) caused a halt for the processing of all signaling in a GSM network. This includes call setup, call receiving, SMS (short message service), logging onto network and basically everything else. The central GSM systems (HLR, VLR, NMC and so on) stayed up but were unable to communicate with the base stations in the field. The primary system suffered a complete failure (software error) and as designed the backup system took over. While it was working fine first the backup system got loaded more and more, judging from the description something like a missing free() call, and eventually broke down too half an hour later. The newspaper "Le Monde" was reporting insider information last week saying that these signaling processors are made by Alcatel and that Alcatel found out about the software errors two weeks before (and probably also had a fix) but "forgot" to inform Swisscom Mobile about it. Alcatel is now facing a Swiss Franc 30 million liability case. This is the loss Swisscom Mobile has because of lost revenues, not including public image damages. In one thing I have respect for Swisscom; They did a pretty good job with public relations and informed the media and public very openly about their technical problem(s). Now, two weeks later, Swisscom Mobile also issued a, thought written for the non technician but pretty detailed, press release of the cause and events of this network failure. Although one funny thing happened; The press release in German is the original one and while translating into English they forgot one just one word but it makes a somewhat significant difference. In the German version it reads "Technical systems do *not* guarantee 100% availability [but we do our best to get 99.95%]. In the English version it reads "Technical systems guarantee 100% availability [but we do our best to get 99.95%]". But see yourself: http://www.swisscom.com/gd/information/press_releases/2001/ natel_disruption-de.html in German http://www.swisscom.com/gd/information/press_releases/2001/ natel_disruption-en.html in English Andre Oppermann ------------------------------ Date: Fri, 10 Aug 2001 13:09:55 PDT From: "Peter G. Neumann" <neumannat_private> Subject: Marines face charges in Osprey records falsifications Eight Marine Corp officers have been charged with misconduct with the alleged falsification of MV-22 Osprey tilt-rotor maintenance records. [http://www.washingtonpost.com/wp-dyn/articles/A59345-2001Aug10.html] [See RISKS-21.14,21,24,31,33,36,38,41 for Osprey problems.] ------------------------------ Date: Fri, 10 Aug 2001 10:35:36 -0400 From: Declan McCullagh <declanat_private> Subject: Woman stalked by Michigan cop via police databases is murdered A Michigan State Police detective whose estranged wife was shot dead at the Potter Park Zoo admitted using police databases such as the Law Enforcement Information Network (LEIN) to check on his wife and her acquaintances before her fatal shooting. [Source: *Free Press*, 8 Aug 2001; PGN-ed http://www.freep.com/news/mich/lein8_20010808.htm] ------------------------------ Date: Wed, 15 Aug 2001 01:17:48 -0400 From: Monty Solomon <montyat_private> Subject: Video crypto standard cracked? Noted cryptographer Niels Ferguson says he's broken Intel's vaunted High-bandwidth Digital Content Protection (HDCP) Digital Video Encryption System, but fear of U.S. law is keeping him silent on the details. HDCP connects digital cameras, high-definition televisions, cable boxes, and video disks players. [Source: Article by Ann Harrison, 13 Aug 2001, PGN-ed; http://www.securityfocus.com/news/236] [Intel has not threatened him, but he can still be sued by the U.S. Govt under DMCA, or by the motion-picture industry. His comments are at http://www.macfergus.com/niels/dmca/index.html Knowledge that it is (or might be) breakable is likely to result in other folks doing it, and perhaps posting it anonymously in some non-US Web site. The globalization of the Internet is clearly going to be an increasingly difficult problem for industries trying to defend information supposedly protected under flawed standards. PGN] ------------------------------ Date: Tue, 14 Aug 2001 11:56:40 -0400 From: Steve Bellovin <smbat_private> Subject: Free hotel reservations canceled We have here a story of sequential bugs, or at least odd behavior. Last March, someone entered a rate of $0 per night for the Mexico City Airport Hilton into an online reservation system. A number of users of the Travelocity web site saw it and reserved rooms. Hilton eventually agreed to honor that rate for one night, and let travelers stay additional nights at "the lowest available rate". But the story has gotten stranger. According to today's Wall Street Journal, at least two people who made such reservations via Travelocity have found that their reservations have been canceled without their knowledge. Hilton and Travelocity deny any knowledge of what happened. Both cancellations were via telephone calls to Travelocity, made within minutes of each other. Steve Bellovin, http://www.research.att.com/~smb ------------------------------ Date: Thu, 9 Aug 2001 19:00:48 -0400 From: Steve Holzworth <schat_private> Subject: Interstate car tags to be photographed and tracked >From WRAL.com (excerpted): http://www.wral.com/news/910501/index.html [Charlotte, NC] ... The cameras will be used to photograph the license tags of some 400,000 vehicles so researchers can analyze freeway travel and predict future air-pollution levels and highway needs. The 43 cameras will photograph and track every car that passes on stretches of U.S. 74, and Interstates 77 and 85 during a 12-hour period on Tuesday. ... North Carolina highway officials say the photos will be destroyed within 90 days to protect the drivers. [Suuure they will - SCH] Steve Holzworth, Senior Systems Developer schat_private SAS Institute - Open Systems R&D VMS/MAC/UNIX Cary, N.C. [Interesting possibility if the numbers and letters can be read, but the state identification cannot -- in which case Steve in NC might get a ticket based on someone's Alaska licence plate. PGN] ------------------------------ Date: 09 Aug 2001 18:09:52 +0100 From: Andrew Hilborne <andrew.hilborneat_private> Subject: Hacked caller ID? Two-and-a-half years ago I received an unexpected telephone call at about 2230 on my British Telecom phone. The caller was adamant that I had called him at about 2020 the same night, from my phone -- he had used "1471" when he arrived home himself, to access the CLID of the last call to his number. But I had been out of the house until 2200, and the house had been empty. It took some effort to persuade my unknown caller that I hadn't called him earlier that evening. So the following day I asked on the BT fault reporting line how this could have happened. I was told that this sort of thing happens quite often. I may well have been in trouble if a crime had been committed at the other house that night. BT don't advertise this failure mode at all. Andrew Hilborne ------------------------------ Date: Fri, 10 Aug 2001 09:01:38 -0700 From: Michael Loftis <mloftisat_private> Subject: Risks of letting MS not-so-Hotmail do your junk filtering... I see that Hotmail has junk/spam filter, I get a fair amount of SPAM in my hotmail account so I figure I'll give this a try. It doesn't block anything that is spam, in fact the only thing it did block in the "Low" setting was mailings from SPEAKEASY my ISP, even after I told it that I *wanted* those! It's a good thing I noticed, they send bills via e-mail too. I mean really! I got 3-4 pices of spam through the filter (even after saying one of htem was spam earlier) and 5-6 pieces of mail from Speakeasy went into the Junk folder with the filter, I turned it off. The RISK is two-fold, blocking very obvious non-bulk mailings via a mechanism that isn't obvious, and then telling the user that they can ask that mechanism to be circumvented in special cases but not implementing it!! Imagine if I had not looked into the Junk Mail folder? How much other legitimate e-mail would go into there, keep in mind this was the "Low" setting. Michael Loftis ------------------------------ Date: Wed, 8 Aug 2001 18:09:33 +0200 From: Martin Schulze <joeyat_private> Subject: GPS-guide in car going nuts? Modern cars may contain GPS systems to guide the driver to unknown destination locations he would otherwise have to use a map for. We went out with three cars, of which two were sold with such a GPS system, ours wasn't, but we were driving in the city I know best. Both cars with GPS system didn't know that city well enough to reach the destination location without a map (or GPS system). After lunch at a restaurant at a distant edge of the city we went back to the house. Right after leaving the restaurant the three cars diverted, used different paths. Our car (w/o GPS) and one other car arrived at the house early. We were wondering where the third car had gone. Finally, some 10 minutes later, they arrived as well. What was the reason? Too much trust and depending on modern computer thingies. The location was stored in the GPS system. In order to reuse the location it was stored by using letters, but unfortunately the display wasn't very wide. When storing the name of the city and some random string the system cut off some parts: Wilhelmshaven Hotel Wilhelmshaven House Wilhelmshaven Restaurant `-----------' Display So when re-selecting the destination after lunch the driver had to make the choice which of the three similar looking locations is the proper one. He had selected the wrong one so the GPS system guided him to the hotel instead of the house. This driver used the GPS system of a modern 'VW Passat', the other car was a 'Audi 100' which has a larger display for the GPS system, so the driver was guided to the correct address. [Joey says "Please always Cc to me when replying to me on the lists." That is always a good policy. PGN] ------------------------------ Date: Thu, 9 Aug 2001 18:21:08 +0100 From: Doug Winter <dwinterat_private> Subject: The risks of not verifying e-mail addresses A colleague of mine recently received the following e-mail, apropos nothing: > Date: Wed, 8 Aug 2001 16:41:07 +0530 > From: HDFC Bank Support <Supportat_private> > To: [name elided] <[address elided]> > Subject: " Welcome to HDFC Bank. " > > This is an auto-generated mail. Please do not reply to it. > Dear Customer, > Thank you for opening an account with us. > We have received your account opening form and opened an account as > per the details mentioned below. > You can now access all your accounts from any of our branches across > the country. To give you quick access to all your accounts with us, we > have generated a Customer Identification Number (Customer ID No.). All > your accounts are linked to this number, and you only need to quote > this number to our Personal Bankers or Tellers for any help you > may require. > Your Customer ID No. is [number elided]. > The Account details are: > Account Number: [number elided] > Primary Account Holder: [name elided] > The Welcome Letter is being sent to you separately by mail. [snip] They sent a real account name, account number and customer ID to a complete stranger on the basis of a new user's registration information, without first validating it in any way. The user in this case had /almost/ got his email address right - only the Top Level Domain was incorrect. On informing the bank of their error they claimed "The information we send across to across e mail is limited hence the possibility of misuse is not possible". The risks are obvious. Doug Winter, CTO, Business Europe, 3 Waterhouse Square, Holborn Bars, 142 Holborn, London EC1N 2NX +44 (0)20 7961 0341 dwinterat_private ------------------------------ Date: Tue, 07 Aug 2001 14:30:12 -0400 From: Sam Garst <samgarstat_private> Subject: Re: Mixing advertising and credit-card activation (Green, RISKS-21.57) In RISKS-21.57 Bob Green <rgreenat_private> discussed a credit-card authorization process that raised some risks. I, too, was confused by a recent credit card activation; with an couple of novel (and risky) twists: My credit card had been compromised. Kudos to the credit card agency, as they called me to confirm a suspicious (and fraudulent) charge. I dutifully called to activate my new card when it arrived. I have CallerID blocked, and I was curious to know how this might be handled. It wasn't, I sailed on through the authorization process. Do they have the means to override CallerID blocking? Or, are they not validating the originating phone number as my home? I promise to call from my office next time, and report back. Just as Bob Green mentioned, I was subjected to a rather long and tedious ad before the authorization process was complete. Ironically, the ad was for one of those credit reporting services, that will send you a consolidated report from all credit agencies, and alert you whenever someone makes a credit check. Well, I hope it was ironic and not targeted advertising for fraud victims. Finally, the prompt at the end of the ad were deeply confusing, just as Bob Green noted. But wait, the confirmation prompt was reversed: "Do you want to buy this service?" <NO> "Are you sure you don't want to buy this service?" <YE...uh, wait, what was the question?> Sam Garst <samgarstat_private> ------------------------------ Date: Tue, 07 Aug 2001 23:27:33 -0700 From: Joel Garry <joel-garryat_private> Subject: Re: Mixing advertising and credit-card activation (Green, RISKS-21.57) >From Pacific Bell web page about caller id http://www.pacbell.com/Products_Services/Residential/ProdInfo_1/1,1973,10-3-,00.html Complete Blocking prevents the transmission of your phone number on all calls you make, except 911 and national 800, 888, and 877 number calls. The risk must be that adhesion contracts (with terms you are stuck with) may define a phrase like "Complete Blocking" with caveats that may unexpectedly negate the phrase. Of course, they are the phone company, they don't have to adhere to any reasonable man or reasonable computer standard. A few days ago, I noticed my business line was in use. Since I wasn't using it, I picked it up and heard telephone technicians talking about line loops and how the "ants were biting the hell out of my arm." So I drove over to where they were installing DSL in the street and told a very surprised tech that if he didn't get off my line, I would make sure his supervisor would bite his ass a lot harder than those ants! Joel Garry, Oracle and Unix Guy http://www.garry.to ------------------------------ Date: Mon, 13 Aug 2001 09:38:30 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "The Internet Security Guidebook", Juanita Ellis/Timothy Speed BKISGFPD.RVW 20010605 "The Internet Security Guidebook", Juanita Ellis/Timothy Speed, 2001, 0-12-237471-1, U$44.95 %A Juanita Ellis %A Timothy Speed tim.speedat_private %C 525 B Street, Suite 1900, San Diego, CA 92101-4495 %D 2001 %G 0-12-237471-1 %I Academic Press %O U$44.95 619-231-0926 800-321-5068 fax: 619-699-6380 %P 320 p. %T "The Internet Security Guidebook: From Planning to Deployment" The introduction outlines some of the basic types of attacks that can happen over the Internet, and seems to concentrate on attacks against machines, rather than people or companies. This emphasis on the technical is odd, since the material provides very few technical details, but does contain more than a little error and confusion. The text of the book doesn't mention a specific target audience, although the jacket notes seem to promote the work to CEOs and other senior executives. Which is odd: the writing level seems more appropriate to the home user. Chapter one is an overview of security planning. Most of the important parts of preparation are included, but the chapter structure and even the figures are very confusing. There are many gaps in the discussion of security reviews, and a number of odd and apparently misplaced items have been inserted. Encryption is covered simplisticly, and the lack of depth in the material becomes a problem in the chapter on network security. After twelve pages that *don't* explain the Internet and OSI (Open Systems Interconnection) models of networking, the text attempts to deal with a number of Internet security tools, most of which rely on encryption and key exchange. There are frequent errors and the sections sometimes even provide contradictory and nonsensical explanations, such as the statement that "unencoded" means both "not encrypted" and "not as plain text." The basic outline of firewalls is better than is provided in most general guides, although the description of circuit- level gateways keeps referring to "stateful inspection" without ever explaining what that is. The long evaluation section is, unfortunately, the usual for this type of book: it does provide most of the right questions to ask, but doesn't give the novice reader much help in analyzing the answers. Authentication is a very important topic in security, and it is too bad that the material on this subject is so confused, and confusing. I find it very difficult to reconcile the statement that there are "very few examples" of biometrics with the existence of a great many fingerprint, palm geometry, iris, voiceprint, and even face readers. The depiction of Kerberos is wrong in some basic aspects, does not address the fundamental problems with the Microsoft version, and does not relate in any way to the very closely associated topic of single sign-on that immediately follows. The discussion of PKI (Public Key Infrastructure) does do well in covering the "build or buy" debate for a certificate authority. Directory issues are not handled particularly well, and there are other errors. (Excuse me? The Internet didn't exist before the mid- 1980s?) The chapter on messaging security is a real grab bag of topics, none of which, with the possible exception of acceptable use, are covered in sufficient depth. (Viruses and trojans get lumped into this chapter, and the commentary is quite sloppy.) The basic outline of risk analysis, including threat, impact, and probability, is good, but the supporting material is not quite standard, and probably not very helpful to the target audience. The chapter also fails to point out the full scope of such an appraisal, as well as the importance of looking at the aggregate risk. On the other hand, the review of policy and procedures hardly seems to address policy creation at all. This is another miscellaneous compendium of vulnerabilities, diving into specifics and missing the bigger picture. The material on incident response is generic, but does point out the foundational concepts. There is little detail, and the text does concentrate on dealing with events by severity, rather than by type. The book closes off with an ordinary presentation on project planning. I would be the first to admit that security can be a dry topic, and a little humour can help to spice up the text. However, I am willing to make an exception in the case of this book. The jokes added to the text do nothing to improve it. They are intrusive, distracting, and do not, in any way, help the reader to understand the topics under discussion. Indeed, the attempts at comedy generally sidetrack the reader from the central issues of the work, and simply confuse any issue under discussion. If this text is aimed at executive management, it definitely needs to be tightened up and reorganized to eliminate duplicated material and ensure the structure and arguments are easier to follow. Many points raised throughout the work are important, but a number of vital issues are not addressed, and the patchwork of writing level and quality of information probably means that this is unsuitable as an only introduction to security. The Internet, in fact, is not really a major concern in this book, although it does get mentioned from time to time. I would have difficulty in suggesting a group that would benefit from this book, although it might serve as an adjunct text to the security planning process, if ideas were being culled from multiple sources. copyright Robert M. Slade, 2001 BKISGFPD.RVW 20010605 rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: Wed, 15 Aug 2001 13:39:14 +0100 From: Cliff Jones <cliff.jonesat_private> Subject: Dependability and "Open Source" development WORKSHOP ON OPEN SOURCE SOFTWARE DEVELOPMENT NEWCASTLE, 25-26 FEBRUARY 2002 Organised by the Dependability of Computer-Based Systems (www.dirc.org.uk) Interdisciplinary Research Collaboration, the focus is on dependability and open source software development. Short abstracts due by 2 Nov 2001, papers later. For further details, see: http://www.dirc.org.uk/events/ossdw_ncl.html and contact Dr. C. Gacek <cristina.gacekat_private>. ------------------------------ Date: Wed, 01 Aug 2001 19:48:44 -0400 From: "Lance J. Hoffman" <hoffmanat_private> Subject: CFP2002: Call for Proposals [CFP has been an extraordinarily valuable conference, bringing together a very diverse group. Strongly recommended. Proposals due 15 Oct 2001. (This CFP CFP has been abridged for RISKS.) PGN] CFP2002: The Twelfth Conference on Computers, Freedom & Privacy Cathedral Hill Hotel, San Francisco, California, USA 16-19 April 2002 http://www.cfp2002.org Lance J. Hoffman, The George Washington University, Washington DC 20052: Professor, Dept. of Computer Science www.cs.seas.gwu.edu (202) 994-4955 and Cyberspace Policy Institute (202) 994-5513 www.cpi.seas.gwu.edu ------------------------------ 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.60 ************************
This archive was generated by hypermail 2b30 : Fri Aug 17 2001 - 12:30:13 PDT