[RISKS] Risks Digest 25.39

From: RISKS List Owner <risko_at_private>
Date: Fri, 17 Oct 2008 14:04:53 PDT
RISKS-LIST: Risks-Forum Digest  Friday 17 October 2008  Volume 25 : Issue 39

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/25.39.html>
The current issue can be found at
  <http://www.csl.sri.com/users/risko/risks.txt>

  Contents:
NSA posts secrets to writing secure code (Joab Jackson via Jim Innes)
Excel error leaves Barclays with extra Lehman assets (Gabe Goldberg)
LAPD blames fingerprint errors for false arrests (PGN)
Maryland Police Put Activists' Names On Terror Lists (David Hollman)
Airport baggage screener charged with stealing passengers' stuff
  (Peter Houppermans)
Credit card readers compromised (Peter Houppermans)
More Smart Card Cracking (Gene Wirchenko)
Stolen Votes and Stolen Elections (Mark E. Smith, PGN)
Online health records (David Magda)
New Data Privacy Laws Set For Firms (Ben Worthen via Monty Solomon)
New Massachusetts Regulation Requires Encryption of Portable Devices ...
  (Monty Solomon)
Amazon e-mail accounts (Steve Loughran)
Security questions with unacceptable answers (Earl Truss)
Worrisome money transfer (Martin Cohen)
Stallman vs. Cloud Computing (jidanni)
A comment on "outliers" (Ken Knowlton)
The Risks of "Something you know" (Steve Taylor)
Re: D10T: National Debt Clock is out of digits (Andrew Raybould)
"Sydney NS vs. Sydney NSW" and popup adds! (Paul D.Smith)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: October 14, 2008 11:58:28 AM EDT
From: "Jim Innes" <james.innes_at_private>
Subject: NSA posts secrets to writing secure code

  [Recall that RISKS has always sought to include success stories on
  approaches that can avoid the types of risks that continually reappear
  here.  Here is one example of something that might be educationally worth
  considering.  PGN]

  [From Dave Farber's IP group.  PGN]
  Archives: https://www.listbox.com/member/archive/247/=now

Joab Jackson, Tokeneer case study serves as an example of writing
low-defect, highly-reliable code, researchers claim, *Government Computer
News* weekly newsletter.

The National Security Agency has released a case study showing how to
cost-effectively develop code with zero defects. If adopted widely, the
practices advocated in the case study could help make commercial software
programs more reliable and less vulnerable to attack, the researchers of the
project conclude.

The case study is the write-up of an NSA-funded project carried out by the
U.K.-based Praxis High Integrity Systems and Spre Inc. NSA commissioned the
project, which involved writing code for an access control system, to
demonstrate high-assurance software engineering.

With NSA's approval, Praxis has posted the project materials, such as
requirements, security target, specifications, designs and proofs.

The code itself, called Tokeneer, has also been made freely available.

``The Tokeneer project is a milestone in the transfer of program
verification technology into industrial application," said Sir Tony Hoare,
noted Microsoft Research computer scientist, in a statement.  "Publication
of the full documents for the project has provided unprecedented
experimental material for yet further development of the technology by pure
academic research.''

Developing code with very few defects has long been viewed as a difficult
and expensive task, according to a 2006 paper by Praxis engineers describing
the work that was published in the International Symposium on Signals,
Systems and Electronics.

For this project, three Praxis engineers wrote 10,000 lines of code in 260
person-days, or about 38 lines of code per day.

After the project was finished, a subsequent survey of the code found zero
defects.

Moreover, Tokeneer meets or exceeds the Common Criteria Evaluation Assurance
Level (EAL) 5, researchers said. Common Criteria is an ISO-recognized set of
software security requirements established by government agencies and
private companies. Industry observers have long concluded that it would be
too expensive for commercial software companies to write software programs
that would meet EAL 5 standards.

According to the 2006 paper, the engineering team used a number of different
techniques for writing the code, all bundled into a methodology they call
Correctness by Construction, which emphasizes precise documentation,
incremental developmental phases, frequent verification and use of a
semantically unambiguous language.

The developers wrote the code in a subset of the Ada programming language
called SPARK, which allows for annotations that permit static analysis of
the program. They used the GNAT Pro integrated developer environment
software from AdaCore.

"This case study has shown that software-based security products can be
built that are reliable, verifiable and cost effective against Common
Criteria guidelines," the paper concluded. "The bar has been raised for both
procurers and suppliers."

------------------------------

Date: Tue, 14 Oct 2008 19:35:22 -0400
From: Gabe Goldberg <gabe_at_private>
Subject: Excel error leaves Barclays with extra Lehman assets

A reformatting error in an Excel spreadsheet has cropped up in the largest
bankruptcy case in U.S.  history, prompting a legal motion by Barclays
Capital Inc. to amend its deal to buy some of the assets of Lehman Brothers
Holdings Inc.  The law firm representing Barclays filed the motion (download
PDF) on Friday in U.S. Bankruptcy Court for the Southern District of New
York, seeking to exclude 179 Lehman contracts that it said were mistakenly
included in the asset purchase agreement. The firm -- Cleary Gottlieb Steen
& Hamilton LLP -- said in the motion that one of its first-year law
associates had unknowingly added the contracts when reformatting a
spreadsheet in Excel.  [Source: Excel error leaves Barclays with more Lehman
assets than it bargained for, *Computerworld*, Oct 14 2008]

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9117143

  [Another Excel-lent risk report, also noted by Chris Leeson, who observed
  that there should be fireworks at the hearing scheduled for 5 Nov, which
  will be just in time for Guy Fawkes Night!  PGN]

------------------------------

Date: Fri, 17 Oct 2008 10:40:13 PDT
From: "Peter G. Neumann" <neumann_at_private>
Subject: LAPD blames fingerprint errors for false arrests

Police have arrested innocent people due to faulty fingerprint analysis but
have not determined how many cases were affected by such errors.  The *Los
Angeles Times* has obtained an internal police report that notes two cases
in which charges were dropped after problems with the fingerprint analysis
were discovered, blamed on "shoddy work and poor oversight".  One
fingerprint analyst, who was involved in both the mishandled cases, was
fired and three others were suspended and two supervisors replaced.
"This is something of extraordinary concern," said Michael Judge, public
defender for Los Angeles County. "Juries tend to afford the highest level of
confidence to fingerprint evidence. This is the type of thing that easily
could lead to innocent people being convicted."  [Source: AP item, 17 Oct
2008; PGN-ed, thanks to Lauren Weinstein]
  http://www.dailynews.com/breakingnews/ci_10743941

------------------------------

Date: Wed, 15 Oct 2008 20:25:05 +0100
From: "David Hollman" <david.hollman_at_private>
Subject: Maryland Police Put Activists' Names On Terror Lists

*The Washington Post*, 7 Oct 2008
http://www.washingtonpost.com/wp-dyn/content/article/2008/10/07/AR2008100703245.html

"[Some of the involved officials] said the activists' names were entered
into the state police database as terrorists partly because the software
offered limited options for classifying entries." (from the second page).

The gist of it is that the MD police added names of people who were
nonviolent protesters to a terrorist watch list/database; their names were
also included on a federal database as well.

While there may be software design and use issues involved (such as: did the
database admins have an incomplete grasp of all the "use cases" to be
tracked?  Were the choices deliberately limited for some political or
statistical purpose?) the most potent risk may be that "computer problems"
can be used as an excuse for a much more serious human error.

------------------------------

Date: Wed, 15 Oct 2008 13:01:27 +0200
From: Peter Houppermans <peter_at_private>
Subject: Airport baggage screener charged with stealing passengers' stuff

 From http://www.theregister.co.uk/2008/10/14/tsa_screener_theft/:

A baggage screener for the US Transportation Security Administration has
confessed to brazenly stealing a trove of electronics gear from the luggage
of passengers he was sworn to protect, federal prosecutors said.

Pythias Brown, 48, of Maplewood, New Jersey, regularly sold the high-priced
video cameras, laptop computers, and global positioning systems on eBay
using the handle "alirla," according to a criminal complaint filed in
federal court in Newark. Brown told investigators he began stealing the
items in September 2007 while screening luggage at Newark Liberty
International Airport.

------------------------------

Date: Wed, 15 Oct 2008 13:07:49 +0200
From: Peter Houppermans <peter_at_private>
Subject:  Credit card readers compromised

This is a biggie:
http://www.theregister.co.uk/2008/10/10/organized_crime_doctors_chip_and_pin_machines/

In a nutshell, criminals installed mobile phone kit INSIDE credit card
readers before they arrived at merchants and shops, thus sending details of
every card used on those terminals to criminals in Pakistan.  Not sure how
this was discovered, but the scale is breathtaking.

  [Followup: I requested more details, and Peter replied.  PGN]

You should watch a BBC program, available on YouTube.  In part 2, my
favourite news reported, Jeremy Paxman, goes into grilling mode, and he
tears strips off the credit card suppliers who are trying to pretend it's
not a big deal.  Well, it is.  See
http://www.youtube.com/watch?v=L7QzOcZAwbg, part 2 is
http://youtube.com/watch?v=pHdX3ZYEvXw.  It's quality TV.  (Paxman can be
incredibly obnoxious if he doesn't get a straight answer, enjoy.)  Also
features Ross Anderson from Cambridge, oh, and they managed to get a
terrorist angle on it (grin).

OK, below an elaboration.  I have omitted by part 2 that I'm one of the two
principal authors of an algorithm that addresses that mutual authentication
problem in full (which will become part of our token firmware Q1 2009 or
maybe earlier), I didn't really want to blow my own horn (or be seen to),
nor do i want to play the marketing buffoon.  I solve problems, not flog
gadgets - and I will get back to you with something new there too.  FYI,
www.axsionics.ch, happy to send you docs.

  Interesting challenge to discover..

  1 - it's an add-on, so the electronics won't detect changes as inputs are
  tapped before they get to the tamperproofing.

  2 - if you block mobile comms there will be another way. You're fixing the
  wrong problem (more on that later).  The good news is that the method they
  used caused interference, eventually leading to discovery.  It sort of
  radiated trouble..

  A disclosure before I start: I actually work for the company that solved
  this whole problem about a year ago (well, actually several years ago, but
  the startup has grown into a "real" company :-).  Who wants to know will
  find out easily enough, but my reply is not for marketing.

  Transaction challenges (also by banks):

  1 - ensure that, as a payment provider, you're talking to the actual
  account holder

  2 - assure to the account holder that you are, indeed, the payment handler

  3 - secure this whole process to ensure authentication, authorisation,
  confidentiality and integrity of the process

  (bonus challenge: 4 - ensure that a transaction is actually as expected by
  the client and get an approval that supports non-repudiation)

Point 1 is done by PIN.  The above hack destroys that assurance, but it was
IMHO weak to start with, even though most of my cards have 6 digits.  The
ones with signatures have my face next to the signature (given the quality
of the picture mainly to frighten people).  How do I know as provider that
"owner" and card are together when this happens?  I don't - at a point of
sale Chip & PIN has driven the assumption that "it must be so", and
merchants no longer have any means to check other than picture cards which
nobody examines other than with a signature.

Point 2 is where both ATMs and credit card terminals fall down, as well as
banks that call their customers - how do you know it's really the bank?  How
do I know I'm entering my PIN safely?  Nothing assures the user of the
rightful recipient of their always-the-same PIN..

Point 3 is inadequately dealt with by the "secure shell" approach a("secure"
network and "secure" terminal, which means a rogue insider -network or
hardware- nulls your whole approach).  It is moderately OK from a risk
management point of view as you contain the fraud ability to a limited
audience, but as soon as someone gets *really* creative many will follow the
new path - QED above.  With Internet banking there is a dependency on the
user terminal being moderately safe, something you can never ensure as a
bank.  In addition, OTP lacks feedback, challenge - response devices work
with cleartext so a Man In The Middle or Man In The Browser remains
possible.  Note that we started this discussion with a credit card which has
NOTHING apart from a secure terminal - if it isn't you thus have a major
problem.

Point 4 is now dealt with with out-of-band methods - get a display and
confirmation via another route, typically mTAN.  But do you really want
transaction details travel via an insecure network which principally has no
SLA for SMS?  SMS traffic is the first that gets dropped if the cell gets
busy..  In credit cards PIN entry is assumed to function both as
authentication and authorisation, but the above hack would have worked even
if those steps were with different PINs.

There are a few solutions to the whole picture, but keep in mind that the
base assumption should always be that the system the card is used on is
infected/hacked/tampered with, which rather reduces the number of options.
In addition, improving security has normally a tendency to make life harder
for the poor end user who has to go through more ritual, incantations and
incense burning on behalf of the relevant issuer to keep things safe.

------------------------------

Date: Tue, 14 Oct 2008 18:54:58 -0700
From: Gene Wirchenko <genew_at_private>
Subject: More Smart Card Cracking

http://www.infoworld.com/article/08/10/07/Researchers_show_how_to_crack_popular_smart_cards_1.html?source=NLC-SEC&cgd=2008-10-13

------------------------------

Date: Tue, 14 Oct 2008 22:46:47 -0700
From: "Mark E. Smith" <mymark_at_private>
Subject: Stolen Votes and Stolen Elections

http://globalpundit.org/2008/10/13/oped-stolen-votes-and-stolen-elections/
http://www.opednews.com/articles/OpEd-Stolen-Votes-and-Sto-by-Mark-E-Smith-081014-17.html

------------------------------

Date: Fri, 17 Oct 2008 10:40:13 PDT
From: "Peter G. Neumann" <neumann_at_private>
Subject: Stolen Votes and Stolen Elections

Mark Smith's message reminds me of a book I just received:

  Richard Hayes Phillips
  Witness to a Crime: A Citizen's Audit of an American Election
  Canterbury Press, Rome NY, March 2008
  ISBN 978-0-9798722-3-5

This is an extraordinarily detailed analysis of the 2004 presidential
election in Ohio, and perhaps a harbinger of things to come.  PGN]

------------------------------

Date: Fri, 17 Oct 2008 10:02:46 -0400 (EDT)
From: David Magda <dmagda_at_private>
Subject: Online health records

This needs to proceed very, very carefully:

> The Progressive Conservative government plans to start slowly, at first
> offering only a bit of information such as vaccination records. However,
> the end goal is to post everything, including prescriptions, X-rays and
> laboratory test results. [...]
>
> Mr. Brisson said addressing security and privacy concerns will be
> paramount as the province builds the new e-health service. He's hopeful
> that 'an incremental approach' will not only build up confidence but also
> usage.
>
> He said Alberta is in a position to take this step because it's already
> developed an electronic medical record system accessible exclusively to
> health-care providers. Every other province and territory is now setting
> up similar paperless systems.

http://tinyurl.com/6755ak
http://www.theglobeandmail.com/servlet/story/RTGAM.20081017.health17/BNStory/National/home

The whole "exclusively to health-care providers" bit sounds a bit naive,
given the reports out of the US of hospital and IRS employees accessing
records of celebrities.

Maher Arar is probably glad that the Syrians couldn't get his medical
records:
  http://en.wikipedia.org/wiki/Maher_Arar

Can government agencies request (warrant or not) a copy of your medical
records if it's in a central database?

We generally know how to secure paper records, I don't think we've quite
figured out how to do the same with electronic records.

------------------------------

Date: Fri, 17 Oct 2008 00:06:43 -0400
From: Monty Solomon <monty_at_private>
Subject: New Data Privacy Laws Set For Firms (Ben Worthen)

Ben Worthen, New Data Privacy Laws Set For Firms, *The Wall Street Journal*,
16 Oct 2008

Alicia Granstedt, a Las Vegas-based hair stylist who works for private
clients and on movie sets, never worried about conducting most of her
business through e-mail.  Ms. Granstedt regularly receives e-mails from
customers containing payment details, such as credit-card numbers and
bank-account transfers. Since she travels frequently, she often stores the
e-mails on her iPhone.  But a Nevada law that took effect this month requires
all businesses there to encrypt personally-identifiable customer data,
including names and credit-card numbers, that are transmitted
electronically.

After hearing about the new law, Ms. Granstedt started using e-mail
encryption software, which requires her clients to enter a password to read
her messages and send responses. It is a hassle, "but I can't afford to be
responsible for someone having their identity stolen," she said.

Nevada is the first of several states adopting new laws that will force
businesses -- from hair stylists to hospitals -- to revamp the way they
protect customer data. Starting in January, Massachusetts will require
businesses that collect information about that state's residents to encrypt
sensitive data stored on laptop computers and other portable
devices. Michigan and Washington state are considering similar
regulations. ...

http://online.wsj.com/article/SB122411532152538495.html

------------------------------

Date: Fri, 17 Oct 2008 09:13:37 -0400
From: Monty Solomon <monty_at_private>
Subject: New Massachusetts Regulation Requires Encryption of Portable
  Devices and Comprehensive Data Security Programs

Miriam Wugmeister and Charles H. Kennedy, Morrison & Foerster, Sep 2008
  http://www.mofo.com/news/updates/bulletins/14495.html

Randy Gainer, New State Laws Require Extensive Data Security Plans and
Encryption, Davis Wright Tremaine LLP, Sep 2008
  http://www.dwt.com/practc/privacy/bulletins/09-08_DataSecurityPlans.htm

201 CMR 17.00: Standards for The Protection of Personal Information
of Residents of the Commonwealth
  http://www.mass.gov/?pageID=ocaterminal&L=4&L0=Home&L1=Consumer&L2=Privacy&L3=Identity+Theft&sid=Eoca&b=terminalcontent&f=reg201cmr17&csid=Eoca

Ben Worthen, New Data Privacy Laws Set For Firms,
*The Wall Street Journal*, 16 Oct 2008
  http://online.wsj.com/article/SB122411532152538495.html

------------------------------

Date: Thu, 2 Oct 2008 19:56:00 +0100
From: "Steve Loughran" <steve.loughran_at_private>
Subject: Amazon e-mail accounts

Regarding the issue about Amazon allowing >1 login per e-mail address, its a
historical legacy that they probably hate. Remember back in 1995 when the
whole family had one compuserve or AOL e-mail address? That's when Amazon was
created, and that is where they came up with the fact that an Amazon user
does not have a 1:1 mapping of e-mail->userID. What they do have is a mapping
of (e-mail,password)->userID; you can create two accounts with the same e-mail
address, but you will get into trouble if you try and give them the same
password. I'm not sure what happens, so try it and see.

The newer Amazon services, such as the Amazon Web Services, have a stricter
"one e-mail address" per account rule. Clearly their support organisation has
learned the error of the original design decision.

------------------------------

Date: Fri, 3 Oct 2008 10:05:05 -0500
From: "Earl Truss" <etruss_at_private>
Subject: Security questions with unacceptable answers

My wife recently bought a new car and the dealer arranged financing through
a local credit union.  This credit union has a web site that allows one to
check on their accounts and do transfers between accounts and such.  I
wanted to use the site to make sure the first payment was credited correctly
so I attempted to log in.  First off, the owner of the account has to call
them so they can send out a password to be used for the initial log in so we
did that.  When I received the password, I again went to the web site and it
required me to change the default password.  So far, so good.  It then
required me to set up some security questions by choosing from a fixed list
of perhaps ten questions.  One of the first was "What was the color of your
first car?"  I picked that one since I thought that was easy for me to
remember but difficult for anyone else to know or find out so I typed in the
answer - "red".  I was told that I had to enter at least four characters for
the answer to the question.  I really had no idea what to do except laugh at
the programmer who came up with this one.  Figuring that this was the case
for all of them, I tried again ...  "What is your father's middle name?"
"Bud" "You must enter at least four characters for the answer to this
question."  Obviously we must distort reality to pass this test.

------------------------------

Date: Thu, 2 Oct 2008 13:16:09 -0700 (PDT)
From: martin cohen <mjc_q_at_private>
Subject: Worrisome money transfer

I wanted to transfer some money between two of my IRAs (banks unnamed). I
logged into the one where the money was to go (I prefer pull to push). I
anticipated having to go to the source, print out a form, signing it, and
mailing it in.

Instead, all I had to do was, at the receiving site, enter the source
account number, and request a transfer. No authentication of any type was
asked for. Less than a week later, the money was transferred.

I don't know if this is common, but this worries me. Can anyone withdraw
money from my account just by knowing the account number? I did not see any
matching of names between the accounts.

------------------------------

Date: Wed, 15 Oct 2008 05:52:31 +0800
From: jidanni_at_private
Subject: Stallman vs. Cloud Computing

Stallman cautions against the "cloud computing" myth:

http://lists.gnu.org/archive/html/bug-findutils/2008-10/threads.html
http://techblog.dallasnews.com/archives/2008/10/cloud-computing-is-stupidity-s.html
http://blogs.zdnet.com/carroll/?p=1880
http://www.guardian.co.uk/technology/2008/sep/29/cloud.computing.richard.stallman
http://blogs.computerworld.com/rms_hates_cloud_computing_says_you_should_too
and also http://www.osnews.com/thread?332053 if you have the right browser.

I just want to add a warning that one day when one's Gmail breaks, one will
attempt for the first time in one's life to contact the massive Google
Corporation. Whereupon one will discover that despite their best intentions,
due to their massive scale, there is little chance one will get a personal
reply. "No problem" you might say, "there will certainly be many others in
the same boat, so it will get fixed".  Well, yes that's usually how it works
with power outages and the electric company, if not at least you can still
always just call their local service center.

  [When Gmail breaks?  What about the complaints that repeated failed login
  attempts (a simple type of denial-of-service attack) results in YOUR Gmail
  account being disabled, with no easy way to get it reactivated?  PGN]

------------------------------

Date: Fri, 3 Oct 2008 16:54:04 EDT
From: Ken Knowlton <KCKnowlton_at_private>
Subject: A comment on "outliers" (RISKS-25.37)

PGN mentions "outliers" (RISKS-25.37) -- leading me to muse on the automatic
elimination of aberrant points.  In some sporting events, a common practice
is to eliminate the highest and lowest judges' scores, and to average the
rest. But now consider generalizing on the idea: It may not be generally
known, for example, that there are configurations of equally-weighted points
in 3-D space for which the pair of points that are farthest apart from each
other are the two points that are closest to the center of gravity of the
lot!

  [I guess that very few RISKS readers will identify Ken with one of his
  most delicious innovations (if I remember correctly from our Bell Labs
  days in the 1960s): the 17-sided unistable uniform solid that will always
  roll over onto the same side: the ultimately loaded-but-unloaded die.
  Very dicey matter.  PGN]

------------------------------

Date: Fri, 3 Oct 2008 12:15:00 +1000
From: "Steve Taylor" <staylor_at_private>
Subject: The Risks of "Something you know" (Re: Miller RISKS-25.37)

A recent article (RISKS-25.37) mentioned the danger that the "something you
know" used to authenticate an account may sometimes be "something everybody
knows".

This brings to mind a newspaper article I once read on computer security.
While for the most part it was a pretty decent article, I winced when the
reporter mentioned that his own e-mail account had once been broken into,
even though he'd carefully chosen the extremely obscure password "THX1138".

While that looks pretty much like a random string of letters, it is in fact
the name of George Lucas's first film, from his student days.

I don't know what the overlap is between hackers and science fiction fans,
but I'm sure it's substantial. "THX1138" is probably more secure than
"Gandalf", but it's still nothing to feel safe with.

The moral: choose a *really* secure password. I suggest "Picard" or
"Skywalker".

------------------------------

Date: Thu, 16 Oct 2008 22:56:48 -0400
From: "andrew raybould" <stop.posting.addresses_at_private>
Subject: Re: D10T: National Debt Clock is out of digits

This is one integer-overflow problem where it seems an opportunity was lost
by not using a signed integer... Oh, well, the timing is fortuitous:
just when this counter needs another digit, one has become available from
the Dow Jones Industrial Average.

------------------------------

Date: Wed, 15 Oct 2008 09:17:21 +0100
From: "Paul D.Smith" <paul_d_smith_at_private>
Subject: "Sydney NS vs. Sydney NSW" and popup adds! (Re: RISKS-25.36-38)

I tried to read the story from the "Athens News" but every single link takes
me into a popup add zone for domains.  I presume the "Athens News" website
has something hacked into it because I see the story briefly but then I'm
thrown elsewhere.

------------------------------

Date: Thu, 29 May 2008 07:53:46 -0900
From: RISKS-request_at_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_at_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_at_private or risks-unsubscribe_at_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_at_private>.
=> SPAM challenge-responses will not be honored.  Instead, use an alternative
 address from which you NEVER send mail!
=> SUBMISSIONS: to risks_at_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 for current volume
     or ftp://ftp.sri.com/VL/risks for previous VoLume
 <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
==> Special Offer to Join ACM for readers of the ACM RISKS Forum:
    <http://www.acm.org/joinacm1>

------------------------------

End of RISKS-FORUM Digest 25.39
************************
Received on Fri Oct 17 2008 - 14:04:53 PDT

This archive was generated by hypermail 2.2.0 : Fri Oct 17 2008 - 14:25:11 PDT