RISKS-LIST: Risks-Forum Digest Monday 2 April 2001 Volume 21 : Issue 32

   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.32.html>
and by anonymous ftp at ftp.sri.com, cd risks .

  Contents:
Future Mac Viruses? (PC Rescue)
The cost of Windows virus (Joaquim Baptista)
Risks of auto-updating software (Alan Wexelblat)
Dutch police fight cell theft with text 'bombs' (Thomas Dzubin)
Cellphone text bombs (Conrad Heiney)
Approved posts to large listservs (Paul Hessels)
MSN "upgrade" creates long-distance calling (Steve Holzworth)
Re: Hidden info on MS Word documents (Joaquim Baptista)
Hidden highway robbery within Terms of Use contracts? (Michael Sinz)
EoExchange shuts down services without warning, customer data lost
  (Derek Ziglar)
Re: "Internet Voting is no 'Magic Ballot'" (Jay R. Ashworth, Jurek Kirakowski)
Re: Bogus Microsoft Corporation digital certificates (Peter da Silva, WBH)
Re: Verisign certificates problem (Camillo Sars)
Re: Aasta train crash (Dag-Erling Smorgrav)
Re: Serious new CA Drivers License ID RISK (Jim Horning, John Rickenbrode)
Abridged info on RISKS (comp.risks)

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

Date: Sun, 25 Mar 2001 06:48:30 +1000
From: "PC Rescue" <paulpcrescue.com.au>
Subject: Future Mac Viruses?

Mac users have been crowing for some time that their system is less prone to
viruses than the horrible alternative. Could this be about to change?

http://www.wirednews.com/news/technology/0,1282,42586,00.html

"The box contains three installation CDs -- Mac OS X, Mac OS 9.1 and a CD
full of developer tools, including the Cocoa programming environment, which
is reportedly simple enough for school kids to use."

www.pcrescue.com.au infopcrescue.com.au Tel 0415 967 017 Fax: 02 9953 8772

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

Date: Tue, 27 Mar 2001 22:44:32 +0000
From: Joaquim Baptista <pxaltitude.com>
Subject: The cost of Windows virus

I am deploying a custom-made server program that makes several
manipulations of XML files, including an automated conversion to Word.

It had been a mystery why the production server, a Pentium 700 with SCSI
disks running Windows 2000, was much slower than the development server, a
Pentium 500 with IDE disks.

Yesterday, a particular long processing involving a 53MB RTF file just run
forever. I killed it consumed after 3 hours of CPU.

Then, we decided to turn off the anti-virus software. A sample task that
took over six minutes now takes two and a half minutes. And the very long
processing now runs in 15 minutes.

Therefore, the cost of the Windows virus includes the cost of running the
anti-virus software. It cripples my server to less than half its
performance. My Pentium 700 becomes a Pentium 270 (usual case)! On some
cases, the anti-virus software delays the computation at least 24 times, and
the Pentium 700 becomes less than a Pentium 30!

Linux suddenly seems a lot cheaper!

Joaquim Baptista, alias pxQuim, Director, Technical Documentation
pxaltitude.com

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

Date: Sun, 1 Apr 2001 11:49:52 -0400
From: Graystreak <wexmedia.mit.edu>
Subject: Risks of auto-updating software

In his recent (April 2001) AskTog column, Bruce Toganzzini reports on his
ReplayTV which, one recent day, updated itself to disable a valuable
feature.
    http://www.asktog.com/columns/045ReplayTV.html

We saw something like this happen when Napster first tried to ban Metallica
song-trading -- they forced users to update to a new client which had the
blocking patch installed. This is the first mass-market product (as in,
people paid lots of real money for this) instance of this that I can think
of.

I'm certain it won't be the last. We are moving to a realm of always-on,
always-connected devices. In this realm, our software will begin
misbehaving without our ever doing anything to it.

Alan Wexelblat, moderator, rec.arts.sf.reviews wexmedia.mit.edu
http://wex.www.media.mit.edu/people/wex/

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

Date: Wed, 28 Mar 2001 11:49:11 -0800 (PST)
From: Thomas Dzubin <dzubintvcn.bc.ca>
Subject: Dutch police fight cell theft with text 'bombs'

After a user reports his GMS handset stolen, the police start sending out
one Short Message Service text message to the phone every three
minutes: "This handset was nicked, buying or selling is a crime. The
police."

See web page story at:
  http://www.cnn.com/2001/TECH/ptech/03/28/SMS.bomb.idg/index.html

Thomas Dzubin, Vancouver, Saskatoon, or Calgary CANADA

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

Date: Wed, 28 Mar 2001 09:21:51 -0800
From: "Conrad Heiney" <conradfringehead.org>
Subject: Cellphone text bombs

CNN and IDG report
  http://www.cnn.com/2001/TECH/ptech/03/28/SMS.bomb.idg/index.html
that the Dutch police are using a kind of mailbomb technique to discourage
theft of wireless phones.

If a phone is believed to be stolen, police track it down with its unique
identification number and send the message "This handset was nicked, buying
or selling it is a crime" every three minutes via SMS.

The RISK here is fairly obvious. What to do if your phone ends up
mysteriously on the 'stolen' list? Go to your local police station? The
phone company?

Conrad Heiney conradfringehead.org http://fringehead.org/

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

Date: Thu, 29 Mar 2001 12:21:17 -0800 (PST)
From: Paul Hessels <timdauyahoo.com>
Subject: Approved posts to large listservs

I recently sent an email to bugtraqsecurityfocus.com, which
was approved after being examined by the moderator.

Here is the risk: Since I made the mistake of using an e-mail address from a
small domain that I manage, my DNS server immediately got killed by the tens
of thousands of mail servers trying to resolve my domain name.(which of
course was not in anyones cache; my domain is pretty much unknown.)

I saw all this traffic and didn't immediately recognize what it was. I was
scared, but a little bit of investigation provided an answer.

After an hour and my cable modem rebooting a few times from the sheer load,
everything seemed to settle down, but I'll tell you, watching the lights on
that modem flash without yet understanding what was happening sure scared
me.

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

Date: Fri, 30 Mar 2001 18:24:20 -0500
From: Steve Holzworth <schunx.sas.com>
Subject: MSN "upgrade" creates long-distance calling

As RISKS readers are aware, automatic upgrades of software aren't always as
innocuous as "they" would have you believe. A recent Microsoft Networks
(MSN) dial-up upgrade caused some users in the Research Triangle, NC area to
suddenly start dialing in via a long distance access number, as opposed to
the previously local exchange. WRAL TV's consumer reporter has received 51
calls about this so far.

Someone's phone bill included $361 in long distance charges to a Chapel Hill
number for his Internet connection through Microsoft Networks, despite
having used a local number. An MSN customer service representative told
someone else that MSN "lost local numbers for several areas" during an
upgrade. Several complainants had online chats where representatives
insisted the Chapel Hill number was not long distance." [Source: WRAL TV
online (excerpted [and PGN-ed])
  http://www.wral-tv.com/features/5onyourside/2001/0329-msn-folo/]

Adding additional dial-in numbers may be a good thing for a service to do.
Arbitrarily changing the numbers that existing customers chose to use,
without at least warning the customers first, seems rather suspect, as MSN
has now discovered. Compounding the error by telling your customers that
they are mistaken, while said customers are holding their long distance
bills in their hands, certainly inspires confidence...

Steve Holzworth, Senior Systems Developer, SAS Institute -
Open Systems R&D VMS/MAC/UNIX, Cary, N.C. schunx.sas.com

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

Date: Tue, 27 Mar 2001 21:56:04 +0000
From: Joaquim Baptista <pxaltitude.com>
Subject: Re: Hidden info on MS Word documents (Henry, RISKS-21.25)

>Mitigation: Use RTF when you can -- no hidden info, no viruses.

...unless your document includes images. Images store their pathname, even
in RTF, although the ASCII characters are "hidden" as hexadecimal numbers.
I have actually used this "feature" to recover the original images included
in Word documents.

Joaquim Baptista, alias pxQuim, Director, Technical Documentation
pxaltitude.com

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

Date: Fri, 30 Mar 2001 17:46:04 -0500
From: Michael Sinz <Michael.Sinzsinz.org>
Subject: Hidden highway robbery within Terms of Use contracts?

Can this ever be considered not unreasonable?

If you use .NET and/or HailStorm PassPort service, you will find that
basically you are giving everything to Microsoft.

If you send source code or business plans or a chapter of your first novel
or anything else of any value (or of no value), Microsoft has the right to
use, exploit, and sublicense any and or all of it without any payment to the
copyright holder. It also has the right to any trademark, service mark, or
patent that you might use in such communications or documents that are
used/stored/transmitted via their service!

See http://www.passport.com/Consumer/TermsOfUse.asp

So, when Windows and Office get .NET'ed, don't expect to be able to use
Windows or Office for anything that you want to keep for yourself.

Microsoft says "All your data belong to us"

And it really is not a joke, given their own legal terms of use documents.

I guess program development for the Windows platform now will need to be
done on some non-.NET systems - otherwise you may as well just give your
software to Microsoft. (And your business plans, and poetry, and payroll
data, and...)

Look at the section "License to Microsoft"

Quote:
  LICENSE TO MICROSOFT

  By posting messages, uploading files, inputting data, submitting any
  feedback or suggestions, or engaging in any other form of communication
  with or through the Passport Web Site, you warrant and represent that you
  own or otherwise control the rights necessary to do so and you are
  granting Microsoft and its affiliated companies permission to:

  1. Use, modify, copy, distribute, transmit, publicly display, publicly
     perform, reproduce, publish, sublicense, create derivative works from,
     transfer, or sell any such communication.

  2. Sublicense to third parties the unrestricted right to exercise any of
     the foregoing rights granted with respect to the communication.

  3. Publish your name in connection with any such communication.

  The foregoing grants shall include the right to exploit any proprietary
  rights in such communication, including but not limited to rights under
  copyright, trademark, service mark or patent laws under any relevant
  jurisdiction. No compensation will be paid with respect to Microsoft's
  use of the materials contained within such communication. Microsoft is
  under no obligation to post or use any materials you may provide and may
  remove such materials at any time in Microsoft's sole discretion.
  :End-Quote

Talk about trying to own the world. Using the ".NET" Word to write
up your patent would give Microsoft rights to use the patent. Sending
information about your patent via MSN EMail or IM does the same.

Can such a Terms of Use even be enforced?

Just when you thought the worst of Microsoft, you find something
that proves that you have not gotten there yet.

Michael Sinz ---- Technology and Engineering Director/Consultant
michael.sinzsinz.org http://www.sinz.org/Michael.Sinz

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

Date: Tue, 27 Mar 2001 08:39:54 -0500
From: "Derek Ziglar" <dziglaryahoo.com>
Subject: EoExchange shuts down services without warning, customer data lost

We've long known the risk of course is depending on 'free' and advertiser
supported services--since they are free to the user, the provider is under
no obligation to continue them.

Last week, EoExchange shut down their multiple advertiser-supported services
they have been offering on the web for several years. These included
EoMonitor (web page change monitoring better than anything else I had ever
seen), EgoSurf (a name-oriented search engine) and Daily Diffs (tracked
content changes across many informative sites).

The real Risk here to the users was that EoExchange chose to discontinue
them *without* advance notice. On Tuesday, the services were operating
normally. On Thursday, the sites were inaccessible and merely forwarded to a
corporate web page promoting different products.

Suddenly and without warning, users of these services could no longer access
the user-specific stored data they had accumulated through them. These
included lists of favorite links and web sites, many of which people
depended on regularly for information. The complete lack of warning meant
none of the users had the opportunity to print off their personal data from
the sites and preserve these lists of important sites.

Adding insult to injury is the company's complete lack of an explanation,
even after the fact. All users of these services simply find the URLs now
redirecting to a corporate site that neither apologizes for the shutdown nor
even acknowledges that these services ever existed. When I contacted the
company for an explanation, I received only a vague reply that they had
chosen to discontinue the advertiser-supported services and focus on their
corporate solutions.

So this was a not-very-subtitle reminder that when using any 'free' online
services where you store personal and needed data (emails, lists of links,
etc.), don't forget to make some kind of regular backup--even if only simple
printouts--of your data there in case the services shut down unexpectedly.

Derek Ziglar, Atlanta, Georgia dziglaryahoo.com

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

Date: Tue, 27 Mar 2001 10:18:15 -0500
From: "Jay R. Ashworth" <jrabaylink.com>
Subject: Re: "Internet Voting is no 'Magic Ballot'" (Jones, RISKS-21.30)

In his comments to RISKS, Douglas Jones asserts that electronic, and more
specifically *Internet*, voting is just like absentee balloting, and that
therefore, it doesn't really merit any more special lawmaking or concern --
we just need to enforce the laws we already have concerning such ballots.

I disagree.

All voting systems are tradeoffs, as nearly everyone interested in the topic
has been reminded repeatedly since 7 November 2000. Different tradeoffs
have traditionally been made for absentee ballots, since elections as close
as the 2000 Presidential election are quite uncommon, and therefore relaxing
the constraints on absentee votes is an acceptable tradeoff for *getting*
those votes -- that is, making it possible for people who could not
otherwise vote to be heard.

But, these relaxed strictures are only acceptable, so far as I can see,
precisely *because* those votes are such a small percentage of the total
(well under 1%, usually). It would *not* be acceptable to use restrictions
that loose for a voting method that might collect 30-50%, or even more, of
the total balloting.

The most notable criterion in question is secrecy of vote. This is in
place, as <a href="http://www.research.att.com/~lorrie/voting/">Lorrie
Cranor's excellent e-voting compendium</a> would remind us, to prevent
vote-selling. "Oh, but no one does that these days -- well, except maybe in
Chicago" (:-).

Nope. The restriction *works*. And, honestly, I cannot see *any way at
all* to *impose* that restriction on voting which may be done from home.
You can't even be *certain* that a vote came from whom it says it did; Bruce
Schneier has explained fairly clearly in his Crypto-Gram newsletters the
pitfalls in depending on even digital signatures, for something this
important.

While the various people involved, according to general press accounts,
seem to properly appreciate the stringent requirements of electronic
voting in precincts -- chief among them the point that a "vote" needs
to be a (rugged) *physical object that the voter can inspect,
completed* (I'm thinking of OCR printing on Polaroid film, myself) --
I don't think the problem of Internet voting at home is soluble.

Though I'm willing to be convinced otherwise. It won't be easy.

Jay R. Ashworth, Member of the Technical Staff, Baylink, The Suncoast Freenet
Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 jrabaylink.com

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

Date: Tue, 27 Mar 2001 12:16:33 +0100
From: jk <jzkucc.ie>
Subject: Re: "Internet Voting is no 'Magic Ballot'" (Jones, RISKS-21.30)

Douglas W. Jones raised the problems of user-testing the DRE machines,
citing among other reasons, that "A voter casts only one ballot, and for
the voter, the voting experience is a peak moment" one may add also that
voting is not a frequent activity so there will also usually be an element
of uncertainty when confronted with the interface to be used... especially
if the interface has changed (maybe for the better) since last time.

In usability testing, an important issue is the 'Context of Use' (see
http://www.ucc.ie/hfrg/baseline/filearchive.html#cou ) which boils down to
the idea that a 'usability test' can be extremely misleading if carried out
under conditions which do not mirror the real-life conditions in important
spects. And emotionality, stress, and uncertainty are crucial features of
this situation which will affect the results of any test.

The basic tenet is: context of test = context of use.

The best check on this kind of software would be to have the keypad or
screen physically wired up to a completely separate second local system
which will record the tallies using an algorithm independent of the main
system, and to test it in situations as close the the real as possible.
Telling pretend users to go in and punch a set of buttons is, I agree, not a
very realistic way of testing; using over-the-shoulder video technology is
incredibly time-consuming and will bring in its own sources of rater error.

Jurek Kirakowski, HFRG, Ireland http://hfrg.ucc.ie/ http://hfrg.ucc.ie/jk/

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

Date: Mon, 26 Mar 2001 12:10:10 -0600 (CST)
From: Peter da Silva <peterabbnm.com>
Subject: Re: Bogus Microsoft Corporation digital certificates (Savit, R-21.30)

The real risk here is the protection model used by Internet Explorer and
related programs. Rather than establishing a mechanism whereby active content
can be run (possibly with somewhat degraded performance) in a sandbox, it
depends on all the certificants being able to ensure that their certificates
and signed applets are secure.

Certificates are useful as an additional mechanism on top of a secure system,
to provide accountability, but they're no replacement for one.

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

Date: Fri, 23 Mar 2001 21:42:37 -0500
From: WBH <mustangerols.com>
Subject: Re: Bogus Microsoft Corporation digital certificates (Savit, R-21.30)

Microsoft isn't the primary victim, WE ARE!!

The only way to practically resolve this issue is for Verisign to re-issue
all certs they ever verified under a new CA signing certificate. THEN,
Verisign has to launch a campaign to replace it's CA certs in every online
users' web browser!!

Why? Because the general public (us) doesn't have a CRL-checking mechanism
when our browsers verify a certificate as valid. Our browsers only look as
far as the list of CA certificates that are embedded in our browser at the
time we verify a cert.

This isn't a minor PKI flap.

THIS IS HUGE SECURITY DEBACLE FOR VERISIGN, AND A MAJOR NEW VULNERABILITY
FOR THE ONLINE PUBLIC AT LARGE!!!

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

Date: 27 Mar 2001 12:47:37 +0300
From: "Camillo Sars" <gediki.fi>
Subject: Re: Verisign certificates problem (Sinclair, RISKS-21.30)

> [...] do not have this CRL Distribution Point field properly filled in.

Unfortunately, the problem lies much deeper. The CDP field is not
mandatory, it is *optional*. Complying implementations are supposed to
"know" where to get the CRL in case the CDP field is not filled in. In most
cases, configuring the CDP for the CA in these cases should be done at the
same time as the CA certificate is given "trusted" status. That is, in
theory at least.

There is no real standard for how "certificates" should be filled in, issued
or used. The often cited X.509 standard is very loose, and requires
significant profiling to suit a particular purpose. The profiling work for
Internet use has only recently produced the first IETF RFC:s. For those who
are familiar with the risks caused by directory lookups based on "common
names", it is interesting to note that one of the tricky parts of the IETF
work was to come to an agreement as to what is part of a "unique name". I'm
not sure a compromise is good risk management in this case...

Current "X.509 certificates" are suitable for deployment in specialized
environments, but anyone relying on them for what one might call "generic
Internet authentication" needs to be aware of the pitfalls. The risk? Only
a handful of people worldwide really know enough to be able to estimate the
risks, but still we rely on things like SSL daily. Ask yourself - Do You
know how your favorite browser responds to different PKI violations? And
how would You respond?

For a good, albeit rather specialized, view on PKIs, I recommend reading
Bruce Schneier's book "Secrets and Lies". Bruce also co-authored a paper on
"Ten risks of PKI" with Carl Ellison, which is probably a "must-read" for
regular RISKS readers.

> Two things need to be done, one is that software which checks certificates
> must be changed to warn users that certificates lacking a CRL are much more
> suspect and Verisign needs to re-place all certificates that currently lack
> this critical information with new certificates that have this field
> properly filled in.

Also note the risk caused by implementing strict CRL checks. The CDP
becomes a single point-of-failure for any relying certificates. I
have experienced a situation where a software update at the CA site
caused relying clients to fail in their CRL requests. If a site
relies heavily on certificate-based authentication, the consequences
can be very severe.

Camillo Särs <+ged+iki.fi> <http://www.iki.fi/+ged>

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

Date: 27 Mar 2001 12:26:38 +0200
From: Dag-Erling Smorgrav <desthinksec.com>
Subject: Re: Aasta train crash (Jarnbjo, RISKS-21.30)

> [...] As this service had been canceled by the operator Telenor, all
> train drivers had to call the train controlling central and report their
> train number and the corresponding mobile phone number.

This is incorrect. Telenor did not cancel NSB's phone service; the report
clearly states that NSB had changed their train numbering scheme so that
train numbers were no longer within the number range allocated to them by
Telenor.

I find it distasteful that people are still trying to invent reasons to
absolve NSB of the responsibility for this and the numerous other accidents
and interruptions of service they had last year. NSB's shoddy management,
total lack of respect for their customers (though I have to admit they're
still more customer-oriented than Oslo's public transportation authority,
who seem to regard every passenger as a potentially violent criminal), and
mismanagement of funds - spending billions on prestige projects with
practically no ROI, while letting their infrastructure and equipment
deteriorate for lack of maintenance - are the deep causes of these
accidents.

Dag-Erling Smørgrav - desthinksec.com

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

Date: Wed, 28 Mar 2001 10:51:00 -0800
From: Jim Horning <horningintertrust.com>
Subject: Re: Serious new CA Drivers License ID RISK (Cornell, RISKS-21.29)

Back in August 1997, in RISKS 19.28, I reported the identical scam being
pulled on me, involving the same bank (Wells Fargo). At that time, my local
branch manager told me that she was currently working with three other
customers of THAT BRANCH to put their banking accounts back in order as a
result of the same scam.

That was before Wells Fargo was bought by an out-of-state bank (that changed
its name to Wells Fargo), and I must say that all the bank employees, both
in the branch and in the fraud detection department, were cooperative and
helpful, and in the end I was only out time, not cash. But it was still a
damn nuisance.

I didn't know about the change in California law making the DL primary id.
The fake driver's license didn't have correct versions of my name, my
birthdate, or my signature (all things the bank could have checked, but
didn't). The gang didn't have my preprinted deposit forms, so they
hand-wrote my account number on counter forms. But they didn't take quite
$1,000 at a time and did it all in one banking day at multiple branches
distant from my home branch, so apparently didn't trigger any real-time
validation. Offline validation did bring in the fraud department. The bank
notified me of the problem, rather than vice versa. As far as I know, the
gang never tried again using my new accounts.

Jim H.

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

Date: Mon, 26 Mar 2001 22:52:38 -0800
From: "John Rickenbrode" <rickenbrodehome.com>
Subject: Re: Serious new CA Drivers License ID RISK (Cornell, RISKS-21.29)

(really about Cal. Commercial Code section 4406)

While Mr. Cornell's concerns (RISKS-21.29) about the CA driver's license may
be well-founded, his message's partial quote of California Commercial Code
section 4406(d) leaves out important parts of the statute.

Cal. Com. Code 4406 provides a "safe harbor" to banks to allocate losses
from forgery onto customers who do not promptly report unauthorized
transactions on their account. So long as a bank provides its customers
with sufficiently detailed statement of account, the subdivisions of section
4406(a-c), which were not quoted in Mr. Cornell's message, create a duty
upon a bank customer to "exercise reasonable promptness" in examining their
bank statements to locate, and report, unauthorized transactions. If the
customer does not do this, the customer has not exercised ordinary care, and
thus, between the customer and the bank, the customer must bear the loss.
However, the quoted section (d) provides an additional protection for a
customer, even when failing in this duty, if the customer can prove that the
bank was also negligent in accepting the forgeries. In that case,
subdivision (e), a comparative negligence standard (e.g. customer 20%
responsible, bank 80% responsible), is used to apportion the loss.

This is not a new law. It was initially adopted in CA in 1965 as part of
the Uniform Commercial Code. A 1992 revision increased the time period of
subdivision (d)(2) from 14 to 30 days (which only fully applies when the
same wrongdoer makes successive transactions). The UCC section was itself
derived from prior statutes and case law concerning the allocation of loss
from forgery and a customer's duty to provide notice of unauthorized
transactions.

Source: Cal. Com. Code Section 4406 (Deering 2001).

The important point, which was not clear in Mr. Cornell's message, is that
if you don't promptly check your bank statement for unauthorized
transactions (and report any to your bank), you, not the bank, can be forced
to suffer the loss.

If you do suffer substantial losses from forgery, which your bank tries to
stick on you, reading the unannotated versions of statutes available on the
web are probably not going to constitute winning legal research: get a
lawyer.

I am not a lawyer. This information is presented for discussion purposes
only, not as legal advice.

John Rickenbrode <rickenbrodehome.com>

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

Date: 12 Feb 2001 (LAST-MODIFIED)
From: RISKS-requestcsl.sri.com
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 DIRECT E-MAIL REQUESTS to <risks-requestcsl.sri.com> with one-line,
   SUBSCRIBE (or UNSUBSCRIBE)
 which now requires confirmation to majordomoCSL.sri.com (not to risks-owner)
 [with option of E-mail address if not the same as FROM: on the same line,
 which requires PGN's intervention -- to block spamming subscriptions, etc.] or
   INFO [for unabridged version of RISKS information]
 .MIL users should contact <risks-requestpica.army.mil> (Dennis Rears).
 .UK users should contact <Lindsay.Marshallnewcastle.ac.uk>.
=> 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 risksCSL.sri.com 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.32
************************

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]