RISKS-LIST: Risks-Forum Digest Wednesday 28 May 2003 Volume 22 : Issue 74 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://catless.ncl.ac.uk/Risks/22.74.html and by anonymous ftp at ftp.sri.com, cd risks . Contents: Soyuz landing problem caused by software? (Steve Bellovin) The "no-fly" list (Steve Bellovin) Scientific American article "Self-Repairing Computers" (Charles Lamb) Microsoft Pulls XP Update (Dave Aronson) Modern Computers, Unsafe at any speed? (Len Spyker) Privacy advocates doubt Pentagon promises on spying (NewsScan) 'Kingpin' cracker arrested in Thailand (NewsScan) Ex-student fined more than $500,000 for stock fraud on Net (NewsScan) Safe-cracking via telephone (Lee Hasiuk) Re: OpenBSD ... protects against buffer-overflow ... (Crispin Cowan, Dag-Erling Smorgrav) Comment on BMW/MSFT failure reported in Risks 22.73 (John Opie) Spam's cure could be worse than the disease (NewsScan) Spam limiting (Harry Hochheiser) Re: more spelling-checker follies? (Anna Shefl) REVIEW: "Protected Internet, Intranet, and Virtual Private Networks", Alexander Moldovyan et al. (Rob Slade) Survivable and Self-Regenerative Systems: workshop (Doug Maughan) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 05 May 2003 21:41:08 -0400 From: Steve Bellovin <smbat_private> Subject: Soyuz landing problem caused by software? In an article by James Oberg -- a well-respected space programanalyst -- MSNBC reports that the cause of the Soyuz module landing far off target was a software glitch. (http://www.msnbc.com/news/909677.asp?cp1=1) To achieve the proper landing profile, the craft is supposed to fly with the top of its heat shield tilted forward, to provide a bit of aerodynamic lift. Steering is done by rotating the capsule -- the center of mass is off-center, whcih means that rotating the Soyuz will steer it. This scheme means that the Soyuz needs to know which way is up. The Soyuz lost track of either its orientation or its position, and switched to a backup mode. In the backup setting, the craft just rotates at a constant speed, which stabilizes the spacecraft, but at the cost of path control. Other suggestions are human error -- perhaps "one of the Americans" hit the backup mode button. The American astronauts deny this. They did know what was going on; however, they had enough confidence in the backup system that they chose to accept the off-target landing rather than try to recover manually. Steve Bellovin, http://www.research.att.com/~smb (me) ------------------------------ Date: Fri, 25 Apr 2003 23:03:58 -0400 From: Steve Bellovin <smbat_private> Subject: The "no-fly" list The 22 Apr 2003 *Wall Street Journal* had a long article on the U.S. "no-fly" list -- a list of about 300 people that the U.S. government regards as too dangerous to allow on airplanes. Apart from anything else, the article discussed the many ways this system is producing false positives and (one would assume) the chance of false negatives. The article is too long to summarize; among the problems cited are the difficulties of transliteration from Arabic (they show five different renderings of one name) and use of computer systems designed for different purposes. For example, some of the systems used hunts for matches based on the first few letters of a surname -- ideal for helping someone check in quickly, but not good for checking against a "no fly" list. Nor are the error recovery processes good; there are some people who will *always* run afoul of this on certain airlines, but they seem incapable of recording that they've checked out particular individuals the previous time. Steve Bellovin, http://www.research.att.com/~smb ------------------------------ Date: Thu, 22 May 2003 17:02:40 -0400 From: Charles Lamb <clambat_private> Subject: Scientific American article "Self-Repairing Computers" There is an article in the June 2003 issue of "Scientific American" titled "Self-Repairing Computers" by Armando Fox and David Patterson. The article seems to me to just be rehash of decades old programming practices such as audit trails, system snapshots, and robust software. These practices were often found in mainframe computer software but seem to have been abandoned when PCs came along. I suspect this is because mainframe computer time was so much more expensive than PC time that it was worth using more wisely. ------------------------------ Date: Wed, 28 May 2003 14:06:19 -0400 From: Dave Aronson <dja2003at_private> Subject: Microsoft pulls XP update Microsoft Corp. said on 27 May 2003 that it has withdrawn a security update for its Windows XP software after discovering that it switched off Internet connections for some of the 600,000 users who downloaded and installed it. Source: Reuters. More details at http://news1.iwon.com/tech/article/id/201872 |technology|05-28-2003%3A%3A00%3A12|reuters.html Yet another RISK of being an "early adopter" -- especially where a company has a "wait for release x.1" reputation.... David J. Aronson, Unemployed Software Engineer near Washington DC http://destined.to/program/ ------------------------------ Date: Sun, 25 May 2003 10:25:02 +0800 From: "Len Spyker" <redmond2at_private> Subject: Modern Computers, Unsafe at any speed? Periodically we see new emphasis placed on the notion that computers need specific hardware support in order to be secure. So it's odd that when a topic like stack buffer overflows gains common awareness we (the computer commumity) can always point to a long ago hardware architecture that solved this problem. It is not like we don't know how to make computers safe. Maybe some of us have buckled to commercial greed, or be unwilling to accept that hardware architecture of 30-50 years ago is still valid today. I do marvel at my new 1 GHz CPU with it's 30+ million transistors, but I gringe that not a single one is dedicated to preventing the stack from running riot over my own data and code. Or if it had any then the OS writers left it disabled. "Look Ma - no hands". I feel that the computer industry and PC users are now at the same point that the American Automotive industry was with Ralph Nader some 30-40 years ago. " Unsafe at any speed". But sadly there is no champion now, no one dares to expose that the PC Emperor has no clothes. The irony is that with proper hardware protection the OS and apps would run faster because all that software now wasting CPU time checking for overflows is no longer needed, and even the most baroque but popular languages could safely co-exist with secure applications. The only possible good effect from this war on terror is that the OS writers and their bosses may be forced to fully use the hardware protection available and the Silicon designers forced to read some history books and re-invent the hardware wheel. To correct the current unsecure PC situation will take a major government action and wether it is done by force of law, at legal gun point or by chucking lots of money at the suppliers to correct their earlier sins and omissions, only time will tell. Len Spyker, 49 Jeanes Rd, Karrinyup, WA Australia +61 8 9245 1771 ------------------------------ Date: Wed, 21 May 2003 09:20:33 -0700 From: "NewsScan" <newsscanat_private> Subject: Privacy advocates doubt Pentagon promises on spying The Pentagon has changed the name of its planned anti-terrorist surveillance systems, but critics say the fundamental program remains the same and would risk violating citizens' privacy if fully implemented. Now renamed the Terrorist Information Awareness program (from Total Information Awareness), the system would broaden government surveillance activities to encompass passport applications, visas, work permits, driver's licenses, car rentals and airline ticket purchases as well as databases including vast amounts of personal information, such as financial, education, medical and housing and identification records. Sen. Ron Wyden (D-Ore.), a major opponent of the TIA, says, "What most Americans don't know is that the laws that protect consumer privacy don't apply when the data gets into government's hands. Lawfully collected information can include anything, medical records, travel, credit card and financial data." Testing of the system is already underway, raising privacy advocates' concerns about "false positives" based on erroneous data. "If TIA is relying on personal information contained in databases to determine whether someone is a suspect, what recourse does that person have whose information has been entered incorrectly?" says a spokeswoman for the Free Congress Foundation, which estimates that an error rate as small as .10% could result in more than 30,000 Americans wrongly being investigated as terrorists. [AP 20 May 2003;NewsScan Daily, 21 May 2003] http://apnews.excite.com/article/20030520/D7R5BBUG0.html ------------------------------ Date: Fri, 23 May 2003 08:29:25 -0700 From: "NewsScan" <newsscanat_private> Subject: 'Kingpin' cracker arrested in Thailand Thai officials arrested a Ukrainian man described by a U.S. embassy spokesman as a "kingpin" of international computer crime. Maksym Vysochansky, 25, is accused of selling counterfeit versions of flagship software products by major companies such as Microsoft and Adobe. Vysochansky, who used a number of aliases, is thought to have been involved in fraudulent schemes worth up to $1 billion. "This guy was on the U.S. Secret Service's 10 most wanted list. He's definitely a big shot," said the embassy official. Authorities allege that Vysochansky also built a "back door" into the software he sold that allowed him to hack into buyers' financial and credit card information. "It was a very complicated and sophisticated fraudulent scheme," said the embassy official. Vysochansky likely will be extradited to the U.S. where he'll face charges of copyright violations, trafficking in counterfeit goods and money-laundering. [News24.com 22 May 2003; NewsScan Daily, 23 May 2003] http://www.news24.com/News24/Technology/News/0,,2-13-1443_1362931,00.html ------------------------------ Date: Thu, 22 May 2003 08:02:27 -0700 From: "NewsScan" <newsscanat_private> Subject: Ex-student fined more than $500,000 for stock fraud on Net Former UCLA student Refael Shaoulian has been ordered by a federal judge to pay $534,000 in fines for using university computers and false identities to post intentionally incorrect about stocks so that he could profit from the buying and selling sprees he caused. The civil suit was brought by the Securities and Exchange Commission. [APOnline/*USA Today*, 22 May 2003; NewsScan Daily, 22 May 2003] http://www.usatoday.com/tech/techinvestor/2003-05-21-bruin-amuck_x.htm ------------------------------ Date: Thu, 22 May 2003 10:46:50 -0400 From: Lee Hasiuk <lhasiukat_private> Subject: Safe-cracking via telephone My elderly aunt owns a large, heavy safe whose combination was lost when her husband passed away. She asked me if I could help her open it. I called the manufacturer and found that they offer a service where they will give you the combination for $35, which may be charged to any major credit card. All you need to provide is the safe's serial number, which is embossed on a plate in the center of the combination dial. They have no way of checking if you are the owner of the safe, and indeed I wasn't. The entire transaction took place over the phone. I've yet to try the combination they read to me, and the company representative noted that it is possible for the owner to change it. I wonder how many thieves have used this safe cracking technique with a pay phone and a stolen or invented credit card number? [Although this is not computer related, it is symptomatic of back doors in many security systems. The manufacturer is probably smart enough to first verify that the credit card is legitimate, although it could have belonged to the owner of the house that was being burgled. However, if we assume that the owner had changed the default delivered combination, then this supposedly beneficial service would not help -- unless there was an unchangeable master combination IN ADDITION TO the user-set one. PGN] ------------------------------ Date: Sat, 10 May 2003 19:19:12 -0700 From: Crispin Cowan <crispinat_private> Subject: Re: OpenBSD ... protects against buffer-overflow ... (Ardley, R 22.72) >What is not so apparent is why technology that was developed and operating >over 30 years ago is just being re-invented in software. Because what was developed in operating systems over 30 years ago was use of heavily segmented architectures. Over 20 years ago (the Intel 432) it was discovered (the hard way) that such architectures run horribly slowly compared to RISC architectures. Since the debacle of the 432, even CISC processors such as the x86 have migrated towards RISC style instruction processing. What OpenBSD is implementing is a variety of software schemes to make up for the lack of hardware protection for array bounds. Some of these schemes (Openwall's <http://openwall.com/> non-executable stack) are performance neutral: just mark the stack segment non-executable. Some (ProPolice, a re-implementation of StackGuard <http://immunix.org/stackguard.html>) are very cheap <http://immunix.org/StackGuard/performance.html>, much cheaper than enforcing memory safety in hardware. Unfortunately, one of these enhancements (W^X) is not so cheap. Here, they try to make all writable pages non-executable, and vice versa. This is problematic on the x86 architecture because waaaay back in the day, Intel decided that memory pages did not need separate Read and Execute permission bits in the TLB (only segments have separate R and X bits, not pages). The W^X hack has to do a lot of work with TLB faults to compensate for this simple omission. >The Burroughs 6700 implemented a hardware solution to the problem by >assigning 3 bits of very 51 bit memory location to the type of data >contained. The 432 did something similar, and the performance penalty was astronomical. For a survey of buffer overflow attacks and defenses, check out these papers: "Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade". Crispin Cowan, Perry Wagle, Calton Pu, Steve Beattie, and Jonathan Walpole. DARPA Information Survivability Conference and Expo (DISCEX) <http://schafercorp-ballston.com/discex/>, Hilton Head Island SC, January 2000. Also presented as an invited talk at SANS 2000 <http://www.sans.org/sans2000/sans2000.htm>, Orlando FL, March 2000. PDF <http://immunix.com/%7Ecrispin/discex00.pdf>. "Software Security for Open Source Systems". Crispin Cowan. IEEE Security & Privacy Magazine <http://www.computer.org/security/>, February 2003, Volume 1, Number 1 <http://www.computer.org/security/sp2003/j1toc.htm?SMSESSION=NO>, pages 35-48. PDF <http://wirex.com/%7Ecrispin/opensource_security_survey.pdf>. Crispin Cowan, Ph.D., Chief Scientist, Immunix http://immunix.com http://immunix.com/~crispin/ http://www.immunix.com/shop/ ------------------------------ Date: Wed, 21 May 2003 10:27:23 +0200 From: Dag-Erling Smorgrav <desat_private> Subject: Re: OpenBSD ... protects against buffer-overflow ... (Ardley, R 22.72) I was rather disappointed to see that the attached e-mail, which I sent as a followup to Jeremy Ardley's comment on "OpenBSD release protects against buffer-overflow attacks" in 22.72, was not included in 22.73. Jeremy Ardley made at least two serious factual errors: misidentifying the FreeBSD project (of which I am a member) with the OpenBSD project [*], and making incorrect assumptions (or wild guesses if you prefer) about Intel's IA32 architecture on the basis of the original article. My followup was intended to correct those errors and give RISKS readers a somewhat better understanding of the matter. I was even more disappointed to see that 22.73 contained a further followup by Mike Albaugh which not only builds on Jeremy Ardley's incorrect assumptions about the IA32 architecture but furthermore does not (in my eyes) contain any useful information about any kind of RISK. Dag-Erling Smorgrav - desat_private [* This error has been corrected in the SRI archive copy, and will be picked up in the risks.org Newcastle archive. PGN] ------------------------------ Date: Wed, 21 May 2003 08:54:04 +0200 From: john.opieat_private Subject: Comment on BMW/MSFT failure reported in Risks 22.73 As someone who has professional ties to BMW (I work with Germany's largest private economic research group, which among other things provides the Quandt family - which own 48.1% of BMW - with investment advice) as well as having learned to drive on one (2002) and just order my third 5 (a 525td after a 530d and a 528i) series as a company car, there are a couple of points I'd like to make. I might be a tad biased 'cause I enjoy driving these cars so much (the 528i handled 240kmh with ease, but for fuel economy I will accept the top speed of 220 in the 525td...). First, the 5 series does not use any MSFT products to run the car's systems. There are two Motorola PowerPC chips in the 5 series, one which runs the engine and the other takes care of the on-board electronics, which in turn run embedded systems that react to environmental changes (air conditioning) or to user changes (power windows, etc.). The on-board navigation system (getting one in the new car...) also uses an embedded, proprietary system. Second, BMW 5-series cars include as a standard safety feature a mechanical interlock. If there is an accident or if there is an interruption of power lasting more than a few seconds, this interlock unlocks the doors in an event of an accident (determined by motion sensors and/or inflation of airbags), so that in case of locked doors and a driver accident which prevents the driver from unlocking the doors, rear-seat passengers are not trapped. They do not open the doors (there is an option for power-assisted door closing and opening...) but this does ensure that in case of accident, no one gets trapped. As a matter of fact, if there is an accident of enough severity to cause a set level of deformation in the motor cell, a small explosive charge will separate the battery of the car from the electrical system, preventing any electrical-caused fires in the wake of an accident. Third, the new 7-series uses a version of WinCE for its I-drive. The new 5-series (with the Dr. Spock eyebrow blinkers) also uses a modified version of this as well. Both are heavily modified, for which BMW pays for. There is no reference to MSFT in BMW's advertising for the 7 series or the new 5 (at least I haven't seen any...) But more fundamentally, and here is where risks come in, what should the default behavior of an armored limousine be? If I were to design such a system, the fundamental importance is to protect the passengers. If it became known that such an armored car would pop its locks when the on-board system would fail, then a terrorist/assassin/kidnapper could exploit this in order to gain access to the passengers, either by an EMP trap or some other manner. Hence if the system failed on the BMW in question - which was most likely the 7-series armored limousine, which is the only armored limousine that BMW supplies (I think only in the 745 S and the 760 S versions with 4.5 V-8 and 6 liter V-12 engines with more horsepower than anyone else really needs) and which would be appropriate for the politician involved - it defaulted to the correct setup: protect the passengers. John F. Opie, Feri Research GmbH, Haus am Park, Rathausplatz 8-10 D-61348 Bad Homburg von der Hoehe +49 (0)6172 916 3216 www.feri-research.com ------------------------------ Date: Tue, 27 May 2003 11:10:30 -0700 From: "NewsScan" <newsscanat_private> Subject: Spam's cure could be worse than the disease CNet columnist Declan McCullagh worries that the proliferation of spam-blocking software incorporating challenge-response technology could lead to the death of e-mail. Challenge-response systems require the human sending a message to perform a simple task such as clicking on a link or typing a special password to get past the barrier. The problem is, says McCullagh, that many challenge-response systems are poorly designed, and could causes big headaches for administrators of legitimate e-mail newsletters (such as NewsScan Daily) that go out to large numbers of people. "Big corporations may be able to afford to hire someone to sit in front of a computer and spend all day proving they're not a spam bot, but nonprofit groups, individuals and smaller companies probably can't," says McCullagh. Earthlink has already announced its intentions to make a challenge-response system available to subscribers by the end of May, and other ISPs may follow suit -- a scenario that has veteran list operators concerned. Dave Farber, a computer scientist at the University of Pennsylvania who runs the "interesting people" list, says: "If I start getting a flood of challenges from Earthlink IPers that require my response I will most likely declare them spam and you will stop receiving IP mail. I fully expect this to be the case for almost all the legitimate mailing lists you are on and count on." Meanwhile, editors at the popular Macintosh newsletter TidBits, have told readers: "Be warned that we will not answer any challenges generated in response to our mailing list postings. Thus, if you're using a challenge-response system and not receiving TidBits, you'll need to figure that out on your own." [CNet News.com 27 May 2003; NewsScan Daily, 27 May 2003] http://news.com.com/2010-1071_3-1009745.html?tag=fd_nc_1 ------------------------------ Date: Tue, 27 May 2003 09:54:08 -0400 From: Harry Hochheiser <hshat_private> Subject: Spam limiting Here's one that's either a risk or the most effective approach that I've yet seen for reducing/eliminating spam: simply refuse to accept any mail, even for your own host. [Domain name and user changed to protect the innocent:] The original message was received at Mon, 26 May 2003 12:49:34 -0400 (EDT) from localhost [127.0.0.1] ----- The following addresses had permanent fatal errors ----- <userat_private> (reason: 550 5.7.1 <userat_private>... Relaying denied) ----- Transcript of session follows ----- ... while talking to smtp2.domain.com: >>> RCPT To:<userat_private> <<< 550 5.7.1 <userat_private>... Relaying denied 550 5.1.1 <userat_private>... User unknown ------------------------------ Date: Wed, 21 May 2003 09:55:30 GMT From: "Anna Shefl" <annaat_private> Subject: Re: more spelling-checker follies? (Hopkins, RISKS-22.73) > For three minutes, an AP story posted on *The New York Times* Web site about > Justice Clarence Thomas referred to his predecessor as "Turgid Marshall." MS has also made the historical black leader Marcus Gravy famous. Given how many names are not spelling-checker-friendly, I'm all the more surprised at how many people let spelling-checkers run on auto-pilot. We'll have to wait and see what risks, other than embarrassment, could occur as a consequence. I searched the Web for "Osaka bin Laden". Results 1 - 40 of about 70. ------------------------------ Date: Tue, 20 May 2003 14:00:51 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Protected Internet, Intranet, and Virtual Private Networks", Alexander Moldovyan et al. BKPIIVPN.RVW 20030404 "Protected Internet, Intranet, and Virtual Private Networks", Alexander Moldovyan et al., 2003, 1-931769-14-1, U$44.95/C$67.95 %A Alexander Moldovyan %A Nick Moldovyan %A Doug Summerville %A Vladimir Zima %C 295 East Swedesford Road, PMB #285, Wayne, PA 19087 %D 2003 %G 1-931769-14-1 %I A-LIST LLC %O U$44.95/C$67.95 fax 702-977-5377 mailat_private %O http://www.amazon.com/exec/obidos/ASIN/1931769141/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/1931769141/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/1931769141/robsladesin03-20 %P 310 p. %T "Protected Internet, Intranet, and Virtual Private Networks" Despite the slim size, it is still disconcerting to find that there are only three chapters in this book. Chapter one provides an introduction to client/server networking, while implying that the technology is *not* hierarchical. Basic networking concepts are covered, but the writing has an academic pomposity without the requisite rigour. Figures and illustrations are not only unhelpful, but may actually confuse issues, and typographical and grammatical errors abound. Lists of idiosyncratic, and very odd, attack taxonomies are given in chapter two. Items like "attacks on the security policy and administration procedures" aren't really explained, while "attacks on permanent components of the security system" seems to be limited to cryptanalysis. Chapter three has some descriptions of virtual private networks, tunnelling, IPSec, and key management protocols. The writing is hard to understand, there does not seem to be any logical organization to the material, and the mistakes in the content do not inspire any confidence in the reliability of any part of this text. All the topics touched on here are covered much more effectively in other works, but the topics are so random that it is difficult to make specific recommendations. For those interested in the basics of data communications I would suggest Tanenbaum (cf. BKCMPNWK.RVW), while "Building Linux Virtual Private Networks (VPNs)" (cf. BKBLVPNS.RVW) is a good introduction to VPNs themselves. copyright Robert M. Slade, 2003 BKPIIVPN.RVW 20030404 rsladeat_private rsladeat_private sladeat_private p1at_private ------------------------------ Date: Thu, 22 May 2003 02:34:26 -0400 From: Doug Maughan <dmaughanat_private> Subject: Survivable and Self-Regenerative Systems: workshop 2003 ACM Workshop on Survivable and Self-Regenerative Systems In conjunction with 2003 ACM International Conference on Computer and Communications Security (CCS-10) 31 Oct 2003 George W. Johnson Center at George Mason University, Fairfax, VA, USA Call for papers One of the key areas of current research in the fields of computer and communication security is survivability, where the objective is to survive rather than to prevent or detect intrusions. Survivability research has explored the intersection of Fault Tolerance and Security, and recently, the notion of using self-regenerative capabilities in the context of survivability has generated a significant interest in the community. This workshop aims to provide a venue for scholars in this area to exchange ideas and to explore research issues involving survivable and self-regenerative systems. Papers offering original research contributions in any aspect of this emerging field are solicited for submission to this workshop. Topics of interest include, but are not limited to, the following: * Survivable Systems & Networks * Self-Regenerative Systems & Networks * Use of Self-Healing Techniques in Surviving Attacks * Security vs. Fault Tolerance in building survivable and self-regenerative systems * Use of Self-Stabilization Techniques in Surviving Attacks * Role of Formal Models in Survivable and Self-Regenerative Systems * Self-Adapting and Self-Securing Systems and Techniques * Measuring and Quantifying Survivability and Self-Regeneration * Role of Redundancy, Diversity, Unpredictability and Deception in Survivable and Self-Regenerative Systems * Impact of Detection Accuracy and Latency on Survivability and Self-Regeneration Papers due: July 9, 2003 Link to the workshop can be found from the CCS webpage at: http://www.acm.org/sigs/sigsac/ccs/CCS2003/ ------------------------------ Date: 29 Mar 2002 (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>. => 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 21" for volume 21] 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 22.74 ************************
This archive was generated by hypermail 2b30 : Wed May 28 2003 - 16:24:22 PDT