RISKS-LIST: Risks-Forum Digest Friday 30 September 2005 Volume 24 : Issue 05
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.05.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Software hijacks jet airliner ... again? (Charles Wright)
Airbus, Whistleblower Dispute A380 Pressurization Controls (PGN)
Metra Rail accident in Chicago (Andy Steingruebl)
Katrina victims required to use Microsoft IE (Douglas W. Jones)
Travelers Continue to Struggle with Wrongful Watch List Matches
(EPIC FOIA Notes)
Scots Jail hi-tech door locking system broke (George Michaelson)
Risks of keyboard shortcuts (Andrew Koenig)
Designing "safe software"...: A 4-star article! (Michael Radow)
Sorcerer's Apprentice in the Driver's Seat?? (David Lesher)
Mea culpa: How we got it wrong on Calling-Number ID (Geoff Kuenning)
Open letter: Why "dot-xxx" is for Chumps (Lauren Weinstein)
Router worms and International Infrastructure (Gadi Evron)
Wolf Blitzer repeats Rudy in questioning governors (Fred Cohen)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Sat, 17 Sep 2005 11:26:11 +1000
From: "Charles Wright" <cw@private>
Subject: Software hijacks jet airliner ... again?
http://www.bleedingedge.com.au/blog/archives/2005/09/software_hijack.html
*The Australian* (17 Sep 2005) has a chilling story about the pilots of a
Malaysian Airlines 777 flying from Perth to Kuala Lumpur last month battling
to regain control after an "unknown computer error" caused the aircraft to
pitch violently, and brought it close to stalling.
An Australian Transport Safety Bureau report
(http://www.atsb.gov.au/aviation/occurs/occurs_detail.cfm?ID=767) released
yesterday reveals the pilot in command disconnected the autopilot and
lowered the plane's nose to prevent a stall, after incorrect data from a
supposedly fail-safe device caused the plane to pitch up and climb 3000ft,
cutting its indicated air speed from 500kmh to 292kmh, activating a stall
warning and a "stickshaker". [A stickshaker vibrates the aircraft's controls
to warn the piot when he is approaching stall speed ... which, you know,
means the plane is about to fall out of the air.]
The system refused to give up control, however. It increased the power on
the automatic throttle, forcing the pilot to counter by pushing the thrust
levers to the idle position. The aircraft immediately pitched up again, and
climbed 2000ft.
The pilot turned back to Perth under manual control. When he kicked in the
two autopilot systems, the plane banked to the right, and the nose pitched
down.
On its landing approach, at 3000ft, the flight display gave a low airspeed
warning and the auto-throttle increased thrust. The warning system also
indicated a dangerous windshear, but the crew landed the jet safely.
According to the report, "investigations are focusing on faulty acceleration
figures supplied by a device called the Air Data Inertial Reference
Unit". The ADIRU collates aircraft navigation and performance data from
other systems and passes the information to the primary flight computer.
What's potentially more disturbing, however - and neither the Transport
Safety Bureau nor The Australian appear to have picked this up - is that a
US FAA directive <a
(http://www.airweb.faa.gov/Regulatory_and_Guidance_Library%5CrgAD.nsf/0/A668AA4EB82ABE4E86256FFE00510CE8?OpenDocument)
in June this year highlighted other problems with the Boeing 777's ADIRU.
Boeing has told operators of the jet -- which by the way has the best safety
record of any aircraft (http://www.geocities.com/khlim777_my/ashowsafe1.htm)
-- to load a previous software version.
[The article at
http://www.avweb.com/eletter/archives/avflash/465-full.html
was also noted by Mickey Coggins and Ian Chard.
http://www.theaustralian.news.com.au
was cited by Richard Weir. PGN]
------------------------------
Date: Tue, 27 Sep 2005 11:13:19 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: Airbus, Whistleblower Dispute A380 Pressurization Controls
James Paul (U.S. House Science Committee professional staffer) called my
attention to an item in the 27 Sep 2005 *Los Angeles Times*. A
whistleblower alleges that the chips controlling cabin pressurization valves
in Airbus's new Flying Whale aren't behaving properly and may lead to
decompression incidents.
http://www.latimes.com/news/printedition/front/la-fi-whistleblower27sep27,1,2186118.story
------------------------------
Date: Tue, 20 Sep 2005 09:40:22 -0500
From: Andy Steingruebl <steingra@private>
Subject: Metra Rail accident in Chicago
As you are no doubt aware, there was a Metra Rail train accident in Chicago
this last weekend that caused the death of two people and injured
approximately 80. The issue has gotten national news coverage, and lots of
local coverage. The Metra spokeperson has been rather forthcoming in
analysing the situation.
Because the train was speeding at the time of the accident and the accident
is similar to previous train accidents, there have been a lot of calls for
solutions:
- Put a second person back in the train to help the engineer. There was a
second person until 1995.
- Implement automated train controls to brake the train in case of an
engineer missing a signal.
The second option has received a lot of attention because Metra currently
has computer controls on several of its train lines, but the controls are
expensive.
This situation presents a great opportunity to get the issue of the
reliability of human and computer controls in the media. As the ideas are
being widely discussed, its a perfect opportunity to discuss failure rates
for the different technologies, the humans, etc.
I'd contact Metra Rail myself, but I don't have the requisite engineering
background to act as a truly knowledgeable source.
Perhaps you or someone from RISKS (perhaps someone in the Chicago area) can
contact local news media and Metra to get this issue discussed in public as
it should be.
[Added note: I believe it was going about 60 and the speed limit for that
section of track was 10. Recent news is the the engineer either missed the
signal, or the signal was green indicating he could keep his speed and not
slow down. In either case since its a big news story. AS]
------------------------------
Date: Thu, 22 Sep 2005 10:02:21 -0500
From: "Douglas W. Jones" <jones@private>
Subject: Katrina victims required to use Microsoft IE
[In a USACM newsgroup, Barbara Simons noted that FEMA requires Katrina
evacuees to use Microsoft IE 6.0 for access to its website:
http://www.groklaw.net/article.php?story=2005091305273070
The following message by Doug Jones discusses that issue. PGN]
The FEMA web portal violates a number of good web usage guidelines. The
first page at http://fema.gov/ is fixed-width, not conforming to the user's
browser window. Things get worse from there.
The web page http://www.disasteraid.fema.gov/ is a mess when viewed under
iCab, my preferred web browser, the browser spent what seemed an eternity
blinking from grey to white and back again before stabilizing with content.
When I clicked on Register for Assistance, it went back to blinking and kept
it up for so long that I gave up.
When I repeated the exercise under Safari, Clicking on Register for
Assistance, which takes me to
https://www.disasteraid.fema.gov/famsVuWeb/integration
I got the following error message:
500 Internal Server Error
Servlet error: java.lang.ClassNotFoundException:
_dynamic._templates._Template__body
When I tried it under IE, it got farther, letting me through an
automated test to distinguish humans from bots, but then it gave me
the message:
Integrated Security Access and Control (ISAAC) Unavailable
Your request cannot be processed because the ISAAC system is unavailable.
Please try again later or contact the FEMA Helpline at the number
listed below.
So, it's clear to me that they've engineered a web system that is:
a) Extraordinarily over-engineered to work under only one browser,
b) Nonfunctional under that browser,
This, I conclude, is simply another example of FEMA incompetence.
------------------------------
Date: Tue, 27 Sep 2005 11:47:44 -0400
From: EPIC FOIA Notes <FOIA_Notes@private>
Subject: Travelers Continue to Struggle with Wrongful Watch List Matches
EPIC FOIA Notes #8:
Travelers Continue to Struggle with Wrongful Watch List Matches
Documents obtained by EPIC from the Transportation Security Administration
under the Freedom of Information Act reveal nearly a hundred complaints from
airline passengers between November 2003 and May 2004. The most common
complaint from passengers is that they have been wrongly placed on a
government watch list. Numerous complaints show passengers' frustration
with the agency's failure to resolve their misidentification problems.
More information: http://www.epic.org/foia_notes/note8.html
FOIA_Notes mailing list FOIA_Notes@private
https://mailman.epic.org/cgi-bin/mailman/listinfo/foia_notes
------------------------------
Date: Tue, 20 Sep 2005 11:18:59 +1000
From: George Michaelson <ggm@private>
Subject: Scots Jail hi-tech door locking system broke
This one begs a few questions: How can the inmates have had over a *month*
of using the hackaround without other non-linked security systems (e.g.,a
video cameras) not noticing?
This suggests that an integrated solution has replaced multiple discrete
lines of protection, with predictable outcomes. George
http://news.scotsman.com/scotland.cfm?id=1965122005
Prison officers have been forced to abandon a new security system and return
to the use of keys after the cutting-edge technology repeatedly failed. The
system, which is thought to have cost over £3 million, used fingerprint
recognition to activate the locking system at the high-security Glenochil
Prison near Tullibody, Clackmannanshire. ... For more than a month, the
420 inmates - including some murderers and other high-risk inmates - had
been able to wander around the high-security jail. Staff claim that the
unlimited access to all parts of the prison had allowed some prisoners to
settle old scores with rivals.
George Michaelson, APNIC, PO Box 2131 Milton, QLD 4064 Australia
http://www.apnic.net ggm@private +61 7 3858 3150
------------------------------
Date: Wed, 28 Sep 2005 10:44:32 -0400
From: "Andrew Koenig" <ark@private>
Subject: Risks of keyboard shortcuts
Background: Microsoft Windows can support only 10 USB MIDI devices. This
may sound like a lot until you realize that when you move a device to a
different USB port, it counts as a new device. The list of devices is
stored in the registry, using keys named "midi", "midi1", ... "midi9". I
was running regedit to try to understand the degree to which these keys had
become filled, and to delete some of the duplicates.
I turned away from the keyboard for a moment. When I turned back, on the
screen was a dialog box saying "Do you want to permanently delete this key
and all of its components? Yes/No", and one of my five-month-old kittens
was ambling away from the keyboard.
I'm not usually a fan of such dialog boxes, but this time I'll make an
exception--especially as regedit does not have an undo function. Yes, I
know about system restore points, but still...
------------------------------
Date: Thu, 15 Sep 2005 19:36:33 -0700 (PDT)
From: Michael Radow <mikeradow@private>
Subject: Designing "safe software"...: A 4-star article!
David Kalinsky, Architecture of safety-critical systems
September issue of "Embedded Systems Programming" magazine
http://www.embedded.com//showArticle.jhtml?articleID=169600396
"compressed" URL http://runurl.com/x.php?b0
------------------------------
Date: Sat, 17 Sep 2005 09:51:21 -0400 (EDT)
From: "David Lesher" <wb8foz@private>
Subject: Sorcerer's Apprentice in the Driver's Seat??
The driver of a runaway [21 ton] truck that locked at 60 mph for 140 miles
on highways in northern France and Belgium is planning to sue the truck
manufacturer. The crisis happened Monday when the driver, who refused to
give his name, used his mobile phone to raise the alarm when he realized
he could not brake or change gears. ... {no good scheme to stop it;
finally skidded out} ... Iveco, the truck manufacturer, sent technicians
to examine the vehicle. The driver denies he was at fault and he was
taking legal action. [UPI item, abstracted]
A slew of Risks, here. First the obvious, did it go down as reported; i.e.,
the driver really had no way to stop it? (Or had he been to see
<http://us.imdb.com/title/tt0111257/> recently.)
If so, why? Diesel vehicles usually have an emergency shutoff that blocks
the air intake. Was it NOT manually operable, or did it fail as well? And
were the brakes out, or insufficient to overcome the engine power?
It will be interesting to see the followup analysis.
------------------------------
Date: 25 Sep 2005 23:37:03 -0700
From: Geoff Kuenning <geoff@private>
Subject: Mea culpa: How we got it wrong on Calling-Number ID
Back in the early 90's, U.S. phone companies began rolling out the service
known as "Caller ID" (really Calling Number ID, or CNID). Early adopters
were very pleased with the feature; it helped them to avoid telemarketers
and occasionally to dodge inconvenient friends.
Then a few privacy advocates noticed that there was a dark side: if
you called a local business, it could capture your number with CNID
and add you to a telemarketing list. Suddenly CNID changed from a
beneficial service to a nefarious plot.
An anti-CNID campaign ensued, culminating in California's decision to
require telephone companies to offer free CNID blocking as a condition of
rolling out the service. At the same time, privacy advocates (including me
and many other RISKS subscribers) publicized the downsides of CNID:
unintentionally revealing your (possibly unlisted) phone number, confusing
the concept of calling number with the identity of the calling person, etc.
The campaign was successful: when CNID was rolled out, something like 50% of
Californians chose to block their number by default.
Fast forward approximately a decade. I recently switched local phone
providers (finally freeing myself from the clutches of Verizon, neé GTE,
after a 25-year quest) and got rid of my CNID blocking in the process.
Rather than advocating against CNID, I've now changed my tune and am trying
to convince my blocked friends to unblock.
What happened? The answer is simply that I was wrong about the evils of
CNID, and wrong about the (perceived lack of) benefits. That error arose
primarily from an inability to correctly predict the future. In particular,
the following forces have reduced the evils and increased the benefits:
1. The predicted data collection by small businesses never happened. It
wasn't worth the effort. Businesses didn't get much benefit from knowing
that somebody at 555-1234 had called to inquire about mattress prices;
their telemarketing money was better spent on buying phone lists that
included names and demographic data.
2. Larger businesses had 800 numbers that included Automatic Number
Identification (ANI), which wasn't bothered by caller ID blocking anyway,
so the people with lots of funds were never stopped from telemarketing.
3. The unforeseen Federal Do-Not-Call List has become an effective defense
against telemarketing, so revealing your telephone number isn't much of a
problem anyway.
4. The rise of cellphones means that we are starting to see a true
one-to-one association between phone numbers and people, so CNID is
becoming the caller ID it was once billed as being.
5. Most cellphone plans include CNID as part of the package, and some local
plans are also offering it as a no-cost option, increasing the number of
people who depend on CNID working.
6. A new generation of CNID signaling allows short text information to be
transmitted along with the calling number, so that the recipient can
identify the caller even if they have never seen the number before.
In addition, in 20-20 hindsight many of our criticisms seem overstated. For
example, we argued that since CNID doesn't identify the individual, you
never really knew who was calling. That's true enough, but do my family and
friends care whether it is I or my wife calling to arrange a visit? We
argued that a stranded teenager calling from a pay phone might have his call
rejected, but would a parent with a teen out on a date really turn down
calls from an unknown number?
I think the lesson here is that we need to remember to be humble, and to
avoid crying wolf about the RISKS we perceive. Overall, CNID's benefits far
outweigh its drawbacks, and we have done society a disservice by encouraging
people to block it. We were right to point out the potential weaknesses and
incorrect marketing claims, but we erred in encouraging so many people to
unnecessarily block their phone numbers, inconveniencing their friends and
family while gaining almost no real benefit.
Geoff Kuenning geoff@private http://www.cs.hmc.edu/~geoff/
------------------------------
Date: Mon, 19 Sep 2005 09:55:28 -0700
From: Lauren Weinstein <pfir@private>
Subject: Open letter: Why "dot-xxx" is for Chumps
This is an open letter addressed to that segment of the Internet community
where the *real* money is made -- the "adult entertainment" industry. For
that matter, the operators of the ubiquitous non-commercial
sexually-oriented Web sites can join in as well.
I have some free advice that may save you a great deal of grief.
Now, in all honesty, I don't have any particular love for your operations or
your products. I'm not a prude (well, not much of one, anyway), but by
continuing to push the envelope you folks have engendered a great deal of
negative reaction that's approaching a fever pitch.
That reaction is what I'm really concerned about, since it's likely to
splatter collateral damage broadly across a wide range of free speech and
civil liberties arenas.
So, in my desire to protect them, I'll try to protect you as well.
My advice? Don't fall into the "dot-xxx" trap that's being set for you by
ICANN.
As you no doubt are aware, ICANN appears to be preparing for the deployment
-- despite broad protests across the political spectrum and a couple of
delays -- of a "dot-xxx" top-level domain (TLD).
I've explained elsewhere ( http://www.pfir.org/ip-exexex ) and (
http://www.pfir.org/ip-exexex-01 ), why dot-xxx is an absolutely atrocious
idea.
ICANN claims that participation in the domain will be voluntary, and that
will indeed be the case -- at first.
But as I discussed back in a 2001 PFIR position paper on "domain
ghettoization" ( http://www.pfir.org/statements/ghetto-domains ), such
efforts are a slippery slope likely leading to widespread filtering and
censoring by ISPs, governments, plus a broad range of other entities,
affecting a *lot more* than merely pornographic materials. A glance at the
current Supreme Court situation is not particularly encouraging in this
regard.
ICANN apparently doesn't view their dot-xxx plan as a trap. They seem to
consider themselves courageous by pushing on with that TLD despite the broad
public and private consensus that it's a terrible concept. Unfortunately,
this is the sort of "forge ahead over the cliff" behavior that we've come to
expect from ICANN as an organization.
So if dot-xxx arrives, my strong recommendation is that *you ignore it*.
Pretend that it doesn't exist. Allow it to be an empty database. Joining
that domain won't provide you with any cover -- what you'll actually be
doing is painting a giant bulls-eye on yourselves -- and on a vast array of
worthy and important groups and materials that have nothing whatever to do
with adult entertainment.
Dot-xxx is for chumps.
By the way, I originally considered titling this entry with a domain-related
variation on the old "Suppose They Gave a War and Nobody Came" line, but
while the situation with dot-xxx is indeed dangerous -- and an example of so
much that's wrong with Internet Governance in general and ICANN in
particular -- this matter is anything but a dirty joke.
Lauren Weinstein, lauren@private http://www.pfir.org/lauren 1-818-225-2800
Moderator, PRIVACY Forum - http://www.vortex.com http://daythink.vortex.com
------------------------------
Date: Fri, 30 Sep 2005 23:29:29 +0200
From: Gadi Evron <ge@private>
Subject: Router worms and International Infrastructure
Michael.Dillon@private wrote:
> Reading through the original Russian posting here
> http://www.securitylab.ru/news/240415.php&direction=re&template=General&cp1=
> It seems that someone has built an IOS worm that
> follows an EIGRP vector from router to router.
A while back I emailed the following text to a closed mailing list. I figure
now that quite a few cats are out of the bag it is time to get more public
attention to these issues, as the Bad Guys will very soon start doing just
that.
Ciscogate by itself ALONE, and now even just a story about worms for Routers
is enough for us to be CLEAR that worms will start coming out. We do learn
from history.
So.. as much as people don't like to talk much on the issues involving the
so-called "cooler" stuff that can be done with routers, now is the time to
start.
Here is one possible and simple vector of attack that I see happening in
the future. It goes down-hill from there.
I wrote this after the release of "the three vulnerabilities", a few months
back. Now we know one wasn't even just a DDoS, and that changes the picture
a bit.
Begin quoted text ----->>>
More on router worms - let's take down the Internet with three public POCs
and some open spybot source code.
- - -
People, I have given this some more thought.
Let's forget for a second the fact that these vulnerabilities are dangerous
on their own (although it's a DoS), and consider what a worm, could cause.
If the worm used the vulnerability, it would shoot itself in the leg as when
network is down, it can't spread.
Now, imagine if a VX-er will use an ancient trick and release the worm,
waiting for it to propagate for 2 or 3 days. Then, after that seeding time
when the say.. not very successful worm infected only about 30K machines
around the world, each infected host will send out 3 "One Packet Killers" as
I like to call them to the world.
Even if the packet won't pass one router, that one router, along with
thousands of others, will die.
Further, the latest vulnerabilities are not just for Cisco, there is a "One
Packer Killer" for Juniper as well.
So, say this isn't a 0-day. Tier-1 and tier-2 ISP's are patched (great
mechanism to pass through as these won't filter the packet out if it is
headed somewhere else), how many of the rest will be up to date?
Let's give the Internet a lot of credit and say.. 60% (yeah right).
That leaves us with 30% of the Internet dead, and that's really a bad
scenario as someone I know would say.
Make each infected system send the one packet spoofed (potentially, not
necessarily these vulnerabilities) and it's hell. Make them send it every
day, once! And the net will keep dying every day for a while.
As a friend suggested, maybe even fragment the packet, and have it
re-assembled at the destination, far-away routers (not sure if that will
work).
These are all basic, actually very basic, techniques, and with the source to
exploits and worms freely available.... We keep seeing network equipment
vulnerabilities coming out, and it is a lot "cooler" to bring down an ISP
with one packet rather than with 1,000,000,000,000,000.
I am sure the guys at Cisco gave this some thought, but I don't believe this
is getting enough attention generally, and especially not with AV-ers. It
should.
This may seem like I am hyping the situation, which is well-known. Still
well-known or not, secret or not, it's time we prepared better in a broader
scale.
How?
Gadi.
----->>> End quoted text.
I would really like to hear some thoughts from the NANOG community on
threats such as the one described above. Let us not get into an argument
about 0-days and consider how many routers are actually patched the
first... day.. week, month? after a vulnerability is released.
Also, let us consider the ever decreasing vulnerability-2-exploit time of
development.
I don't want the above to sound as FUD. My point is not to yell "death of
the Internet" but rather to get some people moving on what I believe to be a
threat, and considering it on a broader scale is LONG over-due.
The cat is out of the bag, as as much as I avoided using "potentially" and
"possibly" above to pass my point.. this is just one possible scenario and I
believe we need to start getting prepared to better defending the Internet
as an International Infrastructure.
As I am sure that this will be an interesting discussion, I am also sure
this will eventually derail to a pointless argument over an un-related
matter, here on NANOG. I'd appreciate if people who are interested would
also email me off-list so that we can see how we can perhaps proceed with
some activity.
My blog: http://blogs.securiteam.com/?author=6
------------------------------
Date: Sun, 18 Sep 2005 09:30:59 -0700
From: Fred Cohen <dr.cohen@private>
Subject: Wolf Blitzer repeats Rudy in questioning governors (Re: RISKS-24.04)
This morning I watched as Wolf Blitzer on CNN questioned governors about
preparedness, and the single frequency question came up again - in that
form. It just shows how the power of ideas can take on its own
life. Fortunately the mayors of Miami and Boston were more clued in than
Rudy. Florida indicated that the he believed that the problem was solved
there without referring to a single frequency in his response. Boston
indicated the use of a system by Raytheon that allows interconnections
between different frequency bands for specific emergency communications
requirements. Hopefully Wolf will start to ask the right question after he
finds out that the notion he is spreading is flawed.
Thanks also to the many people who have responded to me personally with
their views -- all reasoned views -- are as always welcomed.
Security Posture <securityposture.com>, Fred Cohen & Associates <all.net>
572 Leona Drive, Livermore, CA 94550 1-925-454-0171, University of New Haven
------------------------------
Date: 29 Dec 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. Mailman can let you subscribe directly:
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.
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 24.05
************************
This archive was generated by hypermail 2.1.3 : Fri Sep 30 2005 - 16:53:17 PDT