RISKS-LIST: Risks-Forum Digest Wednesday 14 June 2006 Volume 24 : Issue 32
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.32.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Hospitals have dramatically reduced unnecessary deaths (PGN)
Unverified air traffic data (David Magda)
Report on security risks of applying CALEA to VoIP (Susan Landau)
TIAA Breaches Whistleblower (Al Macintyre)
Cybersecurity plan of the Federal government: what a screw-up (Fred Cohen)
IRS Laptop Lost With Data on 291 People (Christopher Lee via Monty Solomon)
Windows XP update may be classified as "spyware" (Lauren Weinstein)
How MS spyware could be used by hackers to disable systems (?)
DoE Discloses Data Theft (Ari Ollikainen via Dave Farber)
UnSalted Credit Cards (Mark Ennis)
Lottery scam spam -- unclear on the concept (Drew Dean)
Dental X-Rays go Digital---same old problems (Howard Israel)
Silver Bullet: Dan Geer (Gary McGraw)
REVIEW: "Software Security: Building Security In", Gary McGraw (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Wed, 14 Jun 2006 12:25:59 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: Hospitals have dramatically reduced unnecessary deaths
[Do you recall "Hospital operates on wrong patient?" (lead item in
RISKS-24.11)? This is the other side of the coin. TNX to Lauren
Weinstein for sending this one to me. PGN]
Hospitals Cut Lethal Errors Rate, Mike Stobbe, AP item,*Newsday*, 14 Jun 2006
http://www.newsday.com/news/nationworld/wire/sns-ap-hospital-lifesavers,0,6425411.story?coll=sns-ap-nationworld-headlines
A campaign to reduce lethal errors and unnecessary deaths in U.S. hospitals
has saved an estimated 122,300 lives in the last 18 months. About 3,100
hospitals participated in the project, sharing mortality data and carrying
out study-tested procedures that prevent infections and mistakes. Experts
say the cooperative effort was unusual for a competitive industry that
traditionally doesn't like to publicly focus on patient-killing problems.
Medical mistakes were the focus of a widely noted 1999 national report that
estimated 44,000 to 98,000 Americans die each year as a result of errors and
low-quality care.
Perhaps the best known of the six changes was to deploy rapid response teams
for emergency care of patients whose vital signs suddenly deteriorate. ...
Another urged checks and rechecks of patient medications to protect against
drug errors. A third focused on preventing surgical site infections by
following certain guidelines, including giving patients antibiotics before
their operations.
------------------------------
Date: Thu, 8 Jun 2006 19:19:39 -0400
From: David Magda <dmagda@private>
Subject: Unverified air traffic data
Dick Smith [1] is warning [2] that the new ADS-B air traffic system [3] uses
unverified data to plot what (supposedly real) aircraft are doing:
> But Mr Smith, who is campaigning against the scheme and has raised safety
> and security concerns about the design, said the system had no way of
> verifying whether a plane was where it claimed to be or if it existed at
> all.
>
> He said the FAA was looking at ways of encrypting signals or setting up
> multiple ground stations at each location to allow the traffic controllers
> to determine whether a signal came from a moving aircraft.
The main advantage of the system is that radar (which is expensive to buy
and run) is not needed since aircraft broadcast their (supposed) position,
and that data can be received using less expensive equipment. Aircraft
determine their position by GPS.
I'm sure the disadvantages of an unauthenticated positioning system don't
have to be spelled out.
[1] http://en.wikipedia.org/wiki/Dick_Smith
[2] http://www.theaustralian.news.com.au/story/0,20867,19378061-23349,00.html
[3] http://en.wikipedia.org/wiki/Automatic_Dependent_Surveillance-Broadcast
------------------------------
Date: Tue, 13 Jun 2006 15:29:56 -0400
From: Susan Landau <susan.landau@private>
Subject: Report on security risks of applying CALEA to VoIP
Below you'll find an executive summary of "Security Implications of Applying
the Communications Assistance for Law Enforcement Act to Voice over IP."
The full report is at http://www.itaa.org/news/docs/CALEAVOIPreport.pdf .
Security Implications of Applying the Communications Assistance to Law
Enforcement Act to Voice over IP
Steven Bellovin, Columbia University
Matt Blaze, University of Pennsylvania
Ernest Brickell, Intel Corporation
Clinton Brooks, NSA (retired)
Vinton Cerf, Google
Whitfield Diffie, Sun Microsystems
Susan Landau, Sun Microsystems
Jon Peterson, NeuStar
John Treichler, Applied Signal Technology
Executive Summary
For many people, Voice over Internet Protocol (VoIP) looks like a nimble way
of using a computer to make phone calls. Download the software, pick an
identifier and then wherever there is an Internet connection, you can make a
phone call. From this perspective, it makes perfect sense that anything
that can be done with a telephone, including the graceful accommodation of
wiretapping, should be able to be done readily with VoIP as well.
The FCC has issued an order for all ``interconnected'' and all broadband
access VoIP services to comply with Communications Assistance for Law
Enforcement Act (CALEA) --- without specific regulations on what compliance
would mean. The FBI has suggested that CALEA should apply to all forms of
VoIP, regardless of the technology involved in the VoIP implementation.
Intercept against a VoIP call made from a fixed location with a fixed IP
address directly to a big Internet provider's access router is equivalent to
wiretapping a normal phone call, and classical PSTN-style CALEA concepts can
be applied directly. In fact, these intercept capabilities can be exactly
the same in the VoIP case if the ISP properly secures its infrastructure and
wiretap control process as the PSTN's central offices are assumed to do.
However, the network architectures of the Internet and the Public Switched
Telephone Network (PSTN) are substantially different, and these differences
lead to security risks in applying the CALEA to VoIP. VoIP, like most
Internet communications, are communications for a mobile environment. The
feasibility of applying CALEA to more decentralized VoIP services is quite
problematic. Neither the manageability of such a wiretapping regime nor
whether it can be made secure against subversion seem clear. The real
danger is that a CALEA-type regimen is likely to introduce serious
vulnerabilities through its ``architected security breach.''
Potential problems include the difficulty of determining where the traffic
is coming from (the VoIP provider enables the connection but may not provide
the services for the actual conversation), the difficulty of ensuring safe
transport of the signals to the law-enforcement facility, the risk of
introducing new vulnerabilities into Internet communications, and the
difficulty of ensuring proper minimization. VOIP implementations vary
substantially across the Internet making it impossible to implement CALEA
uniformly. Mobility and the ease of creating new identities on the Internet
exacerbate the problem.
Building a comprehensive VoIP intercept capability into the Internet appears
to require the cooperation of a very large portion of the routing
infrastructure, and the fact that packets are carrying voice is largely
irrelevant. Indeed, most of the provisions of the wiretap law do not
distinguish among different types of electronic communications. Currently
the FBI is focused on applying CALEA's design mandates to VoIP, but there is
nothing in wiretapping law that would argue against the extension of
intercept design mandates to all types of Internet communications. Indeed,
the changes necessary to meet CALEA requirements for VoIP would likely have
to be implemented in a way that covered all forms of Internet communication.
In order to extend authorized interception much beyond the easy scenario, it
is necessary either to eliminate the flexibility that Internet
communications allow, or else introduce serious security risks to domestic
VoIP implementations. The former would have significant negative effects on
U.S. ability to innovate, while the latter is simply dangerous. The current
FBI and FCC direction on CALEA applied to VoIP carries great risks.
------------------------------
Date: Sat, 10 Jun 2006 21:49:41 -0500
From: Al Macintyre <macwheel99@private>
Subject: TIAA Breaches Whistleblower
go.eweek.com/tiaa
IT Manager seeks redress for firing, claiming SARBOX Whistleblower protection
http://www.eweek.com/article2/0,1759,1969518,00.asp
US Supreme Court lowers Whistleblower protection for employees reporting
fraud or criminal misconduct to the proper authorities, but employees have
more protection if they go straight to the news media
http://www.accountingweb.com/cgi-bin/item.cgi?id=102230&d=815&h=817&f=816&dateformat=%25B%20%25e,%20%25Y
http://www.forbes.com/technology/feeds/ap/2006/05/30/ap2780736.html
http://civilliberty.about.com/b/a/257515.htm
This is a familiar and disturbing picture. Personnel find security problems
with employer systems, report them, nothing happens. Computer staff exhaust
what can be done in-house to get the security problems resolved, but
leadership resistance is too strong.
A year later there is a serious security breach. Top Managers claim nothing
much at risk, but ask computer staff to help the feds find out exactly what
was breached, which turns out to be practically everything. Computer staff
gets fired.
What makes this worse is the news that the Feds apparently support the
coverup, when the whistleblowers appeal the employer punitive action.
Had computer staff lied to investigators, claiming no problem, like
management had wanted, they would still have their jobs.
Thus computer workers have to balance behavior that will help career
integrity vs. what is in the best interests of protecting customers and
investors.
However, there are lots of news stories of whistleblowers who successfully
prevail, so we should wait and see what happens in this case.
------------------------------
Date: Thu, 8 Jun 2006 06:01:35 -0700
From: Fred Cohen <dr.cohen@private>
Subject: Cybersecurity plan of the Federal government: what a screw-up
I just read the new plan for funding information security at the Federal
level and it was pathetic. The most notable element of it is the fact that
they claim to align between several different things but in fact they don't
align at all. The things they identify as worth doing are the very things
that don't need to be done and the things they identify as not worth doing
are the things we most desperately need. But fear not - they won't put any
real money behind anything worthwhile in any case. The plan - if fully
implemented - would not even stop the large-scale theft of identity
information of all the people getting clearances or all the folks in the
military. So we won't be getting much in the way of help from the federal
government in advancing the field for the next few years at least.
www.nitrd.gov/pubs/csia/csia_federal_plan.pdf
Fred Cohen & Associates; Security Posture; University of New Haven; ASP Press
all.net, securityposture.com, unhca.com, asp-press.com, 1-925-454-0171
------------------------------
Date: Sun, 11 Jun 2006 21:13:33 -0400
From: Monty Solomon <monty@private>
Subject: IRS Laptop Lost With Data on 291 People
An Internal Revenue Service employee lost an agency laptop early last month
that contained sensitive personal information on 291 workers and job
applicants, a spokesman said yesterday.
The IRS's Terry L. Lemons said the employee checked the laptop as luggage
aboard a commercial flight while traveling to a job fair and never saw it
again. The computer contained unencrypted names, birth dates, Social
Security numbers and fingerprints of the employees and applicants, Lemons
said. Slightly more than 100 of the people affected were IRS employees, he
said. No tax return information was in the laptop, he said. "The data was
not encrypted, but it was protected by a double-password system," Lemons
said. "To get in to this personal data on there, you would have to have two
separate passwords." Lemons said the Treasury Department's inspector
general for tax administration is investigating the loss. The IRS is
notifying affected individuals and advising them on steps to guard against
identity theft. Lemons declined to name the airline or the employee, or to
say whether the worker was disciplined, citing the ongoing investigation.
... [Source: Christopher Lee, *The Washington Post*, 8 Jun2006, A04; PGN-ed]
http://www.washingtonpost.com/wp-dyn/content/article/2006/06/07/AR2006060701987.html
------------------------------
Date: June 6, 2006 1:15:05 AM EDT
From: Lauren Weinstein
Subject: Windows XP update may be classified as "spyware" (from Farber's IP)
There have been some murmurs about this in other forums, but since I've now
independently verified I figured I'd better report here.
A recent Microsoft update to Windows XP, which modifies the tool that
verifies the "validity" of XP installations to ensure that they are not
illicit, may itself be considered to be spyware under commonly accepted
definitions.
The new version of the "Microsoft Genuine Advantage" tool reportedly will
repeatedly nag users of systems it declares to be invalid, and will then
apparently deny such users various "non-critical" updates. Apparently
various parties have already found ways to bypass this tool, though the
effects of this on later updating capabilities remain to be seen.
However, I've noted a much more serious issue on local XP systems, all of
which are legit and pass the MS validity tests with flying colors. It
appears that even on such systems, the MS tool will now attempt to contact
Microsoft over the Internet *every time you boot*. At least, I'm seeing
these contacts on every boot after the tool update so far, and I've allowed
them to proceed to completion each time. Perhaps it stops after some number
of boots, but there's no indication of such a limit so far. The connections
occur even if you do not have Windows "automatic update" enabled. ...
http://www.interesting-people.org/archives/interesting-people/200606/msg00030.html
------------------------------
Date: Mon, 12 Jun 2006 12:11:53 -0700 (PDT)
From: (?)
Subject: How MS spyware could be used by hackers to disable systems
An anonymous Slashdot user gives virus writers a worrying idea: "A virus
could use one of the 'Product-Key Changer' scripts ... to install a pirated
product key on every infected computer (wiping all traces of the original
key). This would render millions of genuine installations indistinguishable
from pirated installations. What a mess for Microsoft! They would have to
immediately 'kill forever' the WGA helper, and maybe even remove the WGA
check on Windows Update. Such a virus would be a hard lesson to learn for
the writers of all kinds of automated 'genuine' checks."
------------------------------
Date: June 10, 2006 1:37:31 PM EDT
From: Ari Ollikainen <Ari@private>
Subject: DoE Discloses Data Theft (via Dave Farber's IP)
Foot dragging on an incident which occurred in September 2005...
[and was not reported until 8 June 2006. PGN]
Energy Dept. Discloses Data Theft
Victims, Top Officials Were Not Told About 2005 Hacking
A hacker stole a file containing the names and Social Security numbers of
1,500 people working for the Energy Department's nuclear weapons agency.
[Source: Associated Press item, *The Washington Post*, 10 Jun 2006, A04]
http://www.washingtonpost.com/wp-dyn/content/article/2006/06/09/AR2006060901505.html
------------------------------
Date: Tue, 13 Jun 2006 15:14:25 +0100 (BST)
From: Mark Ennis <mark@private>
Subject: UnSalted Credit Cards
The credit card companies publish what is colloquially known as as the PCI
standard. For the standard itself, see:
http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf
This covers various aspects of security for organisations that are involved
in the processing of credit cards.
I'm surprised to see however that where they suggest that cardholder data is
secured:
Render sensitive cardholder data unreadable anywhere it is stored
(including data on portable media, backup media, in logs, and data
received from or stored by wireless networks) by using any of the
following approaches.
-One-way hashes (hashed indexes), such as SHA-1
-Truncation
-Index tokens and PADs, with the PADs being securely stored
-Strong cryptography, such as Triple-DES 128-bit or AES 256-bit with
associated key management processes and procedures.
They omit to mention that one-way hashes of cardholder data are of little
use without applying a salt. They should - as has been documented here
before many programmers see no problem in wrapping a bare md5 function
around a sensitive value.
For instance - as is well known 16 digit credit card numbers start with a 6
digit bank code and end with a checksum. A reverse hash dictionary for all
unsalted MD5 codes for one bank code only needs to cover 16-6-1=9 digits of
possibilities - or one thousand million entries. This could be done for a
storage cost of:
9 digit number = 4 bytes
MD5 checksum = 16 bytes number
Total = 20 bytes * 1,000,000,000 possibilites = 20Gb
As a result its completely feasible a program that asks for unsalted MD5 or
SHA-1 Hash of a credit card number and the 6 digit bank code could generate
the original credit card number after waiting for that bank code's 20gb
dictionary to be generated.
Mark Ennis, NetCommute Ltd. <mark@private> 00-353-1-8569539
------------------------------
Date: Wed, 7 Jun 2006 08:51:16 -0700
From: Drew Dean <ddean@private>
Subject: Lottery scam spam -- unclear on the concept
In my Inbox:
> CONGRATULATIONS: YOU WON -1,000,000.00 EUROS.
I'm sure they'd like me to give them 1 million Euros, but I think not. With
my permission, they'll even enter me into a drawing for -5 Million Euros!
Wow, my lucky day! :-)
------------------------------
Date: Wed, 07 Jun 2006 18:25:28 +0000
From: h.israel@private
Subject: Dental X-Rays go Digital---same old problems
Personal experience, with my dentist yesterday evening.
It was a typical visit, except now my dentist is using a new digital x-ray
machine (from Kodak) that runs on a standard PC (probably this system:
http://www.kodak.com/global/en/health/dental/documentation/sysReqs/KDIS.pdf
).
The process to take the X-Ray is relatively the same as the old analog
method. Noticeable differences: 1) the X-Ray machine is physically smaller,
2) there is no film, but in its place is a reusable digital sensor with a
trailing wire leading out of the patients mouth. 3) images are rendered
immediately on a screen, so the tech can determine if the shot taken is OK
or needs to be re-taken. 4) the images are very clear and noticeably sharper
then the analog X-Rays (to my untrained eye).
Now the not so fun part. After the tech completes the set of 6 pictures,
the dentist comes in to review. A few clicks and pop ups appear, a few too
quick clicks, and poof, the images are accidentally deleted and not
retrievable. The tech admitted afterward that she usually does a save
before the dentist comes in. OK, lets do it again. Take a second set of
images. The tech does the save, but an hour glass comes up and the PC
freezes. The images are mostly still visible on the screen, except there are
a couple of pop-ups that are blocking one of the images of my teeth and they
can not be moved. The dentist comes in to review the images, but can not
access the application, since it is not functioning. The obvious thing to do
is a CTL-ALT-DEL to see what is going on. The CPU is idle, but the app is
"not responding". The dentist claims that this is the first problem he has
had in the few months he has been using the system. Since most of the images
are actually still viewable, he does his assessment, then starts to end the
hung processes.
Eventually a "Send Error Report" window appears giving the user the option
to send in an error report to the software maker, which he elects not to
send. He reboots, then brings up the application, and then tries to access
my patient record and see if the X-Ray images were actually saved, but the
app gives him an error. My guess is that a file corruption occurred.
Of Note: The PC is Internet enabled, via dial-up access. I believe it is
used to transmit data for insurance processing (as confirmed via link
below). Aside from the obvious application issues described above, I
started to wonder about HIPAA issues and how well my data/info is protected
by this PC linked to the Internet. Also, thinking about what backup systems
are in use, etc. Another thought--how easy would it be to manipulate the
digital images to sabotage a forensics investigation (another great use of
PhotoShop!)? Delete the images to prevent the positive ID of a body, or
better yet, cause a body to be incorrectly identified (e.g., fake ones
death). Do these images have digital signatures? (Doubt it!)
While I didn't dig into it deeply, its just a matter of time before ...
Here is a link to an online article (WSJ reprint?): http://www.mindfully.org/Technology/2005/Dental-X-Ray-Digital29nov05.htm It highlights some pros/cons of going digital.
Howard Israel, CEO, Secure Systems Consulting, LLC 1-732-613-9464
------------------------------
Date: Mon, 12 Jun 2006 13:35:29 -0400
From: "Gary McGraw" <gem@private>
Subject: Silver Bullet: Dan Geer
The second edition of the Silver Bullet Security Podcast with Gary McGraw
(hey, that's me) went up just a few seconds ago:
http://www.cigital.com/silverbullet/
The first show (with Avi Rubin) proved to be pretty popular. Hope you all
like this one too! Feedback welcome through the website.
Marcus Ranum is on deck and Dana Epp is on the list. Who else do you want
to hear from in Silver Bullet?
gem www.cigital.com www.swsec.com
------------------------------
Date: Mon, 12 Jun 2006 11:54:22 -0800
From: Rob Slade <rMslade@private>
Subject: REVIEW: "Software Security: Building Security In", Gary McGraw
BKSWSBSI.RVW 20060518
"Software Security: Building Security In", Gary McGraw, 2006,
0-321-35670-5, U$49.99/C$66.99
%A Gary McGraw swsec.com www.buildingsecurityin.com gem@private
%C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D 2006
%G 0-321-35670-5
%I Addison-Wesley Publishing Co.
%O U$49.99/C$66.99 416-447-5101 800-822-6339 bkexpress@private
%O http://www.amazon.com/exec/obidos/ASIN/0321356705/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0321356705/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0321356705/robsladesin03-20
%O Audience a+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P 408 p. + CD-ROM
%T "Software Security: Building Security In"
The preface states that the audience for the book is comprised of developers
(particularly those interested in secure software), security professionals
(in places), managers (in places), and academics (there are a couple of
chapters that indicate where further research might be useful). McGraw also
introduces the major components of the book. His "thee pillars" are not the
usual confidentiality, integrity and availability, but risk management,
"touchpoints," and knowledge. The touchpoints are code analysis, risk
analysis, penetration (vulnerability) testing, security tests, abuse cases,
security requirements, and security operations.
Part one outlines the basics of software security. Chapter one informs us
that problems exist in software, and notes the differences between bugs (due
to careless implementation) and flaws (due to poor design). McGraw also
suggests his three pillars as a means of addressing the difficulty. Using
an example software project, chapter two takes us through a risk management
framework in some detail.
Part two examines the touchpoints. Chapter three introduces them in a
diagram related to the steps in the software development process (they are
numbered, although in a seemingly random pattern which turns out to be the
suggested order of effectiveness). (The latter half of the chapter seems to
be more of a sermon on software security.) Source code review tools (for
finding bugs) are described in chapter four. Chapter five starts off with
traditional risk analysis definitions and then extends the concept with
details of the application of the process to software design. (Sidebars on
software tools for program risk analysis, and other related items, are
dropped in seemingly at random. The information is valuable, but the
reading flow is somewhat disjointed.) Penetration testing of software
sounds like a good idea, but chapter six doesn't really define what the
topic involves. (The sidebar on tools is a case in point: the tools are
listed and recommended, but the descriptions don't say what they actually
do.) Risk-based security testing seems, by the end of chapter seven, to be
a special case of spanning tree analysis, but along the way a number of the
other touchpoints seem to overlap with it. "Abuse cases" is the application
of known common vulnerabilities and attacks (perpetrated on systems similar
to yours), and analysis of means of protection while still in the design
phase. Chapter eight provides a handy list of such attacks (if you are
building a Web application). "Security operations," in chapter nine,
appears to be a discussion of how software developers and security
professionals should relate to each other. (Touchpoint six, "security
requirements," is not covered.)
Part three covers additional topics. Chapter ten outlines advice for a
software security program in a large company. "Knowledge for software
security," in chapter eleven, is mostly an overview of material already
covered, but does include some additional tools. Chapter twelve is a
taxonomy of coding errors, which should be valuable both for those working
on analysis of their own program security, and also researchers in the
field.
One fairly consistent weakness is that the book seems to assume that all
software applications are network-based, and that all software problems
result from malicious attacks. While Web-based applications are definitely
of great importance, and also subject to a larger range of difficulties,
this does limit the application of some of the material of the text in
regard to standalone programs where the major concern is integrity of data,
prevention of errors, and reliability of operation.
The writing and structure could use some work: in many situations it is not
easy to follow the thread of McGraw's argument. However, there is no
denying the value of having all these ideas about software security brought
together in one volume. There is a great deal of useful and interesting
material here, and, with commitment from the reader, much that will be
helpful in building more robust and reliable software.
copyright Robert M. Slade, 2006 BKSWSBSI.RVW 20060518
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev/rms.htm
------------------------------
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.32
************************
This archive was generated by hypermail 2.1.3 : Wed Jun 14 2006 - 16:41:53 PDT