[RISKS] Risks Digest 24.46

risko@private

RISKS-LIST: Risks-Forum Digest  Sunday 5 November 2006  Volume 24 : Issue 46

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

  Contents:
Recent RISKS hiatus (PGN)
Widespread European power failure (PGN)
Rail network faces unlimited fine over 16 safety breaches (Scott Peterson)
VCR gets wrong time as DST ends (Steve Golson)
Three of Australia's major railway routes are blocked (M. Hackett)
Computer failure causing A320 PA not to work... (James Hughes)
SSE delay and failures reported (Martyn Thomas)
Regulating Search Engines? - Calif. Initiative For Internet Privacy
  (Lauren Weinstein)
Several backlogged items from Lauren Weinstein (PGN)
Electronic voting blamed for Quebec municipal election 'disaster' (Dan Hurley)
Re: More on A380 delivery delays (David Smith)
Re: A380 design software incompatibility costs 4.8 billion euros (Ed Prochak)
REVIEW: "Writing Secure Code", Michael Howard/David LeBlanc (Rob Slade)
Abridged info on RISKS (comp.risks)

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

Date: Sun, 5 Nov 2006 11:12:24 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Recent RISKS hiatus

I always regret long gaps between RISKS issues.  However, the past two weeks
involved attending OOPSLA in Portland OR (with a widespread power failure
that triggered evacuation of the entire Convention Center and surrounding
area, apparently including stoppage of the light rail system) and the ACM
CCS06 in Alexandria VA, along with staying in contact with various
activities at work.  In both conferences, hotel wireless systems were
massively overloaded by the plethora of participants' laptops, with repeated
network crashes and process vanishings that made Net access extremely
challenging.  Herewith is an attempt to catch up with the RISKS backlog.

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

Date: Sun, 5 Nov 2006 13:17:12 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Widespread European power failure

A high-voltage transmission line was shut down over a river to enable a
presumably large ship to pass.  This is preliminarily being attributed to a
propagating outage that affected something like 10,000,000 people in
Germany, France, Italy, Austria, Belgium and Spain.  [Source: Danna Avsec,
Power failure hits Europe, Associated Press, 05 Nov 2006; PGN-ed, TNX
to Lauren Weinstein for noting this one.]
  http://www.wkyc.com/news/news_article.aspx?storyid=58868

Somewhat ironically, my keynote talk at the ACM CCS 06 included discussions
on network-propagating outages in power and telephony, how they keep
recurring despite efforts to avoid them, and how they might be prevented.

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

Date: Wed, 01 Nov 2006 08:20:36 -0800
From: Scott Peterson <scottp4@private>
Subject: Rail network faces unlimited fine over 16 safety breaches

NETWORK RAIL faces an unlimited fine after admitting partial responsibility
for one of Britain's worst rail disasters, The company, which owns and
operates the entire rail infrastructure, admitted health and safety breaches
relating to the accident in October 1999 at Ladbroke Grove.  Thirty-one
people died and 400 were injured when a high-speed intercity train crashed
into a local service in West London during the morning rush hour.

Network Rail Infrastructure admitted at least 16 infringements at
Blackfriars Crown Court, in London. Relatives of three of the victims
attended the 20-minute hearing.  The charge referred to inadequate signal
sighting distances and the obscuring of part of a signal.

Other parts of the charge mean that the company has admitted that it failed
to ensure the convening of a signal- sighting committee after equipment was
installed in 1995, and also after six incidents when signals were passed
when red between 1996 and 1998. In addition, it did not carry out "adequate
risk assessments" or investigations following them.  [Source: Nicola
Woolcock, *The Times* (London), 1 Nov 2006]
http://www.timesonline.co.uk/article/0,,200-2431601,00.html#cid=OTC-RSS&attr=Law

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

Date: Mon, 30 Oct 2006 09:51:36 -0500
From: Steve Golson <sgolson@private>
Subject: VCR gets wrong time as DST ends

My Samsung VCR automatically sets its clock using XDS time signals which are
broadcast in my area by WGBH, our local PBS station. The VCR clock has
correctly followed DST on and off for years. Yesterday morning after
Daylight Savings Time ended, the clock was "automatically" set to the wrong
time, and it read two hours early. Turning the VCR on and off had no effect.

This morning the clock was still wrong. I unplugged the VCR, and when I
plugged it back in it displayed "Auto" as it searched the channels for the
XDS time signals. Eureka! we have the correct time today.

See also RISKS-17.73, 20.83, 20.95.

Other DST mixups: my new Day-Timer diary for 2007 gives the wrong DST
start/stop dates.

Steve Golson / Trilobyte Systems / +1.978.369.9669 / sgolson@private
Consulting in: Verilog, Synopsys, patent analysis, reverse engineering

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

Date: Fri, 3 Nov 2006 16:03:30 -0800
From: "M. Hackett" <dist23@private>
Subject: Three of Australia's major railway routes are blocked

I am amazed at the number of Australia's single-track rail lines.  In the
bigger scheme of rail transport in Australia, important lines should all be
double-tracked.

It is one thing for NZ to have so many single-track rail lines, as NZ
geography can be unduly harsh for the railroad builder.

Canada has this problem to a lesser extent -- as the US rail infrastructure
can always be used to route around any multiple trans-Canada rail snafu.
Canada's rail choke points need to be eliminated, but the central government
has not coordinated this yet.

Probably some 30,000 kms of heavily used rail need to be replaced in the
next decade in Canada -- but I don't see Ottawa trying to fix this problem
either.

See also
http://en.wikipedia.org/wiki/Centralized_traffic_control
http://en.wikipedia.org/wiki/Railway_signal
http://en.wikipedia.org/wiki/Railway_signaling

A huge North American rail safety issue: Dark Track -- tracks without any
safety signaling. Canada still has some [due to an incomplete Australian
like routing centralization], but the US has literally 'several million
KMS' of Dark Track.

On a joules/gram basis -- rail is still in many ways more energy
efficient than road transport.

The irony here is that [ideally] coal-steam engines are at best 10%
thermodynamically efficient.
Desil-electric trains manage to only stay in the [still dismal] 30% range
thermodynamically.

Max Power, CEO
http://HireMe.geek.nz/

*Derailments cause rail chaos*

Three of Australia's major railway routes are blocked this morning because
of derailments.  The Sydney to Melbourne railway line is blocked between
Junee and Cootamundra in southern New South Wales after a collision between
a truck and a freight train last night.
Wagga Wagga police say the truck driver was free of the rig before the
train hit and no one was injured.

The Olympic Highway is closed near the site and the railway line is
expected to be blocked until midday.

In outback South Australia seven derailed freight wagons have been
blocking the track near Tarcoola since Wednesday.

The line is an important route between the east coast and Perth, and
Adelaide and the Northern Territory.

Today's Ghan service from Adelaide to Alice Springs has been canceled and
freight deliveries have been delayed indefinitely.

Yesterday, three rail services were cancelled, leaving hundreds of travelers
stranded in Perth, Alice Springs and Adelaide.

Rail traffic in all directions has been delayed.

The Australian Rail Track Corporation expects to clear the line by
Sunday.

For more news visit ABC News Online at http://www.abc.net.au/news

Catch up with the latest arts and entertainment news in the ABC News
Online blogs Articulate http://www.abc.net.au/news/arts/articulate/ and
The Shallow End http://www.abc.net.au/news/arts/theshallowend/.

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

Date: Sat, 21 Oct 2006 13:17:53 -0700
From: james hughes <James.Hughes@private>
Subject: Computer failure causing A320 PA not to work... [Video]

I was on UA 914 from SFO to IAD on October 16th 2006 occupying seat 1B. This
is an A320 with a plaque that reads it is the 500th airbus built, with the
names of the people that accepted the plane from Airbus to United.

At FL39 approaching Denver, the weirdest thing happened.

It was like a 'B' horror movie.

All of a sudden all the lights in the cabin, including things like seat belt
lights, smoking light, call buttons etc. started randomly flashing. The
audio system went bonkers also changing channels, alternating static and
music, etc... The attached video was taken with my palm cell phone. While
this is looking forward, it was even weirder in the back with all the
flashing lights.

In the video you can see the lights flashing and the flight attendant trying
to get into the cockpit. The PA system flight attendant to cabin and cockpit
to cabin did not work. I suspect communications to the cockpit was a problem
to judging on how the flight attendant was constantly "ringing the bell" to
get the flight crew to open the door...

This went on for 10 minutes. The plane did not descent, turn or otherwise,
and even though Channel 9 was not coming through clearly, the chatter on the
radio was normal.

After it was over, the pilot said later that he was trying to turn off the
evacuation alarm(!) which he said was unbelievably loud and sounding in the
cockpit (although I did not hear it). He explained that he had never heard
this in flight before (good thing) and this was something that they heard in
training.

During that 10 minutes he had been in contact with the UA maintenance
people.

The explanation was that the passenger control system had failed. He said it
was the system that controls the "creature comforts" in the back of the
airplane including the lights and toilets (and a bit more I might add! I am
a little surprised that the PA, and crew to cockpit communications can be so
easily trashed.)

The pilot claimed to have been flying the A320 for 8 years and was taken
totally off guard by this.

My kudos to the crew for taking care of this. False alarms are at least
distracting, which can contribute to larger issues.

At the end the video, unbelievably, a passenger just had to get up and go to
the bathroom really bad. I told him to sit back down, but after the end of
the video he went anyway, right in the middle of this mess.

  [Video omitted here.  Contact Jim to view it.  PGN]

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

Date: Wed, 25 Oct 2006 10:15:04 +0100
From: "Martyn Thomas" <martyn@thomas-associates.co.uk>
Subject: SSE delay and failures reported

CRESTCo is the Central Securities Depository for the UK market and Irish
equities, and operates the CREST system, which provides settlement
facilities for a wide range of corporate and government securities,
including those traded on the London and Irish Stock Exchanges.. CREST also
settles money market instruments and funds, plus a variety of international
securities.

In September 2002, Crestco merged with Euroclear, which provides similar
services in other European countries. The merged group decided to develop a
single settlement engine (SSE) to unify their technology. Financial News
Online reported on October 16th that "Euroclear was due to deliver the first
phase last year but it did not go live until May". After the UK Crest system
was integrated with the SSE in August,  "the platform has suffered from
blocked messages, systems instability and slow settlement". The problems
have apparently led to a delay in the launch of a system for the Government
bonds market that was due on October 23rd.

The October Newsletter from Crestco (available online at
http://www.crestco.co.uk/news/newsletters/newsletter-oct2006.pdf) describes
the problems in some detail.

"On Tuesday, 29 August 2006, a small communications issue between CREST and
the SSE late in the afternoon generated a substantial number of error
messages. This blocked communication between the systems and effectively
halted settlement for a period of time. Although settlement was re-started
shortly after 17:00, the result of the delay was that UK banking deadlines
were pushed back to around 19:15, with major banks only able to close their
systems and process client accounts after 20:00. Additionally, although GBP
collateral management processing was fully completed, EUR and USD collateral
management (delivery by value (DBV)) events were not run. The issue was
caused by a configuration error that was magnified on 29 August 2006 as a
result of that date being the record date for coupon payments on a very
large number of gilts."

Other reported errors include: "Errors in the automatic splitting processing
resulted in securities positions not being split and settled efficiently,
leading to clients intervening to assess and manage their securities
positions interactively. Unfortunately, the manual splitting process has
been running much slower than it should, due to software locking and
contention issues similar to those affecting DBV processing. The errors
relating to automatic splitting were not identified in testing. However, it
is also the case that the erratic problem of settling splits in the wrong
order has been difficult to replicate in test scenarios, although CRESTCo
understands why it happens. The locking problems that impacted manual
splitting were not spotted in performance testing and, even if present, did
not negatively impact overall settlement rates, which are higher than in
CREST production. Software changes for the automatic splitting issue are now
in place. CRESTCo is also working to improve the performance of the manual
splitting process. As with the issue affecting DBVs, this primarily involves
�tuning� and �balancing� the system carefully, a process that
was underway at the time of launch but requires further refinement in the
live environment."

I recommend reading the newsletter, which gives an unusually frank
description of a private-sector project that has had significant problems.

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

Date: Wed, 4 Oct 2006 13:01:47 -0700
From: Lauren Weinstein <lauren@private>
Subject: Regulating Search Engines? - Calif. Initiative For Internet Privacy

Greetings.  CIFIP - California Initiative For Internet Privacy
(http://www.cifip.org ) -- is a public effort launched in October 2006 to
explore the desirability and possible implementation of voluntary and/or
mandated approaches toward improving a range of Internet-related privacy
issues.  The possibility of legislative actions, including particularly the
potential placing of a voter initiative on the 2008 California ballot
dealing with search engine data retention and privacy, are important initial
facets of this project.

CIFIP has been founded by Internet veteran Lauren Weinstein, who is
based in Los Angeles.

Major Internet search services based in California such as Google and Yahoo!
(AltaVista), plus other similar firms with substantial physical facilities
located within the state, are routinely collecting vast amounts of data from
those persons who conduct searches or perform other operations on these
companies' systems.  This data frequently includes the details of the
searches (that is, the search keywords themselves), connection-related data
that can be used in most cases to identify the source of those searches, and
other information potentially subject to both internal or external abuse.

Much of this data is intensely personal in nature.  Our search requests
cover a vast range of topics, including medical and other sensitive queries,
business and other research, and for most of us a whole host of searches
relating to our personal information, interests, desires, dreams, fantasies,
and even fears, among other topics.  The outrage over AOL's recent
publishing of a vast cache of users' search data served to demonstrate the
sensitivity of this data in dramatic fashion ...

For more information, including announcement and public discussion lists,
etc., please see:
  http://www.cifip.org

Thank you for your consideration.

Lauren Weinstein <lauren@private> Tel: +1 (818) 225-2800
http://www.pfir.org/lauren
Co-Founder, PFIR People For Internet Responsibility - http://www.pfir.org
Co-Founder, IOIC International Open Internet Coalition - http://www.ioic.net
Moderator, PRIVACY Forum - http://www.vortex.com
Lauren's Blog: http://lauren.vortex.com  DayThink: http://daythink.vortex.com

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

Date: Sat, 4 Nov 2006 15:54:52 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Several backlogged items from Lauren Weinstein

Several additional earlier items from Lauren Weinstein have accumulated
during the recent hiatus.  To catch up with the backlog, it seems
appropriate to steer you to the original documents rather than include them
here, especially if there is already subsequent discussion on Lauren's site.

   Microsoft Plans For Automatic Hobbling of "Pirated" Vista Systems
   http://lauren.vortex.com/archive/000194.html

   Google and Monopolies
   http://lauren.vortex.com/archive/000195.html

   Click Fraud, Google, and Telepathy
   http://lauren.vortex.com/archive/000196.html

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

Date: Wed, 25 Oct 2006 10:39:06 -0700
From: "Dan.Hurley" <Dan.Hurley@private>
Subject: Electronic voting blamed for Quebec municipal election 'disaster'

http://www.cbc.ca/canada/montreal/story/2006/10/25/voting-results.html?ref=rss

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

Date: Fri, 20 Oct 2006 09:55:17 +0100
From: "David Smith" <d.smith@private>
Subject: Re: More on A380 delivery delays (Ladkin, RISKS-24.45)

So isn't the real culprit the developer of CATIA who decided to change
the file format? If this a Microsoft product wouldn't we all be blaming
Bill Gates?

This reminded me of a problem many years ago with the Alsys Ada Compiler.

The company that I worked for used V4 of the Motorola 680x0 compiler on Sun
3/60's, 3/80's etc. Everything was fine until Alsys "upgraded" the compiler
to V5. Suddenly the applications that were being developed would no longer
work.

After much investigation it was found that Alsys had decided that V5 would
use the first page of memory for it's own purposes when the compiled/linked
code was executed. We had been using the first page as a vector
table. (Well, that is how I remember it, it was a while ago)

The only solution was to move from Sun/3 hosts to Sun SPARCstation hosts,
but as the target was 68040 based and, I think, the V5 compiler had not been
validated for such cross development, this was not an option.

This was very nearly the deathknell of one particular product, an Integrated
Health & Usage Monitoring System (I-HUMS).

Whose fault was it?
- Alsys for changing the way the compiler compiled?
- Us for using a particular memory architecture?
- Sun for developing the SPARC processor?

David H Smith, Frazer-Nash Consultancy Limited, Stonebridge House, Dorking
Business Park Dorking, Surrey RH4 1HJ UK Tel: +44 (0) 1306 885050

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

Date: Sat, 21 Oct 2006 16:14:22 -0400
From: "Ed Prochak" <edprochak@private>
Subject: Re: A380 design software incompatibility costs 4.8 billion euros

  Date: Wed, 4 Oct 2006 09:46:48 +1000
  From: "mike martin" <mke.martn@private>
  Subject: A380 design software incompatibility costs 4.8 billion euros

Bloomberg has reported that the wiring problems that have delayed A380
deliveries yet again are related to incompatibility between versions of CAD
software being used:
http://bloomberg.com/apps/news?pid=20601109&sid=aSGkIYVa9IZk&refer=ex...>

  ... engineers in Germany and Spain stuck with an earlier version of
  Paris-based Dassault Systemes SA's Catia design software, even though the
  French and British offices had upgraded to Catia 5.  That meant the German

  teams couldn't add their design changes for the electrical wiring back
  into the common three- dimensional digital mock-up being produced in
  Toulouse, [Charles] Champion [former head of the A380 program]
  says. Efforts to fiddle with the software to make it compatible failed,
  meaning that changes to the designs in the two offices couldn't be managed

  and integrated in real time, he says.  ``The situation worsened when
  construction and tests of the first A380s generated demands for structural

  changes that would affect the wiring. The changes in configuration had to
  be made manually because the software tools couldn't talk to each other.''

Catia file formats changed between version 4 and version 5. An initiative
has now begun to standardise software tools across the program.
 <end quote>

This incompatibility seems an excuse to me. Surely the French division when
upgrading from version 4 to version 5 of the CAD software had available
conversion software. Given that such software exists, why did they not use
it to integrate the German changes into the central design? It would not
have been "realtime", but it would have shown the incompatibility quickly.

Ed Prochak, Magic Interface, Ltd.

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

Date: Fri, 27 Oct 2006 08:50:21 -0800
From: Rob Slade <rMslade@private>
Subject: REVIEW: "Writing Secure Code", Michael Howard/David LeBlanc

BKWRSCCD.RVW   20060910

"Writing Secure Code", Michael Howard/David LeBlanc, 2002,
0-7356-1588-8, U$39.99/C$57.99
%A   Michael Howard
%A   David LeBlanc
%C   1 Microsoft Way, Redmond, WA   98052-6399
%D   2002
%G   0-7356-1588-8
%I   Microsoft Press
%O   U$39.99/C$57.99 800-MSPRESS fax: 206-936-7329
%O  http://www.amazon.com/exec/obidos/ASIN/0735615888/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/0735615888/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0735615888/robsladesin03-20
%O   Audience a Tech 2 Writing 1 (see revfaq.htm for explanation)
%P   477 p. + CD-ROM
%T   "Writing Secure Code"

The introduction states that the purpose of the book is to teach application
designers (and particularly .NET developers) to design, write, and test
application code in a secure manner.

Part one addresses the contemporary security situation.  Chapter one reviews
the need for secure systems.  The text is so supplemented by notes,
comments, text boxes, and sidebars that it becomes difficult to follow at
times.  However, ultimately it does have a lot of interesting material that
would be useful for those who have to make a case for secure coding
practices and processes.  Designing secure systems, in chapter two, provides
a solid list of secure strategy principles along with details and discussion
of them, although much of this deliberation is restricted to "war stories"
which are interesting but not always useful.  The content makes the point
that the mere addition of security technologies does not always make for
secure applications, which point is not supported by the inclusion, in the
latter part of the material, of a huge list of security technologies.

Part two turns to secure coding techniques.  Chapter three details that old
standard and nemesis, the buffer overflow.  Unfortunately, most of what is
provided is limited to code demonstrating that various types of buffer
overflows exist, and some contentions in regard to specific C language
instructions that should not be used.  Code for access control list use on
Windows NT4 and 2000 is reviewed in chapter four.  Code, but not design, for
running with least privilege occupies chapter five.  Chapter six is again
concerned primarily with source code for cryptographic operations, although
limited to pseudorandom number generation (paying insufficient attention to
seed values), key management, and miscellaneous topics.  Further functions
involved with encrypting confidential information are in chapter seven.
Chapter eight turns to canonical representation, although the discussion is
narrowly confined to filenames and issues of traversal.

Part three concentrates on network-based application considerations even
though network connectivity and access has been given as the reason to pay
attention to secure coding in the first place.  Chapter nine looks at the
possibility of port hijacking, and the design of applications in order to
work cooperatively with firewalls.  Securing the use of RPC (Remote
Procedure Calls), ActiveX, and DCOM (Distributed Common Object Model) is
covered well in chapter ten, with concepts as well as code and good
explanations (although I know for a fact that accessing dcomcnfg on XP is
*not* as easy as the authors want to make out).  Chapter eleven lists some
denial of service (DoS) attacks and generally suggests limiting the
resources available to applications.  Most of the advice on securing
Web-based services, in chapter twelve, boils down to advice not to trust the
client, and various examples of malformed input are described.

Part four contains special topics.  Chapter thirteen details .NET functions
and operations related to security, but also provides valuable guidance in
regard to appropriate (and inappropriate) use.  Testing of secure
applications gets a review of standard procedures, in chapter fourteen, but
the material does not provide an abstract overview of assessment concepts
that could be used to find all possibilities of weakness.  Installation
procedures, in chapter fifteen, could have been useful, but is probably the
most Windows specific and least practical section of the entire work.
Chapter sixteen is a bit of a grab bag, but contains worthwhile tips and
principles to follow (mostly in order to avoid common security pitfalls).

Appendices are usually extraneous material, sometimes added merely to pad
out the page count of a book.  However, the essays included at the end of
this volume could be quite helpful.  There are the ten immutable laws of
security and the ten immutable laws of security administration, which have
become famous in their own right, and have spread through the Internet, as
well as a list of dumb excuses given for not doing security properly.

Overall, the book contains much that can be of use for those who wish to
develop code that is secure and resistant against bugs and flaws that may
open the application to attack.  However, there is also a good deal that is
irrelevant and not helpful, and a number of issues that could have useful
have not been included (such as development methodologies, design
strategies, and testing issues).

copyright Robert M. Slade, 2006   BKWRSCCD.RVW   20060910
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.46
************************