Risks Digest 21.87

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

RISKS-LIST: Risks-Forum Digest  Saturday 19 January 2002  Volume 21 : Issue 87

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

  Contents:
Exploding chips: Would you like to be fried with that? (Rob Slade)
Hospital tells elderly men they're pregnant (Arthur Goldstein)
Automated Debit: "There's nothing we can do to stop it." (Carl Fink)
Even unscientific elections get rigged (Jeremy Epstein)
The risks of standards and validators (Lindsay Marshall)
Buffer overflows and other stupidities (Earl Boebert)
Windows update server glitch (Mike Hogsett)
An outrageous violation of privacy (Fred Cohen)
Risks of Internet Reconfigurable Logic (John Gilliver)
Linked DMV databases and biometrics on driver's licenses (Ben Rosengart)
Facial recognition technology doesn't work (Nick Brown)
Honolulu speed camera risk: mainly human error (Dan Birchall)
AOL Buddy-Hole fix has backdoor (Robert Andrews)
Reinventing snake oil: compression (Jeremy Epstein)
Re: Airplane takes off without pilot (Paul Nelson)
Re: Software glitch grounds new Nikon camera (Nickee Sanders)
Re: Kaiser Permanente exposes medical record numbers (Geoff Kuenning)
Re: ING bank debits wrong sum from accounts (Paul van Keep)
REVIEW: "Counter Hack", Ed Skoulis (Rob Slade)
Abridged info on RISKS (comp.risks)

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

Date: Thu, 17 Jan 2002 08:58:01 -0800
From: Rob Slade <rslade () sprint ca>
Subject: Exploding chips: Would you like to be fried with that?

 From NewsScan Daily, 17 January 2002:

> EXPLODING CHIPS COULD FOIL THIEVES
> Researchers at the University of California in San Diego have developed a 
> way to blow up silicon chips using an electric signal --

Now, at this point I was willing to dismiss this as the stuff of fiction.
You all know how computers in books and movies always "blow up real good"
when the bad guy plants a virus or something in them.  However:

> an innovation that could be used to fry electronic circuitry in devices
> after they're stolen or fall into the wrong hands. The American spy plane
> that was impounded in China last year is an example where such technology
> would have proven handy in destroying its secret electronics systems.

OK, this make a bit more sense.  Obviously these are chips that are
specifically designed to blow up once they receive a certain signal.

At this point, though, you start to think about what kind of signal that
could be.  And, could it be counterfeited?

> Similarly, if a cell phone were stolen, the owner could alert the wireless
> carrier, which would send a signal to trigger a small explosion in the
> phone's chip, rendering it useless. The techniques uses a small amount of
> the oxidizing chemical gadolinium nitrate applied to a porous silicon
> wafer. (New Scientist 16 Jan 2002)
>   http://www.newscientist.com/news/news.jsp?id=ns99991795

OK, I am definitely certain that, if I need to get a new cell phone from now
on, I am *definitely* not going to carry it in my pants pocket.  The RISKS,
as have been frequently noted here, are obvious.

(If we could get them to use those chips in pacemakers, wouldn't that just
make a killer application, Peter?)

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

  [I normally delete all trailer quote.  But this one from another message
  from Rob is rather fascinating:
    A modern US Navy cruiser now requires 26 tons of manuals.
    This is enough to affect the vessel's performance.
      -- `New Scientist' article on the paperless office
  PGN]

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

Date: Fri, 11 Jan 2002 04:19:19 +0000
From: arthur.goldstein () att net
Subject: Hospital tells elderly men they're pregnant

The Chesterfield and North Derbyshire Royal Hospital admitted on 10 Jan that
it had mistakenly sent computer generated letters to 30 patients, including
six elderly men, telling them they were pregnant.  The system operator was
blamed for choosing the wrong option (instead of informing them that their
operations had been postponed).  [Reuters, 10 Jan 2002, PGN-ed]
  http://news.excite.com/article/id/65168
  |oddlyenough|01-10-2002::11:30|reuters.html  [SPLIT URL]

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

Date: Wed, 16 Jan 2002 14:02:08 -0500
From: Carl Fink <carl () fink to>
Subject: Automated Debit: "There's nothing we can do to stop it."

A Georgetown, TX man who had arranged for his water bill to be automatically
debited from his bank account alertly noticed that his monthly bill was for
over $21,000.  (If he hadn't noticed, the debit would have happened, causing
him to bounce multiple checks before the error was corrected.)  When he told
the city of the problem, "They said there was absolutely nothing they could
do to stop the automated debit, and it was out of their hands."  Their
solution was to send a city employee with a check for $21,000 to reimburse
their customer!
  http://www.austin360.com/statesman/editions/tuesday/metro_state_1.html

Risks?  Lack of sanity checking on a new billing system springs to
mind.  Lack of any way to correct errors is also quite prominent.

Carl Fink, Manager, Dueling Modems Computer Forum  http://dm.net/ carlf () dm net

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

Date: Wed, 9 Jan 2002 16:28:26 -0500
From: "Jeremy Epstein" <jepstein () webmethods com>
Subject: Even unscientific elections get rigged

ZDNet is doing a poll on whether J2EE or .NET is more important for Web
services.  Although it's a totally unscientific poll, they've set things up
to try to detect (and stop) ballot stuffing.  It seems that Microsoft hasn't
understood the concept, and employees are trying to vote repeatedly,
including automated voting.
  http://news.zdnet.co.uk/story/0,,t269-s2102244,00.html

The risk of believing unscientific polls is nothing new, but the combination
of electronic polls that can be stuffed with the herd mentality that may
influence buying greatly increases the risks.

  [*The Register* noted that 21.5% of the respondents said they would
  use .Net, 46% Java -- until a surge of votes came in from microsoft.com,
  some of which were apparently stimulated by internal MS e-mail saying
  "PLEASE STOP AND VOTE FOR .NET!".  PGN]

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

Date: Fri, 11 Jan 2002 13:16:36 -0000
From: "Lindsay Marshall" <Lindsay.Marshall () newcastle ac uk>
Subject: The risks of standards and validators

This week I ran a page of the RISKS Web site through the W3 html validator,
as I do on a regular basis -- it keeps me clean and legal.  It complained
that I didn't have a charset specification, so I added one as it suggested.
This appears to cause some netscape 4.7 browsers some problems -- I had
complaints that the text was vanishingly small, and also that it was vastly
increased in size.  Presumably a typeface selection that is hard-wired
somewhere, and that nobody is told about.  Anyway, I've taken out the
charset setting for the moment.

http://catless.ncl.ac.uk/Lindsay

  [Lindsay runs our UK redistribution and the excellent RISKS Web site --
  for both of which I am most grateful.  I'm delighted to take the
  opportunity to thank him once again!  PGN]

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

Date: Mon, 14 Jan 2002 10:07:55 -0700
From: Earl Boebert <boebert () swcp com>
Subject: Buffer overflows and other stupidities

  "I used to be disgusted, now I try to be amused."  -- Elvis Costello
  "What a stupid robot." -- Marvin the Paranoid Android

In my view, attempts to close the buffer overflow vulnerability through
software or compiler tricks are doomed to one degree of failure or another
because you're trying to program around a stupid processor design.  Certain
contemporary processors actually host a Pantheon of stupidities, consisting
of a Greater Stupidity and two handmaiden Lesser Stupidities.

Greater Stupidity: Read access implying execute access. Any piece of data
that the processor can be tricked into loading into the command register
immediately becomes code. This is a stupidity of such breadth and depth that
it comes with an event horizon.

Lesser Stupidity I: Segmented addressing that isn't. Let's say you have an
addressing scheme consisting of segment number plus offset. This raises the
question of what to do when, in executing code, block moves, etc., the
offset gets counted up to maximum length plus one. Smart answer: take a
fault. Dumb answer: set offset to zero and count up one in segment number.

Lesser Stupidity II: Brain-dead stack design. If you enumerate the design
space of dynamic storage management, you may realize that one actually has
to *work* to produce a stack design so dumb that overflow attacks are
possible. Here are four classes of designs that are immune to the
vulnerability:

1. Descriptor stacks.  The only thing that goes in the stack are addresses,
preferably with a bounds value attached. Overflow a buffer and at worst you
clobber the heap. Penalty: one level of indirection, which (The Horror! The
Horror!) may cause your dancing pigs to dance slower than the other
guy's. Possibility: can be fitted transparently to existing processor
designs, assuming anybody cared.

2. Stack per protection domain. This assumes you can find the perimeters of
your protection domains. Also slows down dancing pig displays because of
copying parameters from stack to stack.

3. Separate control and data stacks. CALL/RETURN works the control stack,
PUSH/POP works the data stack. Doh.

4. Error-checking stacks. A whole raft of options, including "shadow stacks"
with checksums, return addresses protected with trap bits, etc. etc.

So, if it's all so straightforward and well known, why hasn't some vendor or
other fixed it?  Answer: the dancing pigs have won.

  [Ah, yes.  Earl is tacitly recalling the good old days of Multics
  (beginning in 1965) and its progenies (SRI's object-oriented Provably
  Secure Operating System design 1973--1980, and the Honeywell/Secure
  Computing Corporation type-enforced systems), all of which took care of
  this problem and so many others so long ago.  But with today's badly
  designed bloatware, the dancing pigs are increasingly becoming 700-pound
  porkers that can barely move around the pigsty without massive memory
  and processing power, and whose pigpen could not even contain them if
  they were in reality Trojan pigs.  PGN]

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

Date: Tue, 15 Jan 2002 14:48:14 -0800
From: Mike Hogsett <hogsett () csl sri com>
Subject: Windows update server glitch

A glitch in Microsoft's server software has left some users unable to
download important security patches and other fixes for Windows software
since last Thursday.

  http://www.cnn.com/2002/TECH/internet/01/15/microsoft.security.server.ap/index.html

  http://www.cnn.com/2002/TECH/internet/01/15/
  microsoft.security.server.ap/index.html   [SPLIT]

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

Date: Sun, 13 Jan 2002 10:27:20 -0800 (PST)
From: Fred Cohen <fc () all net>
Subject: An outrageous violation of privacy

I just saw a piece on MSNBC where they prominently featured the face of a
man who helped someone out of the WTC on 11 Sep 2001 -- and just because
they don't know who the man is, they have created a composite picture of him
and posted him as if he were a wanted man on the national news.

Now I understand their desire to make human interest stories go, but I think
it is outrageous to take the image of a person and smear it all over
national TV, creating a manhunt for someone, when all the person did was to
help someone else out in a public place.

If I were this man, I would sue them for as much as I could get and do all I
could to try to recover what semblance of privacy I might barely still have
left after being exposed on national TV without my permission.

Is this all we have left of our privacy?

Fred Cohen http://all.net/ Fred Cohen & Associates tel/fax:925-454-0171
Sandia National Laboratories 1-925-294-2087  University of New Haven 

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

Date: Tue, 08 Jan 2002 16:40:35 +0000
From: john.gilliver () baesystems com
Subject: Risks of Internet Reconfigurable Logic

  ... "For example, IRL (Internet Reconfigurable Logic) means that a new
  design can be sent to an FPGA in any system based on its IP address."
  (From Robert Green, Strategic Solutions Marketing with Xilinx Ltd., in
  "Electronic Product Design" December 2001.  Xilinx is a big manufacturer
  of FPGAs.)

For those unfamiliar with the term, FPGA stands for field-programmable logic
array: many modern designs are built using these devices, which replace tens
or hundreds of thousands of gates of hard-wired logic.

The RISKs involved are left as an exercise to the readers ...

J. P. Gilliver, BAE SYSTEMS Advanced Technology Centre, 
West Hanningfield Road, GREAT BADDOW, Essex, CM2 8HN, UK  +44 1245 242133

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

Date: Wed, 9 Jan 2002 17:38:14 -0500
From: Ben Rosengart <ben+risks () narcissus net>
Subject: Linked DMV databases and biometrics on driver's licenses

*Time Magazine* is reporting that the federal Department of Transportation,
by instruction of the Congress, is working to link together the states'
driver databases, and also to introduce biometric security on drivers'
licenses.

http://www.time.com/time/nation/article/0,8599,191857,00.html

RISKS include false arrest due to database screwups, abuse for personal
reasons by government personnel, abuse by the government itself, all the
RISKS known to be associated with biometrics, disclosure of the databases to
the public, and probably much, much more.

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

Date: Wed, 9 Jan 2002 11:38:39 +0100 
From: Nick Brown <Nick.BROWN () coe int>
Subject: Facial recognition technology doesn't work

An article by the ACLU at
  http://www.aclu.org/issues/privacy/drawing_blank.pdf reveals that a
highly-publicised facial recognition system has been quietly dropped by law
enforcement officials in Tampa, Florida, following a large number of false
positives (including males identified as females, and vice versa) and a
total of zero matches against known criminals, leading to zero arrests.

Aside from the already-discussed civil liberties RISKs of such systems, it
seems we need to add the possibility that the taxpayers may not be getting
value for money, with or without their knowledge (the withdrawal of this
kind of thing tends to be done with rather less media coverage than its
introduction).  One wonders if this will have any effect on plans to
introduce such systems into airports to "detect" terrorists.

Nick Brown, Strasbourg, France

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

Date: Wed, 9 Jan 2002 22:52:58 -1000
From: Dan Birchall <djb () nospam danbirchall com>
Subject: Honolulu speed camera risk: mainly human error

After much debate, and general wailing and gnashing of teeth from those who
like to drive fast, the powers that be here in Honolulu have a private
contractor operating cameras to photograph vehicles which speed or run red
lights.  After the license number, time, and location of the violation are
verified, a citation is mailed.

In their first day of operation, the cameras caught 927 speeders.
  http://starbulletin.com/2002/01/03/news/index1.html

However, more than 80% were unenforceable due to human errors in operation
of the cameras - poor aim, inaccurate location recording, etc.
  http://starbulletin.com/2002/01/08/news/index4.html

On the bright side, people do seem to be speeding less since the cameras
started working.

http://danbirchall.com/

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

Date: Wed, 9 Jan 2002 12:19:10 -0400
From: "Robert Andrews @ PrivacyExposed.com" <Robert () PrivacyExposed com>
Subject: AOL Buddy-Hole fix has backdoor

"A member of w00w00, the security enthusiasts who first reported the AOL
Instant Messenger (AIM) games request vulnerability, has alerted users that
a fix the group recommends has its own backdoor.  Apparently, the AIM Filter
by Robbie Saunders which w00w00 had recommended is infected, group member
Jordan Ritter disclosed on the Bugtraq mailing list late Tuesday. "At the
time, Robbie Saunders' AIM Filter seemed like a nice temporary solution.
Unfortunately, it instead produces cash-paid click-throughs over time
intervals and contains backdoor code combined with basic obfuscation to
divulge system information and launch several Web browsers to porn sites,"
Ritter wrote."  [...]  Thomas C Greene, *The Register*
http://www.theregister.co.uk/content/4/23596.html

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

Date: Wed, 9 Jan 2002 16:13:31 -0500
From: "Jeremy Epstein" <jepstein () webmethods com>
Subject: Reinventing snake oil: compression

Snake oil is on the rise.  Latest to join the fray is Zeosync
(www.zeosync.com), which announced on 7 Jan 2002 that they have new
algorithms that can provide 100:1 lossless data compression over
"practically random" data.  (What they mean by "practically" isn't defined.)
Lots of criticism and proofs that it's impossible in Slashdot
  http://slashdot.org/article.pl?sid=02/01/08/137246&mode=thread
and elsewhere.  So far the algorithms haven't been given, except to provide
the single longest stream of buzzwords I've seen in a long time.  The one
part that says it might not be 100% snake oil is that they have a Fields'
Prize winner as one of the participants.

The risk here is that they've added enough buzzwords to the announcement
that some people might actually believe it.  The media doesn't seem very
skeptical, which they should be.  Reuters quoted David Hill, an analyst with
Aberdeen Group as saying "Either this research is the next 'Cold Fusion'
scam that dies away or it's the foundation for a Nobel Prize. I don't have
an answer to which one it is yet."  Others have been much more willing to
figure out which way it's going.  Remember the 1999 story about the
16-year-old Irish girl whose new form of cryptography would revolutionize
the world?

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

Date: Mon, 7 Jan 2002 15:20:53 -0600
From: pnelson () sauer-danfoss com
Subject: Re: Airplane takes off without pilot (Klein, RISKS-21.84)

There are many aircraft which have no starters (or electrical system, for
that matter)- commonly antique or classic small, one- or two- place planes
like the 1947 Aeronca Champ that was the subject of this item. There are
well-known safety precautions which go along with starting them- one of the
oldest is that there should be someone in the cockpit with feet on the
brakes, operating the magneto switches and throttle while a second person
"props" the plane to start it. (The classic shouts "CLEAR!", "CONTACT!",
"SWITCH OFF!", "BRAKES", "THROTTLE BACK AND CRACKED!" come to mind.)

If a plane like this is to be started by one person, the accepted
precaution is to tie the tailwheel to a stationary object, turn the fuel
OFF so that only the small amount in the carburetor bowl is available, and
then make CERTAIN that the throttle is only cracked open a small amount.
I've started my 1946 Cessna 140 in this manner many times when the battery
happened to be run down.

All that being said, incidents like this still happen when people try to
take shortcuts. It shouldn't have happened!

Paul Nelson, Senior Engineer, Sauer-Danfoss Company, Ames, IA  515-239-6614

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

Date: Wed, 9 Jan 2002 12:10:32 +1300
From: Nickee Sanders <njs () ihug co nz>
Subject: Re: Software glitch grounds new Nikon camera (Gillett, RISKS-21.85)

Our first digicam was also a Kodak.  When the battery voltage was low enough
(and it happened suddenly), the camera would simply stop responding to *any*
user actions whatsoever.  It didn't even do a power down.  The only way to
clear this condition was to take the batteries out for a number of hours;
after this, on insertion of fresh batteries, the camera would power down and
then could be powered up again.

The first time this happened it was pretty scary.  One minute we were
snapping away; the next minute the camera was frozen, with the lens fully
extended (and thus the lens cap wouldn't stay on it).  The local service
reps knew nothing of this error condition and could only offer to send it to
Australia (from New Zealand) for servicing, which would take several weeks.
We figured out by trial and error how to solve it ourselves.

Nickee Sanders, Auckland, New Zealand

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

Date: Mon, 14 Jan 2002 13:09:28 -0800
From: Geoff Kuenning <geoff () cs hmc edu>
Subject: Re: Kaiser Permanente exposes medical record numbers (Debert, R-21.86)

J. Debert writes about an insecure Web page at http://www.kponline.org.

It happens that my best friend works for Kaiser Permanente's IT department,
so I forwarded the message to her.  As a result of discussions and
exploration, I think that the alleged risk does not in fact exist.

The claim was that medical-record numbers were being exposed during the
signon process.  However, in viewing the source of the referenced Web page,
it appears that the "sign on" button makes an https (SSL) connection.  Thus,
although the "padlock" icon in the browser is unlocked, anything sent from
that page is in fact sent using SSL.

I have recommended that Kaiser change their main page so that it forwards
the browser to an SSL equivalent, solely so that the padlock icon will
appear locked.

I think that the true RISK is not in Kaiser's Web page, but rather in the
browser.  The "padlock" icon reflects not whether the page SENDS information
securely, but rather the fact that the page was FETCHED securely.  This
disconnect between what is shown and what is expected has been raised
recently by Jeff Mogul in the converse direction: a page that had the
padlock proceeded to send information insecurely.

The first problem (apparently insecure page is actually secure) can be
patched around with the forwarding kludge I mentioned above.  The second can
be handled by the user to some extent (certain browser settings can warn you
when you transition from a secure page to an insecure one).  However, the
true problem is in browser design.  The "padlock" icon should be associated
with a LINK, not a page.  Regardless of how it was fetched, if a page
contains both secure and insecure links, the lock should be shown as
unlocked and should lock only when you mouse over a secure link.  Only if
all outgoing links from a page are secure should the padlock be permanently
displayed in its locked form.

    Geoff Kuenning   geoff () cs hmc edu   http://www.cs.hmc.edu/~geoff/


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

Date: Wed, 9 Jan 2002 11:04:45 +0100
From: Paul van Keep <paul () sumatra nl>
Subject: Re: ING bank debits wrong sum from accounts

Several people have pointed out that I was wrong in my statement about
disproving a 10000 euro cash withdrawal would be tough. Banks have a sane
upper limit on the amount of cash you can withdraw from an ATM, even at your
own branch. That limit is somewhere below 2000 euro. A 10000 euro ATM
transaction is therefore totally impossible.

Paul van Keep

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

Date: Mon, 14 Jan 2002 07:34:47 -0800
From: Rob Slade <rslade () sprint ca>
Subject: REVIEW: "Counter Hack", Ed Skoulis

BKCNTRHK.RVW   20011023

"Counter Hack", Ed Skoulis, 2002, 0-13-033273-9, U$49.99/C$75.00
%A   Ed Skoulis
%C   One Lake St., Upper Saddle River, NJ   07458
%D   2002
%G   0-13-033273-9
%I   Prentice Hall
%O   U$49.99/C$75.00 800-576-3800 416-293-3621
%P   564 p.
%T   "Counter Hack"

Chapter one, as in many texts, is an introduction to the book, but is
unusually important in this case.  First, Skoulis lays out the philosophy
behind the work.  While the text of the book does concentrate on attacks,
the author points out that invaders already have other sources of
information.  Further, Skoulis proposes that a detailed, complete, and
integrated examination of representative samples of classes of attacks will
provide an outline of defensive measures that can protect against a wide
variety of assaults.

A second point in this introduction is a brief examination of the character
of attackers.  Skoulis does point out that those who attempt to penetrate
computer and communications security do so from a diversity of motivations
and skill levels.  However, he does tend to overstress the participation of
"professional hackers," proposing that industrial espionage, terrorism, and
organized computer crime activities are common.  Certainly such campaigns
may become common, making the need for pre-planning even more important, but
the vast majority of endeavors we are seeing at present are amateur efforts.

Finally, the introduction recommends the establishment of a computer
security test laboratory, which is an excellent idea for any large
corporation, but probably is not within the financial, personnel, or
educational reach of even medium sized businesses.

Chapter two provides a background in TCP/IP for the purposes of discussing
networking offence and defence.  There are frequent forward references to
later sections of the book that deal with network attacks.  The material
could, however, have been condensed somewhat to emphasize those aspects of
the protocols that are closely related to security.  UNIX and Windows (NT
and 2000) are similarly covered in chapters three and four, and, again, the
text could be tightened up by focusing on safety factors.

Chapter five points out the ways in which people can obtain data in order to
direct and mount an attack.  While the content is informative, and there are
a  few suggestions  for restricting  the release  of such  intelligence, the
defensive value of  the text is limited.  The  information gathering process
continues  in chapter  six with  war dialling  and port  scanning.  Defences
against application  and operating system  attacks are covered a  bit better
than  in most  "hacking" books  (there are  descriptions of  buffer overflow
detection  tools),  but the  protective  value  of  chapter seven  is  still
questionable.  Chapter eight  examines network sniffing, scanning, spoofing,
and hijacking.  Denial of service  is covered well in chapter nine.  Various
examples of malware are described in chapter ten.  Chapter eleven deals with
the means used to hide an attack.

A number of scenarios are created in chapter twelve.  Chapter thirteen
describes some resources for keeping up with the latest computer
vulnerabilities.

Recently there has been a flood of books to the security marketplace, all
based on the premise that if you know how to attack a system, you will know
how to defend it.  Skoulis has done a better job than most, but the thesis
is still unproven.  Yes, knowledge of the details of an attack does help you
fine tune your defence.  Yes, providing specifics of an example of a class
of attacks does help you consider a protective mechanism that might work
against a whole class.  Yes, Skoulis does recommend safeguards for most of
the attacks listed.  But taking a crowbar to a padlock still doesn't teach
you locksmith skills.

copyright Robert M. Slade, 2001   BKCNTRHK.RVW   20011023
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: 12 Feb 2001 (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 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-request () pica army mil> (Dennis Rears).
   .UK users should contact <Lindsay.Marshall () newcastle 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 risks () CSL 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.87
************************