SPAM: -------------------- Start SpamAssassin results ---------------------- SPAM: This mail is probably spam. The original message has been altered SPAM: so you can recognise or block similar unwanted mail in future. SPAM: See http://spamassassin.org/tag/ for more details. SPAM: SPAM: Content analysis details: (7 hits, 5 required) SPAM: Hit! (1 point) BODY: Contains 'Dear Somebody' SPAM: Hit! (3.73 points) BODY: Talks about social security numbers SPAM: Hit! (1.27 points) BODY: Includes a link to send a mail with a subject SPAM: Hit! (1 point) Received via a relay in inputs.orbz.org SPAM: [RBL check: found 74.15.107.130.inputs.orbz.org.,] SPAM: [type: 127.0.0.1] SPAM: SPAM: -------------------- End of SpamAssassin results --------------------- RISKS-LIST: Risks-Forum Digest Saturday 23 November 2002 Volume 22 : Issue 39 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/22.39.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: More on the Breeders Cup Pick-6 fix (Danny Lawrence) Crackers steal 52,000 university passwords (Monty Solomon) Slashdot suggests X-Box gamezone open to DoS (George Michaelson) Laptop injures lap (Gene Spafford) "AccuVote" comes to Boston -- argh! (Jonathan Kamens) NSF FastLane promotes excessive sharing? (Lee Rudolph) Interesting new spammer trick (Jonathan Kamens) Bad assumption in automated toll collection (Andrew Goodman-Jones) REVIEW: "Security Engineering", Ross Anderson (Rob Slade) REVIEW: "Network Intrusion Detection", Northcutt/Novak/McLachlan (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Thu, 21 Nov 2002 13:07:40 -0500 From: Danny Lawrence <Dannyat_private> Subject: More on the Breeders Cup Pick-6 fix Unsurprisingly, the *Daily Racing Form* is doing a better job of covering the scam than the general media, here are a couple of references: The "3rd member" of the party (whose account was used to make the "test runs" of the fix prior to the Breeders Cup) was already under investigation by the OTB http://www.drf.com/members/web_news.generate_article_html?p_news_head=42153&p_arc=1 The fired Autotote employee pleads guilty to one count of wire fraud: http://www.drf.com/news/article/42458.html Also it seems that he (and his 2 confederates) were cashing unclaimed tickets that he found in the Autotote system. As in many cases of this type it looks like greed was their undoing. Here's a link to another betting scam from the 1970's: http://www.drf.com/members/web_news.generate_article_html?p_news_head=42077&p_arc=1 I think that the fact that the OTB was already looking into the 3rd person's suspect account indicates that the checks were there, that they didn't act sooner indicates prudence on their part. The worst thing (from a creditability standpoint) that a betting organization can do is withhold a payout and accuse a player of cheating, only to be proved wrong. --Danny Lawrence, Tiassa Technologies Inc. http://www.tiassatech.com/domino/saga.nsf/story/uk ------------------------------ Date: Wed, 20 Nov 2002 02:05:07 -0500 From: Monty Solomon <montyat_private> Subject: Crackers steal 52,000 university passwords The University of Oslo had to change the passwords of 52,000 users and reinstall software on dozens of computers after crackers managed to infiltrate the network and extract the institution's central password file. http://www.aftenposten.no/english/local/article.jhtml?articleID=437439 ------------------------------ Date: Fri, 22 Nov 2002 10:59:30 +1000 (EST) From: George Michaelson <ggmat_private> Subject: Slashdot suggests X-Box gamezone open to DoS ***UNPROVEN RISK*** gamers with modded XBoxes are banned by Microsoft. banning means they can be recognized. recognition requires a unique ID, the pozited unique ID is serial no and MAC address. Xbox hackers allege that by changing serial number and MAC address and turning off their modchip they succeeded in registering in Xbox gamezone. Therefore, since integers between 0 and the size of the register in the chip are a finite resource, they have 'stolen' some unsold/unregistered machines ID. Therefore there is an identity theft risk. And there is a DoS game here: walk the space, with your modded box, and lock out the entire XBox userspace from the gamezone Yes, its a large numberfield, maybe a 128-bit sequence space. But I bet you can walk it for fun and profit... >From SlashDot: >Changing serial numbers and macs... >by AtariDatacenter on 11:11 AM November 22nd, 2002 (Score:5, Insightful) >(#4727735) >(User #31657 Info) mailto:jmccormat_private?Subject=SlashdotResponse Neutral > > > So they said they changed their serial number *and* MAC address to > get back on. This is interesting and points back to something > someone said in a previous thread. All you need to do is to make > a program to burn through serial number space and get them marked > invalid, and you've got a DoS of entertaining proportions. ------------------------------ Date: Fri, 22 Nov 2002 18:23:57 -0500 From: Gene Spafford <spafat_private> Subject: Laptop injures lap There are all kinds of new risks with higher-power processors and metal cases: http://www.cnn.com/2002/WORLD/europe/11/22/health.laptop.reut/index.html [Alo noted by Mark Brader. PGN] ------------------------------ Date: Thu, 14 Nov 2002 22:06:38 -0500 From: Jonathan Kamens <jikat_private> Subject: "AccuVote" comes to Boston -- argh! [A letter I'm about to send to the Massachusetts Secretary of State and the City of Boston's Election Department:] Dear Sirs, I was dismayed to learn recently that the City of Boston has decided to replace its lever-activated voting booths with Diebold AccuVote-OS machines, and indeed has already purchased the Diebold machines. As you may know, with the Diebold machines you mark your votes by coloring in circles on a paper ballot, then you feed the ballot through the machine and into a ballot box. After you feed your vote through the machine, a count of successful votes displayed by an LED on the front of the machine is incremented. I asked the volunteer demonstrating the machine to me, "But how do I know that the machine recorded my vote correctly?" In response, she told me that since the number was incremented, my vote was counted. I didn't even try to make her understand that since a ballot could have multiple races on it, and since I could abstain from any of them by not filling in any of the circles for that race, there was no way for me to distinguish between the machine correctly registering all the votes I recorded and the machine registering some of them and missing some and treating them as abstentions. Not to mention the possibility that the machine might register my votes wrong, rather than just register some abstentions where I actually voted. It's certainly a good thing that this voting machine uses a paper ballot. Such a human-readable, physical record of each vote is an essential part of any reliable voting system, electronic or otherwise. However, without explicit acknowledgment from the machine to the voter of which votes were and were not registered, and a chance for the voter to correct any errors or omissions revealed by that acknowledgment, the functionality provided by this machine is simply not adequate for reliable, accurate voting. Furthermore, I cannot help but wonder what happens if the machine says that it didn't successfully register my vote, if the back of the machine feeds directly into a ballot box as the volunteers at my polling place led me to believe it would. Presumably the ballot box is locked, so they can't remove my first ballot. Do I get to try again? And what if there is then a recount of the paper ballots, and my first ballot is legible the during the recount -- I got to vote twice! In short, this technology is simply not acceptable. I am deeply disturbed that the City of Boston has chosen to ignore the reams of scholarly evidence of this fact and went ahead with the purchase of simply inadequate voting technology. If you are unfamiliar with all the evidence of why most electronic voting machines are inadequate and of how electronic voting might be done properly, a good place to start researching it is at the Web site of Rebecca Mercuri, "http://www.notablesoftware.com/evote.html". Thank you for your time. Sincerely, Jonathan Kamens ------------------------------ Date: 12 Nov 2002 14:00:54 -0500 From: lrudolphat_private (Lee Rudolph) Subject: NSF FastLane promotes excessive sharing? I'm in the middle of preparing a grant proposal for the National Science Foundation, using FastLane, NSF's (now mandatory) online system for proposal preparation, submission, reviewing, etc. For the first time in my grant-writing life, I'm going to have "Co-PIs" (co-Principal Investigators; I am the PI on this proposal). Each Co-PI has to be able to log in to access and modify the proposal; (Co)-PIs' names must be entered on the "Cover Sheet" form, and that form states that "Only Co-PIs entered here will be available on other forms in this proposal." How must they be entered? "To add Co-PIs, enter the SSNs of the Co-PIs and then save the remainder of the cover sheet by clicking on the "OK" button at the bottom of this screen." In other words (as I have confirmed with a phonecall to the FastLane help desk), *either* my Co-PIs have to give me their Social Security numbers so that I can enter them on this form (and thereafter they can log in by themselves), *or* I have to give my Co-PIs my FastLane password (and my SSN, that being [unfortunately] required as well as the password to log in) so that they can log in as me and enter their own SSNs (and thereafter log in by, but not necessarily *as*, themselves). Of course, there's a third choice, the one I will actually make: I can walk over to each Co-PI's office in turn, log in to FastLane on that Co-PI's computer, and let him or her enter his or her SSN. That's easy enough; we're all working at the same university. However, if we were at several universities several hundred miles apart, using FastLane to *facilitate collaboration* among distant colleagues (one of its purported reasons for being), this third choice would not be quite so practical. The RISK is left to the reader. ------------------------------ Date: Thu, 14 Nov 2002 09:56:17 -0500 From: Jonathan Kamens <jikat_private> Subject: Interesting new spammer trick Since many of you are interested in the topic of E-mail spam, e.g., the techniques used by the spammers to evade filtering and the techniques used by everybody else to try to outsmart them, I thought you might be interested in the following new spammer trick which I first saw on October 17 and have seen numerous times since then. I use a home-grown script to analyze the "Received:" headers of the spam that I receive, determine the appropriate sites to whom to complain, and generate the complaint messages. Spammers figured out quite a while ago to insert forged Received: headers in their messages, but they're usually pretty easy to weed out, e.g., they refer to nonexistent hosts, they list bogus envelope recipients, they have bogus dates, the destination host of one Received: header doesn't match the sender host of the next one in the chain, etc. However, at least one spammer has figured out how to forge a Received: header which more convincing than any I've seen. Here are some of the headers of a spam message I received on October 17: Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by jik.kamens.brookline.ma.us (8.12.5/8.12.5) with ESMTP id g9HBd2aP009915 for <jikat_private>; Thu, 17 Oct 2002 07:39:02 -0400 Received: from 146-153-179-208.pajo.com (146-153-179-208.pajo.com [208.179.153.146] (may be forged)) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id HAA12722 for <jikat_private>; Thu, 17 Oct 2002 07:39:01 -0400 (EDT) Received: from 13217 (20458 [53.86.86.54]) by 6432 (8.12.1/8.12.1) with ESMTP id 27244 for <jikat_private>; Thu, 17 Oct 2002 04:39:00 -0700 From: "Consult" <wizard_21at_private> To: "jikat_private" <jikat_private> Subject: Компьютеры и комплектующие по САМЫМ низким ценам. Date: Thu, 17 Oct 2002 04:39:00 -0700 Message-ID: <811325562@mlnCplw1hgx> Note the last Received header. Both the date and the envelope recipient listed in it are correct, and the rest of the header is pretty much formatted correctly; the only tip-off that something strange is going on is the numeric host names. But whoever is doing this got a little smarter pretty quickly. Here's the last Received: header from a spam message I receive on November 6: Received: from delphi.com (mailexcite.com [85.34.182.181]) by aol.com (8.11.6/8.11.6) with ESMTP id 9874 for <jikat_private>; Wed, 6 Nov 2002 09:37:38 +0000 Much better, eh? I've seen various incarnations of this since then with data that seems at first glance to be correct but does not withstand closer inspection. Note that you can't use a simple regular expression match to filter out all messages with headers in this format, because this is a valid Received: header format and I've received real non-spam messages that use it (albeit with data that isn't bogus). They're getting smarter. I just hope by bogofilter database can keep up with them :-). ------------------------------ Date: Thu, 14 Nov 2002 17:09:47 +1100 From: "Andrew Goodman-Jones" <goodieat_private> Subject: Bad assumption in automated toll collection eTags are (optionally) used in Sydney for automated highway toll collection. [risk #1 - well known - loss of privacy] Background: If the tag does not read electronically, then your licence plate is photographed. Before sending out an infringement notice, they lookup your licence plate on the database of eTag account holders. In Sydney we have many different types and colours of licence plates (for fashion reasons) and the type of plate forms part of the unique key. [risk #2 - makes identity harder] Motorcyclists are not allowed to have eTags because they haven't found a secure way to attach them to motorcycles. My friend Robyn had this experience: I have an eTag for my car which I have used on my bike on a number of occasions. Once it didn't work when I used it on my bike so I thought rather than wait to get a fine I'd ring them. Although they did tell me I should not be using it on my bike they said it didn't matter because it had come up as a misread on my account and that they had just automatically charge my account anyway. The interesting thing is that I had not told them that I have a bike!!! So how did they know to charge it to my account ??? Well, the number plate [licence plate] on my car is exactly the same as the number plate on my bike (car has black & white plate with 2 letters & 3 numbers the same as the bike plate but its yellow). So basically if you have a number plate on your bike that is the same as a car with an eTag you can go through the express lane and it will just get charged to someone else's account. (A bit of a worry if you're the account holder.) Robyn [The main risk, #3, their licence plate database apparently does not seem to include the colour of the plate in the field.] [Robbin' Robyn to Pay Pal? That's Round-Robyn. PGN] ------------------------------ Date: Mon, 18 Nov 2002 08:14:55 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Security Engineering", Ross Anderson BKSECENG.RVW 20021015 "Security Engineering", Ross Anderson, 2001, 0-471-38922-6, U$65.00 %A Ross Anderson ross.andersonat_private rja14at_private %C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8 %D 2001 %G 0-471-38922-6 %I John Wiley & Sons, Inc. %O U$65.00 416-236-4433 fax: 416-236-4448 %P 612 p. %T "Security Engineering: A Guide to Building Dependable Distributed Systems" The preface states that this book is intended as a text for self-study or for a one term course, a reference for professionals, an introduction to the underlying concepts, and an original scientific contribution in terms of the foundational principles for security engineering. A very tall order to promise, but one which, for once, seems to have been fulfilled. I have often been asked, in regard to these reviews, whether there are, in fact, any books that I like. Well, I like this one. If you are involved with security and you haven't read it, you should. Part one deals with the basic concepts of engineering and security. Chapter one presents four example situations of security needs. Protocols are not limited to the precise but limited structures computer people are familiar with. A set of more conceptual, but more formal, authentication problems and protocols are advanced in chapter two. It is unlikely that the models presented exhaust the field, but some thought indicates that they are applicable to a wide variety of applications. (Anderson's writing is clear enough, but he does betray a taste for symbolic logic that might limit the audience for the book. Still, perseverence on the part of the reader will be amply rewarded.) Much the usual thoughts and advice on passwords is issued in chapter three, although the research is better documented, and some additional research (passphrase generated passwords are as secure as randomly assigned ones, and as memorable as naively chosen ones) is presented. It is strange not to see any mention of the work factor of passwords overall. Chapter four reviews access control, but primarily from the perspective of system and hardware internals. Cryptography, in chapter five, is covered reliably and well, although Anderson does not work overly hard to make the material easy to follow. The problems of distributed systems are examined; in terms of concurrency, failure resistance, and naming; in chapter six. Part two uses a number of applications of secure systems to introduce particular concepts or technologies. Chapter seven discusses multi- level security, which encompasses most of the formal security models such as Bell-LaPadula. Medical (and census) databases are used, in chapter eight, as examples of multilateral, or compartmented, security: the need to deal with information of equal sensitivity, but restricted to different groups. There is good discussion of inference and aggregation problems. Integrity controls, particularly related to the banking system and fraud, are presented in chapter nine, although the material is long on anecdotes, and contains weaker analysis than the preceding text. Chapter ten reviews monitoring systems, of both monitoring and metering types. In regard to nuclear command and control systems, chapter eleven examines the tension between availability (the ability to fire a missile) and confidentiality (or authentication: making sure nobody else does). Various aspects of the technology for security printing and seals is dealt with in chapter twelve. Biometrics, in chapter thirteen, gets a good, but fairly standard, treatment. Chapter fourteen delves into tamper-resistance in cryptographic gear and smartcards. The TEMPEST and Teapot (no, I'm not kidding) projects on emission security are reviewed in chapter fifteen. There is good coverage of the basics of traditional electronic warfare in chapter sixteen, although the material on information warfare is not as thorough. Chapter seventeen looks at telecommunications system security, with some material on phone phreaking and lots on cellular encryption. Network attack and defense, in chapter eighteen, is less focussed than other chapters, and adds malware. (There is an odd, and unexplained, assertion that malware would formerly have merited a full chapter: In correspondence, Anderson has said that the new email viruses show less diversity than the old DOS versions. I disagree. But then, I would, wouldn't I? :-) The relation of types of antiviral and intrusion detection systems is good. Chapter nineteen, on protecting e-commerce systems, has good information but mixed in a bit of a grab bag: e-commerce is always a bit of a fuzzy topic. There is solid coverage of recent controversies in regard to copyright and privacy protection, in chapter twenty. Part three turns to politics, management, and assurance. Chapter twenty one has a fascinating discussion of major issues in public policy. Management issues, in chapter twenty two, are presented in an interesting but generic manner. The discussion of system evaluation and assurance asks the usual question of how we know our systems are secure. In a sense, though, the subtitle of the book is wrong: much of the material points out how *not* to build dependable systems, and chapter twenty three is a bit disheartening. The conclusion, in chapter twenty four, is that we need more engineers and engineering. Although the material is presented in a very formal way, the writing is usually quite readable, and the exceptional stilted passages are still accessible to the determined reader. On occasion, one could hope for additional explanations of some items that are mentioned briefly and passed over, but, by and large, one has to agree with Bruce Schneier's assessment, reprinted on the book jacket, that this is one of the most comprehensive works on security concepts that is available. The constant emphasis on how security protections have failed can be depressing, but the examination of the errors of others does provide the basis for better designs in the future. copyright Robert M. Slade, 2002 BKSECENG.RVW 20021015 rsladeat_private rsladeat_private sladeat_private p1at_private ------------------------------ Date: Fri, 15 Nov 2002 07:44:13 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Network Intrusion Detection", Northcutt/Novak/McLachlan BKNTINDT.RVW 20021009 "Network Intrusion Detection", Stephen Northcutt/Judy Novak/Donald McLachlan, 2001, 0-7357-1008-2, U$45.00/C$67.95/UK#34.99 %A Stephen Northcutt stephenat_private snorthcuttat_private %A Judy Novak %A Donald McLachlan don_mclachlanat_private %C 201 W. 103rd Street, Indianapolis, IN 46290 %D 2001 %G 0-7357-1008-2 %I Macmillan Computer Publishing (MCP)/New Riders %O U$45.00/C$67.95/UK#34.99 800-858-7674 http://www.newriders.com %P 430 p. %T "Network Intrusion Detection: An Analyst's Handbook, Second Ed." The introduction for the first edition of this work was a bit confusing. The front matter for the second edition is much more so. The only item listed in the table of contents is the introduction, but, while still stating that the book is intended as a training aid and reference for intrusion detection analysts, it is much the smallest item of the many at the beginning of the book. There is a longish, and not very clear, history of the "shadow" program. In addition, there is a preface, which meanders around presenting opinions about various aspects of the Internet and security. It does finally provide a rather interesting definition of intrusion detection; the purpose is to identify threats and make sure the network is hardened against them; but does not make clear what the book is for, or how it approaches the subject. Chapter one is a basic overview of TCP/IP. The material is reasonable, albeit limited, but not exemplary. TCPdump is examined before TCP itself, in chapter two. Again, the content is informative, but there are definite gaps. Fragmentation uses, issues, and patterns in TCPdump are presented in chapter three. Chapter four does provide some idea of the use of ICMP (Internet Control Message Protocol), but not a comprehensive or clear one, and not in the stated introduction. The coverage of ICMP attacks is neither particularly lucid nor particularly complete. It does, however, furnish some convincing arguments for the use of stateful inspection. Chapter five presents a few "normal" transactions that you might see in network traffic, and some that might indicate some type of attack. The material is interesting, but is not displayed in a structure that would make it useful to the reader. DNS (Domain Name Service) is explained in some detail in chapter six, although the attack and exploit coverage is terse. In chapter seven (chapter one, from the first edition), we are given some details of the TCP hijacking attack Kevin Mitnick launched against computers used by Tsutomu Shimomura. In fact we are given rather a lot of details, and not a little C code, much of which is simply thrown out at us. The experienced UNIX network analyst and C programmer will, of course, have no difficulty with the material, and any reasonably experienced computer user will likely be able to find references in order to work through the real implications of the text. Late in the chapter there is a promise of explaining how to detect such an intrusion with two different systems: this promise is not fulfilled. The concept of filters and signatures is introduced in chapter eight, although the examples tend to be either system specific and heavily coded, or overly simplistic. The initial section of chapter nine attempts to present a means for determining which events are important enough to record and analyze, and does not succeed very well. The latter portion, on considerations for intrusion detection system (IDS) architecture is much more useful. Chapter ten starts out with a look at a variety of attempts at interoperability between intrusion detection vendors (making me think of the bygone days of standardized virus signature files: the availability of standards is shown to be problematic) and then tenders some ideas about suspicious types of traffic, finishing with a few thoughts on database queries and data reduction. A number of IDSes are described in chapter eleven, although the level of detail, and even the general writeup structure, varies greatly. Chapter twelve seems to be out of place: the prediction about the future usually happens at the end of the book. Exploits, denial of service, and scan patterns are described in chapters thirteen, fourteen, and fifteen, repeating some of the material from chapters five and seven. Although interesting, not all of the content would be helpful to analysts or IDS administrators. Signatures related to the use of RPC (Remote Procedure Calls) as an attack tool are given in chapter sixteen. Chapter seventeen describes various options for filtering traffic for or with TCPdump. A "cracking" session, after a system has been penetrated, is presented in limited detail in chapter eighteen. In this case we are presented with a log of UNIX shell commands, and, rather ironically, a great deal more exegesis than is available in other sections (although the attempts at humour do confuse the issue, here and elsewhere in the book). A discussion of blackhat communities and resources has been added in this edition. A "detection" is outlined in chapter nineteen, but with a supremely anticlimactic ending: the summary admits that no reason for the anomalous traffic has been found. Chapter twenty reviews some basic security topics, such as policy development and risk assessment, but in a very simplistic and terse fashion. A number of possible responses to an intrusion are outlined in chapter twenty one. Chapter twenty two closes with suggestions on ow to make a business case. Those who need to know about intrusion detection should probably first look at Bace's (cf. BKNTRDET.RVW) or Amoroso's (cf. BKINTDET.RVW) books, both (somewhat annoyingly) titled "Intrusion Detection." Because of the lack of structure in the work, this volume is not usable as an overview introduction to the field, although the examples do contain a great deal of informative content: if you can dig it out. For those who do have the basic concepts, the material does provide numerous practical examples, and some real-life considerations for implementation. copyright Robert M. Slade, 1999, 2002 BKNTINDT.RVW 20021009 rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ 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. .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 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.39 ************************
This archive was generated by hypermail 2b30 : Sat Nov 23 2002 - 17:08:29 PST