RISKS-LIST: Risks-Forum Digest Sunday 26 December 2004 Volume 23 : Issue 63
ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <http://www.risks.org> as
<http://catless.ncl.ac.uk/Risks/23.63.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Patients not notified due to computer glitch (Jim Bruce)
Comair cancels all flights 25 Dec (Jeremy Epstein)
Restarting a reactor with a flawed part (Ken Knowlton)
Wrong braking algorithm causes trains to overrun stops (Mark Brader)
Banksys solves cash card mystery (David Kennedy)
Y2K? Never heard of it... (Dag-Erling Smørgrav)
The new NASA calendar (Tom Nimitz)
Flaw in Google's New Desktop Search Program (John Markoff)
Windows into the world (Monty Solomon)
The Graphing Calculator Story (Ron Avitzur)
Why adding more security measures may make systems less secure (Don Norman)
Re: GPS Shutdown "during national crisis" (Pat Place)
Re: Unintended effects of RFID devices (cogg)
Re: Strange S&P numbers (Dawn Cohen)
Re: Whites Only websites? (Jonathan de Boyne Pollard)
Software Engineering for Secure Systems: SESS05 (Gene Spafford)
REVIEW: "Network Security Hacks", Andrew Lockart (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Wed, 22 Dec 2004 09:16:19 -0500
From: Jim Bruce <jim.bruce@private>
Subject: Patients not notified due to computer glitch
The *Toronto Sun* reported this morning that a computer bug is being
blamed for the fact that over 14,000 radiology reports were not printed
and sent to doctors. This occurred at a newly built hospital in the
Montreal area from 7 Jan 2004 until 17 Dec 2004! The reports were not
destroyed, but because they were never printed, doctors did not follow
up with the patients. The reports included abnormal radiology results,
so some patients may have cancer and not know it.
I suspect that most patients assumed that if they heard nothing then
there was nothing to worry about.
http://www.canoe.ca/NewsStand/TorontoSun/News/2004/12/22/793248-sun.html
[Taj Khattra noted that the same article referred to the health status of
579 Quebec patients.]
------------------------------
Date: Sat, 25 Dec 2004 20:43:48 -0500
From: Jeremy Epstein <jeremy.epstein@private>
Subject: Comair cancels all flights 25 Dec
CNN reports that "Comair, which flies an average of 30,000 people per day,
called off all 1,160 daily flights for both Saturday and Sunday. It will
resume a limited schedule Monday, Comair spokesman Don Bornhorst said. The
computer system Comair uses to book pilots for flights broke down, he said.
Comair could not pinpoint a reason for the computer crash and could not say
why there was no backup system." [Comair flies flights in the eastern and
midwest US as Delta Express.]
http://www.cnn.com/2004/TRAVEL/12/25/flights.canceled/index.html
Comair's web page admits that they are "currently experiencing computer
problems, resulting in cancellation of flights through December 26th, 2004.
This includes, but is not limited to, flights to/from Cincinnati, Ohio."
We shouldn't be surprised that computer failures (whether hardware,
software, a combination, or something else) is causing problems, but this is
the first case I can recall where it's caused an airline to cancel *all* of
their flights for days.
Between failures like this and the nasty weather in the midwest, I'm sure
glad to be home this holiday weekend!
[A short squib in the Palo Alto California Sunday *Daily News* noted that
the 30,000 passengers span 118 cities, although *The New York Times*
article said 119. Also of note were the USAir baggage-handling problems
in Philadelphia, where an estimated 8 to 10 thousand luggage items piled
up; USAir canceled 65 flights on Thursday, 176 on Friday, and 143 on
Christmas Day, due to bad weather, sick baggage handlers in Philadelphia,
etc. PGN]
------------------------------
Date: Wed, 22 Dec 2004 17:29:24 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Restarting a reactor with a flawed part (via Ken Knowlton)
Ken Knowlton noted an article by John Sullivan in *The New York Times* Metro
Section, 12 Dec 2004 (PGN-ed here), that I somehow missed in my morning
musing/newsing that day. Ken's comment: ``Here's a fantastic way to fix a
serious technical problem: change the location of the sensors that have
indicated it!''
Despite opposition, managers of the Salem nuclear power station managers
(second largest in the U.S.A.) are planning to restart operations after
discovery of a flaw in a critical recirculation pump first that helps cool
three reactors, just south of Wilmington, Delaware. This flaw was first
noted in April 2003, when it was noted that seals were wearing out too
rapidly. Then, in November 2004, an engineering team determined that the
steel drive shaft was probably cracked -- and at certain speeds ``bangs like
a freight train.'' New Jersey's top regulator (which has no regulatory role
in Delaware) advises fixing the pump before restarting the shutdown Hope
Creek reactor, which had to be shut down on 10 Oct 2004 because of a broken
steam pipe. Sensors were added to the pump that showed lower vibration
readings than historical records, although those sensors were in different
places than those producing earlier diagnostics (which had previously showed
an almost doubling in vibrations between 2000 and 2002!). The operators are
concluding that the pump is now safe (without having had any repairs). The
state regulators are recommending replacing the bent drive shaft, but the
final decision is up to the U.S. Nuclear Regulatory Commission.
------------------------------
Date: Wed, 22 Dec 2004 14:46:00 -0500 (EST)
From: msb@private (Mark Brader)S
Subject: Wrong braking algorithm causes trains to overrun stops
The December 2004 issue of "Modern Railways" reports a series of incidents
with the Pendolino electric trains, which earlier this year began operating
at 125 mph on the West Coast Main Line in England.
In one case, with the train moving at about 7 mph, the driver attempted a
normal brake application to bring it to a stop just short of the end of
track as usual -- but it did not slow. By the time the emergency brake had
been applied, there wasn't enough track left, and the train rammed the
buffer stop at 4 mph. This was repeated a few days later. Another case
involved a SPAD (signal passed at danger) after all axles on the leading car
locked up as the train approached the red signal: the speedometer read 0
while the train was moving. The driver released and reapplied brakes, but
could not stop in time.
As on many modern electric trains, the conventional friction braking on the
Pendolino is supplemented by regenerative braking: the train's motors become
generators, feeding much of its kinetic energy back into the power supply
for use by other trains.
In this case the choice of braking mode is made by computer control. When
the train is moving at speed, a normal command for brakes activates the
regenerative braking first, with the friction brakes added as braking demand
increases. But the train only has motors on 1/3 of its axles, so the
regenerative braking is more prone to slipping in poor rail conditions, and
it can take up to 6 seconds for the computer to balance everything and reach
the desired braking level after a normal brake application. So at lower
speeds, when even a light brake application might be intended to stop the
train in a short distance, the friction braking is brought on immediately.
(Presumably emergency braking also does this, although the article doesn't
actually say.)
The manufacturer, Alstom, had used this "braking and traction package"
successfully on other trains; the problem with the Pendolino (or maybe just
with this particular version -- there are Pendolinos in other countries) was
simply that the speed threshold for immediate friction braking had been
lowered from 20 to 7 mph, and that was too low. It looks to me as though
someone just didn't understand the way that trains are driven at low speeds.
Rocket, 1829: The first 30 mph train. TGV-A, 1989: The first 300 mph train.
------------------------------
Date: Sat, 18 Dec 2004 01:21:23 -0500
From: David Kennedy CISSP <david.kennedy@private>
Subject: Banksys solves cash card mystery
http://www.expatica.com/source/site_article.asp
?subchannel_id=24&story_id=14880&name=Banksys+solves+cash+card+mystery
9 Dec 2004
Last weekend's catastrophic failure of bank card readers and cashpoints
across Belgium was caused by a chain of small technical errors and not a
computer virus, it has been discovered. "(A)n unfortunate sequence of minor
hiccups in the internal Banksys system was aggravated by the large number of
bank card payments made by shoppers."
220K bank card transactions failed as did 60K credit card transactions
representing 20M Euros. Banksys announced that all transactions will be
free on 18 December as a measure of consideration. "But it is still denying
overall responsibility for the blunder."
David Kennedy CISSP Risk Analyst Cybertrust Corp.
http://www.cybertrust.com
------------------------------
Date: Thu, 23 Dec 2004 11:27:50 +0100
From: des@private (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=)
Subject: Y2K? Never heard of it...
According to www.lexpress.fr (the website of a leading French news
magazine), today's date is Jeudi 23 décembre 104. The date is
generated by the following snippet of ECMAScript:
var tj= new Array("Dimanche","Lundi","Mardi","Mercredi","Jeudi","Vendredi","Samedi");
var tm= new Array("janvier","février","mars","avril","mai","juin","juillet","août","septembre","octobre","novembre","décembre");
d= new Date() ;
document.write( tj[d.getDay()] + " " + d.getDate() + " " + tm[d.getMonth()] + " " + d.getYear()) ;
One wonders how long this has been so, and how much longer it will
take before they realize that they need to add 1900 to the year (and
start reading manuals).
Dag-Erling Smørgrav - des@private
------------------------------
Date: Tue, 21 Dec 2004 20:47:08 -0500
From: Tom Nimitz <tnimitz@private>
Subject: The new NASA calendar
One of the Web sites I occasionally visit on the web is
http://spaceflight.nasa.gov/realdata/sightings/cities/index.cgi
-- which allows you to pick a city and find out when there will be an pass
by the International Space Station. The site is updated weekly.
This week the header at the top of the pages reads "THE FOLLOWING ISS
SIGHTINGS ARE POSSIBLE FROM MON DEC 20 TO SAT JAN 32".
Fortunately, the only a risk would be using the same logic for calculating a
trajectory for landing a probe on Titan.
------------------------------
Date: Mon, 20 Dec 2004 10:34:06 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Flaw in Google's New Desktop Search Program
Rice University Computer Scientists Find a Flaw in Google's New Desktop
Search Program
By John Markoff, *The New York Times*, 20 Dec 2004
http://www.nytimes.com/2004/12/20/technology/20flaw.html
[Also noted by Jim Schindler; PGN-ed]
Rice University professor Dan Wallach and two of his graduate students, Seth
Fogarty and Seth Nielson, have discovered a potentially serious security
flaw in the desktop search tool for personal computers that was recently
distributed by Google. The flaw could allow an attacker to clandestinely
search your PC via the Internet. This is an example of a composition
flaw, which results from putting two components together.
------------------------------
Date: Fri, 24 Dec 2004 20:51:02 -0500
From: Monty Solomon <monty@private>
Subject: Windows into the world
Researchers warn of multiple unpatched Windows holes;
Vulnerabilities could leave systems open to remote attacks
Paul Roberts, IDG News Service, 24 Dec 2004
Symantec Corp. warned its customers about a number of critical holes in
Microsoft Corp.'s Windows operating system that surfaced late yesterday and
that could make Windows systems vulnerable to compromise by remote
attackers. Symantec acted after security researchers published the details
of the heap overflow vulnerabilities in messages posted to online security
news groups Thursday, including the Bugtraq mailing list, and on
xfocus.net. The flaws affect most supported versions of Windows, but
Microsoft has not yet issued a patch for the newly disclosed holes. Windows
users are vulnerable to Internet based attacks until patches are issued,
Symantec said.
http://www.computerworld.com/securitytopics/security/holes/story/0,10801,98532,00.html
Three Serious Windows Vulnerabilities Surface,
David Morgenstern, eweek.com, 24 Dec 2004
Symantec Corp.'s Security Response service on Friday confirmed that
unpatched Windows vulnerabilities could pose a serious risk for exploits via
malicious Web pages and e-mail messages. One of the three security
vulnerabilities involves image handling-a source of recent exploits on
Windows and Unix operating systems. The other two risks are found in the
Help system and in Window's ANI (Automatic Number Identification)
authentication. Symantec said the Microsoft Windows LoadImage API Function
Integer Overflow Vulnerability could be exploited via browsers or e-mail
client software. Users who open an HTML message or Web page bearing the
image could face security risks. ...
http://www.eweek.com/article2/0,1759,1745642,00.asp
Exploits released for new Windows flaws
Robert Lemos, CNET News.com, 23 Dec 2004
A Chinese security group has released sample code to exploit two new
unpatched flaws in Microsoft Windows. The advisory comes in the week before
Christmas, a time when many companies and home users are least prepared to
deal with the problems. Security firm Symantec warned its clients of the
vulnerabilities on Thursday, after the Chinese company that found the flaws
published them to the Internet.
One vulnerability, in the operating system's LoadImage function, could
enable an attacker to compromise a victim's PC when the computer displays a
specially crafted image placed on a Web site or in an e-mail. The other
vulnerability, in the Windows Help program, likewise could affect any
program that opens a Help file. ...
http://news.com.com/2100-1002-5502534.html
------------------------------
Date: Wed, 22 Dec 2004 02:20:21 -0800
From: Ron Avitzur <avitzur@private>
Subject: The Graphing Calculator Story
This is an old story, but I've only told it in person before. Now that I've
put it in print, I wanted to share it with other readers of Risks. I'll
leave enumerating the risks as an exercise for the reader.
"It's midnight. I've been working sixteen hours a day, seven days a
week. I'm not being paid. In fact, my project was canceled six months ago,
so I'm evading security, sneaking into Apple Computer's main offices in the
heart of Silicon Valley, doing clandestine volunteer work for an
eight-billion-dollar corporation."
The story behind the Macintosh Graphing Calculator is at
http://www.PacificT.com/Story
------------------------------
Date: Tue, 21 Dec 2004 22:07:45 -0800
From: "Don Norman" <norman@private>
Subject: Why adding more security measures may make systems less secure
In RISKS-26.30, Peter Neumann recommended a paper by Scott Sagan entitled:
"The Problem of Redundancy Problem: Why More Nuclear Security Forces May
Produce Less Nuclear Security" http://cisac.stanford.edu/publications/20274/
I want both to second the recommendation and also to expand upon it. Many
attempts by both experts and amateurs in the world of security and safety
actually weaken their systems.
Sagan provided three major reasons why this might be so: I add a
fourth. Sagan's three reasons were:
1. Common-mode problems. Adding redundancy only makes things more secure or
safe if the new items are truly independent of the existing ones. They
seldom are, and accident after accident demonstrates the common mode
problem, where one accident takes out all the supposedly redundant
system. (Classic example: redundant hydraulic lies in a DC-10, but an
accident destroyed the part of the fuselage that held all three
lines. Poof. No more hydraulics.)
2. The "shirking" problem (also known to psychologists as "bystander
apathy"). The more people that are asked to check upon a system, the less
thorough any individual is apt to be. Think about it -- will you take extra
steps to check something if you know that "n" people have already vetted it
and "m" more will do so after you? But if everyone shirks their duty, the
reliability goes to zilch. In Social Psychology, "bystander apathy" refers
to the experimentally validated observation that the more people that
witness a crime, the less likely it is to be reported.
3. The overcompensation problem. This can be phrased as "the system is now
safer, so I can take more risks" problem. Make a system more safe or more
secure and people learn they can take chances. Add seat belts in automobiles
and people drive faster. Add a secondary limit detector on a mechanical
system, and people are willing to go beyond the first limit ("because the
backup will catch any problem").
I want to emphasize the importance of these problems, while adding an equally
important fourth one:
4: The Dedicated Worker problem. If the security or safety requirements get
in the way of doing the work, then the most dedicated workers will defeat
them. Put in locked doors, and they will prop them open with waste
baskets. Require long, lengthy, hard-to-guess passwords, changed frequently,
and they will write them down and post them in easy to reach places. After
all, security and safety are risks, not realities (and usually
low-probability at that.(*) Getting the work done on time is a reality, and
these extra steps invariably make it harder to do the work. Hence, the most
dedicated workers will remove whatever tends to block getting the work done.
------- (*) This is what I have sometimes called the "one in a million"
problem. Low probability events are often judged to be non-existent, or at
least, that happen to others. I've named it after the pilot who decided that
all three of his engines could not be failing because "the chance of this
happening is one in a million." My observation is, "yes, you are correct,
and you are that one." Actually, with some 7 million flights a year, one in
a million is not nearly good enough, but that is a different argument.
------- Item one of these four is a technical issue: the other three are
psychological ones. When attempting to increase security and safety of
systems, it is essential that the psychology of the people be considered to
be of equal or greater importance than the purely technical analysis. Note,
the most obvious response of security and safety people is "more training is
necessary." Yes, proper training is always useful, but don't count on it
solving these problems. These issues happen despite training. They often
are present in the best, most well motivated, most effective people in the
organization. Indeed, professionals in the security and safety industry have
succumbed to just these issues. ("I know my home computer isn't secure, but
it was absolutely essential that I finish this report, ..."). The correct
solution lies in ensuring that the security and safety measures take into
account both the technical and the psychological factors.
Don Norman norman@private www.jnd.org
------------------------------
Date: Thu, 23 Dec 2004 10:25:05 -0500
From: Pat Place <prhp@private>
Subject: Re: GPS Shutdown "during national crisis"
There are many services that depend on GPS so shutting it down in a national
crisis appears to be foolhardy. On the other hand, a GPS unit trivializes
the development of a guidance system. For example,
http://www.buzzle.com/editorials/6-3-2003-41208.asp discusses how
inexpensive it is to build such a system. I'm sure that there are plenty of
other applications that risks readers can think of that use GPS for guidance
that might, indeed, be the basis for future attacks in the US or elsewhere.
------------------------------
Date: Sat, 25 Dec 2004 09:32:30 -0500
From: cogg@private
Subject: Re: Unintended effects of RFID devices (Wallich, RISKS-23.62)
I recall that Richard Feynman found a similar issue with the storage of
radioactive material in adjacent rooms. Neither room had a dangerous mass
of material, but when the material is stacked back-to-back on the same wall
in different rooms, it was possible for the mass to become critical.
------------------------------
Date: Wed, 22 Dec 2004 09:30:00 -0500
From: Dawn Cohen <dcohen@private>
Subject: Re: Strange S&P numbers (Cohen, RISKS-23.62)
[PGN asked Dawn: "Any follow-up?"]
As of this morning, I see that the S&P is at 1205, rather than 324. I
wonder how many automated trading systems saw that 324 and tried to create
orders.
------------------------------
Date: Wed, 01 Dec 2004 12:42:46 GMT
From: Jonathan de Boyne Pollard <J.deBoynePollard@private>
Subject: Re: Whites Only websites? (Jacobson, RISKS 23.60)
DJ> Now some websites don't even allow browsers from lesser countries
... like the U.K., in the George W. Bush case ...
DJ> countries to connect. "Who from there would need to read our
DJ> website? They're all just spam bots."
The problems of determining country from the IP address of the connecting
client are known, of course, although less well than they should be, it
seems. IP addresses simply don't map reliably onto countries. Most
approaches rely upon tables derived from coarse-grained data, and are thus
either inaccurate or incomplete. For example: Dan Bernstein provides an
example DNS service that returns different answers depending from the
continent (It doesn't even aspire to determining the specific country.) of
the client (strictly: the resolving proxy DNS server) performing the lookup.
Perform a "TXT" lookup for "clientcontinent.cr.yp.to." to see it in action.
The service is based upon the 2001 IANA IPv4 address space allocation list.
Even accounting for the datedness of the source data, there are vast swathes
of IP address space for which it cannot even determine the *continent* of
the client IP address. One might blame the coarseness of the IANA source
data, but finer grained approaches suffer from other problems, such as
errors caused by address assignment churn. And that's not to mention other
factors such as VPNs, caching proxy servers, and the cases, common in years
gone by although less so today, of people who make international calls for
PPP access.
And of course, there are always the humourous consequences of people
trying to determine country from IP address. *The Register* covered the
George W. Bush website block, for example, and noted that Canada was
deemed to be part of the United States by the Bush Campaign.
(<URL:http://www.theregister.co.uk./2004/10/28/letters_politics/>)
------------------------------
Date: Thu, 23 Dec 2004 19:56:27 -0500
From: Gene Spafford <spaf@private>
Subject: Software Engineering for Secure Systems: SESS05
Software Engineering for Secure Systems (SESS05)
Building Trustworthy Applications
http://homes.dico.unimi.it/~monga/sess05.html
May 15-16, 2005
St. Louis, Missouri USA
An ICSE 2005 workshop
http://www.cs.wustl.edu/icse05
This workshop will provide a venue to discuss techniques that enable the
building and validation of secure applications. We are especially interested
in (1) design and implementation approaches that make it easier to deal with
security requirements, and (2) program analysis techniques that enhance the
trustworthiness of applications.
Areas of interest include, but are not limited to:
o Security requirements management
o Architecture and design of trustworthy systems
o Architecture and design of protection systems
o Separation of the security concern in complex systems
o Secure programming
o Black box components trustworthiness
o Security testing
o Trustworthiness verification and clearance
o Defining and supporting the process of building secure software
o Deployment of secure applications
** Submission of 7-page-max workshop papers 21 Feb 2005
[Excerpted for RISKS. See the Web site for full details. PGN]
------------------------------
Date: Wed, 22 Dec 2004 13:42:37 -0800
From: Rob Slade <rslade@private
Subject: REVIEW: "Network Security Hacks", Andrew Lockart
BKNTSCHK.RVW 20041106
"Network Security Hacks", Andrew Lockart, 2004, 0-596-00643-8,
U$24.95/C$36.95
%A Andrew Lockart
%C 103 Morris Street, Suite A, Sebastopol, CA 95472
%D 2004
%G 0-596-00643-8
%I O'Reilly & Associates, Inc.
%O U$24.95/C$36.95 707-829-0515 fax: 707-829-0104 nuts@private
%O http://www.amazon.com/exec/obidos/ASIN/0596006438/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0596006438/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0596006438/robsladesin03-20
%P 298 p.
%T "Network Security Hacks"
Chapter one lists twenty tips for using a number of utilities and
programs to enhance the security of UNIX systems. The explanations
are clear and specific, although you would probably have to be really
familiar with UNIX administration to get the full benefit of these
suggestions. Windows gets ten hacks in chapter two. While useful,
these could have had more explanation in some cases, in regard to the
limitations and pitfalls of the recommendations. Almost all of the
network security tools discussed in chapter three are for UNIX,
although some do have Windows versions. The same is true with the
logging tips in chapter four, although there is mention of arranging
to have Windows report to a syslogd. Network monitoring, and some
analysis thereof, is in chapter five. Tunnels and VPN (Virtual
Private Network) products are detailed in chapter six. Most of the
network intrusion detection material in chapter seven concerns Snort.
(You are not my NIDS, you are a Snort!) Chapter eight lists a few
recovery and response tools.
If you run a UNIX system and network, this book enumerates many useful
tasks, settings, and tools that will help to make your systems and
network more secure.
copyright Robert M. Slade, 2004 BKNTSCHK.RVW 20041106
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
------------------------------
Date: 2 Jun 2004 (LAST-MODIFIED)
From: RISKS-request@private
Subject: Abridged info on RISKS (comp.risks)
The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you. 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 the process by sending directly to either
risks-subscribe@private or risks-unsubscribe@private
depending on which action is to be taken.
Subscription and unsubscription requests require that you reply to a
confirmation message sent to the subscribing mail address. Instructions
are included in the confirmation message. Each issue of RISKS that you
receive contains information on how to post, unsubscribe, etc.
INFO [for unabridged version of RISKS information]
.UK users should contact <Lindsay.Marshall@private>.
=> SPAM challenge-responses will not be honored. Instead, use an alternative
address from which you NEVER send mail!
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
<http://www.CSL.sri.com/risksinfo.html>
The full info file may appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to risks@private with meaningful SUBJECT: line.
*** NOTE: Including the string "notsp" at the beginning or end of the subject
*** line will be very helpful in separating real contributions from spam.
*** This attention-string may change, so watch this space now and then.
=> ARCHIVES: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i]
<http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive
http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.
Lindsay has also added to the Newcastle catless site a palmtop version
of the most recent RISKS issue and a WAP version that works for many but
not all telephones: http://catless.ncl.ac.uk/w/r
<http://the.wiretapped.net/security/info/textfiles/risks-digest/> .
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
<http://www.csl.sri.com/illustrative.html> for browsing,
<http://www.csl.sri.com/illustrative.pdf> or .ps for printing
------------------------------
End of RISKS-FORUM Digest 23.63
************************
This archive was generated by hypermail 2.1.3 : Fri Jan 28 2005 - 10:24:22 PST