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