RISKS-LIST: Risks-Forum Digest Wednesday 22 June 2005 Volume 23 : Issue 91 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.91.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: [Seasonal Slowdown in effect] New Zealand Outage Shut Down Stock Exchange (Marcus H. Sachs) First no more air maps, next no more road maps? (Dan Jacobson) TSA kept passenger information it promised not to (PGN) Libraries Say Yes, Officials Do Quiz Them About Users (Eric Lichtblau from Richard Forno via Dave Farber) SOFTWARE 2015 (Jim Horning) US e-government risks (Al Macintyre) Asian Hackers Blamed for Attacks On U.K., U.S. Computer Networks (Cassell Bryan-Low) CardSystems' noncompliant practice compromises credit information (Eric Dash via Monty Solomon) CardSystems' Systems (Al Macintyre) Hacker accesses files at Equifax (Bob Heuman) Cell Phones Now Playing Role of Wallet (Bruce Meyerson via Monty Solomon) SIM Cards with GPRS (Darryl Smith) New 'Heathrow Connect' Trains - do not want to go to Heathrow! (S Byers) Re: Plane diverts after erroneous hijack alert (Dan Jacobson) REVIEW: "Brute Force", Matt Curtin (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 20 Jun 2005 19:57:49 -0400 From: "Marcus H. Sachs" <marcus.sachs@private> Subject: New Zealand Outage Shut Down Stock Exchange A major outage in New Zealand Telecom Corp.'s cable network Monday disrupted data services, electronic cash transactions, mobile phone, and Internet services, as well as shutting down the nation's stock exchange for hours (the third time in the past nine months that data link failures have halted trading). Widespread disruption to business and private services was caused by two cable breaks on its North Island network. They were repaired by mid-afternoon Monday--at least five hours after they occurred. [Internet service and mobile phones were also out of commission due to two cable breaks. MHS] The outage was caused by two separate incidents, including a fiber cable break north of the capital, Wellington, and a second cable being cut in Taranaki province on the west coast of North Island, more than 300 kilometers (188 miles) north of Wellington. [Source: Associated Press, 20 Jun 2005; PGN-ed] http://www.informationweek.com/story/showArticle.jhtml?articleID=164900973 ------------------------------ Date: Mon, 20 Jun 2005 19:06:46 +0800 From: Dan Jacobson <jidanni@private> Subject: First no more air maps, next no more road maps? The U.S. National Geospatial-Intelligence Agency (NGA) has proposed to withdraw all aeronautical data and products from public distribution. http://www.urisa.org/Board_Initiatives/NGA.htm ------------------------------ Date: Tue, 21 Jun 2005 11:15:52 PDT From: "Peter G. Neumann" <neumann@private> Subject: TSA kept passenger information it promised not to "The Transportation Security Administration has done exactly what Congress told it not to do -- and what it said it wouldn't do." [Source: Associated Press item, 20 Jun 2005] http://www.news4jax.com/travelgetaways/4631077/detail.html ------------------------------ Date: June 20, 2005 4:29:12 PM EDT From: Richard Forno <rforno@private> Subject: Libraries Say Yes, Officials Do Quiz Them About Users (from article by Eric Lichtblau, via Dave Farber's IP) Law enforcement officials have made at least 200 formal and informal inquiries to libraries for information on reading material and other internal matters since October 2001, according to a new study that adds grist to the growing debate in Congress over the government's counterterrorism powers. In some cases, agents used subpoenas or other formal demands to obtain information like lists of users checking out a book on Osama bin Laden. Other requests were informal -- and were sometimes turned down by librarians who chafed at the notion of turning over such material, said the American Library Association, which commissioned the study. [Source: Eric Lichtblau, *The New York Times*, 20 Jun 2005; PGN-ed] http://www.nytimes.com/2005/06/20/politics/20patriot.html? Dave Farber's IP Archives: http://www.interesting-people.org/archives/interesting-people/ ------------------------------ Date: Thu, 16 Jun 2005 13:06:52 -0700 From: "Horning, Jim" <Jim.Horning@private> Subject: SOFTWARE 2015 There's a recent report by the Center for National Software Studies that does not seem to have been adequately publicized, and hence has not received the attention it deserves: "SOFTWARE 2015: A National Software Strategy to Ensure U.S. Security and Competitiveness" http://www.cnsoftware.org/nss2report/NSS2FinalReport04-29-05PDF.pdf Risks loom large in the discussion, including * Risk of critical infrastructure failures * Risk of sudden and severe economic loss * Risk of loss of life and limb * Risk of loss of public confidence * Risk of loss of our technological edge and leadership I've posted excerpts from the Executive Summary at both http://bayosphere.com/node/554 and http://horning.blogspot.com/2005/06/software-2015.html ------------------------------ Date: Thu, 16 Jun 2005 08:35:28 -0500 From: Al Mac <macwheel99@private> Subject: US e-government risks The GAO surveyed what passes for computer security at scores of US Government agencies, and conducted some tests to see what is needed. This investigative arm of the US Congress determined that the fast majority of US Gov agencies are oblivious to most of the threats, detailing what they found in a 79 page report http://www.gao.gov/cgi-bin/getrpt?GAO-05-231 with a 1 page summary http://www.gao.gov/highlights/d05231high.pdf Your pal Al read through the whole story and wrote up a 5 page summary which you can find in the archives of other discussion groups http://groups.yahoo.com/group/e-com-sec/message/1729 http://groups.yahoo.com/group/TYR/message/23897 http://groups.yahoo.com/group/VeeWire/message/2736 Al Macintyre http://www.ryze.com/go/Al9Mac BPCS/400 Computer Janitor ------------------------------ Date: Mon, 20 Jun 2005 17:12:34 PDT From: "Peter G. Neumann" <neumann@private> Subject: Asian Hackers Blamed for Attacks On U.K., U.S. Computer Networks Bid to Steal Valuable Data Targets Corporate Systems, Government Institutions Article by Cassell Bryan-Low, *The Wall Street Journal*, 20 Jun 2005; PGN-ed] A U.K.'s National Infrastructure Security Coordination Center (NISCC) report says unidentified hackers from Asia have been launching a wave of attacks on government and corporate computer systems in the U.S., Canada, and the U.K. in an effort to steal sensitive commercially and economically valuable information. ------------------------------ Date: Mon, 20 Jun 2005 01:45:54 -0400 From: Monty Solomon <monty@private> Subject: CardSystems' noncompliant practice compromises credit information (Eric Dash) CardSystems (a Tucson AZ company that handles credit card transactions for smaller banks and merchants) turns out to have been the source what was reported as the potential compromise of 40,000,000 credit cards (Visa, MasterCard, and American Express). In violation of established procedures, CardSystems was keeping old transactions online -- for research purposes -- with the intent of analyzing incompletely processed transactions. Something on the order of of 200,000 cards may be particularly at risk, and 70,000 bogus charges have already been reported. The CardSystems systems were hit with a virus that resulted in the capture of the information. [Source: Lost Credit Data Improperly Kept, Company Admits, Eric Dash, *The New York Times*, 20 Jun 2005; PGN-ed] http://www.nytimes.com/2005/06/20/technology/20credit.html?ex=1276920000&en=04e9ba4fe5ae0543&ei=5088 ------------------------------ Date: Tue, 21 Jun 2005 04:55:38 -0500 From: Al Mac <macwheel99@private> Subject: CardSystems' Systems We can figure out what kind of computer system was at CardSystems when they (a) placed 40 million credit card transactions at risk of breach (b) had 200,000 actually hacked http://www.nytimes.com/2005/06/20/technology/20credit.html?hp&ex=3D111932640=0&en=3Dd0b4ff6a62629204&ei=3D5094&partner=3Dhomepage May 22 they discovered the breach by magic, independently of Master Card tracing fraud to them, and fixed the problem immediately May 27 they flunked a Visa security audit, to check whether in fact they had fixed the problem http://www.redherring.com/Article.aspx?a=3D12451&hed=3DCardSystems+May+Face+=Fine According to http://www.cardsystems.com/car=ADeers.html (the recruiting page for the company), CardSystems has the following types of systems installed: Microsoft .NET (and Windows servers) Oracle databases VMS http://groups-beta.google.com/group/bit.listserv.ibm-main/browse_thread/thread/7924e794e51d444d/719ed6452cf16035?q=3Dwww.cardsystems.com%2F&rnum=3D1&hl=3Den#719ed6452cf16035 A few years ago CardSystems advertised for a Programmer Analyst in Experience in one or more of the following areas: C++, Java, Visual Basic reqd. E-commerce, HTML, XML, ASP, MTS, COM, CORBA, UML Windows/NT http://groups-beta.google.com/group/az.jobs/browse_thread/thread/ae4469478c923be4/ac08e9e84f79560b?q=3Dwww.cardsystems.com%2F&rnum=3D5&hl=3Den#ac08e9e84f79560b A few days before this breach news story hit the fan, CardSystems was boasting about their great systems. CardSystems Solutions Inc. is a leading provider of integrated payment solutions to associations, financial institutions, Independent Sales Organizations and retail merchants. With CardSystems' comprehensive and flexible array of processing services, clients can manage the entire payment processing cycle and customize services to fit their needs while maintaining complete control of risk, dispute resolution and proprietary customer data. CardSystems' intelligent enabling technologies include an expert system, neural network and service offerings optimized for the card processing industry. CardSystems products include traditional terminals, integrated applications and e-payment solutions. The company processes payment transactions for more than 125,000 customer locations. http://home.businesswire.com/portal/site/google/index.jsp?ndmViewId=3Dnews_view&newsId=3D20050614005656&newsLang=3Den Data at risk: Credit Card Account #s, their expiration dates, what brand (e.g. Visa), what bank (e.g. MBNA) Names of people on the credit cards the 3-4 security #s found on back of cards Data NOT taken: addresses, phone #s, date of birth, mother's maiden name, nationality, gender, social security #s etc. for the names of people on the credit cards PIN # where the credit card can be used in an ATM machine Al Macintyre http://www.ryze.com/go/Al9Mac ------------------------------ Date: Fri, 17 Jun 2005 21:55:34 -0600 From: RsH <rsh@private> Subject: Hacker accesses files at Equifax As per CBC news, 17 June 2005, another hack into a sensitive area at one of Canada's two major credit bureaus: A computer hacker has accessed the files of about 600 consumers at Equifax Canada, one of Canada's major credit bureaus. Most of the files are for consumers from British Columbia. Equifax Canada uses data provided by banks to compile credit records on Canadian consumers. Those records include personal information such as social insurance numbers, bank account numbers and up to six years of credit and banking history ... Equifax said all affected customers in this latest breach have been contacted. The RCMP is investigating. http://www.cbc.ca/story/business/national/2005/06/17/equifax-050617.html R.S. (Bob) Heuman, Toronto, ON, Canada, Indep. Computer Security Consulting Web Site Auditing for Compliance with Standards rsh@private ------------------------------ Date: Sat, 18 Jun 2005 00:11:34 -0400 From: Monty Solomon <monty@private> Subject: Cell Phones Now Playing Role of Wallet (Bruce Meyerson) With the number of cell phones in the world is reportedly about 1/4 of the world's population, the next step seems to be incorporating all of your credit and debit cards into a single wireless multipurpose mobile device. In Japan, DoCoMo already has 3 million cell-phone subscribers using its Mobile Wallet. The next step seems to be the incorporation of checkbooks, Quicken, PayPal, CheckFree, etc. [Source: Bruce Meyerson, Associated Press, 17 Jun 2005; PGN-ed] http://finance.lycos.com/home/news/story.asp?story=49940191 Risks??? What risks? ------------------------------ Date: Thu, 16 Jun 2005 18:54:04 +1000 From: "Darryl Smith" <Darryl@radio-active.net.au> Subject: SIM Cards with GPRS I am a GPS tracking consultant - and I usually use GPRS, which is a packet switched data service built on top of GSM. Unlike AMPS and CDMA, the personality of each mobile device is stored in a Smart Card called a SIM card. This stores the local encryption key as well as a serial number that points to your phone number. It also stores information on the preferred GSM network to connect to and your phonebook. If you want to swap phones you just swap SIM cards. This makes upgrading phones really easy, and also makes it easy to rent a phone in another country if your phone does not work in that country because it operates on a different frequency. One of my clients was issued 80 SIM cards for a project I was doing for them. The carrier supplied the SIM cards as well as printed documentation listing the serial number for each card. This serial number is the reference that translates into a phone number and a billing identifier. This customer also arranged to have their own VPN set up so that their data traffic would not pass over the internet but over a private link between the carrier and customer. The way this is done is by assigning a different APN or Access Point Name. This APN was specific to this customer, and no-one else had access to it. When I was testing the equipment with the SIM cards and the custom APN, the SIM cards would not work. So I tried it in my GPRS phone - and strangely it worked using the standard APN. This did not surprise me as the carrier was notorious for not correctly configuring the APN. My customer then sent the list of SIM cards to the carrier for them to fix, attaching the custom APN. This was the same list the carrier had provided to them, but thanks to business processes it was easiest for my client to e-mail the carrier the list back. The changed the APN on all 80 cards to the custom APN, removing GPRS access through the default APN to all cards. 24 hours later I tried the equipment again, and it still did not work. So I rang my client, and for a joke I told him the serial number of the SIM card, and asked him if it was on his list. I was rather surprised when he could find no reference of it. Comparing his list of serial numbers to my list of serial numbers, we worked out that only 3 out of 80 of the SIM cards were on his list. So my client then contacted the carrier. After some discussions, the carrier then transferred the 77 SIM cards to my client, and presumably restored the correct APN to the other 77 SIM cards being used by other clients returning GPRS functionality. What had happened is that the carrier did not provide the correct SIM Serial Numbers to my client in the first place. My client assumed that this list was correct. I did not care what the serial numbers were, but I recorded them on each piece of equipment anyway, copying the number from the cards themselves, rather than copying from his list. Then my client, assuming his list was accurate e-mailed the carrier, and the carrier assumed that this list was correct. And then changed the SIM cards to 'Fix Them', breaking many other services at the same time. Management in the carrier took some time to be convinced that they had not issued the correct serial numbers to the client - even wanting to speak to me directly to verify that I physically had these SIM cards in my possession. Right now my clients GPRS devices seem to be working, but I have no idea about the 77 SIM cards being used by other clients. This is likely to be a huge billing nightmare too. Thankfully we only used a few cents worth of GPRS bandwidth on cards that did not (at the time) belong to my client. The risk? Don't rely on information that a supplier gives you. Do not rely on information a customer gives you without cross checking it. Do not rely on mobile devices for critical purposes if there is any chance that someone could re-configure your mobile device. Darryl Smith, VK2TDS, POBox 169 Ingleburn NSW 2565 Australia +61 4 12 929 634 www.radio-active.net.au/blog/ www.radio-active.net.au/web/tracking/ ------------------------------ Date: 16 Jun 2005 05:47:38 -0700 From: "SB" <s_byers666@private> Subject: New 'Heathrow Connect' Trains - do not want to go to Heathrow! A new electric train service has just started between Heathrow Airport and Paddington Station in West London, UK. This uses brand new multi-million-pound trains made by Siemens in Germany/France. They were specially designed for the British Airports Authority (BAA) and First Great Western Link (FGWL) who have the main franchise for services out of Paddington (in West London). The emergency evacuation instructions engraved on the windows are all in French - somewhat important since there have been at least three very major fatal crashes on the line. The trains are highly computerised but not so automated in that they still need revenue protection officers (ticket inspectors) to check tickets in the three carriages. They are short trains. The route is a short one but ordinary tickets and Travel Cards (one day go anywhere 'seasons') are available - EXCEPT for the one mile link between the last station on the mainline and Heathrow Airport itself. This is priced at 6 UK pounds, making it the most expensive train fare in the world for the distance. Fare more expensive per mile or kilometre than even for Concord. The equivalent bus fare is a mere one pound 20 pence. However these multimillions trains have a fault. This doesn't bother regular travelers on the line well used to the vicissitudes of the alternative ex-Thames Trains and FGWL services. But it might bother travelers from overseas. This is that the on-board announcements are computerised. Unfortunately however the computer controlling them hasn't a clue where the train is and keeps on announcing that the "next stop is Paddington where the train terminates," and "please mind the step between the train and the platform." And "please make sure you take all of your belongings with you when you leave the train." On the way to Heathrow every next station is announced as Ealing Broadway (an intermediate stop) even if Ealing Broadway has long been called at. And other intermediate stations, e.g. Southall, are announced as being Hanwell or somewhere else. There is also a problem with the computerised braking system in that at Hayes and Harlington Station the trains invariable pull up a LONG way from the entrance. Other trains pull up near the entrance. This means that sans announcements from station staff passengers have to run after the train in order to board it. The trains are soon to be extended to four carriages long. For this they have to be shipped back to Siemens in Europe. Apparently it is not possible to do this work in the UK. And the Risks? Emergency instructions do need to be in the majority language of the country in which the trains are designed for. Computerised announcement systems have been around for a long while, passengers do need the correct information especially when there is a charge of 6 pounds if they inadvertently stay on board for the extra very short trip into Heathrow itself, and staff are there to make sure they pay up. Adding an extra carriage should not have to entail shipping an entire train unit back to the manufacturers in a different country. At least these trains do not have the fault of earlier electric units that were so computerised that the doors wouldn't open at stations to let passengers on/off - because the sun had gone behind a cloud and there wasn't enough power to operate the door release mechanism. ------------------------------ Date: Sun, 19 Jun 2005 06:12:15 +0800 From: Dan Jacobson <jidanni@private> Subject: Re: Plane diverts after erroneous hijack alert (Kuenning, R-23.89) http://www.faa.gov/atpubs/ATC/Chp10/atc1002.html http://www1.faa.gov/atpubs/AIM/Chap4/aim0401.html: When making routine code changes, pilots should avoid inadvertent selection of Codes 7500, 7600 or 7700 thereby causing momentary false alarms at automated ground facilities. For example, when switching from Code 2700 to Code 7200, switch first to 2200 then to 7200, NOT to 7700 and then 7200. This procedure applies to nondiscrete Code 7500 and all discrete codes in the 7600 and 7700 series (i.e. 7600-7677, 7700-7777) which will trigger special indicators in automated facilities. Only nondiscrete Code 7500 will be decoded as the hijack code. ------------------------------ Date: Thu, 16 Jun 2005 16:06:54 -0800 From: Rob Slade <rslade@private> Subject: REVIEW: "Brute Force", Matt Curtin BKBRTFRC.RVW 20050531 "Brute Force", Matt Curtin, 2005, 0-387-20109-2, U$25.00/C$33.50 %A Matt Curtin http://ergo-sum.us/brute-force/ %C 233 Spring St., New York, NY 10013 %D 2005 %G 0-387-20109-2 %I Copernicus/Springer-Verlag %O U$25.00/C$33.50 800-842-3636, 212-460-1500, fax: +1-212-254-9499 %O http://www.amazon.com/exec/obidos/ASIN/0387201092/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0387201092/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0387201092/robsladesin03-20 %O Audience i+ Tech 2 Writing 3 (see revfaq.htm for explanation) %P 291 p. %T "Brute Force: Cracking the Data Encryption Standard" As the subtitle states, this is the story of the assessment of the strength (and weakness) of the Data Encryption Standard, particularly as computer power increased over time. Specifically, it is the tale of the formation and development of the DESCHALL operation, one of the forerunners of distributed.net. It is not just a story, though: Curtin tells the tale from a specific social and political perspective. An indication of this position is given in the forward, where John Gilmore reiterates the somewhat questionable assertion that DES was "deliberately ... flawed." Although this work does not address more technical aspects of cryptography, using hyperbolic arguments such as this may weaken the overall case of the book in regard to cryptographic censorship. There are forty-one very short chapters to the book, the first describing the particular machine that found the key for the first DESCHALL distributed cracking attempt. A brief history and background for cryptography is given in chapter two. Chapter three outlines the process of transforming Lucifer into DES. However, there are numerous errors in the account. Some are minor. (The Data Encryption Standard and the Data Encryption Algorithm are not equivalent: the algorithm is the engine, while the standard includes additional functions for real world operations.) Other problems include issues such as the fact that the modification of S-boxes (the substitution function, which the book refers to as permutation) is mentioned, while that of the P-boxes (permutation) is not. Most references state that the Lucifer version finally submitted for DES was 70 bit, rather than 112 bit. It is quite misleading to say that a 112 bit key is "fifty-six times" as strong as a 56 bit key. The Diffie-Hellman objections to the 56 bit key length are not given in detail, which makes the arguments hard to assess. Not all the dates are given, which sometimes creates difficulty in following the thread. (In response to a first draft of this review, Curtin has noted that he has collected a fairly extensive errata for the book, and hopes to correct the issues in a second edition.) Chapter four is a rather mixed bag: despite the "Key Length" title, it touches on various algorithms, cryptanalytic concepts, and other topics. (There is a seeming confusion of the Vernam cipher with a one-time pad, and triple DES is generally considered to have an effective 112 or 113 bit key, rather than 168, due to the meet-in-the- middle attack.) The author's personal involvement with cryptology, and analysis of the feasibility of cracking cryptosystems, is outlined in chapters five through eight, culminating in a review of the possibilities of distributed computing. The technical, social, and political factors involved in creating and operating the DESCHALL team are discussed in chapters nine to thirty-eight. (It is odd that explanations of IP addresses almost always use the non-routable 192.168.x.x range. Specific IP addresses have a depressing tendency to change and so non-routable addresses are often used in explanations, but it seems particularly inappropriate when the subject deals with identification and location of machines.) The material is fascinating, instructive, and even exciting at times. Interspersed are mentions of legislative debates and hearings into cryptographic policy during that time. Two chapters cover events subsequent to DES Challenge I, while analysis and lessons learned are reviewed in forty- one. The density of errors in the early chapters is unfortunate, since it is not representative of the work as a whole, and yet it may lead readers to distrust the facts in the book. In reality, there are significant points to be made, not only in terms of cryptography and public policy, but also in regard to distributed computing itself. The book is certainly useful for those interested in the issue of brute force attacks against cryptographic systems, and is an engaging read for anyone into technology. copyright Robert M. Slade, 2005 BKBRTFRC.RVW 20050531 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.91 ************************
This archive was generated by hypermail 2.1.3 : Wed Jun 22 2005 - 11:23:41 PDT