Risks Digest 22.76

[RISKS List Owner <risko () csl sri com>]

RISKS-LIST: Risks-Forum Digest  Friday 13 June 2003  Volume 22 : Issue 76

   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 http://www.risks.org as
  http://catless.ncl.ac.uk/Risks/22.76.html
The current issue can be found at
  http://www.csl.sri.com/users/risko/risks.txt

  Contents: Huge backlog, Seasonal slowdown beginning soon
Challenge to 'challenge-response' users: Be Careful! (NewsScan)
Phantom voting in Israeli Knesset (Ed Ravin)
Student hacks school, erases class files (PGN)
Canadian firearm registration system overwhelmed by traffic (swabsox 
  via Declan McCullagh)
Sea King Helicopter crash - fire control system deployment failure 
  (Stuart Lynne)
Computer glitch causes traffic lights malfunction (Teemu Leppänen)
Risks of trusting CORRECT dive computers and tables (Daniel P.B. Smith)
Electric utility direct-debit fiasco (Jonathan Kamens)
Incremental insecurity (Paul Wexelblat)
Re: ATM time sync (David Lesher)
Re: University of Calgary to teach virus writing (Nicholas Weaver,
  Dan Bornstein)
Denial of Service via Algorithmic Complexity Attacks: Crosby-Wallach
  (Monty Solomon)
REVIEW: "Mission Critical Security Planner", Eric Greenberg (Rob Slade)
Abridged info on RISKS (comp.risks)

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

Date: Mon, 09 Jun 2003 10:01:34 -0700
From: "NewsScan" <newsscan () newsscan com>
Subject: Challenge to 'challenge-response' users: Be Careful!

EarthLink has begun offering its 5 million subscribers "challenge and
response" technology set up to send a "challenge" to any message from an
unknown source, requiring that source to "respond" (and thereby supposedly
proving it's from a human being rather than a spammer or pornographer).  But
many people who hate spam are saying the cure is worse than the illness;
anti-spam consultant Steve Adkins warns, "It's sufficiently tempting that
people will use it and will not realize all the bad things that will begin
happening.  Challenge-response is very, very unfriendly and rude to
legitimate senders of e-mail." [AP/*Seattle Post-Intelligencer*, 9 Jun 2003;
NewsScan Daily, 9 June 2003]
  http://seattlepi.nwsource.com/business/125638_spamtech06.html

  [Note: If you sign up for challenge-response, then say goodbye to NewsScan
  Daily.  (The NewsScan editors)]  

    [And say goodbye to RISKS also (unless you set up an alias address for
    RISKS issues that does not challenge.  (We will never reveal it.)  PGN]

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

Date: Wed, 4 Jun 2003 17:44:15 -0400
From: Ed Ravin <eravin () panix com>
Subject: Phantom voting in Israeli Knesset

An investigation is going on in the Israeli Knesset (Parliament) on how
votes are being cast on behalf of parliamentarians who are absent from their
seats.  It seems that electronic voting has problems even in a controlled
environment like the floor of a parliament...

  Knesset probe fails to reveal who voted in Likud
  By Gidon Alon, Haaretz Correspondent

  A special committee set up by Knesset Speaker Reuven Rivlin, has failed to
  discover which MK was responsible for voting in place of Likud MK Inbal
  Gavrieli, who was not present in the Knesset plenum during a debate
  concerning the new budget plan, even though computer records indicate a
  vote was cast from her seat.
  Israel Radio reported several Likud MK's saying they had observed MK
  Yehiel Hazan (Likud) voting on Gavrieli's behalf. The vote was conducted
  electronically.

  The incident follows another case of double voting, in which MK Michael
  Gorlovski (Likud) admitted to having voted on behalf of another Likud MK,
  Gilad Erdan, also during the vote on the economic plan.

  http://www.haaretzdaily.com/hasen/pages/ShArt.jhtml
  ?itemNo=300587&contrassID=1&subContrassID=7&sbSubContrassID=0&listSrc=Y

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

Date: Thu, 12 Jun 2003 08:35:00 -0400
From: neumann () csl sri com
Subject: Student hacks school, erases class files

A 17-year-old student in a networking course was arrested for breaking into
his school's computers and erasing folders of other members of the junior
class at Marion High School, near Rochester NY.  He apparently was sniffing
passwords with keylogging software.  [The school's fix for this is to have
students change their passwords every 60 days, and force them to use
passwords with a ``combination of letters, numbers, and at least one special
character''.  Whoopee!  That sure solves the problem!  Sure stops the 
sniffer, which could be getting the new passwords as they are entered!!! PGN]
  http://www.cnn.com/2003/TECH/internet/06/10/school.hacked/index.html

  [One of our correspondents suggested that perhaps his charges will claim
  that his keylogging software is in the WMD category, and ask for a life
  sentence.  PGN]

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

Date: Fri, 06 Jun 2003 09:43:26 -0400
From: Declan McCullagh <declan () well com>
Subject: Canadian firearm registration system overwhelmed by traffic

> Date: Fri, 6 Jun 2003 08:41:33 -0600
> From: swabsox <swabsox () knology net>
> To: Declan McCullagh <declan () well com>
> Subject: ITBusiness.ca
>
> Gun registry backfires after system exceeds capacity:
>
>  The CFC's IT woes really aren't that different from any other government
> department's, said Wendy Cukier, president of the Toronto-based Coalition for
> Gun Control. She noted that government projects are frequently plagued by
> things like budget and capacity issues, but the amount of vocal opposition to
> the gun registry and made the CFC a flashpoint for controversy.
>
> "The system was built on the assumption that it would have something like 
> a 10% error rate and instead the error rate was 90 per cent. Some of that
> was because of the complexity of forms and some of that was deliberate" said
> Cukier, who's also a professor of information technology management at
> Ryerson University. "You'd be hard-pressed to find another program that faced
> such extensive efforts to undermine it."
>
> http://www.itbusiness.ca/index.asp?theaction=61&lid=1&sid=52538

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

Date: Wed, 4 Jun 2003 21:24:27 -0700
From: Stuart Lynne <sl () belcarra com>
Subject: Sea King Helicopter crash - fire control system deployment failure

An article in today's *National Post* related that, when a Sea King
helicopter crashed on the deck of a Canadian Forces Iroquis destroyer
earlier this year, the first two fire control systems failed and only the
third finally worked.

The article does not say why the first system failed, but the second failed
because of an obviously (well, perhaps in hindsight, obvious to RISKS
readers) poor design of the operators console:

  An operator in the control room then pressed a button to active the second
  system. Nothing seemed to happen. He pushed the button again and again --
  a total of six times -- but nothing happened.

  The operator "was not aware of the fact that as he repeatedly depressed
  the button to active the AFFF system, he was actually starting and
  stopping the system with every alternate push," a report from the
  subsequent technical investigation sayes.

  It also notes none of the indicator lamps on the system's console were
  working, so they did not light up when the button was pushed.

  And the crew may not have known about a 30-second delay from the the
  system is activated to the time the fire suppressant reaches the hose
  nozzle...

1. Poor design of a critical system. A toggle or second switch to disarm 
would have been a better choice perhaps.

2. Poor maintenance apparently leaving a critical system usable but not
apparently so when the operator wanted results right now.

3. Poor training so that the operator did not know what to expect when
activating the system.

Kudos that they did have a third fire control system that apparently was
deployed successfully.

Stuart Lynne <sl () belcarra com> 
Belcarra, Embedded Linux USB Software 604-461-7532

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

Date: Sat, 31 May 2003 11:25:24 +0300 (EEST)
From: Teemu Leppänen <teemulep () sun3 oulu fi>
Subject: Computer glitch causes traffic lights malfunction

In Oulu, Finland, computer glitch in central "traffic lights controlling"
computer caused traffic jams in city centre at 9am friday morning. The
computer transferred back to year 1991 and to night time (they did not
specify exact date and time), meaning some of the traffic lights were in
"night mode" and signaling "ignore me". Problem was solved in 90 minutes,
but the original cause of the glitch remains yet unknown. Authorities say
this was the first glitch ever experienced by the tax payers, also admitting
there has been "minor" ones before. Seems that the police was not used to
guide the traffic instead.

No accidents were reported, hence no need to clear the way for the emergency
medical teams.. perhaps with system which state is unknown, even requiring
reboot, or having technicians trying to fix the issue at the same time.

Original article (in Finnish) http://plus.kaleva.fi/html/JTpage321980.html

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

Date: Fri, 30 May 2003 23:15:39 -0400
From: "Daniel P.B. Smith" <dpbsmith () bellatlantic net>
Subject: Risks of trusting CORRECT dive computers and tables

Craig S. Bell submitted a note about dive computers with an alleged software
defect. Without minimizing the seriousness of the issue, or excusing the
alleged behavior of the manufacturer, I think there is another RISK as well.

The actual physiology and physical chemistry of decompression sickness isn't
understood precisely.  The models used to calculate dive tables and those
used in dive computers are rough.
http://www.theage.com.au/articles/2002/12/11/1039379882081.html 
cites a Dr. Gregory Emerson as saying, of decompression sickness, "We kind
of know why it occurs but we still don't really understand why some people
get it and other people don't."

A manual I downloaded from http://www.uwatec.com says that "Aladin Pro
Nitrox uses a new decompression calculation model known as the ZH-L8
ADT. This model uses eight compartments or 'tissue' groups with nominal half
time periods from 5 to 640 minutes." In another place, however, they make
the disclaimer "decompression modeling is an inexact science, and of
necessity must be based at least partly on certain unproven assumptions."
(I interpret this to mean that their "eight-compartment ZH-L8 ADT model" can
be regarded as an educated guess).

But even if the model were perfect, it would not be perfectly accurate
unless there were a way to measure the size of an individual diver's tissue
"compartments." The manual makes no reference to any way of matching the
device to the body characteristics an individual diver.  There is no way to
enter percentage of body fat, for example, let alone the other seven tissues
incorporated n the model.

And nitrogen is soluble in fat.  A person with more body fat will absorb
more nitrogen while breathing compressed air at depth, and release more of
it on ascent.  Thus, if two divers follow identical dive plans, their
computers will indicate the same results--but the diver with more fat will
be at greater risk for decompression sickness.

Uwatec's manual has a disclaimer for this, too: "each diver will vary in his
or her susceptibility to decompression sickness. Not only that, but each
individual diver's own susceptibility may vary from day to day."

These disclaimers need to be taken seriously.

A sufferer from decompression sickness
  http://www.photo.net/travel/diving/decompression-illness
says he was told that "85% of people treated for decompression illness
were diving within limits imposed by tables or a dive computer (i.e., most
people struck by DCI are following the rules)." Dr. Emerson in the article
cited above noted scuba divers can suffer from decompression sickness even
if they religiously follow diving tables.

A sample chapter from a 1997 book by Lawrence Martin, MD,
http://www.mtsinai.org/pulmonary/books/scuba/sectiong.htm goes into
considerable detail, but the bottom line is that "For a given
individual, [decompression sickness] is unpredictable."

How do divers behave? The article Bell cites about about the allegedly
defective computers,
http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2003/05/25/MN309974.DTL
says that a pair of divers who "surfaced... then checked their computers
to make sure another dive was safe. 'I look at Mitch's computer and look
at mine,' said Iazdi in his throaty Portuguese accent. 'I say, "We're
good."'"  

Dive computers have the intrinsic RISK of false precision.  They do
calculations with great precision that simulate sophisticated models and
take care of dozens of details.  Unfortunately, the correspondence between
the models and reality is crude.

Even without software flaws, divers are subject to the RISK of believing
something must be true just because it's a "computer" that said so.

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

Date: Tue, 20 May 2003 20:58:09 -0400
From: Jonathan Kamens <jik () kamens brookline ma us>
Subject: Electric utility direct-debit fiasco

Yet another direct-debit horror story....

Knowing that I was going to be out of town when my next electricity
bill came due, and not wishing to worry about having enough money in
my checking account to cover it while on vacation, I telephoned my
electric company (NSTAR) and asked them to suspend direct debit until
further notice.

They agreed, and indeed, the electricity bill which arrived while I
was on vacation said "please pay this bill" instead of "your account
will be debited on <date>."

Upon my return, I sent the electric company a check and then
telephoned them and asked for direct debit to be resumed as of my next
bill.  I was assured that payment for the bill which arrived while I
was on vacation would not be debited from my account.

Two weeks later, when my next bill arrived, I discovered that the
payment was, in fact, debited from my account.  Thus I had paid twice
for the same bill, and NSTAR was holding onto over $100 of my money to
which they were not entitled.  As luck would have it, I didn't bounce
any checks because of this, but I could have done so easily.

An additional wrinkle is that despite the fact that the total amount
due on the new bill was less than the overpayment, the bill still
claimed that they would be taking money from my checking account,
apparently because when they received my overpayment, they applied all
of it as an NSTAR credit and none of it to the supplier half of the
bill (I use a third-party electricity supplier).

I contacted the electric company by E-mail and asked them to return
the money to me.  First, they said that they could only refund the
difference between the debit and how much I owed on the new bill,
despite the fact that the amount on that bill was not actually due for
two more weeks.  When I responded that this was unacceptable, they
agreed to refund the entire debit amount, but said that it would take
two to three weeks for a check to be issued.  I said that, too, was
unacceptable -- they had no right to that money in the first place,
and they should immediately either reverse the debit or issue me a
check and send it via overnight delivery.  They refused.  I instructed
them to immediately and permanently disable direct debit on my
account.

I also informed them that I would not be sending any money in response
to the new bill, because I had a credit balance greater than the total
amount owed, and it was up to them to ensure that the appropriate
amount was transfered from that balance to the third-party supplier.
They responded that this would happen correctly as a matter of course,
i.e., that even though my bill told me to pay the third-party supplier
balance, I didn't really need to do so.  This is not the first time
that the amount due given on my NSTAR bill was different from what
they actually debited.

There are many risks here, including:

* It should be impossible for their billing system to debit an account
  to satisfy an unpaid balance after sending the customer a bill
  instructing him to pay the bill manually.

  Other utilities in my area get this right.  If the bill they send
  you says "please pay," then you need to pay it, regardless of
  whether you activate direct debit between when you receive the bill
  and when it is due.

* It should be impossible for their billing system to tell the
  customer that an amount will be debited automatically and then, with
  no prompting from the customer, debit a different amount or no
  amount at all.

  Putting it another way, the bill that gets sent to the customer
  should be correct (what a concept!).

* The billing system should have safeguards in place to automatically
  detect double payments and bounce them to a human for handling
  (e.g., contacting the customer and/or sending a refund for the
  overpayment).

* They should have procedures in place for reversing unauthorized
  debits promptly.  The only things preventing them from doing this
  are bureaucracy and an inadequate billing system.  It is
  unreasonable for them to allow these to get in the way of promptly
  returning money that they stole from customers.

* The billing system should know how to reconcile credit balances with
  monies owed to third-party suppliers.

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

Date: Fri, 30 May 2003 20:04:43 -0400
From: Paul Wexelblat <geezer () diapensia com>
Subject: Incremental insecurity (Re: Cohen and Weiss, RISKS-22.75)

RISKS-22.75 had a couple of entries that illustrate another RISK:
* ISP resets password to an easily guessed one (Dawn Cohen)
* Sensitive data on Web sites reflects lack of security awareness (Rick Weiss)

They point out the insidious problem of secure systems spontaneously
becoming insecure through no action of the user.  This means that, no matter
how safe and secure any service that has your info may be now, tomorrow they
may change their system or be bought out -- as illustrated in the two cases
above.

What are the chances that either of these outfits will be either willing or
able to remove the compromised data?

...and what are the odds that complaints of violation of privacy statements
will be met with a claim that the "privacy statement" includes a term
equivalent to "we reserve the right to make any change we want to to these
terms at any time without notice"?

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

Date: Tue, 3 Jun 2003 10:01:40 -0400 (EDT)
From: David Lesher <wb8foz () nrk com>
Subject: Re: ATM time sync (RISKS-22.73)

The arrest of the wrong party based on defective "money machine" timestamps
has also occurred in the District of Columbia.

> From memory, there was brutal murder and the victim's card had been used
after the time of death. The ATM camera's photo got wide play on TV and in
the newspapers. The person pictured surrendered with his attorney AND the
receipt from his girlfriend's card; he had used it with her permission.

Despite that evidence and an alibi; he was still jailed for about a week
before the US Attorney would relent.

I would think there would be the potential for substantial civil litigation
against the bank, the ATM network and the machine manufacturer in these
cases. Judgments often have the effect of spurring correction of the design
errors...(Another RISK, perhaps -- {system} validation by verdict?)

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

Date: Fri, 30 May 2003 17:44:47 -0700
From: Nicholas Weaver <nweaver () CS berkeley edu>
Subject: Re: University of Calgary to teach virus writing (Brunnstein, R-22.75)

I have to strongly second Klaus Brunnstein's comments in comp.risks
concerning http://www.cpsc.ucalgary.ca/News/virus_course.html

As a researcher who has analyzed existing worm strategies and developed
novel strategies (warhol worms, metaserver worms) and plausible defenses, I
find the notion of actual virus and worm writing as part of the educational
and research process both abhorrent and of effectively NO value.

For evaluating propagation behavior, simulation, "on-paper" evaluations, and
analysis of previous worms can tell us effectively all we need to know: How
worms and viruses spread, how they interact with many existing and possible
defenses, and some requirements (such as automatic reactions) required to
build robust defenses.

Simulation predicted the possibility of very fast worms and many of the
requirements for automated defenses.  Paper analysis insures that I will
never run KaZaA myself (the recent vulnerability could be used to take out
all supernodes in probably less than <2 minutes).  And analysis gives us a
treasure-trove of what works well for malicious coders, such as how to cross
firewalls and enter local Windows domains.

There are some surprises which come up, such as Slammer/Sapphire's speed,
but these are second-order effects.  Sapphire was still a scanning worm, so
automated defenses which could stop a 1 hour scanning worm should stop a
Sapphire-esque worm.  Likewise, there are numerous other techniques
(Hitlisting & permutation scanning, topological, metaserver) which can
create worms that spread to all vulnerable hosts in roughly the same
timeframe.

Likewise, to evaluate the defenses themselves, existing attacks can often
been used as long as the defense hasn't been pre-trained.  For worms which
exploit security vulnerabilities, such as Code Red, these are no longer
threats, as effectively all vulnerable machines have been patched and
effectively all of the remaining machines are infected.

And, if existing attacks, paper design, and simulation are all insufficient
to evaluate a defense-mechanism, the best solution is to create daemon
programs which run on test machines and who's behavior (eg, system calls,
network communication) MIMICS the behavior of a worm when communicating with
other copies of the program, as such program can not spread beyond the test
machine.

There is room for a good course on malicious code and defenses, but it need
not, and should not, include construction of self-propagating programs
(worms or viruses).

I do not need to write worms to understand the problem, construct, and
evaluate defenses.

Nicholas C. Weaver                                 nweaver () cs berkeley edu

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

Date: Fri, 30 May 2003 16:37:06 -0700
From: Dan Bornstein <danfuzz () milk com>
Subject: Re: University of Calgary to teach virus writing (Brunnstein, R-22.75)

I'm willing to give the U of C the benefit of the doubt here. 

Many years ago I had a lot of fun writing programs for a game called Core
Wars.  The idea of the game (for those unfamiliar with it) was that your
program and an opponent's program get loaded into a single "core" and the
goal is for your program to subvert the other one such that the only threads
of execution left are ones that your program initiated.

This was (a) educational, (b) fun, and (c) arguably a helluva lot like
virus-writing. I don't think writing code for Core Wars games is immoral,
nor do I think it should be illegal; and I'd be hard pressed to tell you the
difference between doing that and writing any other code for use in a
controlled, quarantined computing environment, such as is proposed for the
course.

  [When I was at Bell Labs in the early 1960s, there was a version of
  core wars that ran on the IBM 70x machines.  Doug McIlroy, Vic Vyssotsky,
  and perhaps Bob Morris will certainly remember that one.  PGN]

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

Date: Sat, 31 May 2003 10:22:56 -0400
From: Monty Solomon <monty () roscom com>
Subject: Denial of Service via Algorithmic Complexity Attacks

Denial of Service via Algorithmic Complexity Attacks
  Scott A. Crosby <scrosby () cs rice edu>
  Dan S. Wallach <dwallach () cs rice edu>
  Department of Computer Science, Rice University

We present a new class of low-bandwidth denial of service attacks that
exploit algorithmic deficiencies in many common applications' data
structures. Frequently used data structures have ``average-case'' expected
running time that's far more efficient than the worst case. For example,
both binary trees and hash tables can degenerate to linked lists with
carefully chosen input. We show how an attacker can effectively compute such
input, and we demonstrate attacks against the hash table implementations in
two versions of Perl, the Squid web proxy, and the Bro intrusion detection
system.  Using bandwidth less than a typical dialup modem, we can bring a
dedicated Bro server to its knees; after six minutes of carefully chosen
packets, our Bro server was dropping as much as 71% of its traffic and
consuming all of its CPU. We show how modern universal hashing techniques
can yield performance comparable to commonplace hash functions while being
provably secure against these attacks.

http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003/index.html
http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003.pdf

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

Date: Tue, 3 Jun 2003 12:00:58 -0800
From: Rob Slade <rslade () sprint ca>
Subject: REVIEW: "Mission Critical Security Planner", Eric Greenberg

BKMSCRSP.RVW   20030330

"Mission Critical Security Planner", Eric Greenberg, 2003,
0-471-21165-6, U$35.00/C$54.95/UK#25.95
%A   Eric Greenberg
%C   5353 Dundas Street West, 4th Floor, Etobicoke, ON   M9B 6H8
%D   2003
%G   0-471-21165-6
%I   John Wiley & Sons, Inc.
%O   U$35.00/C$54.95/UK#25.95 416-236-4433 fax: 416-236-4448
%O  http://www.amazon.com/exec/obidos/ASIN/0471211656/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/0471211656/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0471211656/robsladesin03-20
%P   416 p.
%T   "Mission Critical Security Planner"

In the introduction, Greenberg claims that his book provides guidance
on how to do quantitative security planning without calculations
(which sounds somewhat self-contradictory) using a new technique he
calls impact analysis (which doesn't sound too different from business
impact analysis).  A technical background is said to be unnecessary,
the process is worksheet based, and the target audience is security
managers.

Chapter one says that protecting information is not exact (a statement
that doesn't seem to fit well with the worksheet approach).  Random
security topics include planning, intruders, and a risk analysis
example which is, ironically in view of the introduction, more
computationally intensive than most.  An overview of planning, in
chapter two, majors on the minors.  Policies are not discussed until
twenty five pages into the material, and then the emphasis is on very
specific areas like exit (termination of employment) procedures,
leaving huge topics uncovered.  Twenty eight security elements are
listed, and all are important, but almost all are either over-vague or
over-specific.

Chapters three and four introduce the worksheets themselves.  Sixteen
topic areas have four sheets each, dealing with the technical,
lifecycle, business, and "selling to management" aspects of the
themes, while other domains may have only a single sheet.  The
questions listed may be helpful as reminders to address certain
aspects which are often overlooked, but the odd and arbitrary
structure is confusing, and the real work is definitely left as an
exercise to the reader.

A description and analysis of PKI (Public Key Infrastructure), in
chapter five, is vague and weak, and contains much unrelated material. 
Chapter six is a recap of the book, along with a simple list of
threats.

While the advice in the book is not wrong or misleading, and many
important and useful points are buried throughout, poor organization,
a lack of consistent depth, and gaps in topical coverage ensure that
the text would only poorly repay the investment of time spent studying
it.  Certainly it should not be used as a major guide to structure the
security planning process.

copyright Robert M. Slade, 2003   BKMSCRSP.RVW   20030330
rslade () vcn bc ca  rslade () sprint ca  slade () victoria tc ca p1 () canada com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

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

Date: 30 May 2003 (LAST-MODIFIED)
From: RISKS-request () csl 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 e-mail requests to <risks-request () csl sri com> with one-line body
   subscribe [OR unsubscribe]
 which requires your ANSWERing confirmation to majordomo () CSL sri com .
 If Majordomo balks when you send your accept, please forward to risks.
 [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.
   .UK users should contact <Lindsay.Marshall () newcastle ac uk>.
=> 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  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 risks () CSL sri com with meaningful SUBJECT: line.
=> ARCHIVES: http://www.sri.com/risks
 http://www.risks.org redirects you to the Lindsay Marshall's Newcastle archive
 http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., 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/ .
 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 22.76
************************