RISKS-LIST: Risks-Forum Digest Friday 14 January 2005 Volume 23 : Issue 66 ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <http://www.risks.org> as <http://catless.ncl.ac.uk/Risks/23.66.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: A Comedy of Errors (Leslie Lamport) 30,000 personal records stolen in GMU server compromise (James Bauman) New FBI software not usable (NewsScan) Wal-Mart Stung in $1.5 Million Bar-Code Scam (Evan Schuman via Monty Solomon) Attack on T-Mobile (NewsScan) Risks of /pseudo-?/random alphanumeric generation (Joe Thompson) Risks of lenient parsing (Jim Horning) Heisenberg at work? Ranking cardiologists (David Lesher) Ticket not in computer system: your insurance rates may increase (Joyce Scrivner) eBay open invitation to phishing scammers (Thomas L. Jones) Honest, General, it was only a little glitch (Jeremy Epstein) Microsoft AntiSpyware beta - quick review (Rob Slade) Re: Why adding more security measures may make systems less secure (Ron Bean) Re: New Year's Privacy Resolutions (Erling Kristiansen) REVIEW: "Net Crimes and Misdemeanors", J. A. Hitchcock (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 5 Jan 2005 09:55:36 -0800 From: "Leslie Lamport" <lamport@private> Subject: A Comedy of Errors The TLA+ specification language uses a common notation in which strings are enclosed in double-quotes. Special characters within a string, such as double-quote and backslash, are quoted by preceding them with a backslash. Thus, the string consisting of the five characters a " b \ c is written "a\"b\\c". The string "a\"b" appearing in a specification should traverse the following circuitous path if it is printed by the model checker: 1. The parser should convert the string "a\"b" to the list ('a', '"', 'b') of the three characters a " b. 2. The printing routine should convert ('a', '"', 'b') to the string "a\"b". 3. The pretty-printer, which inserts spaces and line breaks to format the output, should leave the string "a\"b" unchanged. In the current version, none of these steps is performed correctly. Instead, they do the following: 1. The parser converts the string "a\"b" to the list ('a', "\", '"', 'b') of the four characters a \ " b. 2. The printing routine, which should covert ('a', "\", '"', 'b') to "a\\\"b", instead converts it to "a\"b". 3. The pretty printer, which should leave the string "a\"b" unchanged, instead prints it as "a\". What is remarkable is that these three transformations are performed by code written by three different people. The programmers are all PhD researchers at different institutions--one at a university and the other two at two different industrial research labs. Quoted characters are one of only two special cases that occur in handling strings. (The other, the empty string, should be handled automatically by any competently-written code.) Yet three different people forgot about that case when writing code. (I presume that the first transformation is done in two steps--the first identifying the string and the second converting it to a list--and the programmer forgot about quoted characters only in the second step.) This comedy of errors shows that smart people can overlook even obvious cases. One hopes that, had this been production code written by professional programmers rather than research-project code written by researchers, then so simple an error would have been caught. But programs contain many problems that are not so simple. This incident points out the limitation of code reviews. It also calls into question the use of multi-version programming as an alternative to verification for building highly reliable systems. ------------------------------ Date: Tue, 11 Jan 2005 14:59:32 -0500 From: James Bauman <James.Bauman@safety-kleen.com> Subject: 30,000 personal records stolen in GMU server compromise The server at George Mason University in Virginia was compromised by crackers who stole personal information ("names, photos, Social Security numbers and (campus ID) numbers of all members of the Mason community who have identification cards") on 30,000 students, faculty, and staff. The mega-risk here is obvious -- tens of thousands of people who may become victims of identity theft, one of the fastest growing crimes in America. A system alert is posted on the University web site --> http://www.gmu.edu/prod/alerts/supportcenter/index.jsp?ID=1157 For more details, see http://news.com.com/2100-7349_3-5519592.html ------------------------------ Date: Thu, 13 Jan 2005 08:49:59 -0700 From: "NewsScan" <newsscan@private> Subject: New FBI software not usable A new FBI computer system called Virtual Case File, designed to help agents share information to ward off terrorist attacks, may have to be discarded because it doesn't work as designed. The agency will be soliciting proposals for new software from outside contractors for new software. Sen. Judd Gregg (R-N.H.), chairman of the Senate appropriations subcommittee, calls the development "a stunning reversal of progress" and adds: "If the software has failed, that sets us back a long way. This has been a fits-and-starts exercise, and a very expensive one for a very long time. There are very serious questions about whether the FBI is able to keep up with the expanding responsibility and the amount of new dollars that are flowing into it. We have fully funded it at its requested levels." Science Applications, the company that developed the system, says it "successfully completed" delivery of the initial version of the Virtual Case File software last month. [*Los Angeles Times* 13 Jan 2005, NewsScan Daily, 13 Jan 2005] http://www.latimes.com/technology/la-na-fbi13jan13,1,2171776.story? coll=la-headlines-technology http://www.latimes.com/technology/la-na-fbi13jan13,1,2171776.story?coll=la-headlines-technology [VCF is part of a four-year, $.5 billion overhaul of the FBI's ``antiquated'' computer systems. PGN] ------------------------------ Date: Fri, 7 Jan 2005 01:49:49 -0500 From: Monty Solomon <monty@private> Subject: Wal-Mart Stung in $1.5 Million Bar-Code Scam By Evan Schuman January 5, 2005 In a scheme that leveraged a little technology but relied on inattentive cashiers, Tennessee authorities have arrested two couples on charges that they used bogus bar codes to steal at least $1.5 million from hundreds of stores--some belonging to Wal-Mart--in 19 states. The group is slated to appear in court Wednesday. Although the accused are said to have spent a lot of time and effort organizing colleagues in various parts of the country, the technology portion of their scheme was quite simple. They are accused of visiting a retailer and purchasing a low-priced item. The group would then scan the bar codes and simply print out duplicate bar codes, said Thomas Dean, the assistant Sumner County (Tennessee) district attorney who is assigned to the case. The accused--Michael Poore, 29, and Julie Marie Simmons, 35, also known as Julie Poore; and Dewey Howerton, 39, and Laura Howerton, 39--would then go back to the store, tape the duplicate bar code on a higher-priced item and purchase the more expensive item at the lower scanned price, Dean said in an eWEEK.com interview. One of the accused, according to the police complaint, would then remove the bogus tag and try to return the item to the store for the full purchase price. Instead of cash, the defendants would often ask for gift cards, Dean said. "Wal-Mart will more quickly put it on a gift card than hand you cash," he said. ... http://www.eweek.com/article2/0,1759,1748274,00.asp ------------------------------ Date: Thu, 13 Jan 2005 08:49:59 -0700 From: "NewsScan" <newsscan@private> Subject: Attack on T-Mobile A network vandal broke into the network of wireless carrier T-Mobile over a seven-month period and read e-mails and personal computer files of hundreds of customers -- including those of the Secret Service agent investigating the hacker himself. The online activities of the vandal, 21-year-old computer engineer Nicolas Lee Jacobsen of Santa Ana, were traced to a hotel where he was staying in Williamsport, N.Y. Although Jacobsen was able to view the names and Social Security numbers of 400 customers (all of whom were notified in writing about the break-in), customer credit card numbers and other financial information never were revealed, and T-Mobile says it "immediately took steps that prevented any further access to this system." [AP, 12 Jan 2005; NewsScan Daily, 13 Jan 2005] http://www.siliconvalley.com/mld/siliconvalley/10633193.htm ------------------------------ Date: Thu, 6 Jan 2005 13:50:16 -0500 From: Joe Thompson <kensey@private> Subject: Risks of /pseudo-?/random alphanumeric generation The Cabbage Patch doll, known to legions of kids from the 80s on, comes with "adoption paperwork" including a unique, randomly-generated serial number. However, apparently the company's random number generator was, from a certain point of view, a little too random: Girl Gets Cabbage Patch Doll With Obscene Message http://www.10news.com/news/4050756/detail.html Apparently, purely by chance -- or so the company insists, at any rate -- one serial number included a six-letter string commonly considered obscene, especially so in the context of children's toys. The slide show on the linked new story page has a shot of the string in question (with the first letter helpfully covered up to avoid further offense). That it was given as a Christmas gift seems particularly unfortunate. Many are the tales of large computer systems where user account names are fully or partially randomized to avoid embarrassing formations from pieces of names or other data. Even in such cases, some basic filtering is needed; in fact given the audience for the product I'm surprised no one at Play-Along has realized this in twenty years. People easily forget that 0000, 1111, 2222, etc. are as random as any other four-digit string in certain contexts. ------------------------------ Date: Fri, 07 Jan 2005 4:26 PM From: Jim_Horning@private Subject: Risks of lenient parsing Yesterday I had a frustrating experience trying to help track down a problem in a post to a blog I subscribe to, <http://www.cra.org/govaffairs/blog/index.php>. It ended happily enough when we were able to locate a syntax error in the HTML of the post, but not before we had explored several blind alleys. For the gory details, see http://horning.blogspot.com/2005/01/risks-of-lenient-parsing.html So what is the lesson? There was clearly a syntax error, so what we got is what we deserved, right? I think not. Given the frequency of errors in HTML, it would be unreasonable for renderers to refuse to display pages with errors. (There is an error somewhere in my blog post on this that I am still looking for.) However, we stumbled around blindly because *none* of the browsers we were using gave any hint that there was a syntax error on the page. Each just silently "corrected" the error. Unfortunately, but predictably, they didn't all "correct" it in the same way, meaning that Peter and his testers were consistently getting one result, and I was consistently getting another. I contend that *all* of the browsers were wrong not to indicate clearly the presence of a syntax error. A friendly browser would even have made some attempt to indicate the approximate location on the page of the error. Although it was published more than thirty years ago, I think my advice on "What the Compiler Should Tell the User" (in *Compiler Construction, an Advanced Course*, F. L. Bauer and J. Eickel (eds.), Springer-Verlag, pp. 525-548, 1974) is still pertinent to those who build compilers and other formal language interpreters. Those who do not study the past are very likely not to learn its lessons, and therefore to repeat old mistakes, such as silently "correcting" syntax errors. ------------------------------ Date: Tue, 11 Jan 2005 07:52:25 -0500 (EST) From: David Lesher <wb8foz@private> Subject: Heisenberg at work? Ranking cardiologists Cardiologists Say Rankings Sway Choices on Surgery, Marc Santora, 11 Jan 2005 An overwhelming majority of cardiologists in New York say that, in certain instances, they do not operate on patients who might benefit from heart surgery, because they are worried about hurting their rankings on physician scorecards issued by the state, according to a survey released yesterday. I am reminded of the {alleged} quota scheme in the FBI. For years, no agent would willingly undertake terrorism cases, as such are long, time consuming and fraught with failure. Stick to the meat & potatoes of doofus bankrobbers, and you'll get promoted. So the PHB's made terrorism cases carry more weight... Result? Now jaywalking and felony mopery are charged as terrorism... ------------------------------ Date: Thu, 06 Jan 2005 16:19:07 -0600 From: Joyce Scrivner <kscriv@private> Subject: Ticket not in computer system: your insurance rates may increase <http://www.boingboing.net/2005/01/05/a_kafka_day_at_the_l.html>http://www.boingboing.net/2005/01/05/a_kafka_day_at_the_l.html Mark Frauenfelder: In November, my wife, Carla Frauenfelder, was driving home when a Los Angeles Police officer pulled her over. He ticketed her for making an illegal left turn. The next day, with her ticket in hand, I entered the url for the website listed on the ticket (lasuperiorcourt.com). I wanted to pay the fine and sign her up for driving school so our car insurance rates wouldn't increase. The website couldn't find the ticket. I tried searching for it both by entering the ticket number and by entering my wife's driver license number. No luck. So I called the phone number on the ticket. The woman who answered said there was no record of the ticket. She said my wife would have to drive to the ticket office on Penfield St, in Chatsworth to take care of it. So, my wife drove there on January 5th and showed the woman at the counter the ticket. The woman entered the ticket number and nothing came up. She scratched her head for a minute, and then noticed that the police officer forgot to write a date on the ticket. Apparently, that screws everything up. The woman told my wife what the fine is (about $135), but told her that she could not accept payment for the fine, because the ticket is not in the database. My wife is not allowed to attend driving school, either, because the ticket isn't in the database. The woman instructed my wife to call the court every day week, to find out if the ticket had been entered into the computer yet. Once it shows up, she is supposed to drive to the ticket office the very next day to take care of it. And once the ticket has been entered, she is going to be hit with a penalty and possibly a warrant for her arrest, because once the information goes into the computer it'll see that she hasn't paid the fine yet, and it will be flagged as delinquent. My wife will then have to explain the situation to another helpful city employee. My wife asked the woman how it long will take for the ticket to be entered into the computer system. The woman said she had no idea. My wife asked her if she is going to have to call every day week for the next several years. She shrugged and said "Well, it might take a week, it might take six months, I don't know." My wife asked again if she could just pay the fine and have it apply to the ticket when it finally does show up. Woman: "Nope." I'm at a loss for what to do here. If you have a good idea please <mailto:mark@private>email me and let me know if you do! ------------------------------ Date: Sun, 2 Jan 2005 05:23:20 -0500 From: "Thomas L. Jones" <DrJones@private> Subject: eBay open invitation to phishing scammers Recently I received an e-mail from eBay.com involving something called = "My Messages." The e-mail directs the user to click on a link and enter = his or her password. Thus it is indistinguishable from a phishing scam, = and eBay.com will have only itself to blame when its customers fall = victim to scammers. Thomas L. Jones, Ph.D., Computer Science cc: Federal Trade Commission <reportphishing@private> ------------------------------ Date: Thu, 13 Jan 2005 8:18:22 -0500 From: Jeremy Epstein <jeremy.epstein@private> Subject: Honest, General, it was only a little glitch As has been widely reported, the DoD's missile interceptor test failed miserably in December, building on a rather impressive history of failures. According to Pentagon brass, the problem was "with an automated pre-launch check of the communications flow between the interceptor and the main flight control computer. Detecting too many missed messages, the system shut down automatically, as designed. [so] the Pentagon will increase the pre-launch tolerance for missed messages. [General] Obering said the tolerance level was set too low; increasing it will not risk a flight guidance failure". Well, that makes me feel better. The system ran into problems, so it generated errors. Rather than figuring out what the problem was, let's ignore the errors. Not unlike turning up the radio in your car so you can't hear it falling apart. The general went on to say "Statistically, it's a very rare occurrence and most likely would not happen again." Gee, I feel safer every minute. http://www.cnn.com/2005/TECH/01/12/missile.defense.ap/index.html ------------------------------ Date: Fri, 7 Jan 2005 13:49:15 -0800 From: Rob Slade <rslade@private> Subject: Microsoft AntiSpyware beta - quick review The beta version of Microsoft's Anti-Spyware program (purchased from Giant) is available at http://www.microsoft.com/downloads/details.aspx?familyid=321cd7a2-6a57-4c57-a8bd-dbf62eda9671&displaylang=en&Hash=5BMW635 The beta version is about a 6.4 meg download, and can be downloaded as a file in order to copy and install it onto other machines. That's very nice, and a departure from Microsoft's often heavy-handed approach. Installing offers you a few options: do you want to set it to automatically update (I did), do you want it to install real-time protection (I did: so far it hasn't interfered with much, but I haven't used it much, either), and do you want to join Spynet. Spynet is not an invitation to join a kind of corporate CIA, but will report on "suspect" files. There is a fair amount of information on what it collects, if you ask for it. It seems to send information about file sizes and an MD5 hash back to HQ, but not, seemingly, the suspect file itself. In any case, there wasn't enough information on what it *doesn't* collect for me to feel comfortable, so I turned it off. (I hope.) The installation seems to default to a reasonably protected mode: the defaults are for auto updating, real-time protection, and scheduled scans (although the schedule is for 2 am). When you start up the program, it is initially set for a quick scan. I changed that to a full scan, which took about half an hour on my machine. >From a quick test, the MS antispyware, at least in beta, falls between Spybot S&D and Adaware in terms of detection. Spybot is fairly conservative, and only deals with stuff that is pretty certain to be spy/adware, whereas Adaware will detect a bunch of other stuff. The MS product detected one copy of BackWeb (inactive) that Spybot had not, and detected about 38 copies of 15 versions of other stuff from my samples directory. (Adaware quarantined about 60.) The items detected all seem to have a least some remote access component, even if it is rather limited (such as BadTrans.B, that drops a keylogger). Oddly, it only detected two of my extensive collection of Bagles. You can ask the program to deal with individual threats in different ways, although seemingly not individual files. (As a researcher, I like that. In terms of protection, I'm not as sure.) The options are to remove, quarantine, ignore, or always ignore. The program usually defaults to quarantine, although some threats are considered more serious, and marked to remove. The explanation of "always ignore" is not detailed enough, as far as I am concerned: does this mean always ignore this particular file, or always ignore this threat? You can also specify certain directories to scan, or to ignore. Again, as a researcher I really appreciate the ability to tell it so ignore my sample directory. Unfortunately, this option doesn't work properly: it scans directories you tell it to ignore, regardless. When I told it to scan *only* my sample directory, it seemed to scan a fair amount of other stuff as well. Again, from a protective standpoint, this is probably a good thing. At the moment, after a very quick test, I'd provisionally recommend the use of the MS/Giant antispyware program, at least in fairly restricted and manual mode. I'd be interested in hearing from others who have tested the real-time operations more extensively, and particularly from anyone who has tested the Spynet capabilities, and what information is returned thereby. http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: Wed, 29 Dec 2004 00:17:01 -0500 From: rbean@private (Ron Bean) Subject: Re: Why adding more security measures may make systems less secure "Don Norman" <norman@private> writes in RISKS-23.63: > 4: The Dedicated Worker problem. If the security or safety requirements > get in the way of doing the work, then the most dedicated workers will > defeat them. > Note, the most obvious response of security and safety people is "more > training is necessary." There is training, and then there is operant conditioning. If defeating a safety and/or security system results in an "attaboy" for increased productivity, the employee is being "trained" to defeat the system, regardless of anything that may have been said in the official training session. The only way I see around this is to _continually_ emphasize the value of safety/security systems, and to somehow downplay the all-too-obvious value of defeating them (possibly by making them less awkward to use-- don't assume this is impossible). A lot of safety training focuses on reviews of "one in a million" accidents that actually happened, so people will remember why the safety systems are there in the first place. The book "Construction Failure" by Feld & Carper (Wiley 1997) notes that many construction accidents are caused by "unexpected" weather conditions, that statistically are not "unexpected" at all. This may be true of computer security issues as well. It would also help if the security message were coming from the people responsible for production rather than from a separate department. In many companies, the people in charge of safety and/or security are seen purely as obstacles, because they don't seem to be of any help when it comes to actually getting things done. ------------------------------ Date: Thu, 06 Jan 2005 21:14:53 +0100 From: Erling Kristiansen <erling.kristiansen@private> Subject: Re: New Year's Privacy Resolutions (Peek, RISKS 23.65) Bernard Peek sets as a goal "Every ad a wanted ad". But he thereby excludes those people who feel that "Every ad an unwanted ad". For those of us who belong to this group, Rotenberg's Resolution seems a better starting point. Peek advocates the view that the more complete trail of your actions you leave, the better can advertising be targeted. I would like to ask: What kind of trail am I supposed to leave in order to get the message across that I do not want any unsolicited ads at all? The only answer I can think of is: Leave as little trail as possible. Which is exactly what Rotenberg suggests. ------------------------------ Date: Mon, 10 Jan 2005 15:33:56 -0800 From: Rob Slade <rslade@private> Subject: REVIEW: "Net Crimes and Misdemeanors", J. A. Hitchcock BKNTCRMD.RVW 20041016 "Net Crimes and Misdemeanors", J. A. Hitchcock, 2002, 0-910965-57-9, U$24.95/C$37.95 %A J. A. Hitchcock %C 143 Old Marlin Pike, Medford, NJ 08055 %D 2002 %G 0-910965-57-9 %I Information Today Inc. %O U$24.95/C$37.95 609-654-6266 custserv@private %O http://www.amazon.com/exec/obidos/ASIN/0910965579/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0910965579/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0910965579/robsladesin03-20 %P 359 p. %T "Net Crimes and Misdemeanors" This book is not about net crimes in general, but about cyberstalking and online harassment. Chapter one details Hitchcock's own experience with cyberstalking and harassment, an extremely unpleasant case of deliberate personal attack by fraudsters she had exposed. Three other cases are briefly described in chapter two, along with some basic advice on header analysis. Spam is delineated, and some helpful sites for dealing with it are listed, in chapter three (which also contains the usual, not terribly useful, suggestions for keeping your address off the net). Chapter four lists some urban legends and chain letters, which are hardly criminal material. Chapter five lists various types of online scams, but really only addresses credit card theft. The utility of the advice varies: the book suggests that you only deal with vendors with a professional looking website (hardly a guarantee of virtue), but also gives fairly detailed descriptions of indicators for a secure HTTP (HyperText Transfer Protocol) session. Online auction fraud is covered in chapter six, from the perspective of both buyer and seller. The story of adoption fraud, in chapter seven, is particularly distressing. Chapter eight give some account of identity theft, but the initial "case" is more related to harassment, and the material never really looks at more usual identity theft situations. More cases of cyberstalking are listed in chapter nine, with not as much helpful content. Chapter ten discusses trolls, flames--and more harassment. Chapter eleven examines chat and harassment. Other means of harassment are discussed in chapter twelve. Child exploitation is reviewed in chapter thirteen. Chapter fourteen looks at various issues in the workplace. Statements from various law enforcement personnel are given in chapter fifteen--along with an odd mention of the Sam Spade program. Harassment at universities is covered in chapter sixteen. There is a terse mention of the PGP program in seventeen. Chapter eighteen describes viruses and firewalls, but not very well. Tips on investigating harassment are in chapter nineteen. The book does provide some helpful resources on certain topics. It could have provided more, if it didn't keep returning to the same topic over and over again. copyright Robert M. Slade, 2004 BKNTCRMD.RVW 20041016 rslade@private slade@private rslade@private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: 29 Dec 2004 (LAST-MODIFIED) From: RISKS-request@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. Mailman can let you subscribe directly: http://lists.csl.sri.com/mailman/listinfo/risks Alternatively, to subscribe or unsubscribe via e-mail to mailman your FROM: address, send a message to risks-request@private containing only the one-word text subscribe or unsubscribe. You may also specify a different receiving address: subscribe address= ... . You may short-circuit that process by sending directly to either risks-subscribe@private or risks-unsubscribe@private depending on which action is to be taken. Subscription and unsubscription requests require that you reply to a confirmation message sent to the subscribing mail address. Instructions are included in the confirmation message. Each issue of RISKS that you receive contains information on how to post, unsubscribe, etc. INFO [for unabridged version of RISKS information] .UK users should contact <Lindsay.Marshall@private>. => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from <http://www.CSL.sri.com/risksinfo.html> The full info file may appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@private with meaningful SUBJECT: line. *** NOTE: Including the string "notsp" at the beginning or end of the subject *** line will be very helpful in separating real contributions from spam. *** This attention-string may change, so watch this space now and then. => ARCHIVES: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i] <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue. Lindsay 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/> . ==> 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 23.66 ************************
This archive was generated by hypermail 2.1.3 : Fri Jan 28 2005 - 10:24:45 PST