RISKS-LIST: Risks-Forum Digest Saturday 28 January 2006 Volume 24 : Issue 15
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/24.15.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Google's Search Query Log vs. China Censoring: Perceptions Matter!
(Lauren Weinstein)
NSA on redacting Word and PDF documents (dmagda)
NTSB report on Southwest Airlines crash (Joe Thompson)
United computer failure (Steve Wildstrom)
H&R Block blunder exposed SSNs (Leigh Blankenship)
"Analog Hole" Bill to impose secret requirement? (Randall)
NSA explains how to redact documents electronically (Steven M. Bellovin)
Phone calling records for sale instantly (Lauren Weinstein via PGN)
'Hacker' held over U.S. Navy breach (Bob Heuman)
Bank loses tape with personal information on 90,000 customers
(John Christoffersen via Monty Solomon)
Re: Bank loses tape with personal information on 90,000 customers (Dan Shoop)
Another finger goof at the Tokyo Exchange, Lower loss, wrong company!
(Bob Heuman)
E-mail and the courts (Art T.)
Cisco, haven't we learned anything? (Gadi Evron)
REVIEW: "Rootkits", Greg Hoglund/James Butler (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Thu, 26 Jan 2006 17:39:19 -0800 (PST)
From: Lauren Weinstein <lauren@private>
Subject: Google's Search Query Log vs. China Censoring: Perceptions Matter!
Reality matters, but perceptions can matter even more.
The juxtaposition of Google's stance on the Feds' search query log COPA data
demand and Google's decision to cooperate with China's censorship does not
realistically represent "hypocrisy" as is being erroneously suggested by
various media articles. The two issues are very different in many key
aspects.
However, this is not to minimize the enormous risks to Google -- and other
Internet services -- if they're perceived to be making "inconsistent" policy
decisions that directly affect important issues (often relating to
essentially non-technical impacts) about which many people are very
concerned, and often very emotional.
Now, as was completely predictable, Congress is getting involved.
Congressman Tim Ryan has announced a hearing of the Congressional Human
Rights Caucus (16 Feb is the date that I've heard) to explore the potential
drafting of laws that would limit or otherwise control U.S.-based Internet
companies from complying with the censorship demands of foreign
countries. Emotions were clearly exasperated by Google's launching of the
"dot-cn" Chinese version of Google search that blocks links as per Chinese
government directives, though Google is not alone in this regard among
U.S.-based Internet companies.
Ryan also specifically tied this to the COPA case, directly and dramatically
suggesting that Google was more willing to obey Chinese law than
U.S. law. This is an example of the perception risk I described above
crystalized in a very potent way.
The situation highlights the minefield of issues that Google and other
Internet companies now face, and the desperate need for proactive approaches
to dealing with the ways that these technologies affect individuals and
society.
Google's participation in the Chinese censorship program (which I consider
to be extremely problematic) creates a perception that is undermining what I
view as Google's correct decision regarding the search query COPA case, with
the sorts of reactions we're now seeing.
Coincidentally, I spent a very pleasant afternoon two days ago at Google's
Los Angeles (actually Santa Monica) facilities giving a talk regarding
exactly these and other issues. This included (among other topics)
discussion both regarding those areas where I feel that Google is doing a
terrific job, and their policies and operations about which I've been
(sometimes highly) critical -- where I feel that changes would be of benefit
to Google, their users, and society at large. (Google invited me and we
scheduled this talk prior to the breaking of the COPA search query story --
talk about timing...)
I much appreciated the opportunity to address such issues directly at Google
and meeting a bunch of nice folks at the site. The talk was taped and I hope
that the video will become publicly available in the near future -- I'll let
you know.
Lauren Weinstein +1-818-225-2800 http://www.pfir.org/lauren
http://lauren.vortex.com http://daythink.vortex.com lauren@private
------------------------------
Date: Sat, 21 Jan 2006 10:23:42 -0500 (EST)
From: dmagda@private
Subject: NSA on redacting Word and PDF documents
There have been numerous cases in past RISKS issues where information has
been leaked via electronic documents. This includes mainly the history
included with Word files and "redacted" PDF files.
It seems that this has finally caught the attention of the US National
Security Agency (from [1]):
Section 2: Procedures to Sanitize a Word Document
The following steps were tested with MS Word 2000 and Acrobat 5.0 and 6.0.
Other recent versions should work similarly. While time-consuming, these
steps give the highest confidence that sensitive information is not hidden
in the released document. Copying the text and images into a blank document
is a good way to manually review a sensitive document, since sections can be
copied over one at a time as they are reviewed.
Found via Boing Boing [2].
[1] http://www.fas.org/sgp/othergov/dod/nsa-redact.pdf (670 KB)
[2] http://www.boingboing.net/2006/01/21/nsa_howto_sanitize_w.html
------------------------------
Date: Fri, 27 Jan 2006 16:12:18 -0500
From: Joe Thompson <joe@orion-com.com>
Subject: NTSB report on Southwest Airlines crash
The NTSB has reported on the cause of the Southwest Airlines crash in
Chicago:
http://www.cnn.com/2006/TRAVEL/01/27/airplane.landings/
http://www.chicagotribune.com/news/local/chi-060127midwayaccident,1,3064315.story?coll=chi-news-hed
Executive summary: the thrust reversers did not deploy properly, causing the
plane to overshoot the end of the runway.
A point of contention right after the accident was that the pilots had
apparently activated the automatic brake system in violation of Southwest
policy, but the NTSB concluded the crucial factor was the unanticipated
18-second delay in the thrust-reversers deploying. As a result, NTSB is
urging the FAA to to prohibit allowing for thrust-reversers in onboard
stopping-distance calculations. (Before landing, the crew had used the
onboard computer to calculate stopping distance for "wet-poor" conditions;
those calculations assumed the thrust reversers would deploy normally.)
The risks here appear to be two of the most common ones: trusting an
automatic system to activate within specification 100% of the time, and
allowing that trusted system to be the critical margin between success and
catastrophic failure -- even in the successful-landing scenario represented
by the onboard computer's figures, the plane was anticipated to stop within
30 feet of the end of the runway after a rollout of over 4000 feet, a margin
of error of less than 1%. -- Joe
Joe Thompson | joe@orion-com.com
------------------------------
Date: Thu, 5 Jan 2006 09:49:58 -0500
From: "Steve Wildstrom" <steve_wildstrom@private>
Subject: United computer failure
More than reservations was affected. I was on a United flight at Dulles
waiting to take off at the time the reservation system went down. I was
listening to air traffic control when the pilot of my flight and another UAL
plane told the tower they couldn't take off because they didn't "have their
numbers." Later, our pilot came on the PA and said that because of a
computer outage, UAL operations was having to do load and balance
computations manually.
Steve Wildstrom, Technology & You columnist, BusinessWeek
------------------------------
Date: January 5, 2006 3:08:01 PM EST
From: leigh blankenship <leigh_b@private>
Subject: H&R Block blunder exposed SSNs (From Dave Farber's IP)
Happy New Year, 234-56-7890! Trust us and our software to protect your
confidential tax information!
http://netscape.com.com/H38R+Block+blunder+exposes+consumer+data/2100-1029_3-6016720.html
> Some consumers may be dismayed to find their Social Security numbers
> printed on unsolicited packages from H&R Block, the result of a recent
> labeling blunder at the company.
>
> The packages, which H&R Block mailed in December, contained free copies of
> the company's tax preparation software, TaxCut. By mistake, some of the
> packages also displayed recipients' Social Security numbers, which were
> embedded in 47-digit tracking codes above mailing labels.
IP Archives at: http://www.interesting-people.org/archives/interesting-people/
------------------------------
Date: January 24, 2006 5:38:44 PM EST
From: Randall <rvh40@private>
Subject: "Analog Hole" Bill to impose secret requirement? (via Dave Farber's IP)
[First seen on the Telecom Digest]:
http://htdaw.blogsource.com/post.mhtml?post_id=198659
Monday January 23, 2006 by Ed Felten
If you've been reading here lately, you know that I'm no fan of the
Sensenbrenner/Conyers analog hole bill. The bill would require almost all
analog video devices to implement two technologies called CGMS-A and
VEIL. CGMS-A is reasonably well known, but the VEIL content protection
technology is relatively new. I wanted to learn more about it.
So I e-mailed the company that sells VEIL and asked for a copy of the
specification. I figured I would be able to get it. After all, the bill
would make compliance with the VEIL spec mandatory -- the spec would in
effect be part of the law. Surely, I thought, they're not proposing passing
a secret law. Surely they're not going to say that the citizenry isn't
allowed to know what's in the law that Congress is considering. We're
talking about television here, not national security.
After some discussion, the company helpfully explained that I could get the
spec, if I first signed their license agreement. The agreement requires me
(a) to pay them $10,000, and (b) to promise not to talk to anybody about
what is in the spec. In other words, I can know the contents of the bill
Congress is debating, but only if I pay $10k to a private party, and only if
I promise not to tell anybody what is in the bill or engage in public debate
about it.
Worse yet, this license covers only half of the technology: the VEIL
decoder, which detects VEIL signals. There is no way you or I can find out
about the encoder technology that puts VEIL signals into video.
The details of this technology are important for evaluating this bill. How
much would the proposed law increase the cost of televisions? How much would
it limit the future development of TV technology? How likely is the
technology to mistakenly block authorized copying? How adaptable is the
technology to the future? All of these questions are important in debating
the bill. And none of them can be answered if the technology part of the
bill is secret.
Which brings us to the most interesting question of all: Are the members of
Congress themselves, and their staffers, allowed to see the spec and talk
about it openly? Are they allowed to consult experts for advice? Or are the
full contents of this bill secret even from the lawmakers who are
considering it?
http://www.freedom-to-tinker.com/?p=958
Archives at: http://www.interesting-people.org/archives/interesting-people/
------------------------------
Date: January 24, 2006 4:01:02 PM EST
From: "Steven M. Bellovin" <smb@private>
To: cryptography@private
Subject: NSA explains how to redact documents electronically (via Dave Farber)
http://www.fas.org/sgp/othergov/dod/nsa-redact.pdf
One wonders how long it will be till someone finds an error...
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Archives at: http://www.interesting-people.org/archives/interesting-people/
------------------------------
Date: Thu, 12 Jan 2006 10:03:05 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Phone calling records for sale instantly (via Lauren Weinstein)
FBI Agent's Cell Phone Records For Sale Locatecell.com seems to have a good
thing going. According to this Chicago Sun Times story:
To test the service, the FBI paid Locatecell.com $160 to buy the records for
an agent's cell phone and received the list within three hours, the police
bulletin said.
Representatives of Data Find Solutions Inc., the Tennessee-based operator of
Locatecell.com, could not be reached for comment.
Frank Bochte, a spokesman for the FBI in Chicago, said he was aware of the
Web site.
"Not only in Chicago, but nationwide, the FBI notified its field offices of
this potential threat to the security of our agents, and especially our
undercover agents," Bochte said.
Funny how the FBI's first reaction is to go on the defensive.
Funny how this is a big surprise to the FBI.
The Chicago Sun-Times paid $110 to Locatecell.com to purchase a one-month
record of calls for this reporter's company cell phone. It was as simple as
e-mailing the telephone number to the service along with a credit card
number.
Locatecell.com e-mailed a list of 78 telephone numbers this reporter called
on his cell phone between Nov. 19 and Dec. 17. The list included calls to
law enforcement sources, story subjects and other Sun-Times reporters and
editors.
Cheating spouse? Disloyal employees? Need to find out what your competition
is doing? Hey, no problem. Telecom services are just information services
these days.
Fortunately friend Chris Hoofnagle, of Electronic Privacy Information
Center, is on the case.
Thanks to Steve Crandall, who spotted this story first!
------------------------------
Date: Mon, 16 Jan 2006 18:05:57 -0500
From: Bob Heuman <rsh@private>
Subject: 'Hacker' held over U.S. Navy breach
Of course, not answered [nor likely to be answered] is why the security even
could be breached at a facility that handles nuclear submarines. RsH
An 18-year-old suspected Spanish hacker who allegedly breached the
top-secret computer security of a U.S. Navy base in San Diego has been
arrested in his home town of Malaga, Spain, according to the Spanish Civil
Guard. He reportedly "seriously compromised the correct operations and
security of a maintenance dry dock for nuclear submarines." [Source: CNN
Madrid Bureau Chief Al Goodman, 16 Jan 2006; PGN-ed]
------------------------------
Date: January 12, 2006 2:21:39 AM EST
From: Monty Solomon <monty@private>
Subject: Bank loses tape with personal information on 90,000 customers
By John Christoffersen, AP Business Writer | January 11, 2006
STAMFORD, Conn. --A tape containing the Social Security numbers and
other confidential data of 90,000 People's Bank customers was lost
recently while en route to a credit reporting bureau, state and bank
officials said Wednesday.
Millions of people around the country have been affected by a recent string
of data losses and thefts involving major financial institutions and
businesses including Citigroup Inc., Time Warner Inc. and Ameritrade Holding
Corp.
People's has no reason to believe the data has been used inappropriately and
has received no reports of unauthorized activity, officials said. Customers
do not need to close accounts because the information is not sufficient to
allow unauthorized access, the bank said.
But consumer advocates say identity thieves could use Social Security
numbers to open new accounts in the names of those affected.
They say such data should be encrypted so it cannot be illegally accessed
and they advocate new laws that would allow consumers to place fraud or
security alerts on their credit reports to prevent thieves from creating
accounts. ...
http://www.boston.com/news/local/connecticut/articles/2006/01/11/bank_loses_tape_with_personal_information_on_90000_customers/
------------------------------
Date: January 12, 2006 9:41:01 AM EST
From: Dan Shoop <shoop@private>
Subject: Re: Bank loses tape with personal information on 90,000 customers
(From Dave Farber's IP)
This actually happens all the time. The bank FedEx's or otherwise sends a
tape, it get's lost. This happens. In a past life as a datacenter manager at
Citibank we used to receive palettes of tapes by FedEx every morning from
Sioux Falls, SD, where the credit card processing center was, a truck of
tapes having better bandwidth at lower cost that any telco line.
Occasionally tapes got lost, it was no big deal and no one thought much of
it other than to request another copy. California, IIRC, was the first state
to mandate that any lost customer records of any sort has to be reported,
and other states have followed suit. Since such laws been enacted that it
must be reported it's been getting recent press and what is actually a
common occurence is now "news". The risk from this is considered very
low. In most all cases the data is encrypted. Even if it wasn't other
policies prevent keeping say account numbers and names, or other required
pieces of information necessary to commit a fraud or identity theft with
information together in the same place at once.
Having names and Social Security numbers together is considered low risk
since this information is readily available through numerous sources.
Dan Shoop, Systems & Networks Architect 1-646-217-4725
http://www.iwiring.net/ http://www.ustsvs.com/ shoop@private
------------------------------
Date: Fri, 13 Jan 2006 20:24:55 -0500
From: Bob Heuman <rsh@private>
Subject: Another finger goof at the Tokyo Exchange, Lower loss, wrong company!
A Japanese trader pushed the wrong button Friday and cost his brokerage
house almost 500 million yen, or $5.1 million Cdn. The incident is the
latest in a series of blunders and computer glitches on the Tokyo Stock
Exchange, Japan's biggest bourse. In the latest case, a trader with Daiwa
Securities SMBC apparently made a mistake just before the start of trading
and sold 25,000 shares of the wrong company. Daiwa realized the error a few
minutes later and issued a buy-back order, but investors had already snapped
up 13,000 shares. The brokerage house repurchased all those shares by the
end of the trading day, but lost almost 500 million yen ($5.1 million Cdn)
in the process, according to Daiwa spokesman Daishu Nagata. [Source:
Trader's typing error costs Japanese brokerage house millions CBC News, 13
Jan 2006; PGN-ed; see RISKS-24.12 for the earlier Mizuho screwup.]
http://www.cbc.ca/story/business/national/2006/01/13/goof-060113.html
------------------------------
Date: Wed, 18 Jan 2006 20:29:46 -0500
From: "Art T." <myspamtrap01@private>
Subject: E-mail and the courts
Here's a site RISKS users might be interested in. It appears to be a
compendium of legal cases in which e-mails play a significant role. It
includes several cases where deleting e-mail has cost companies large
amounts of money, even when the e-mails were not recovered.
http://arkfeld.blogs.com/ede/email/
------------------------------
Date: Thu, 12 Jan 2006 22:19:28 +0200
From: Gadi Evron <ge@private>
Subject: Cisco, haven't we learned anything? (technician reset)
In this (http://www.cisco.com/warp/public/707/cisco-sa-20060111-mars.shtml)
recent Cisco advisory, the company alerts us to a security problem with
Cisco MARS (Cisco Security Monitoring Analysis and Response System).
The security issue is basically a user account on the system that will
give you root when accessed.
The account is:
1. Hidden.
2. Default.
3. With a pre-set password.
In other words, this is a journey back 10 years when technicians would
commonly have special keys (actual keys, electronics or passwords) to access
a device if they have to troubleshoot it for anything, or say? the user
lost his password.
People used to trade these keys online and hidden accounts were a thing of
common practice. Today people still trade commonly used default passwords
but it is not as popular as it used to be, at least in the online world.
On the other hand, the most common practice to hack routers today, is
still to try and access the devices with the notoriously famous default
login/password for Cisco devices: cisco/cisco.
Cisco/cisco is the single most used default password of our time. It got
more routers pwned than any exploit in history, and it still does. One
would think that a company such as Cisco, especially with this history,
would stay away from such "default" accounts? but the fact that this
account is hidden makes it something different.
It makes it a backdoor. One much like those used by the Bad Guys.
Now... if Cisco knowingly put it there, shame on them. If somebody put it
there without their knowledge... well, shame on them.
This is indeed a vulnerability, as in a weakness. It is not however a
software coding bug that may result in say... a buffer overflow. It is a
part of the design of the system. Cisco disclosing this is very nice and
commendable, but perhaps they should also let us know whether this was
indeed a backdoor somebody put in their system or if it was part of the
design?
I love easter eggs. I just don't like surprises in system privileges or
backdoors, especially not in a security monitoring and response product.
I very much doubt it was anything else but a part of the design but that
should be admitted to.
As the advisory states:
"No other Cisco products are currently known to be affected by this
vulnerability."
Okay, but how about other vulnerabilities of this type? Are there any more
backdoors to other Cisco products? If not, why wouldn't they just come out
and say that? "There are NO other such backdoors in our products."
I'd even be happy with: "To our knowledge, there are no other
vulnerabilities of this type in our products."
This is not a bug. One can never be sure ALL bugs are eliminated - however
hard one may try. One CAN admit to having no such features in other
products, though.
Once again we fall upon re-naming of a feature as a bug or a bug as a
feature to make the problem sound less severe.
In this case, the judgment is plain and simple:
If Cisco were Bad Guys, this is a backdoor.
As Cisco are Good Guys, this is a technician reset.
Terminology? What's the difference?
The difference is that Cisco are not Bad Guys. If they disclosure a
problem they should do it fully, because as a client, I am now concerned.
This reminds me of Ciscogate but not for obvious reasons. That was a bad
event for everybody involved.
It reminds me of the very issue Mike Lynn discussed:
Remote exploitation for Cisco is possible, while so far Cisco disclosed
all these problems as DoS vulnerabilities.
I am not saying Cisco did that on purpose, but in THIS case they CAN set
my mind at ease.
Why don't they?
Update: After writing this I've been made aware that this product was from a
company Cisco bought not so long ago. This very same issue happened before
(and more than once)... in one recent example with another company Cisco
bought named Riverhead. Checking into new investments security-wise,
especially with security products and external QA may help solve such issues
in the future.
------------------------------
Date: Mon, 09 Jan 2006 07:59:12 -0800
From: Rob Slade <rMslade@private>
Subject: REVIEW: "Rootkits", Greg Hoglund/James Butler
BKROOTKT.RVW 20051023
"Rootkits", Greg Hoglund/James Butler, 2006, 0-321-29431-9,
U$44.99/C$62.99
%A Greg Hoglund
%A James Butler
%C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D 2006
%G 0-321-29431-9
%I Addison-Wesley Publishing Co.
%O U$44.99/C$62.99 416-447-5101 fax: 416-443-0948 bkexpress@private
%O http://www.amazon.com/exec/obidos/ASIN/0321294319/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0321294319/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0321294319/robsladesin03-20
%O Audience s+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P 324 p.
%T "Rootkits: Subverting the Windows Kernel"
The preface (and therefore the book) begins with a definition of a rootkit.
The authors proceed to outline their initial interest in the phenomenon, and
any security professional who understands the centrality of system internals
can begin to see the importance of the work.
Chapter one addresses a major selling point (in the blackhat mindset) for
rootkits: the evasion of detection. Concentrating on this aspect, the
material outlines what a rootkit is, and is not, noting also that the
programs need not be limited to illegal activities but do have legitimate
uses. Subversion of the core of the operating system is examined in chapter
two, although this is limited to the creation of device drivers. (This
chapter again raises the issue of whether a book investigating the breaking
of a system can provide valuable advice when it comes to protecting
computers. While some works do; Hoglund, along with Gary McGraw, having
created an example in "Exploiting Software" [cf. BKEXPLSW.RVW]; this
particular material concentrates on items of interest in the process of
producing rootkits. The limited sections dealing with more theoretical
considerations would be those of greater interest to the security
community.) Chapter three explores some hardware related items, although
there are others that could be perused, and most of those surveyed may be
initiated in hardware, but operate primarily in the software realm.
Hooking of interrupts and functions is covered in chapter four, at both a
kernel and user level. Chapter five reviews various means of directly
patching software. (Much of this material should be familiar for those who
have studied operations of older viruses.) The interception techniques
addressed in chapter four are extended, in chapter six, to include adding
new "layers" to existing device drivers. The operating system kernel uses
data and other resources in order to perform properly, and chapter seven
shows that manipulating these objects can modify the actions of the machine.
Although nominally about hardware, chapter eight really concentrates on the
patching of firmware. Chapter nine examines covert channels, but the
explanation is quite poor, and most of the space is dedicated to listings of
program code. Rootkit detection is discussed in chapter ten. It is
interesting to note that analogies of antiviral change detection and
activity monitoring are mentioned, but there is no consideration of
signature scanning.
"Rootkits" does raise a number of interesting topics, and much of the
material could be of use to those charged with protecting systems. However,
the content is not as valuable as that presented in "Exploiting Software."
There is, of course, much that will be of assistance for those writing
legitimate rootkits, but this would be a fairly limited audience.
copyright Robert M. Slade, 2005 BKROOTKT.RVW 20051023
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
------------------------------
Date: 2 Oct 2005 (LAST-MODIFIED)
From: RISKS-request@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@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.
=> 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@private>.
=> SPAM challenge-responses will not be honored. Instead, use an alternative
address from which you NEVER send mail!
=> 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 24.15
************************
This archive was generated by hypermail 2.1.3 : Sat Jan 28 2006 - 20:06:04 PST