RISKS-LIST: Risks-Forum Digest Sunday 22 February 2009 Volume 25 : Issue 58 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/25.58.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: Buffer overflows in SHA-3 submissions (Joy Marie Forsythe) Re: Train brake failure - broken valve (Al Stangenberger) Due Diligence or is that "Don't..."? Citibank fraud (David Lesher) Digital Archivists, Now in Demand (Conrad De Aenlle via Monty Solomon) Re: Wikipedia prankster dupes German media (Debora Weber-Wulff) Re: Control-Alt-Eject? French Navy grounded (CBFalconer) Capital One Phishing Warning is dangerous (Marc Auslander) Re: The mystery of 'Ireland's worst driver' (Bernard Lyons) Re: Hiding in plain sight (Phil Smith III) Bounds checking in C (Andrew Koenig) The risks of Silver Bullets (Michael Smith) Re: Tony Hoare: "Null References" (Steven M. Bellovin, Dimitri Maziuk, Randy Saunders) Related to blacklists for antispam (De Vries Duane) Re: Dates of birth are not unique identifiers (David E. Ross) Re: USAA Web site follies (Jonathan Kamens) Alert TA09-051A -- Adobe Acrobat and Reader Vulnerability (US-CERT via Monty Solomon) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Sat, 21 Feb 2009 11:19:27 -0800 From: Joy Marie Forsythe <jforsythe_at_private> Subject: Buffer overflows in SHA-3 submissions NIST is currently holding a competition to choose a design for the SHA-3 algorithm. The reference implementations of a few of the contestants have bugs in them that could cause crashes, performance problems, or security problems if they are used in their current state. Based on our bug reports, some of those bugs have already been fixed. Two of the projects (Blender and MD6) contained buffer overflows. The rest of the issues found were out-of-bounds reads, memory leaks and null dereferences. The code was good overall, but it's important to get these implementations right. They end up being the basis for future implementations, or used as is, and can be a factor is the outcome of the SHA-3 competition. More details about the issues: http://blog.fortify.com/blog/fortify/2009/02/20/SHA-3-Round-1 Joy Marie Forsythe, Security Researcher, Fortify Software 1-650-358-5621 jforsythe_at_private ------------------------------ Date: Fri, 20 Feb 2009 12:19:44 -0800 From: Al Stangenberger <forags_at_private> Subject: Re: Train brake failure - broken valve (Lesher, RISKS-25.56) The lack of an emergency brake exhaust valve in a locomotive must be a British peculiarity. Every American locomotive built within the past century has an emergency dump valve in the locomotive cab (and these are the Westinghouse brake design). When locomotives had firemen, the valve was located by the fireman's seat in case the engineer was incapacitated. Also, every American railroad passenger car has an emergency dump valve (aka the conductor's valve). In older cars this valve was connected to a cord which ran above the windows for the full length of the car. Modern cars eliminated the emergency cord, and now the handle for the conductor's valve is often found near the vestibule at the end of the car. It is often not very obvious, but the crew knows where it is. AL Stangenberger, Western Railway Museum [Added: Fri, 20 Feb 2009 19:43:15 -0800] I learned a lot more about railroad locomotive emergency brake valve requirements. Emergency brake valves are now only required by U.S. Federal law (49 CFR Ch. II, sec. 229.47) if the locomotive cab is designed for occupancy by more than one person. The requirement is actually for the valve to be accessible to a member of the crew other than the engineer. In the British case in RISKS, the US-built locomotive was designed for only one person in the cab, so the emergency brake pipe valve was not required. Possibly this policy should be reconsidered. In any case, though, it is not the case that nobody ever thought about having emergency valves in Westinghouse-design air brake systems. ------------------------------ Date: Sat, 21 Feb 2009 15:10:59 -0500 (EST) From: "David Lesher" <wb8foz_at_private> Subject: Due Diligence or is that "Don't..."? Citibank fraud <http://www.nytimes.com/2009/02/21/nyregion/21scam.html?emc=eta1> "A Nigerian citizen duped Citibank into wiring $27 million to accounts that he and others controlled, prosecutors said." Citibank accepted a package changing contact data for the National Bank of Ethiopia; and only months later noticed it came not from Ethiopia but Lagos, Nigeria. When they finally started looking into it; they also found the new contact numbers were cell phones in Nigeria, UK and South Africa. I'm reminded of the ex-President who'd never seen a grocery store scanner. An enormous international bank has never connected Nigeria and identity fraud? The Risk? Reliance on easily forged documents with no verification. Sometimes, a fraud too simple to ever work, shall... ------------------------------ Date: Sat, 21 Feb 2009 15:53:29 -0500 From: Monty Solomon <monty_at_private> Subject: Digital Archivists, Now in Demand (Conrad De Aenlle) Conrad De Aenlle, Fresh Starts: Digital Archivists, Now in Demand, *The New York Times*, 8 Feb 2009 When the world entered the digital age, a great majority of human historical records did not immediately make the trip. Literature, film, scientific journals, newspapers, court records, corporate documents and other material, accumulated over centuries, needed to be adapted for computer databases. Once there, it had to be arranged - along with newer, born-digital material - in a way that would let people find what they needed and keep finding it well into the future. The people entrusted to find a place for this wealth of information are known as digital asset managers, or sometimes as digital archivists and digital preservation officers. Whatever they are called, demand for them is expanding. One of them is Jacob Nadal, the preservation officer at the University of California, Los Angeles. He does not use the "digital" modifier because his duties include safeguarding analog materials in U.C.L.A.'s collection, not just preparing them to cross the digital divide. "I don't think there's any day where I would say I'm the digital guy," he said. But he concedes that he's not really an analog, ink-on-paper guy, either, and that is increasingly the case in his field. These days, he noted, "if you want to work in a library, you have to deal in electronic resources." Mr. Nadal and 10 or so colleagues at U.C.L.A. devote much of their effort to organizing and protecting material in digital form. Their duties include licensing and buying digital content from vendors, assigning identification markers called meta-tags so that material can be found easily, researching copyright matters and ensuring that files remain intact whenever new iterations of relevant software or hardware come along. ... http://www.nytimes.com/2009/02/08/jobs/08starts.html ------------------------------ Date: Sat, 21 Feb 2009 14:00:06 +0100 From: Debora Weber-Wulff <D.Weber-Wulff_at_fhtw-berlin.de> Subject: Re: Wikipedia prankster dupes German media (RISKS-25.57) Actually, the prank goes deeper. An anonymous IP (shorthand for non-registered editors on the Wikipedia), 78.34.237.194, a broadband user from Cologne, added the additional given name "Wilhelm" on 8 Feb 2009 at 9.40 pm for the newly designated German Minister of Commerce [1]. As a true blue-blood, he has more than the average number of them. On 9 Feb at 12.23 pm the administrator Arudaki complained that there was no source for this name, and removed all of the additional given names [2]. But by then the damage had been done, and the newspapers who had done a quick Wikipedia "fact"-check were already online and included the name "Wilhelm". A rage ensued, as people "fixed" the Wilhelm back in, quoting the now online sources that had used the faked Wikipedia entry. As is usual in a vandalism war, the page was removed from editing mode until people could cool down and get out a copy of the German peerage book [3] and discover that there was no "Wilhelm" listed there. The page is back being editable (and of course the pranksters keep putting in new names such as "Marcus", but they get quickly reverted (and the prankster given an hour in the corner, unable to edit). Anonymous then bragged about his or her heroic feat in [4], and it became clear that the German media relies heavily on the Wikipedia, without citation, of course. And this is not just the more yellow press, many newspapers printed the name. The risks? Don't rely on Wikipedia information for current events. And find a second, preferably offline, source for your information if you are doing serious journalism. Especially if you are doing print. [1] http://de.wikipedia.org/w/index.php?title=Karl-Theodor_zu_Guttenberg&oldid=56419545 [2] http://de.wikipedia.org/w/index.php?title=Karl-Theodor_zu_Guttenberg&oldid=56439344 [3] Genealogischen Handbuch des in Bayern immatrikulierten Adels, Band 17. Neustadt, Aisch, 1988 [4] http://www.bildblog.de/5695/wie-ich-freiherr-von-guttenberg-zu-wilhelm-machte/ with picture document of the Bild front page Prof. Dr. Debora Weber-Wulff,FHTW Berlin, FB 4, Internationale Medieninformatik (from 1.4.2009 HTW Berlin), Treskowallee 8, 10313 Berlin +49-30-5019-2320 weberwu@(f)htw-berlin.de http://www.f4.(f)htw-berlin.de/people/weberwu/ ------------------------------ Date: Fri, 20 Feb 2009 23:26:21 -0500 From: CBFalconer <cbfalconer_at_private> Subject: Re: Control-Alt-Eject? French Navy grounded (Lesher, RISKS-25.56) ... From this I conclude that France is using Windows in its military. I thought nobody other than the US (and possibly the UK) were so foolish. http://cbfalconer.home.att.net ------------------------------ Date: Sat, 21 Feb 2009 16:00:53 -0500 From: "Marc Auslander" <marcausl_at_private> Subject: Capital One Phishing Warning is dangerous I got an e-mail alert from Capital One that a new message was in my account. The messages was a boilerplate warning that a phishing attach on Capital One was in progress. Unfortunately, the email alert was sent by a third party which Capital One uses for this purpose. Capital One does not have an SPF record for the sender, but is using SPF. GMAIL correctly marks this as a phishing letter and throws it into SPAM. If you try to read it you get the big bright GMAIL phishing warning! So I try to tell Capital One they have a problem. Their response is advice on how to turn the warning off! So much for their anti-phishing campaign. ------------------------------ Date: Sat, 21 Feb 2009 00:25:16 +0000 From: Bernard Lyons <bernard.lyons_at_private> Subject: Re: The mystery of `Ireland's worst driver' (Cantrell, RISKS-25.57) Ireland doesn't yet have credit-card style licenses (they've been coming Real Soon Now for several years), but we've had the tri-fold licenses with standardised numbered fields for well over a decade. Mine is one. It defies belief that any Garda doesn't know how to figure out a driving license - no matter what it looks like - or establish someone's name from other documentation. Their internal performance rating depends on it, amongst other things. Further, Polish people have been working in Ireland since at least the late 1970's to my personal knowledge. They just didn't suddenly appear from nowhere. So 50 members of An Garda Siochana making the same mistake stretches credulity. It's far more likely to be a problem with their PULSE system, perhaps to do with data entry. It's known to be inflexible, and there were several expensive investigations into poor design and cost overruns before it went live. Something about this story doesn't add up. ------------------------------ Date: Sat, 21 Feb 2009 09:38:59 -0500 From: "Phil Smith III" <lists_at_private> Subject: Re: Hiding in plain sight Jeremy Epstein <jeremy.j.epstein_at_private> wrote about a product with an asterisk in the middle between two common words, making it almost impossible to find using search engines. IBM has done something similar: the hardware line once known as AS/400, then iSeries, then System i, is now known simply as "i", making it beyond impossible to find. I can't imagine what their marketroids were thinking. ------------------------------ Date: Sat, 21 Feb 2009 12:36:14 -0500 From: "Andrew Koenig" <ark_at_private> Subject: Bounds checking in C There have been a number of claims in RISKS recently that bounds checking is impossible in C. These claims are false. In fact, there was a software product (Centerline) available for a number of years that checked bounds in C programs at run time. However, out-of-bounds array references are far from the only run-time transgressions in C programs that are both common and difficult to check. Another such is referring to memory after it has been freed. Such problems are exacerbated by the fact that at one time (before approximately 1980), freeing memory was guaranteed not to affect its contents--it was not until the next time you tried to allocate memory that any values would be changed. This phenomenon led to code such as this: struct node *p = listhead; while (p) { free(p); p = p->next; } Even worse, the original definition of realloc *required* the memory being reallocated to be freed first; if you tried to call realloc with memory that had not been freed, it would *always* allocate new space and copy the contents of the old memory block into the new space, relying on you to free the old block in the fullness of time. Thus the original definition of malloc and free encouraged, and sometimes required, programmers to use pointers to unallocated memory. This requirement made checking for legitimacy very difficult indeed. The definition of free and realloc were eventually changed to say that free was permitted to destroy the contents of the memory being freed, and that realloc could (and should) accept the address of a block that was already allocated, and would free the block after copying its contents elsewhere. That change at least made it plausible to check the legitimacy of pointers. ------------------------------ Date: Sun, 22 Feb 2009 18:34:29 +1100 From: Michael Smith <emmenjay_at_private> Subject: The risks of Silver Bullets (was Tony Hoare: "Null References") Ah! If only we had the right programming language, then we could write robust software. I have heard that refrain since the early eighties as I developed software in FORTRAN, BASIC, COBOL, C, C++ Pascal, Prolog and various assemblers, 4GLs, 5GLs and more. It remains, as it has always been, garbage. You can write robust code in almost any language and can write garbage just as easily. We have known for many years how to write robust software. We do not do so for one reason: cost. We can write junk software much more cheaply than the good stuff and nobody wants to pay the extra cost. 1. We skimp on training our programmers and architects. Maybe you can teach yourself <$PROGRAMMING_LANGUAGE> in 30 days (or whatever) but it takes many years to learn quality software engineering. 2. We rush through the specification phase. Stakeholders are too busy to give time to nailing down requirements. Sometimes we skip this stage altogether. 3. We skimp on the design phase. Frequently we just start coding with no thought of a proper architecture. Even when we do a design phase it is with mobile requirements and a short deadline. 4. We skimp on testing. We don't have adequate test specs. We don't have well trained testers. And the pressure to ship, so that we can book some revenue, is overwhelming. We chose not to produce quality software because all those things cost money and we'd rather make do with the cheap alternative. If we produced a word processor with almost zero bugs, an intuitive user interface and excellent performance, but it cost $50,000 per copy, we would not have a top seller. Though if every company summed all the cost of crashed and buggy software, bad products and training to manage poor interfaces, I wonder if it is still a bargain. Michael J Smith <emmenjay_at_private> ------------------------------ Date: Sat, 21 Feb 2009 14:29:35 -0500 From: "Steven M. Bellovin" <smb_at_private> Subject: Re: Tony Hoare: "Null References" (Franklin, RISKS-25.56) If we're going to take Hoare's name in vain, let me point people to his Turing Award lecture from 1980: The first principle was security: ... A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. ... I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law. And novelty? Circa 1966, I knew a magic incantation (in Fortran II, using some platform-specific subroutines) to interfere with the ability to do a soft reboot. (The machine in question was an SDS 920; as I recall, it didn't even have any disk drives.) ------------------------------ Date: Sat, 21 Feb 2009 13:01:01 -0600 From: Dimitri Maziuk <dmaziuk_at_private> Subject: Re: Tony Hoare: "Null References" (Ables, RISKS-25.57) In this particular case I have to disagree: I believe with C it's not so much "hysterical raisins" as "nails and screwdrivers". What gets lost in advocacy hype is that creators of a programming language usually have a specific set of problems (real, perceived, transient or fundamental) in mind and are thinking of ways to solve them. The programmers get to choose what language to write in and it's their job to understand available tools and choose the right one for the task at hand. For some definition of "right". C was created to write portable operating systems in, not end-user applications. "Portable" is the big plus when you consider potential customers and all the different computing platforms they may have been using. The lack of proper high-level facilities is a minus, but what choice do we have -- the language that has std:string and std::vector? Up until recently those weren't portable, and judging from past experience there's a good chance they'll revert to that state again when the next version of C++ standard comes out. Of course nowadays 99.9% of the target user base is using an x86-based platform with mice and graphical user interfaces, so one would expect the focus to shift to the tool that built-in GUI and runs on all x86 computers: Java virtual machine. Which has a whole lot of its own shortcomings and I'm sure 20 years down the track we'll read all about them in RISKS. ------------------------------ Date: Sat, 21 Feb 2009 16:19:45 -0500 From: Randy Saunders <R.Saunders_at_private> Subject: Re: Tony Hoare: "Null References" (Ables, RISKS-25.57) Not everyone in the "olden days" was as trusting as King Ables in RISKS-25-57. In the 1970's the Multics implementors at MIT and Honeywell were developing a time-sharing system. The language was PL/1, though that's a minor difference. Pointers that pointed to segments had bounds, and you got a hardware exception if you violated them. In PL/1 this was reflected as part of a higher level construct called the refer extent of a structure. The problem programmers happened alone the scene later on, with microprocessors and "personal" computers. The professional computer scientist was displaced by hordes of self-taught C coders. I hope to live to see today's programming paradigms replaced, I'm on my third round of "what where those idiots thinking?" Randy Saunders, JHU Applied Physics Lab +1.240.228.3861 R.Saunders_at_private ------------------------------ Date: Sun, 22 Feb 2009 12:10:25 -0500 From: De Vries Duane <duanedv_at_private> Subject: Related to blacklists for antispam This may be pure coincidence but it struck me as very odd. I use Earthlink as my E-mail provider. I have the 'spam' setting set to put all suspicious things into a 'spam folder' which I look at every few days (as opposed to them automatically being deleted). During the U.S. presidential campaign, I would frequently find E-mail from 'Democratic' candidates AND conservation groups in this folder. Not once did I find any E-mail from Republican candidates in this folder. I flagged the Democrat and conservation E-mails as 'not spam' which supposedly sent copies to Earthlink to figure out why they were improperly marked as spam. However, this kept up until AFTER the election was over. Then all my mail was delivered correctly. I'm not accusing Earthlink of anything duplicitous but I did find it curious. Duane De Vries, Retired, ex-computer geek, practicing curmudgeon ------------------------------ Date: Sun, 22 Feb 2009 11:08:09 -0800 From: "David E. Ross" <david_at_private> Subject: Re: Dates of birth are not unique identifiers > Steven J Klein asked, "Why not use the social security number, which is guaranteed to be unique?" In California, Civil Code Section 1798.85 generally prohibits the use of Social Security numbers as identifiers, especially for Internet services. This law is the result of numerous instances where Social Security numbers were not adequately protected from improper disclosure, resulting in identity theft. Of course, this law cannot be enforced against services based outside of California. David E. Ross <http://www.rossde.com/>. ------------------------------ Date: Sat, 21 Feb 2009 18:47:57 -0500 From: "Jonathan Kamens" <jik_at_private> Subject: Re: USAA Web site follies (Klein, RISKS-25.57) Preventing siblings with the same birthdate from being entered via the Web site seems like a reasonable precaution, especially given that there is an easy fallback, i.e., calling and giving the information over the phone. On the other hand, I acknowledge that I might see it differently if I had been thus inconvenienced. Steven Klein's story about his problem with the USAA Web site brings to mind a problem I had with the site last week which might be of interest to RISKS readers. I was entering the information on the Web site for myself and my wife, when I found listed in my wife's profile a "parent" whose name most certainly was not the name of one of my wife's parents. I sent USAA a message about this through their Web site, and they confirmed that the "parent" had been added to my wife's profile in error and they had removed it (I was not able to remove it myself through the Web site). I don't know what precautions USAA has in place to prevent such "errors" (e.g., do their member numbers have a checksum digit to detect mistyping?), but something definitely seems wrong with the fact that someone was able to attach a complete stranger to my wife's record in their database. ------------------------------ Date: Sat, 21 Feb 2009 18:39:18 -0500 From: "Jonathan Kamens" <jik_at_private> Subject: Re: The Trouble with Trusting Trend Micro (RISKS-25.57) Kevin Way's description of the absurd hoops demanded by Trend Micro before removing static IP ranges from their DNS blocklists reminded me of an incident which occurred during the 2008 U.S. Presidential Campaign. I was an active volunteer for one of the candidates and thus regularly received bulk emailings and email list messages from his campaign. At some point during the campaign, the flow of email petered out to nothing. Eventually I realized that this was because one of the blocklists my mail server was configured to use, NJABL, had the candidate's mail servers listed as spam sources. Only registered users of the candidate's site and donors to his campaign were added to his mailing lists, and every single message sent by the candidate had a working unsubscribe link at the bottom of it, so the candidate could not reasonably be categorized as a spammer. I contacted both the maintainers of NJABL and the webmasters of the candidate's site, pointing out that the site was listed in the blocklist and suggesting that perhaps one or more people who opposed the candidate had falsely reported his site as a spam source as a political dirty trick. I received no response from either NJABL or the webmasters, and after waiting in vain for several days for the problem to be fixed, I threw up my hands and removed NJABL from the set of blocklists my server was using. I'm now using only the Spamhaus ZEN blocklist, which apparently has somewhat more rigorous procedures than NJABL. The implications of being able to use DNS blocklists as weapons in political campaigns are quite frightening. ------------------------------ Date: Fri, 20 Feb 2009 21:56:43 -0500 From: Monty Solomon <monty_at_private> Subject: Alert TA09-051A -- Adobe Acrobat and Reader Vulnerability National Cyber Alert System Technical Cyber Security Alert TA09-051A [PGN-excerpted: Please see the cited item in case of updates.] Adobe Acrobat and Reader Vulnerability Original release date: February 20, 2009 Last revised: -- Source: US-CERT Systems Affected * Adobe Reader version 9 and earlier * Adobe Acrobat (Professional, 3D, and Standard) version 9 and earlier Overview Adobe has released Security Bulletin APSB09-01, which describes a vulnerability that affects Adobe Reader and Acrobat. This vulnerability could allow a remote attacker to execute arbitrary code. I. Description Adobe Security Bulletin APSB09-01 describes a memory-corruption vulnerability that affects Adobe Reader and Acrobat. Further details are available in Vulnerability Note VU#905281. An attacker could exploit these vulnerabilities by convincing a user to load a specially crafted Adobe Portable Document Format (PDF) file. Acrobat integrates with popular web browsers, and visiting a website is usually sufficient to cause Acrobat to load PDF content. II. Impact An attacker may be able to execute arbitrary code. III. Solution Disable JavaScript in Adobe Reader and Acrobat [...] Prevent Internet Explorer from automatically opening PDF documents [...] IV. References * Adobe Security Bulletin apsa09-01 - <http://www.adobe.com/support/security/advisories/apsa09-01.html> * Securing Your Web Browser - <http://www.us-cert.gov/reading_room/securing_browser/> * Vulnerability Note VU#905281 - <http://www.kb.cert.org/vuls/id/905281> The most recent version of this document can be found at: <http://www.us-cert.gov/cas/techalerts/TA09-051A.html> Feedback can be directed to US-CERT Technical Staff. Please send email to <cert_at_private> with "TA09-051A Feedback VU#905281" in the subject. For instructions on subscribing to or unsubscribing from this mailing list, visit <http://www.us-cert.gov/cas/signup.html>. Produced 2009 by US-CERT, a government organization. Terms of use: <http://www.us-cert.gov/legal.html> Revision History February 20, 2009: Initial release ------------------------------ Date: Thu, 29 May 2008 07:53:46 -0900 From: RISKS-request_at_private Subject: Abridged info on RISKS (comp.risks) The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. The mailman Web interface can be used directly to subscribe and unsubscribe: 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_at_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_at_private or risks-unsubscribe_at_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. => The complete INFO file (submissions, default disclaimers, archive sites, copyright policy, etc.) is online. <http://www.CSL.sri.com/risksinfo.html> The full info file may appear now and then in RISKS issues. *** Contributors are assumed to have read the full info file for guidelines. => .UK users should contact <Lindsay.Marshall_at_private>. => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => SUBMISSIONS: to risks_at_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 for current volume or ftp://ftp.sri.com/VL/risks for previous VoLume <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 ==> Special Offer to Join ACM for readers of the ACM RISKS Forum: <http://www.acm.org/joinacm1> ------------------------------ End of RISKS-FORUM Digest 25.58 ************************Received on Sun Feb 22 2009 - 14:41:02 PST
This archive was generated by hypermail 2.2.0 : Sun Feb 22 2009 - 15:09:39 PST