RISKS-LIST: Risks-Forum Digest Thursday 18 March 2004 Volume 23 : Issue 28 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://www.risks.org as http://catless.ncl.ac.uk/Risks/23.28.html The current issue can be found at http://www.csl.sri.com/users/risko/risks.txt Contents: House Panel Slams Federal IT Security (PGN) JFK AirTrain passengers end up at storage yard instead of airport (Tom Lambert) Connecticut automobile emissions tests faulty (Danny Burstein) Diebold Opteva 520 ATM crashes exposing Windows XP Inside! (Scott A. Hissam) The RISKS of Risk Analysis (Michael Bednarek) Anti-spam lawsuit complaints (Monty Solomon) Self adjusting firewalls in Longhorn (Neil Youngman) Death of UK skydiver in Australia (Anthony Youngman) "Special Skills draft" (Geoffrey Brent) Risks of automated pedophilia detection (Nick Brown) Latest e-mail worms use password trick to foil filters (NewsScan) CORRECTION to "SSL is being severely stressed by phishing expeditions" (Alistair McDonald) Re: SSL is being severely stressed by phishing (Isaac Morland, Nelson Minar) Re: When is a decimal point not a decimal point? (John Carlyle-Clarke, Nick FitzGerald) Throwing out the baby with the bathwater: Crypto sigs (Tim Panton) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 17 Mar 2004 17:10:06 PST From: "Peter G. Neumann" <neumann@private> Subject: House Panel Slams Federal IT Security The latest "report card" of the U.S. House Government Reform Subcommittee on Technology on cybersecurity in U.S. government agencies continues to paint a generally dismal picture. The National Science Foundation and the Nuclear Regulatory Commission received A grades, while eight other agencies had F (Failing) grades -- including the Department of Homeland Security. FOURTEEN of 24 agencies received a score worse than C. According to U.S. Representative Adam Putnam (R-Fla.), Federal agencies aren't doing enough to secure their network systems, even as documented cyber-attacks against the U.S. government continue to rise dramatically -- from 489,890 in 2002 to 1.4 million in 2003. "Our government has taken very dramatic steps to increase our physical security, but protecting our information networks has not progressed commensurately either in the public or private sector." Putnam closed the hearing by saying his subcommittee will seek accountability of the "highest agency official responsible for information technology investments to insure that IT security is baked into the investment decision making process." [Source: Roy Mark, *Internet News*, 17 Mar 2004; PGN-ed] http://www.internetnews.com/infra/article.php/3327081 [What's New? Technology alone does not solve management problems. Management alone does not solve technology issues. Reducing risks is a beginning-to-end, end-to-end system problem where the systems include all of the relevant technology, all of the relevant people, and all of the dependencies on and interactions with the operating environment, however flawed and complicated. But those flaws and complexities must be addressed systemically. The many lessons familiar to RISKS readers tend to be widely ignored by the folks who should most seriously be learning them. PGN] ------------------------------ Date: Thu, 4 Mar 2004 14:19:12 -0500 From: "Peter G. Neumann" <neumann@private> Subject: JFK AirTrain passengers end up at storage yard instead of airport For the second time this year, passengers on the Kennedy Airport AirTrain were accidentally diverted to a unused-train storage yard -- where passengers were exposed to live rails. The 12 Feb 2004 mistake prompted an internal overview of the $1.9 billion, eight-mile long transit system to JFK. Fifteen minutes later, the train was back on course. A similar event occurred on 26 Jan 2004, with a train winding up in the same storage yard. [Source: FreeRepublic.com, 4 Mar 2004, PGN-ed.] http://www.freerepublic.com/focus/f-news/1091020/posts Thanks to Tom Lambert at ACM for noting this one. Tom's reaction was this: "Whenever I hear of MTA [subway system] plans to further automate subway service here in NY City, I think of events such as this one."] ------------------------------ Date: Tue, 16 Mar 2004 18:47:40 -0500 (EST) From: danny burstein <dannyb@private> Subject: Connecticut automobile emissions tests faulty Lisa Chedekel, Connecticut: New Emissions Tests Faulty, DMV Says False Readings May Have Led Inspectors To Fail Thousands Of Vehicles, (Hartford) *Courant*, 16 Mar 2004 As many as 13,000 vehicles tested under Connecticut's new emissions inspection program may have been failed in error because the software used to measure a critical pollutant produced false readings, state motor vehicle officials confirmed Monday. [...] In Connecticut, state Department of Motor Vehicle officials, working with Agbar technicians, discovered recently that an analyzer used to detect hexane, the main hydrocarbon present in gasoline exhaust, was instead measuring propane levels. http://www.ctnow.com/news/custom/topnews/hc-agbar0316.artmar16,1,5617910.story ?coll=hc-headlines-topnews Sigh. The usual two problems here. First, no one kept track of the expected versus the actual failure rates. And second, there's apparently no periodic quality control checks. (and third, of course, is the entire question of the value of emissions testing, but that's a horse of a different color) ------------------------------ Date: Thu, 18 Mar 2004 07:27:55 -0500 From: "Scott A. Hissam" <shissam@private> Subject: Diebold Opteva 520 ATM crashes exposing Windows XP Inside! Want to listen to a little Beethoven, Jazz, or even the Talking Heads while making that ATM deposit? * The Scene: Carnegie Mellon University * The Event: A newly installed Diebold Opteva 520 ATM crashes, then reboots. Surprisingly, it's vanilla-style Windows XP operating system initialized without the actual ATM software. * The Result: A desktop computer with only a touch screen interface is left wide open for the amusement of the most wired university in the U.S. Eschewing more malicious schemes, the first move was to connect to the Internet. This plan proved unsuccessful as there seemed to be no network capability. The situation was complicated in that even typing proved extremely difficult due to the lack of a keyboard. The Character Map program was used to enter text by copy-and-pasting, yet the most that was accomplished by doing so was making the text-to-voice program say, "What, do you think I'm made of money?" Windows Media Player was set up to loop a series of Beethoven, Jazz, and Talking Heads (the sample sound files included with XP) while running a full screen visualization. [Source: http://midnightspaghetti.com/news.htm; 17 Mar 2004] [Another report noted by George Michaelson in Dave Farber's IP. PGN] ------------------------------ Date: Thu, 18 Mar 2004 00:02:58 +1000 From: Michael Bednarek <mb@private> Subject: The RISKS of Risk Analysis A recommendation by a Government agency to allow banana imports from the Philippines is being reviewed after finding an error in its risk assessment report, reports the ABC [Australian public broadcaster]. (1) According to the agency, Biosecurity Australia, it was a "transcription error in the electronic spreadsheet used in the estimation of risk for this particular IRA [import risk analysis]. The spreadsheet has now been corrected." (2) Well, it wasn't really a spreadsheet, but a MS Project file with the @Risk add-on. (3) A quote from the ABC's coverage: (1) "The Australian Banana Growers Council says its opposition to banana imports has been vindicated. Council spokesman Tony Heidrich says a revision is not good enough and the assessment process needs to start again from the beginning. 'We just don't think you can continue to have faith in Biosecurity Australia's ability to carry out this [import risk analysis],' Mr Heidrich said. 'We think there could well be fundamental flaws going right back the first commencement of the process.' " The RISK? Surely one of the oldest chestnuts in computerdom: don't believe something just because it's a computer printout. (1) <http://www.abc.net.au/news/newsitems/s1067958.htm> (2) <http://www.affa.gov.au/content/output.cfm ?ObjectID=DAD55B7F-9F61-49D3-9CB1B9F38F09A82F> (3) <http://www.palisade.com/html/risk_for_project.asp> Michael Bednarek http://mbednarek.com/ [This case was also noted by George Michaelson. Incidentally, for those of you who have not seen it, you might enjoy Section 7.10 of my *Computer-Related Risks* book, pages 255--257, entitled Risks in Risk Analysis, drawn from an earlier *CACM* Inside Risks column from June 1991, written by Robert N. Charette. It is still very relevant. PGN] ------------------------------ Date: Fri, 12 Mar 2004 09:35:30 -0500 From: Monty Solomon <monty@private> Subject: Anti-spam lawsuit complaints Spam Litigation http://news.findlaw.com/legalnews/documents/index.html#spam * Complaint and Exhibits (America Online, Inc. v. John Does 1-40) (March 9, 2004) http://news.findlaw.com/hdocs/docs/cyberlaw/aoldoes30904cmp.pdf * Complaint and Exhibits (America Online, Inc. v. Davis Wolfgang Hawke, et al. (March 9, 2004) http://news.findlaw.com/hdocs/docs/cyberlaw/aolhawke30904cmp.pdf * Complaint (Earthlink, Inc. v. John Does 1-25, et al. (March 9, 2004) http://news.findlaw.com/hdocs/docs/cyberlaw/elnkdoes30904cmp.pdf * Complaint (Microsoft Corp. v. JDO Media, Inc., et al. (March 9, 2004) http://news.findlaw.com/hdocs/docs/cyberlaw/msjdo30904cmp.pdf * Complaint (Microsoft Corp. v. John Does 1-50 d/b/a Super Viagra Group) (March 9, 2004) http://news.findlaw.com/hdocs/docs/cyberlaw/mssprviag30904cmp.pdf * Complaint (Yahoo!, Inc. v. Eric Head, et al. (March 9, 2004) http://news.findlaw.com/hdocs/docs/cyberlaw/yahoohead30904cmp.pdf [My unfiltered spam has gone through the roof again in the past two weeks. Thank you all for using the designated keyword in the subject line of your postings. So, I have a new strategy. I delete ALL of the unkeyworded NEW MAIL, and then check for exceptions. In the past week, I have detected only a few legitimate messages that did not use the keyword. The result is that even after SpamAssassin filtering, 95% of the residual e-mail is spam. But this really simplifies my pain. PGN] ------------------------------ Date: Wed, 17 Mar 2004 17:33:34 +0000 From: Neil <no.spam.for.n.youngman@private> Subject: Self adjusting firewalls in Longhorn According to http://www.internetnews.com/ent-news/article.php/3325631 "Longhorn engineers are packing new technologies into the OS to check against a central patching Web service for security holes on computers. If a user does not have a patch installed, Longhorn's active protection technology will kick in to adjust the firewall or PC settings" Great if it works and it doesn't break any critical functions. RISKS? how about blocking communication to/from a heart monitor in an intensive care ward? Further examples are left as an exercise for the reader ;-) According to Robert McLaws of Interscape Technologies, an independent software partner of Microsoft, "if they don't care enough to keep their systems secure, then they have lost that right to complain," ------------------------------ Date: Thu, 18 Mar 2004 12:45:47 -0000 From: "Anthony Youngman" <Anthony.Youngman@eca-international.com> Subject: Death of UK skydiver in Australia Skydiving victim Clare Barnes was doomed from the moment she jumped from a plane at 14,000ft, an enquiry revealed yesterday. What appears to have happened in this case is that all the cards have been stacked against her and have fallen the wrong way each time. A parachute has a number of components. They are largely interchangeable, but not always. She was apparently using her own equipment, and the incompatibilities meant that there was no way that parachute was going to open successfully. The risks are obvious and, sadly, tragic. ------------------------------ Date: Thu, 18 Mar 2004 10:52:18 +1100 From: Geoffrey Brent <g.brent@private> Subject: "Special Skills draft" The USA's Selective Service System has begun working on developing procedures and policies for a targeted military draft of Americans with computer and foreign-language skills, although the SSS has emphasised that such a draft is not imminent. http://sfgate.com/cgi-bin/article.cgi?f=/c/a/2004/03/13/MNG905K1BC1.DTL (A similar plan for selective drafting of medical personnel, the HCPDS, has already been assembled. See http://www.sss.gov/FSmedical.htm for a brief overview, or http://www.livejournal.com/users/turnberryknkn/79171.html for a friend's observations on the HCPDS - some of which may also be pertinent to this latest project.) It has long been known that conscripts are vastly less effective and less reliable than volunteer soldiers; during the Korean War, the AP famously reported that only one in four US draftees used their weapons even when defending against enemy attack. Computing is a field where a sloppy, unmotivated worker can all too easily achieve negative productivity without immediate detection. A disgruntled, _malicious_ worker can do far worse - compare the man-hours spent in writing malware with those spent in repairing its effects. Relying on conscripts to supply the computer expertise the US armed forces might need strikes me as an exceptionally bad idea. ------------------------------ Date: Thu, 18 Mar 2004 16:16:49 +0100 From: Nick Brown <Nick.BROWN@private> Subject: Risks of automated pedophilia detection The BBC's web site reports on a "chatbot" program which is designed to run in chat rooms oriented at children, and detect when the people chatting with it may be attempting to lure children into "inappropriate" activity. Highlights: 'The chatbot has already been used in many chatrooms and its creator claims that, so far, no-one has caught it out.' (Nothing unsubstantiated or speculative there, then.) '[The author of the software] said that information gathered by the Chatnannies had already helped some police investigations.' (Uh-huh.) '"If this software works, then it would be marvelous because there is nothing like this out there," Chris Atkinson, Internet safety officer at the National Society for the Prevention of Cruelty to Children, said.' (Can you say "non-sequitur" ?) The RISKs are left as an exercise to the reader, but to get you started: - How will law enforcement officers tend to treat chatroom participants whose behaviour has been flagged as dubious by this program ? Will they spend large amounts of resources to trap a pedophile, only to find that all they meet is an over-eager 13-year-old boy ? - The claims made for this software seem to amount to passing the original Turing test. That's quite an achievement. I wonder if the software community will be allowed to verify these claims; or will the bot be kept secret "to protect the children"? http://news.bbc.co.uk/2/hi/technology/3520834.stm Nick Brown, Strasbourg, France ------------------------------ Date: Tue, 16 Mar 2004 07:09:31 -0700 From: "NewsScan" <newsscan@private> Subject: Latest e-mail worms use password trick to foil filters The most recent versions of the pesky Bagle worm -- Bagle N and Bagle O -- arrive in a compressed and password-locked .zip or .rar file with the password included in the body of the e-mail along with a message urging the recipient to open it right away. This latest technique is designed to foil corporate e-mail filters that may block ordinary zipped attachments but allow password-protected documents to pass through the network's defenses unimpeded. Once the attachment is unlocked, the worm is then forwarded to everyone in the victim's e-mail address book. "The worm's author is sneakily trying to make it more difficult for antivirus products to scan inside the password-protected files," says Graham Cluley, a researcher with U.K cybersecurity firm Sophos. [*New Scientist*, 15 Mar 2004; NewsScan Daily, 16 Mar 2004] http://www.newscientist.com/news/news.jsp?id=ns99994777 ------------------------------ Date: Wed, 17 Mar 2004 08:44:55 -0000 (GMT) From: "Alistair McDonald" <alistair@private> Subject: CORRECTION to "SSL is being severely stressed by phishing expeditions" I am indebted to David Wagner for correcting me when reporting on the Netcraft News item, regarding plain-text SSL, in RISKS-23.27. Those with better knowledge than I have been discussing this, and, in David's own words, the reports are "Hogwash". David has provided a link to a newsgroup archive at Google groups: http://tinyurl.com/39p4h where the matter is discussed. If you're interested, then please take a look. The risks (to me): don't believe everything you read, even if it comes from a normally reputable source. Alistair McDonald (+44)(0)7017-467386 ------------------------------ Date: Thu, 18 Mar 2004 08:37:06 -0500 (EST) From: Isaac Morland <ijmorlan@private> Subject: Re: SSL is being severely stressed by phishing (RISKS-23.27) Of course, the ultimate fix to phishing would be an end to the mixed-endian nature of URLs: The domain name and user/password are little-endian, while the rest of the URL is big-endian. So for example, a bogus url like http://www.microsoft.com@abcd:hacker.org/a/b/c?hack=yes&ddos=true would look like this in big-endian form: http://org.hacker:www.microsoft.com@abcd/a/b/c?hack=yes&ddos=true Note that even disallowing the user/password stuff would still allow an URL like this: http://www.microsoft.com.index.html.com/hack Which again is quickly revealed as a fraud in big-endian notation. So the real fix is to use big-endian notation. Of course, in real life this would never work even if the technical aspects would be worked out because people will just click on anything. But we can dream. ------------------------------ Date: Tue, 16 Mar 2004 16:40:03 -0800 From: Nelson Minar <nelson@private> Subject: Re: SSL is being severely stressed by phishing (RISKS-23.27) "Alistair McDonald" <alistair@private> writes: >My advice on phishing avoidance: never click on a link in an e-mail from a >financial institution, always navigate from a bookmark. If possible, avoid >typing in web addresses too Microsoft offered one more item to your advice: don't click on links on web pages. Or as Microsoft Knowledge Base Article - 833786 said: The most effective step that you can take to help protect yourself from malicious hyperlinks is not to click them. Rather, type the URL of your intended destination in the address bar yourself. By manually typing the URL in the address bar, you can verify the information that Internet Explorer uses to access the destination Web site. To do so, type the URL in the Address bar, and then press ENTER. This absurd suggestion used to appear here: http://support.microsoft.com/default.aspx?scid=kb;%5Bln%5D;833786 It's since been removed and a patch for this problem has been issued. (Search for the above quote to find many copies of the original.) Something is seriously wrong with the state of Web security when the approved way to verify the identity of a site is to look for a 16x16 icon in one corner of the screen and even that doesn't work in many cases. It's not just MSIE URL display bugs or obscure SSL modes at fault; the model is broken. ------------------------------ Date: Wed, 17 Mar 2004 11:33:24 -0000 From: "John Carlyle-Clarke" <john.cc@private> Subject: Re: When is a decimal point not a decimal point? (RISKS-23.27) > Date: Thu, 11 Mar 2004 23:40:51 +1100 > From: "Darryl Smith" <Darryl@radio-active.net.au> > Subject: When is a decimal point not a decimal point? > Unfortunately on systems where the locale has been changed to have > a comma as a decimal place, then Visual Basic ignores the fact > that I have specifically stated that I want to use a decimal point > when I format the number into a string, and changes it to a comma. > To be fair to Microsoft this is listed in the manual Visual Basic > 6. We encounter the same problem regularly with VB software that we produce. We have made efforts to by default use Val and Str (which are non-locale aware functions) unless a locale aware conversion is specifically needed. We have also written our own non-locale aware Format replacement where number formatting is needed. A RISK here is that salepeople assume that producing French and German versions of the software will be "just a matter of translating a few strings", which ignores the many pitfalls. This is before you even try more complex problems like non-Roman alphabet languages, or even right-to-left ones! Another gotcha: if you change your locale on your development machine to test the effects, VB breaks its own source code. If the hidden part of form files (text format, but concealed by the IDE) contains any non-integer numbers, VB will save them using the locale settings. Switching back can make the project fail to load. The RISK, it seems to me, is assuming that OS locale-handling functions will deal with all these problems without the developer having to worry about it, and approaching language or locale conversion as a "Phase 2" option, rather than being aware of it from the outset. Like many others, I imagine, this was learned the hard way for us. (Perhaps this is mostly a UK/USA problem? Maybe developers in other countries tend to be more aware of this.) ------------------------------ Date: Wed, 17 Mar 2004 14:16:55 +1300 From: Nick FitzGerald <nick@virus-l.demon.co.uk> Subject: Re: When is a decimal point not a decimal point? (Smith, RISKS-23.27) "Darryl Smith" <Darryl@radio-active.net.au> wrote: <<snip gory details>> > Unfortunately on systems where the locale has been changed to have a comma > as a decimal place, then Visual Basic ignores the fact that I have > specifically stated that I want to use a decimal point when I format the > number into a string, and changes it to a comma. ... Your description of what VB is doing is incorrect. When you write and compile your program on a system whose locale settings mean "<digit>.<digit>" represents a "decimal number", VB is taking note of the meta-information about locales, number (and no doubt, date, time and several other) formats and representing that internally in a locale- independent way. > ... To be fair to Microsoft > this is listed in the manual Visual Basic 6. Precisely. VB6 is designed to be localization sensitive and to more or less automatically handle such things on behalf of the programmer (depending where in Canada your correspondent is, there is a high probability that any VB6 runtime error messages generated by your program will be displayed in French too...). > Of course since the NMEA sentence I am generating uses commas as field > delimiters, the fields are getting totally messed up. And the mapping > software is making its best effort to display the obviously incorrect > position. > > The risk: using the same character to denote decimal places as for denoting > different fields is not a good idea. This is an historic issue with "soft" data formats where field and/or record delimiters occur "in-band" (i.e. in the same transmission stream) _and_ where the set of such delimiters contains one (or more) characters that can validly comprise part of a valid field value. I think the greater risk you have described is that of a programmer using a tool whose complete feature set s/he was not fully aware of. This is a class of risk that is probably much greater the "simpler" the tool is to use (assuming it is a tool of modest power, as VB6 certainly is). This is so for (at least) two obvious reasons -- if a powerful (and therefore complex) tool is made simple to use much of its complexity is necessarily hidden (at least from those of its likely users who are less widely experienced in that field), and simple yet powerful tools are likely to attract the attention (and use) of those who are otherwise prevented access to such power (because other such tools are obtuse for not disguising their complexity, etc). (I'm not a VB user, but suspect a simple, albeit perhaps not strictly "correct" solution to the issue here might be to quote the field values, at least for those fields that can contain such "ambiguous" data values.) And finally, there was potential for an even larger risk in this story -- had your Canadian user had a GPS device that expected "locale- correct" input and was configured for "French Canadian" language or somesuch, your program would have worked for reasons you would not have understood _nor_ been unaware of... ------------------------------ Date: Wed, 17 Mar 2004 17:32:28 +0000 From: Tim Panton <thp@private> Subject: Throwing out the baby with the bathwater: Crypto sigs What's wrong with this picture ? > [demime 0.98b removed an attachment of type > application/pkcs7-signature which had a name of smime.p7s] So in order to protect me from a potential virus, the sending system has removed the one thing that would have helped me judge the provenance of the e-mail. To be fair, stripping cryptographic signatures isn't entirely stupid if either: (a) the crypto software is not sanity checking its inputs, or (b) the mail client can be fooled into executing an attachment that the mail gateway took to be a data, i.e., a signature. Unfortunately both of these conditions are true for most Outlook on Windows setups (or at least were until the recent ASN1 patch). This isn't really any different from the problems we saw with buffer overruns in the from line permitting execution of arbitrary code. In that case no one stripped from addresses as a protective measure! We still have a prevalent mindset that sees security (in this case authentication) as optional. I suppose that's what I'm complaining about. By the way, as an author of an ASN1 decoder (for SNMP), I know how hard it is to parse ASN1 securely. If you use the right language and design, it really isn't that hard. The sender is a mailing list with a strict no-attachments policy, so it could be said that they are just treating the signature like any other attachment. However it would be a sad day if this were the norm, as signatures should be part of the solution to spam and viruses -- not part of the problem. ------------------------------ Date: 28 Jan 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. Alternatively, via majordomo, send e-mail requests to <risks-request@private> with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomo@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.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. *** NEW: 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 the Lindsay Marshall's Newcastle archive http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., 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.28 ************************
This archive was generated by hypermail 2b30 : Thu Mar 18 2004 - 11:39:24 PST