RISKS-LIST: Risks-Forum Digest Saturday 25 August 2001 Volume 21 : Issue 62
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/21.62.html>
and by anonymous ftp at ftp.sri.com, cd risks .
Contents:
Oklahoma whistleblower asked to accept felony conviction (Deborah Weisman)
Follow-up on Oklahoma whistleblower (PGN)
Wireless security vulnerabilities (PGN)
AirSnort! (PGN)
Kaiser Permanente (identity withheld by request)
Air Force officer mails confidential information to all cadets (Jim Griffith)
Re: Avoiding prosecution of the DMCA (David Petrou, Fred Cohen)
Re: Why I don't publish my HDCP results (Bill Weitze, David Gillett)
Re: rot13 (Mike Perry)
Hack the vote? Not in Broward County! (James Paul)
Re: Runway incursions (Bill Hopkins)
Code Red 9? Code Crimson (Alistair McDonald)
AT&T - the computer MUST be right! (Sharon Mech)
Re: DejaGoogle rides again (Geoffrey Leeming)
Re: Risks of automated junk/spam filters (AlphaLau)
Yet another MS Hotmail risk (Kimmo)
REVIEW: "SSL and TLS", Eric Rescorla (Rob Slade)
Dependable Systems and Networks DSN-2002 Call for Contributions (Anup Ghosh)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Wed, 22 Aug 2001 10:40:06 +0300
From: Deborah Weisman <dvorahat_private>
Subject: Oklahoma whistleblower asked to accept felony conviction
A Federal prosecutor has asked Brian West, a 24-year old sales and support
employee of an Oklahoma ISP "to accept a felony conviction and 5 years
probation" for notifying the editor-in-chief of his local newspaper *Poteau
Daily News* that they had failed to set up password security for their Web
site: no authentication, anyone could edit the site using Microsoft
FrontPage. Following their phone conversation, the EIC gave a tape of the
conversation to the Poteau Police Department, who invoked the FBI.
[http://www.macintouch.com/newsrecent.shtml; PGN-ed]
Computer Center Faculty of Agriculture Hebrew University of Jerusalem
P.O.B. 12 Rehovot 76100 ISRAEL 972-8-9489232 dvorahat_private
[Also noted by Ron LaPedis at
http://www.linuxfreak.org/post.php/08/17/2001/134.html. PGN]
------------------------------
Date: Sat, 25 Aug 2001 10:12:13 PDT
From: "Peter G. Neumann" <neumannat_private>
Subject: Follow-up on Oklahoma whistleblower
Sheldon Sperling <Sheldon.Sperlingat_private>, the U.S. Attorney in the
Brian K. West case, has responded to various e-mail protests on his handling
of the case. He claims that West was not arrested and has not been charged.
However, an investigation is pending, to determine whether West
"intentionally accessed a computer without authorization or exceeded
authorized access (to access a computer with authorization and to use such
access to obtain or alter information in the computer that the accesser is
not entitled so to obtain or alter), (2) whether the employee thereby
obtained information from a protected computer (a computer which is used in
interstate or foreign commerce or communication), and (3) whether the
conduct involved an interstate communication. 18 USC 1030." [The full
statement from Sperling is included in a message from Declan McCullagh,
which is accessible at http://www.politechbot.com/ .]
I have noted in this space before that when there is no security in place,
the alleged culprit cannot have exceeded authority when no authority is
implied. As long-time RISKS readers will recall, this issue came up
relating to the trial of Robert Tappan Morris: in 1988, the Internet worm
never exceeded authority, because no authority was required to use the
sendmail debug option, to use the .rhosts mechanism, to execute the finger
daemon, or to read an unprotected encrypted password file. I wonder how
if prosecutors will ever figure this out!
As long as we attempt to shoot the messenger and hide lame security behind
overly broad laws, weak security will prevail, and whistleblowers will be
much rarer than glassblowers. (For example, DMCA is among other things an
attempt to outlaw whistleblowers.)
------------------------------
Date: Sun, 19 Aug 2001 13:16:18 PDT
From: "Peter G. Neumann" <neumannat_private>
Subject: Wireless security vulnerabilities
Sitting in the Morristown (N.J.) Memorial Hospital, AT&T Labs' Avi Rubin (a
note from Avi on WEP insecurity is in RISKS-21.57) noticed that his laptop
wireless connection card was blinking, and then discovered that the
hospital's wireless network was open to his laptop, using 802.11b (Wi-Fi)
and automatically granting him access. [Source: As Wireless Networks Grow,
So Do Security Fears, by John Schwartz Sunday Business Section of *The New
York Times*, page 10, 19 Aug 2001 (National edition), PGN-ed; full article at
http://www.nytimes.com/2001/08/19/technology/19WIRE.html]
[Another case of *not* having to exceed authority because there was
no security involved! Sloppy hospital? Insecurity by obscurity? PGN]
------------------------------
Date: Fri, 24 Aug 2001 11:52:33 -0700
From: "Peter G. Neumann" <neumannat_private>
Subject: AirSnort!
AirSnort, WEPCrack, and other programs available on the Internet make it
easy to sniff sensitive data such as passwords that fly around 802.11b
wireless Internet networks. A competing standard, Bluetooth, is not
susceptible, although Bluetooth is considered "more vulnerable to spies than
hard-wired networks." [Source: AP item, 24 Aug 2001, courtesy of Ken Nitz;
PGN-ed]
The vulnerabilities have been noted here before, but now maybe there
will be some incentives to do something about it? On the other hand,
probably not, if our historical RISKS warnings are not observed, as usual.
------------------------------
Date: Tue, 21 Aug 2001 19:23:53 -0700
From: identity withheld by request
Subject: Kaiser Permanente
There's a self-service section on the Kaiser Permanente (an HMO) Web site at
http://www.kaiserpermanente.org/ that allows you to notify them of a change
of address. In bold letters next to the submit button, it claims "Your
information is secure!". Sounds good. Checking View Source showed the form
was being submitted over SSL. Ok, let's submit the information. A few
minutes later an e-mail arrives. No encryption. Ouch -- it contains a
verbatim copy of the personal information I typed into the form. So much
for "Your information is secure!".
Why bother breaking SSL flows, when you can just watch the e-mail?
------------------------------
Date: Sat, 25 Aug 2001 14:48:44 -0500
From: Jim Griffith <griffithat_private>
Subject: Air Force officer mails confidential information to all cadets
AP reports that an Air Force Academy officer accidentally sent confidential
information about some 40 cadets to all 4400 cadets at the school. The mail
in question contained details of past and pending disciplinary issues,
including the identity of confidential informants in some cases. The
information in question was reportedly protected by federal law, and
officials subsequently ordered cadets to delete the letters.
http://www0.mercurycenter.com/breaking/docs/044576.htm
------------------------------
Date: Sun, 19 Aug 2001 20:56:30 -0400
From: David Petrou <dpetrouat_private>
Subject: Re: Avoiding prosecution of the DMCA (Ferguson, RISKS-21.60)
Just staying out of the U.S. won't necessarily do the trick. The DoJ can
obtain an arrest warrant based upon a criminal violation of the DMCA and
seek extradition from a number of countries. If US law is violated and the
country where the person is has an extradition agreement with the United
States, the foreign government will cooperate in arresting the person and
having that person delivered to the United States for prosecution.
------------------------------
Date: Fri, 17 Aug 2001 15:47:51 -0700 (PDT)
From: Fred Cohen <fcat_private>
Subject: Re: Avoiding prosecution of the DMCA (Ferguson, RISKS-21.60)
The DMCA has also had effects on my forensic analysis products. Because the
current copyright law makes anything that is put into tangible form
copyright unless made otherwise by the author (or by law), things like
criminal records are copyright.
This means that if the criminal tries to protect their material - for
example by hiding it using steganography, encrypting it, or by putting
it on a computer with a password to prevent unauthorized access - then
that work is protected by the DMCA (after all, the password on Windows
systems is effective protection unless you try to circumvent it).
Because the primary purpose of most of my forensic analysis tools is to
reveal things that are protected from revelation, and because the DMCA
makes it illegal to distribute such a device, I have been forced (based
on the recent arrests and other threats against authors of such things)
to withdraw my forensic products from the market.
I should note that companies like Access Data who sell products that are
explicitly designed for undoing encryption, etc. are almost certainly in
violation of the DMCA. While the FBI might not arrest them now because they
sell to the FBI (and other in law enforcement - as did I), this does not
mean that the FBI cannot arrest them at any time and charge them with a
felony. Indeed, sale to law enforcement is not legal, even though law
enforcement can, on its own, build and use such tools.
The effects on research and education are even more interesting. For
example, I am having a discussion with my university now about canceling
courses on forensics and cryptanalysis because in these courses we teach
people how to get around protection of this sort and may provide the
capabilities to do so in so teaching. The DMCA has, I believe, made this
illegal - and if you are teaching such a course next semester, you might
think about the issues as well. On the research side, I don't work on
research I cannot publish, so I am canceling the aspects of my research
that go into these areas.
Fred Cohen Fred Cohen & Associates.........tel/fax:925-454-0171
fcat_private The University of New Haven.....http://www.unhca.com/
http://all.net/ Sandia National Laboratories....tel:925-294-2087
------------------------------
Date: Fri, 17 Aug 2001 21:36:04 -0700
From: "Bill Weitze" <bweitzeat_private>
Subject: Re: Why I don't publish my HDCP results (Ferguson, RISKS-21.61)
Hmm, a blind person could sue the publisher under the Americans with
Disabilities Act.
> Why did the movie industry campaign for the DMCA if it doesn't work? The
> movie and record industry have a history of claiming that new technologies
> will bankrupt them.
They complain about paper books, too. In the September 18, 2000 issue of U.S.
News and World Report, p. 55, an article titled "The empire strikes back"
states the following:
A typical book, for example--the old-fashioned kind--finds its way to five
or six readers beyond the original purchaser, according to Laurence
Kirshbaum, CEO of Time Warner's trade-publishing arm. "One of the
attractions of electronic publishing," he says, is the ability to "cut down
on this pass-along."
I wrote to U.S. News as follows:
This "loaning", as its practitioners call it, is indeed most subversive.
There are even institutions, called "libraries", which carry on this sort
of thing in a wholesale fashion. This was started by a very dangerous
individual named Franklin; maybe Mr. Kirshbaum should sue him.
Bill Weitze, San Jose, CA
------------------------------
Date: Fri, 17 Aug 2001 16:38:04 -0700
From: David Gillett <dgillettat_private>
Subject: Re: Why I don't publish my HDCP results (Ferguson, RISKS-21.61)
To my mind, one of the more dangerous aspects of DMCA is the deliberate
conflation and confusion of "copy protection" (use restriction mechanisms)
with "copyright protection". Experience has already shown that the former
are not an acceptable substitute for the latter, a lesson which DMCA
attempts to unlearn by fiat.
------------------------------
Date: Tue, 21 Aug 2001 18:55:08 +0100
From: "Mike Perry" <PERRYMat_private>
Subject: Re: rot13 (RISKS-21.58 and .59)
If companies are using rot13 to "encrypt" copyrighted information, doesn't
that make every unix user in the USA a criminal under the DMCA? It would be
interesting to see what would happen to "the system" if a few million people
went to the police and confessed...
------------------------------
Date: Fri, 17 Aug 2001 23:03:31 -0500 (CDT)
From: james.paulat_private
Subject: Hack the Vote? Not in Broward County!
In RISKS-21.61, Adam Shostack noted that Broward County was apparently going
to let students have a crack at their new touch-screen voting systems. Bob
Cantrell, director of intergovernmental affairs for the Broward Supervisor
of Elections, claims that this will not happen. [Source: William Welsh, 17
Aug 2001 *Washington Technology*, PGN-ed from
http://www.washingtontechnology.com/news/1_1/daily_news/17017-1.html]
------------------------------
Date: Fri, 17 Aug 2001 19:35:42 -0400
From: "Bill Hopkins" <whopkinsat_private>
Subject: Re: Runway incursions
The runway-incursion system that's behind schedule (RISKS-21.60) is the
Airport Movement Area Safety System (AMASS). It uses data from the Airport
Surface Detection Equipment (ASDE-3), a primary radar. "Primary" means it
relies on reflections, not transponders, for detection and ranging.
It seems to me that any system that relies only on position tracking is
going to have a tough time reliably detecting incursions without racking up
lots of false alarms. The distance from the hold-short line to disaster is
so small and the time to react so limited that the alarms have to be set to
go off on very small changes. Variations in RF propagation, changing
reflections from other moving aircraft (or service trucks), and system
instabilities almost guarantee that they will when nothing is wrong. The
technical folks may be able to tune each system to a level that ATC finds
acceptable, but it will be slow, labor-intensive, frequent, site-specific,
and expensive. Results will vary from facility to facility.
Much better systems are technologically feasible. Flight Management Systems
know when the aircraft is stopped, when its brakes are off, when the engines
are spooling up. A prototype FAA system controls red Runway Status Lights
(RWSL) for visual back-up to "hold short" instructions, based on whom the
controller has cleared to use the runway. The next generation aircraft
radios have provision for addressable data link. Moving map displays are
increasing common. Limited vocabulary speech understanding is increasingly
reliable.
Mix these together with some intelligent design for the controller's
display, and the runway monitor can raise a fuss when the pilot fails to
acknowledge a "hold short", or the brakes come off too early, not when the
radar jitters. Most operational errors by ATC and pilots will be prevented
by putting redundant information where it is useful instead of relying on
memory; others will be caught and corrected early. Life will be good.
Stocks will rise. Politics will be civil. PGN's puns will all be funny.
To all of us.
The risk: believing it might actually happen in our lifetime?
Bill Hopkins (whopkinsat_private, no longer in the ATC biz)
------------------------------
Date: Fri, 24 Aug 2001 16:06:13 +0100
From: Alistair McDonald <alistairat_private>
Subject: Code Red 9? Code Crimson
Two weeks into the Code Red exploit, when variant II or III or whatever you
want to call it was particularly active, incidents.org noticed that another
MS security flaw was being exploited. Their report is here
http://www.incidents.org/diary/august2001.php#132. They give no data as to
how many compromised systems are out there, possibly the reported probes are
all an attempt to "jump start" the worm.
The vulnerability is described at
http://www.microsoft.com/technet/security/bulletin/ms01-023.asp. Again,
there has been a patch available for some time (since May, apparently), yet
I'm sure that some systems will be unpatched. My Win2K SP2 machines did not
need the patch, so I guess it's installed with SP2.
When will the world wake up and stop buying software from a software company
that obviously can't write software well?
[Actually, the buying decision is probably done by people who know little
about software, IMO].
Alistair McDonald, Bacchus Consultancy Ltd http://www.bacchusconsultancy.com
------------------------------
Date: Fri, 17 Aug 2001 17:26:03 -0400 (EDT)
From: "Sharon Mech" <sharonat_private>
Subject: AT&T - the computer MUST be right!
Our long distance service is plain, vanilla AT&T service. Long-distance
charges appear on our local Ameritech phone bill. This past month, we got
a bill showing charges for the AT&T One Rate plan, for which we had not
signed up. (We also have an anti-slamming policy signed & on file.) So I
called Ameritech. After negotiating their automated attendant hell, I was
told that there was nothing they could do - I needed to call AT&T. At AT&T, more
automated attendant hell. When I get the rep on the line, I give her my
phone number and name, and explain the problem. She tells me that she can't
help me, because our phone number has someone else's name on it, and neither
I nor my husband is that person (whose name she will not reveal - I guess
privacy does matter!) and she can't give me to a supervisor, thank you for
calling AT&T! Just a note: We've lived at our house for 7 years, and always
had the same area code and phone number. Apparently the AT&T record had been
changed in February of this year, and our phone number was now associated
with a different name and address. If there was a notation of who authorized
the change, she sure didn't tell me - after all, it wasn't my phone line....
Back to Ameritech. Their rep confirmed that our line was indeed our line, in
my name, at our address. I was fortunate - this rep had initiative. Once I
explained the situation (took a couple of repeats) he put me on hold &
called AT&T to set up a conference call. Things almost fell apart at this
point, because Ameritech reps have a pretty strict time limit on their
calls. We got an AT&T rep on the phone at just about the limit. He went on
to explain to the AT&T rep that my line was really my line. She wasn't
buying it - after all, her computer MUST be right, but finally grudgingly
agreed to amend her record, noting his ID, info, etc. as
justification. Finally we could get to the point of removing the unwanted
calling plan. Mission accomplished. One last detail - the calling plan cost
a certain amount, but also involved a credit. Because the plan changes
tariffs & long distance rates, our long- distance usage (minimal) had been
billed at the wrong rate, and neither of the reps could tell me what we
actually owed.
Sharon Mech <sharonat_private>
------------------------------
Date: Mon, 20 Aug 2001 08:59:45 +0100
From: "Leeming, Geoffrey" <gleemingat_private>
Subject: Re: DejaGoogle rides again (Weingart, RISKS-21.61)
What risks? If you read a post in Deja/Google it gives you a nice link to
the rest of the thread. Full marks to Google for only giving one link to
the thread as a whole, not one to each of the entries. If it had been the
wrong thread, getting one link to each entry would have meant that the next
search result would have been pushed way down the list.
Geoffrey Leeming, Technical Security Manager
Lehman Brothers International Ltd. +44 (0) 20 7260 1338
[Also noted by several others. PGN]
------------------------------
Date: Wed, 22 Aug 2001 09:14:01 +0100 (BST)
From: AlphaLau <avlxyzat_private>
Subject: Re: Risks of automated junk/spam filters (Loftis, RISKS-21.60)
Unfortunately, this happens with Yahoo Mail as well. Their "Bulk Mail"
feature is similar, and you used to be able to specify if an email was
indeed not spam. Of course what they actually did with it...
Y!Mail also has a nifty "Block email from this Address" feature that will
send email with those addresses into a blackhole.
I have suggested to Yahoo to keep a log of blackholed emails, just the date,
from, to & subject fields should be enough. All I got in reply was, that is
how the blocking works. Use Y!Mail Filter to manually handle it.
So in effect, users are saddled with 2 spam "features" that are not really
useful. I have disabled both.
Still, Y!Mail is one-up on Hotmail with it's block-mail feature! :)
Alpha
------------------------------
Date: Mon, 20 Aug 2001 17:44:25 +0300
From: Kimmo <kimmo.pyykkoat_private>
Subject: Yet another MS Hotmail risk
One addition on Michael Loftis' article about MS's Hotmail service
(http://catless.ncl.ac.uk/Risks/21.60.html#subj11):
I also have a Hotmail account to handle the private mail and I noticed
today an interesting behaviour concerning the Junk Mail-folder:
Now, logging in this morning (Aug 20) I noticed a warning mail from
Hotmail Staff (Aug 18) that my account size is too large. Opening the
mail was impossible, because all I got was a warning that I was 5120K
over my quota. Someone's spam bot had gone to overdrive and sent over
600 spams to my account (all similar and from the same address, size
about 10K).
Emptying the Junk Mail folder (and blocking the spammers address) meant
that I could again use my account normally and also read the mail from
Hotmail Staff, which told me that if I didn't react before Aug 23,
Hotmail would start "deleting messages (usually older ones from all of
your folders) until your account is smaller than the 2-MB size limit".
Apparently, this is normal behaviour for MS Hotmail, as I managed to
find out in the service conditions. 5 days reaction time, before we
start emptying your account starting from the oldest. The risk?
If someone does not check his/her Hotmail for a week (eg. vacation,
illness), it is very easy to remove all his/her mail from all the
folders by simply sending in too much spam. Including the Junk
Mail-folder into the account size limit makes this kind of
"denial-of-mail" very easy, because mail in a Junk Mail folder isn't
deleted for 14 days from it's arrival.
Fortunately, I don't trust WWW-based email services enough to use them
for anything important but still: wiping out your email box is a
nuisance.
Kimmo Pyykkö, Development Manager, New Communications Services/
Technology Center tel. +358 2040 58328
------------------------------
Date: Mon, 20 Aug 2001 10:42:59 -0800
From: Rob Slade <rsladeat_private>
Subject: REVIEW: "SSL and TLS", Eric Rescorla
BKSSLTLS.RVW 20010607
"SSL and TLS", Eric Rescorla, 2001, 0-201-61598-3, U$39.95/C$59.95
%A Eric Rescorla ekrat_private
%C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D 2001
%G 0-201-61598-3
%I Addison-Wesley Publishing Co.
%O U$39.95/C$59.95 416-447-5101 fax: 416-443-0948
%P 499 p.
%T "SSL and TLS: Designing and Building Secure Systems"
The preface states, quite clearly, that this is a work for designers,
programmers, and implementors. In other words, it's a very technical
book. Even the preface, though, is written with a clarity that is
unusual, and refreshing, in technical literature.
Chapter one provides some background to communications security and
encryption. The material is demanding, and is definitely not a
primer. A number of items are glossed over, but the persistent reader
should be able to glean some very solid explanations of important
concepts. The "family tree" of SSL (Secure Sockets Layer) is given in
chapter two, with a description of the development steps along the
way. Chapter three outlines the basic, or most common, mode of SSL,
and then provides details about specific aspects of the algorithms and
data structures used at different points. Various options and
extensions, for a number of functions, are described in chapter four.
The security of the SSL system itself, as opposed to the security it
provides for transactions, is thoroughly examined in chapter five.
Chapter six is an examination of performance issues, and the ways in
which execution can, and can't, be improved.
SSL is, of course, only a protocol and not a full application. Design
considerations for effective use within a system are detailed in
chapter seven, and sample C and Java code for effecting the operations
is given in eight. SSL was designed for, and is most widely used
with, HTTP (HyperText Transfer Protocol), and chapter nine details the
requirements and difficulties of using the system to secure Web
communications. Chapter ten uses SMTP (Simple Mail Transfer Protocol)
as an example of the use of SSL to protect other communications
operations. Finally, Rescorla compares SSL to the major competing
systems of IPsec, S-HTTP (Secure HTTP), and S/MIME. (It is nice to
see that the author identifies his own potential bias in the debate.)
This book is aimed at a technical audience, and members of that group
will undoubtedly welcome it. However, the lucid presentation, and
range of security concepts covered make this a useful reference for
many others. Those involved in online commerce and the necessity to
secure transactions over insecure links will find solid discussions
addressing those issues. Security analysts and practitioners may be
challenged to look into the internals of systems generally examined
only at a superficial level. And anyone interested in the security of
the Internet will find a clear and fascinating review of its
underpinnings.
copyright Robert M. Slade, 2001 BKSSLTLS.RVW 20010607
rsladeat_private rsladeat_private sladeat_private p1at_private
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
------------------------------
Date: Thu, 23 Aug 2001 08:31:18 -0400
From: Anup Ghosh <aghoshat_private>
Subject: Dependable Systems and Networks DSN-2002 Call for Contributions
The International Conference on Dependable Systems and Networks (DSN-2002)
Bethesda, Maryland, USA 23-26 Jun 2002 http://www.dsn.org
Full papers and workshop proposals due 19 Nov 2001
This conference has combined the International Symposium on Fault-Tolerant
Computing (FTCS), the Working Conference on Dependable Computing for
Critical Applications (DCCA), into the DSN track now called Dependable
Computing and Communications, and in 2002 will also include the
International Performance and Dependability Symposium (IPDS).
See www.dsn.org for submission information. [PGN-ed for RISKS]
------------------------------
Date: 12 Feb 2001 (LAST-MODIFIED)
From: RISKS-requestat_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. Alternatively, via majordomo,
send e-mail requests to <risks-requestat_private> with one-line body
subscribe [OR unsubscribe]
which requires your ANSWERing confirmation to majordomoat_private .
[If E-mail address differs from FROM: subscribe "other-address <x@y>" ;
this requires PGN's intervention -- but hinders spamming subscriptions, etc.]
Lower-case only in address may get around a confirmation match glitch.
INFO [for unabridged version of RISKS information]
There seems to be an occasional glitch in the confirmation process, in which
case send mail to RISKS with a suitable SUBJECT and we'll do it manually.
.MIL users should contact <risks-requestat_private> (Dennis Rears).
.UK users should contact <Lindsay.Marshallat_private>.
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to risksat_private with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
[volume-summary issues are in risks-*.00]
[back volumes have their own subdirectories, e.g., "cd 20" for volume 20]
http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue].
Lindsay Marshall 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/ .
http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/
==> 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 21.62
************************
This archive was generated by hypermail 2b30 : Sat Aug 25 2001 - 15:05:05 PDT