RISKS-LIST: Risks-Forum Digest Weds 20 February 2002 Volume 21 : Issue 92
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.92.html>
and by anonymous ftp at ftp.sri.com, cd risks .
Contents:
Patriot misses again (Lord Wodehouse)
Researchers claim to crack Wi-Fi security (Monty Solomon)
When machine metadata fails, address humans (Diomidis Spinellis)
Unwitting cell calls swamp 911 systems (Monty Solomon)
Abuse of intercept capabilities: 'Tampa' affair (Geoffrey Brent)
PayPal's tenuous situation (Jeff Jonas)
Ice-skating judging solution (Ken Knowlton)
Re: Miami-Dade OKs touchscreen voting (Alan Brain)
An unlocked system can be compromised quickly (Greg Searle)
Dangerous characters (Mark Lomas)
Computerized assistance with non-standard punctuation (David Piper)
Re: Homograph problems (Geoffrey Brent)
What's a buffer overrun problem? (William P. N. Smith)
Sorry, that number is now in service (Gene Spafford)
Re: Officer calls for refund of 'speeding' fines (Henry Baker)
Re: Social Security numbers on tax envelopes (Robert Ellis Smith)
The Security Risks of Programs That Automatically Update (Scott Schram)
New Security Conference - GOVSEC, Call for Presentations (Jack Holleran)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Tue, 19 Feb 2002 11:06:49 +0000 (GMT Standard Time)
From: Lord Wodehouse <w0400at_private>
Subject: Patriot misses again
The long running saga of the Patriot missile continues. Spacedaily reports
(http://spacedaily.com/news/020217211535.6h8kn7ih.html) that two of three
missiles fired recently at White Sands under "battlefield conditions" with
three targets failed to intercept them.
... and someone wants to build a missile defence system ... (and if you
still think it is a good idea, check back through the RISKS archives)
John, SCS Global Services, GlaxoSmithKline, Medicines Research Centre,
Gunnels Wood Road, Stevenage SG1 2NY UK +44 1628 482 634 http://www.gsk.com/
------------------------------
Date: Fri, 15 Feb 2002 12:24:10 -0500
From: "monty solomon" <montyat_private>
Subject: Researchers claim to crack Wi-Fi security
Ephraim Schwartz, InfoWorld, Thursday, February 14, 2002
Researchers Claim to Crack Wi-Fi Security;
Proponents deny wireless networking spec is vulnerable to hijack,
authentication attacks.
http://www.pcworld.com/news/article/0,aid,84424,00.asp
A University of Maryland professor and his graduate student have apparently
uncovered serious weaknesses in the next-generation Wireless Fidelity
security protocol known as 802.1x. In a paper, "An Initial Security
Analysis of the IEEE 802.1X Standard" funded by the National Institute of
Standards, Professor William Arbaugh and his graduate assistant Arunesh
Mishra outline two separate scenarios that nullify the benefits of the new
standard and leave Wi-Fi networks wide open to attacks. The use of public
access "hot spots" are particularly vulnerable to session hijacking because
these locations do not even deploy the rudimentary Wired Equivalent Privacy
protocol. "This problem exists whether you use WEP or not, but it is
trivial to exploit if not using WEP," said Arbaugh.
Flaws Described
Dubbed "session hijacking" and "man-in-the-middle," both attacks basically
exploit inherent problems in Wi-Fi as well as exploiting how the new 802.1x
standard is designed. "Here's how session hijacking works. The hacker waits
for someone to finish successfully the authentication process. Then you as
the attacker send a disassociate message, forging it to make it look like it
came from the AP [access point]. The client [user] thinks they have been
kicked off, but the AP thinks the client is still out there. As long as WEP
is not involved you can start using that connection up until the next time
out, usually about 60 minutes," said Arbaugh. [...]
[Fine article. Well worth reading The Rest of the Story. PGN]
------------------------------
Date: Tue, 19 Feb 2002 15:16:20 +0300
From: Diomidis Spinellis <ddsat_private>
Subject: When machine metadata fails, address humans
The aggressive indexing of the Google search engine combined with the
on-line caching of the pages in the form they had when they were indexed, is
resulting in some perverse situations.
A number of RISKS articles have already described how sensitive data or
supposedly non-accessible pages leaked from an organization's intranet or
web-site to the world by getting indexed by Google or other search engines.
Such problems can be avoided by not placing private information on a
publicly accessible web site, or by employing metadata such as the robot
exclusion standard to inform the various web-crawling spiders that specific
contents are not to be indexed. Of course, adherence to the robot exclusion
standard is left to the discretion of the individual spiders, so the second
option should only be used for advisory purposes and not to protect
sensitive data.
Today I came across a web page <http://www.rietta.com/sqlconnect/> with
metadata addressing the humans reading a page rather than the spiders. The
page was apparently inadvertently, from the company's point of view indexed
by Google:
"NOTE: This page has been picked up by Google before we intended for it to
become visible. The SQL Connect software is completed, but we still have to
finalize the documentation and this website in order to release it. Please
check back soon for the download, or if you have questions, you can e-mail
productsat_private"
Worryingly, the same company also markets RoboGen, a product to manage the
robot exclusion specification file: "RoboGen allows you to easily manage a
robot exclusion file to control search engines indexing your website.
Featured in magazines and books, RoboGen is the most popular and easy to use
program for managing search engines that visit your website."
The moral? The web has a long (and growing, see
<http://www.archive.org>) memory. Information leaks due to incorrect
spider metadata and other errors can only be partially contained by
addressing new metadata to humans.
Diomidis Spinellis - http://www.dmst.aueb.gr/dds/
Athens University of Economics and Business (AUEB)
------------------------------
Date: Wed, 20 Feb 2002 18:46:02 -0500
From: Monty Solomon <montyat_private>
Subject: Unwitting cell calls swamp 911 systems
Unwitting Cell Calls Swamp 911 Systems,
By JILL LEOVY, Los Angeles Times, 19 Feb 2002
Frustrated by the large volume of 911 calls caused by people accidentally
hitting programmed buttons on their cell phones, police and emergency
response authorities are seeking new ways to keep systems from becoming
overloaded. Nearly two-thirds of all the 911 calls from wireless phones in
California, and even higher proportions elsewhere in the country, involve
people pushing emergency buttons on their cell phone keypads without knowing
it, authorities say.
http://www.latimes.com/technology/la-000012715feb19.story
------------------------------
Date: Thu, 14 Feb 2002 15:25:01 +1100
From: Geoffrey Brent <g.brentat_private>
Subject: Abuse of intercept capabilities: 'Tampa' affair
Last year, shortly before a federal election, the ship 'Tampa' made
Australian headlines when it rescued a boatload of about 400 refugees off
the Australian coast. A controversy followed on whether Australia would be
obliged to give the 'Tampa' harbour and accept said refugees.
It has recently been alleged that Australia's Defence Signals Directorate
(DSD) intercepted communications between the skipper of the 'Tampa' and the
Maritime Union of Australia and passed this information on to government. By
law the DSD is banned from intercepting Australian communications (with
certain exceptions not relevant here).
The Defence Minister, Robert Hill, has issued a very carefully-worded
response: there were "no significant breaches" of these rules, and
guidelines designed to protect privacy were adhered to "in the broad". While
denying that MUA communications were intercepted, Hill conceded that the DSD
had broken its rules relating to spying on Australians. Hill has given
assurances that the breach was not a major one, but without any information
on the nature of the breach confirming that is another matter...
http://www.theaustralian.news.com.au/common/story_page/0,5744,3766399%255E601,00.html
http://www.abc.net.au/am/s480125.htm
http://www.smh.com.au/news/0202/14/national/national3.html
et al.
Since the Tampa crisis played a very major role in the resurrection of the
Howard government's political fortunes, quite likely altering the outcome of
last year's federal election, the possibility of illegally-obtained
intercepts being used for political ends is not being taken lightly by
anybody (except, perhaps, that government...)
Geoffrey Brent
------------------------------
Date: Sun, 10 Feb 2002 06:38:08 -0500 (EST)
From: "Jeff Jonas" <jeffjat_private>
Subject: PayPal's tenuous situation
PayPal is much in the news after their NASDAQ IPO was further delayed due to
a lawsuit filed by CertCo concerning patent infringement. (the risk of
frivolous software patents had been discussed before in RISKS).
More damning in my eyes are the problems PayPal had to reveal in their
prospectus and the lack of discussion I've seen about the failures:
Their prospectus is found at:
http://www.edgar-online.com/bin/edgardoc/finSys_main.asp?dcn=0000912057-01-543278
It's interesting reading: they admit that they've never made any profit,
might never make a profit, and all the ways they might be squeezed out of
business.
> AMENDMENT NO. 2 TO FORM S-1 REGISTRATION STATEMENT
> UNDER THE SECURITIES ACT OF 1933 PAYPAL, INC.
> We have not reached profitability to date.
> We have accumulated net losses of $264.7 million
> from our inception, March 8, 1999, through September 30, 2001,
> and net losses of $90.6 million during the nine months
> ended September 30, 2001.
> During the four months between July and October 2000,
> we experienced a significant fraud episode and, as a result,
> we incurred gross losses due to unauthorized charge-backs totaling
> $5.7 million. This amount represented 64.0% of total charge-backs
> due to unauthorized transactions for the year ended December 31, 2000.
Ummm, what was done to prevent this fraud from recurring?
Anyone caught? Anything learned?
> For the year ended December 31, 2000, the amount of losses
> with respect to unauthorized use of bank accounts totaled $0.3 million.
> The gross amount of charge-backs received through September 30, 2001
> with respect to unauthorized use of credit cards for transactions
> that occurred during the nine months ended September 30, 2001
> totaled $3.2 million. For the nine months ended September 30, 2001,
> the amount of our losses with respect to unauthorized use of
> bank accounts totaled $0.9 million.
Gee, where do I get my share?
> We may experience breakdowns in our payment processing system
> that could damage customer relations and expose us to liability,
> which could affect adversely our ability to become profitable.
So why not act proactively with better failsafes such as having 2
active/active sites, automatic load balancing to shift the load in case of
failure, etc. All things available to buy and implement NOW!
> A system outage or data loss could have a material adverse effect on our
> business, financial condition and results of operations.
> To operate our business successfully, we must protect our payment processing
> and other systems from interruption by events beyond our control.
> Events that could cause system interruptions include:
> * fire;
> * earthquake;
> * terrorist attacks;
> * natural disasters;
> * computer viruses;
> * unauthorized entry;
> * telecommunications failure;
> * computer denial of service attacks; and
> * power loss and California rolling blackouts.
> We depend on two third parties for co-location of our data servers
> and rely upon these third parties for the physical security of our servers.
> Our servers currently reside in facilities in Santa Clara, California.
All your eggs in one basket: power failure, telecom failure, etc
are all totally fatal.
> Currently we are not able to switch instantly to another back-up site
> in the event of failure of the main server site.
> This means that an outage at one facility could result in our system being
> unavailable for at least several hours. This downtime could result in
> increased costs and lost revenues which would be detrimental to our business.
I see no excuse for that since quality of service load balancing routers exist
specifically for such protection.
> Our primary Internet hosting provider, Exodus, recently filed for protection
> under Chapter 11 of the U.S. Bankruptcy Code.
> Subject to court approval, Britain's Cable and Wireless plc has agreed to
> purchase Exodus's data center assets. We cannot predict the effect this may
> have on its ability to continue to provide reliable service.
> We have engaged Equinix, which is located in the same geographical area,
> to replace Exodus as our primary Internet hosting provider and intend to
> complete this transition in the first quarter of 2002.
So how's the transition going?
> Our infrastructure could prove unable to handle a larger volume of
> customer transactions. Any failure to accommodate transaction growth
> could impair customer satisfaction, lead to a loss of customers, impair
> our ability to add customers or increase our costs,
> all of which would harm our business.
With their inability to handle cutovers from emergencies,
I don't see how that's making things scalable.
------------------------------
Date: Tue, 19 Feb 2002 13:59:10 EST
From: Ken Knowlton <KCKnowltonat_private>
Subject: Ice-skating judging solution
What a marvelous solution to the problem exposed by the Olympics ice-skate
judging brouhaha: use computers and random numbers, and-- most important --
remove the process from public view!
[The algorithm reported: 14 judges, reporting anonymously, with the
computer program randomly and without accountability throwing out a
handful of votes. Sounds like we are once again back to the wonders
of nonaudited electronic voting systems that have received so much
discussion in RISKS, such as the following item. PGN]
------------------------------
Date: Fri, 15 Feb 2002 16:38:49 +1100
From: Alan Brain <abat_private>
Subject: Re: Miami-Dade OKs touchscreen voting (Price/PGN, RISKS-21.90)
The risks for vote-rigging on COTS systems [include]:
a) Someone tweaks the BIOS of the voting machines.
b) Someone tweaks the OS of the voting machines.
c) Someone tweaks the applications code
d) Someone tweaks the compiler.
a) Can best be dealt with via physical security only - have non-flashable
BIOSes, and disallow unauthorised access.
The rest require both a publicly available Open Source codebase, and
physical security to make sure that what you think is on the machine,
actually is. And that the right OS has been installed, and the right
compiler used.
Well, it's not a touchscreen system per se, but close enough.
Have a look at http://www.elections.act.gov.au/EVACS.html. The source
code's available at http://www.elections.act.gov.au/evacs.tar.gz
Compile with a gcc compiler, run on FreeBSD or Linux.
Conversely, if the voting is being done with machines where the OS,
Applications Sourcecode and Compiler aren't Open Source, then security is
problematic.
------------------------------
Date: Fri, 15 Feb 2002 12:41:06 -0500
From: "Greg Searle" <greg_searleat_private>
Subject: An unlocked system can be compromised quickly
Audrie Krause's submission on non-profit's security brought up the problem
of not locking a workstation when walking away from it. If you don't
understand why locking your system is so important, try the following
exercise. (Don't worry -- if you hit "Cancel" in the final step** as
instructed, it won't actually do anything. This sequence would be slightly
different on Windows 95/98/ME boxes, which can't be effectively locked,
anyway.)
On an unlocked system (preferably yours!):
Hit Windows Key-E to bring up an Explorer window.
Select the "C:" drive in the right pane (tab,down arrow, or click on it).
Hit Alt-Enter to bring up the Properties dialog for that drive.
Click on the "Sharing" tab.
Click "Share this Folder" if it is not selected.
Only if "Share this Folder" was already selected, click the "New Share"
button, enter a share name, and hit "OK".
** Hit "Cancel" to dismiss the dialog safely. DON'T HIT OK.
Close the Explorer window.
If you had hit "Ok" instead of "Cancel" above, this sequence would give
EVERYBODY TOTAL ACCESS to the C: drive. This means that anyone on the local
net could read and write any file or directory on your drive, and you
wouldn't know it. A malicious person with physical access to the machine
only cares about being able to freely access your machine from the privacy
of another workstation. They don't care that everybody else has access, as
well.
So, how long did the exercise above take you? It would only take less than
10 seconds for an experienced Windows user, and there is no visible evidence
that the system was tampered with. How long does it take for you to walk to
the coffee machine and back? Lock your systems when you walk away. This
exact thing actually happened to an employee at the company I work for.
Eventually she realized that her system was wide open to the network.
Worse, some damage had been done by a remote user. They never found out who
did it.
If you're worried that I'm giving away some secret information, don't. This
can be accomplished in many ways, and the information is public knowledge.
This particular sequence would usually be selected as the fastest way to get
in, make the change, and get out. I'm just attempting to impress how
quickly a Windows system can be compromised.
(If you really hit "Ok" instead of "Cancel", you will want to remove the new
share, quickly.)
------------------------------
Date: Fri, 15 Feb 2002 00:06:57 -0000
From: "Mark Lomas" <mark.lomasat_private>
Subject: Dangerous characters
Many of us are familiar with web sites that, because of inadequate checking
of user-supplied data, are vulnerable to attack. Careful filtering of data
can prevent such attacks.
Waitrose, a well-respected chain of UK shops, took this a little too far on
their on-line shopping site. It appears that they decided that the humble
apostrophe was too dangerous to appear in user input.
I noticed this because it changed the message I had asked to be sent with
some flowers for my wife. As today is St Valentine's day, I imagine a large
number of customers had their messages changed.
------------------------------
Date: Thu, 14 Feb 2002 08:33:11 -0800
From: "David Piper" <dxp7949at_private>
Subject: Computerized assistance with non-standard punctuation
In RISKS-21.91 Toby Gottfried notes potential problems with the name of
Microsoft's new project ".Net" violating common rules of English sentence
structure. Robert Marshall advises that Google may be stripping self-defined
"extraneous" punctuation from email addresses.
I used to live on a street called "Oak Crest Way". One day my address was
OCR scanned by some mailing list company and the "O" was resolved as a
period. I then began to receive junk mail addressed to:
".Ak Crest Way"
Notice how the "intelligent" software automatically capitalized the "A". I
received several pieces from different junk mailers as the address was
resold. Then one day a new junk mail piece arrived addressed to:
"Ak Crest Way"
Another "intelligent" program had automatically stripped out the leading
period. I don't have high hopes for ".Net".
David R. Piper, Administrative Analyst, Los Angeles Unified School District
Maintenance&Operations, District I, 1500 E. 14th Street, Los Angeles, CA 90021
------------------------------
Date: Sun, 17 Feb 2002 17:12:24 +1100
From: Geoffrey Brent <g.brentat_private>
Subject: Re: Homograph problems (Kline, RISKS 21.91)
Merlyn Kline mentions homograph problems with lowercase L, uppercase I, and
the number 1. I had the misfortune to encounter a net access program that
gave me a randomly-generated password with three of these in it... and
wouldn't allow font changes. With 27 possibilities to try, I was glad it
didn't lock-out after three failed attempts.
Geoffrey Brent
------------------------------
Date: Wed, 13 Feb 2002 10:46:41 -0500
From: "William P. N. Smith" <wpnsat_private>
Subject: What's a buffer overrun problem?
Something about being doomed to repeat history:
> Software: Telnet Service in Microsoft Windows 2000; Telnet
> Daemon in Microsoft Interix 2.2
> http://www.microsoft.com/technet/security/bulletin/MS02-004.asp.
[...]
> The implementations [...] contain unchecked buffers in the
> code that handles the processing of telnet protocol options.
and
> Software: Microsoft Windows 95, 98, 98SE, NT 4.0, NT 4.0 Terminal
> Server Edition, 2000, XP
> http://www.microsoft.com/technet/security/bulletin/MS02-006.asp.
[...]
> A buffer overrun is present in all implementations [of SNMP].
It's nice that they are closing holes, but with all the Navy shipboard
networks that are apparently running Windoze, 'overflow' is going to take
on a brand new meaning. 8*}
William Smith wpnsat_private N1JBJat_private
ComputerSmiths Consulting, Inc. www.compusmiths.com
------------------------------
Date: Mon, 18 Feb 2002 09:03:23 -0500
From: Gene Spafford <spafat_private>
Subject: Sorry, that number is now in service
Long ago, I configured the router for our center to reject packets coming
from nonsensical addresses. These include packets coming from the outside
with addresses of inside hosts, with the loopback address as source, and
with any unassigned IP addresses. The latter were taken from the IANA list
of "reserved" IP ranges.
Blocking these packets helps keep away packets employing address spoofing
and DOS attacks with falsified "from" addresses. Needless to say, this is a
desirable outcome!
Because our router config is complicated, it is something I try to avoid
changing (or even looking at) unless something breaks. Usually, that is
obvious -- we install something new, or add a new subnet, and things need to
be adjusted.
About 3 months back, my email to a long-time friend started bouncing. Well,
to be specific, it would sit in our queue and timeout -- it couldn't seem to
get delivered to the destination. I didn't think much about it because
hosts sometimes go down. Plus, her company was undergoing some expansion
and moving offices. But the problem persisted. A mutal friend reported no
such problems, which really seemed odd.
Then, I tried sending email from a separate account I have outside the
university. It got through! But email to my account at CERIAS failed. How
odd.... Further investigation revealed that I could do a traceroute right
up to her company's firewall, but no further. Meanwhile, the admin at her
firm reported he could traceroute to our router, but no further. Really
odd!
An inquiry to their ISP revealed no filter rules that blocked traffic. And
I could reach their machine from other campus hosts. It must be our router.
It took me nearly a full day to find the offending line buried deep within
the router config. This was complicated because I generate part of the
config using a macro preprocessor (saves some of the tedium of typing the
almost-same line over and over).
It appears that sometime in 2001, the 69.x.x.x IP range (plus others) went
from "reserved" to "assigned". However, if there was some place this was
announced, I never saw it (or it never registered to me). Meanwhile, my
router was happily blocking all the traffic from my friend's site.
There must be a moral to this story, but I am unsure what it might be. I
can say that I am still blocking address ranges, but now I have a reminder
in my mailer to check the assigned number list every 6 months.
------------------------------
Date: Fri, 15 Feb 2002 13:31:26 -0800
From: Henry Baker <hbaker1at_private>
Subject: Re: Officer calls for refund of 'speeding' fines (Solomon, R 21 92)
This is a very old problem. Road & Track did an article 25+ years ago about
Italian drivers who would take their cars out on the Autostrada tollroad and
keep and frame the stamped toll receipt which proved that they achieved 200
kilometers per hour (or whatever) for a particular Autostrada segment.
I think that the Italian government got wise and started automatically
printing out speeding tickets along with the toll receipts!
------------------------------
Date: Thu, 14 Feb 2002 12:45:57 -0500
From: "Robert Ellis Smith" <ellis84at_private>
Subject: Re: Social Security numbers on tax envelopes (Klein, RISKS-21.91)
Gee, a new federal law prohibits federal agencies from doing this - but it
doesn't kick in until November 2004!, according to Privacy Journal's new
Compilation of State and Federal Privacy Laws.
Robert Ellis Smith, Publisher, Privacy Journal, Providence RI
privacyjournalat_private http://www.privacyjournal.net
------------------------------
Date: Fri, 15 Feb 2002 09:31:47 -0600
From: Scott Schram <scottat_private>
Subject: The Security Risks of Programs That Automatically Update
I've just completed an article addressing some risks of programs that
update themselves:
Rather than a bona-fide update, the auto-update feature could be used to
send programs with undesired features. The activity of these updaters
would not be detected by firewall tools, as they are expected to be
periodically checking for updates and downloading them. Further, the most
careful reverse-engineering of the updater would not reveal anything
unexpected.
http://schram.net/articles/updaterisk.html
Comments are welcome! Thanks,
Scott Schram <scottat_private> http://schram.net
------------------------------
Date: Thu, 14 Feb 2002 00:22:20 -0500
From: Jack Holleran <Holleranat_private>
Subject: New Security Conference - GOVSEC, Call for Presentations
[Jack is seeking participant ideas, not completed works,
by 23 Feb. PGN]
As the program develops, information will be posted on
http://www.govsecinfo.com
GOVSEC 2002 is the only conference dedicated to enterprise security for the
government. GOVSEC offers two powerful conferences in one. GOVSEC will
address physical security issues and information security issues.
If you have any questions on submitting a Call for Presentations for GOVSEC
2002, please contact Sharon Patterson, CMP, at spattersonat_private or
call 703.941.5896.
GOVSEC is produced by National Trade Productions, Inc.
313 S. Patrick Street, Alexandria, VA 22314. Phone 703.683.8500
------------------------------
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.92
************************
This archive was generated by hypermail 2b30 : Wed Feb 20 2002 - 19:03:46 PST