RISKS-LIST: Risks-Forum Digest Monday 27 May 2002 Volume 22 : Issue 10

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

  Contents:
US Navy suffers domain hijacking (Geoffrey Brent)
California personnel files were breached for 265,000 workers (Monty Solomon)
Face recognition kit fails in Fla airport (Thomas C Greene via Dave Farber)
Dutch city implanting chips to monitor tree health (Sander Tekelenburg)
Risks of quoting command language in e-mail (Mich Kabay)
Glitch leads to huge airfare bargains (Jason Axley)
Re: Copy-Protected CDs (Alan J Rosenthal)
Re: Apple copy-protected CD (Benjamin Robinson)
Re: Ford Motor Credit office baffled by theft (Greg Searle)
Re: Vending Machines - Poor Programming (Ryan O'Connell)
Re: Candy machine punishes the quick-thinking (Alan P)
Re: S-P-A-M-demonium (Klaus Johannes Rusch)
Re: SpamAssassin + Vipul's Razor (Karsten M. Self)
Re: 5am call (Gavin Treadgold)
More on Klez (Simson L. Garfinkel, Jonathan Kamens)
Klez and mail loops (Martin Pool)
REVIEW: "CISSP All-in-One Certification Exam Guide", Shon Harris (Rob Slade)
Abridged info on RISKS (comp.risks)

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

Date: Mon, 27 May 2002 14:52:05 +1000
From: Geoffrey Brent <g.brentstudent.unsw.edu.au>
Subject: US Navy suffers domain hijacking

When the US Navy forgot to renew registration on NavyDallas.com
- apparently because Network Solutions forgot to send them a
renewal notice - it was snapped up by a pornography site. NSI
accepted the new registration despite the new owner being
identified simply as "Bog". Meanwhile, NavyBoston.com now directs
users to an eBay auction site:

http://www.newsbytes.com/news/02/176741.html

Porn hijacking is annoying, but at least it's pretty obvious.
IIRC RISKS has previously mentioned some of the nastier things
that can be done when someone has the opportunity to impersonate
a 'trusted' domain, and allowing somebody to do so without even
giving reasonable contact details looks like a recipe for trouble.

Geoffrey Brent - g.brentstudent.unsw.edu.au

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

Date: Sun, 26 May 2002 14:35:16 -0400
From: Monty Solomon <montyroscom.com>
Subject: California personnel files were breached for 265,000 workers

Hackers gain entry to key state database
Ryan Kim, *San Francisco Chronicle*, 25 May 2002

Computer hackers have cracked into the state's personnel database and gained
access to financial information for all 265,000 state workers, including
Governor Gray Davis, officials said Friday. The database, housed at state's
Teale Data Center in Rancho Cordova, holds names, Social Security numbers,
and payroll information for everyone from office workers to judges.
Authorities said that so far they have found no evidence that the
information has been used illegally.

<http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2002/05/25/MN179392.DTL>

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

Date: Mon, 27 May 2002 11:16:55 -0400
From: Dave Farber <davefarber.net>
Subject: Face recognition kit fails in Fla airport

Thomas C Greene in Washington, The Register 27 May 2002
  http://www.theregister.co.uk/content/55/25444.html

The face recognition system in experimental use at Palm Beach International
Airport on 15 volunteers and a database of 250 snapshots. The success rate
is less than 50%. Extrapolations also suggest a false-positive rate of
about 50 passengers a day for a single checkpoint handling 5,000 passengers.
"Eyeglasses gave the system a great deal of difficulty, in spite of copious
Visionics marketing hype denying this particular glitch. Small rotations of
the head, fifteen to thirty degrees off the camera's focal point, also
bamboozled it repeatedly, and the lighting had to be just right."

  [PGN-ed for RISKS. For Dave's IP archives see:
http://www.interesting-people.org/archives/interesting-people/ ]

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

Date: Fri, 24 May 2002 02:49:04 +0200
From: Sander Tekelenburg <tekelenbeuronet.nl>
Subject: Dutch city implanting chips to monitor tree health

Re: WashDC database crash linked to a death by a falling tree (R 22 08),
here is another computer angle on dead tree branches:
  http://nu.nl/document?n=57035 (dutch only)

[Loose translation] The Dutch city of Bloemendaal is going to implant
chips in all its trees. With a portable computer, it will become easy to
track the trees' health. The city thinks this will make tree maintenance
cheaper and better, allowing trees to remain healthier and live longer. Each
chip contains a unique ID. Each tree's data is stored in a portable
computer. The cost reduction is in not having to carry big stacks of paper
and maps around while monitoring trees' health. More can be done in less
time, and it will be easier to track exactly what maintenance was applied to
which tree. Added bonus is that when a dead branch drops on a car, the city
will be able to show that this was not caused by lack of maintenance. Cost
of implanting all trees with these so-called "transponders" is 56.722 euro.

Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

  [Note that linguistically, a "transponder" is anything that
  works across the pond (familiarly, the Atlantic Ocean). PGN]

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

Date: Fri, 24 May 2002 08:09:38 -0400
From: Mich Kabay <mkabaycompuserve.com>
Subject: Risks of quoting command language in e-mail

In a newsletter sent to 40,000 recipients, I included a block of HTML
code showing a forged header.

The e-mail list software spotted what it thought was the end of the
document and inserted the e-mail address of each recipient in that
person's copy of the newsletter, making many readers believe that
their e-mail address had been distributed to the entire list.
Result: hundreds of letters (some nice, some not).

LESSONS:

(1) When designing macros that scan for search strings associated
with a particular condition (in this case, the end of a message), it
would be wise to test the presumption that the condition is in fact
true. In this example, perhaps a second check might verify that
there is in fact no further text in the message before inserting the
valediction.

(2) When quoting control language (in this case, HTML), and in the
absence of some sort of escape character (meaning "the following is
literal text, not command language"), we may avoid accidents by using
symbol substitution to prevent accidental misreading of the quoted
strings as if they were actually to be interpreted.

M. E. Kabay, PhD, CISSP -- AssocProf Information Assurance, DeptCompInfoSys,
Norwich University, Northfield VT http://www2.norwich.edu/mkabay/index.htm

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

Date: Wed, 15 May 2002 07:43:23 -0700
From: Jason Axley <jason-risksaxley.net>
Subject: Glitch leads to huge airfare bargains

  ``For about 45 minutes on 14 May 2002, visitors to the United Airlines Web
  site were able to buy roundtrip tickets for $25. United blames it on an
  error by a computer that distributes fares for major airlines... It's not
  the first time United has sold $25 tickets on its site. In January, 142
  passengers bought tickets to international destinations for as little as
  $25.''

However, from the article, it sounds like it may have been due to human
error, because ATP Co., the clearinghouse that distributes new sale fares to
their Web site, was trying to fix a problem where a $5 online discount was
not reflected in the sale prices but ended up loading all prices but the
actual fare itself. So the $25 includes just the "taxes, facility charges
and a $5 surcharge".

Full story:
http://www.cbsnews.com/stories/2002/05/15/national/main509107.shtml
 
------------------------------

Date: Fri, 24 May 2002 09:38:07 -0400 (EDT)
From: flapsdgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Copy-Protected CDs (Dunn, RISKS-22.09)

I strongly disagree. The CD is not "corrupted"; it contains an additional
data partition, with malware on it. It is a trojan horse, because you
execute that malware when you are trying to do something else. It prevents
normal use of the CD (playing it for one's listening pleasure in a CD
player, if that CD player is controlled by a computer).

I've listened to audio CDs on computers a handful of times, not many; but I've
never extracted any audio data from them, because I don't need to because I
already have the data (on CD). I imagine that a great many RISKS readers
are in a similar situation, as are the majority of the victims of these
malware CDs. It prevents the regular use of the product with the consumer's
choice of equipment, like any "embrace and extend" technological maneuver.

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

Date: Fri, 24 May 2002 23:09:22 -0400
From: "Benjamin Robinson" <ixiondigital.net>
Subject: Re: Apple copy-protected CD (Arthur, R 22 07)

Apple has apparently softened their original position. I followed the link
provided in the article, and found this end note, instead:

 If a disc with copyright protection technology remains inside the drive after
 following the procedures above, or if the computer does not start up normally,
 it is recommended that you contact an Apple Authorized Service Provider (AASP)
 or Apple Technical Support. Audio discs that incorporate copyright protection
 technologies do not adhere to published Compact Disc standards. Apple designs
 its optical disc drives to support media that conform to such standards.

No mention of repair fees or the like, so I'll assume they will cut users some
slack the first time they bring in their machines for service.

Benjamin Robinson bjr7freenet.tlh.fl.us

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

Date: Fri, 24 May 2002 12:41:59 -0400
From: "Greg Searle" <greg_searlehotmail.com>
Subject: Re: Ford Motor Credit office baffled by theft (Hansen, RISKS-22.09)

How's this for a possible scenario?

- A Ford employee walks away from a workstation without locking it first.
- A watchful contractor/employee/visitor/whoever walks up to the system with
  a prepared, custom-burned CD in hand.
- S/he pops the CD in, and an autorun program loads and immediately ejects
  the CD.
- The perpetrator takes the CD, closes the tray, and walks away within 10
  seconds of approaching the workstation.
- The program that was just loaded goes to work in the background.
- The original employee returns with a fresh cup of coffee and resumes
  working, unaware that anything has happened.
- Later, at home/cafe/wherever, this person connects to the zombified system
  (which has opened a path to itself through the firewall) and gets busy.

Sound farfetched? No. Any programmer with the proper motivation (13,000
credit reports are very motivating), a few bits of publicly-available
developer knowledge, a simple development system, and a cheap CD-R drive
could do just that. All firewalls have the same basic weaknesses that can
be taken advantage of, as long as the activity initiates from inside. The
most secure Internet connection is no Internet connection at all.

This is all just informed speculation, but an office is only as secure as
the weakest habits of its employees.

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

Date: Thu, 23 May 2002 20:03:11 +0100 (GMT Daylight Time)
From: "Ryan O'Connell" <ryan-riskscomplicity.co.uk>
Subject: Re: Vending Machines - Poor Programming (Griesenbrock, Risks 22.09)

This reminds me of an incident that happened not too long ago on the
University campus (in the UK) that I attended. The vending machines on
campus were the style where you can't see the item (Chocolate) before it is
dispensed - you dial a two digit number and it gives you the product or
tells you it's out of stock or how much it costs as appropriate. The
machines usually had about 10 varieties of chocolate/chewing gum in them, so
the valid entries were typically in the range 10-19 although some had more
or less choices.

It seems some of the machines had been misprogrammed and some debt-ridden
students had discovered that some of the higher numbers (80+) dispensed
chocolate with the incorrect prices. Some of these prices were very high but
others were ridiculously low - a few pence (less than 10 cents) per
item. Some even had a zero value!

As you can imagine, it does not take long for news like this to spread and
very quickly everyone knew if you wanted free or cheap chocolate and didn't
care what you got then you could just walk up to the nearest machine and
start punching buttons at random until you got something.

What is even more surprising is that the engineers that came to fill the
machines with food and empty the cash did so several times before someone
actually came along (A different engineer) and reprogrammed all the machines
to fix this problem. I'm surprised this problem hadn't been discovered
before at other sites, so I suspect either we had a badly setup batch of
machines or the problem was known about but they didn't have the resources
to reprogram every machine just in case.

The Risks here are obvious - as with almost every other Risks item, buggy
software doesn't just cause bad PR, it can cost money!

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

Date: Thu, 23 May 2002 09:18:57 +0200
From: arp <alanpprism.co.za>
Subject: Re: Candy machine punishes the quick-thinking (Rice, RISKS-22.08)

FYI, here is some info on the architecture of (admittedly older) vending
machines:

Consists of the executive (typically the note acceptor/coin box) which
controls the peripherals (typically the dispenser which also displays prices
and come-on message, accepts your selection choice and vends the
products). All these components are separate devices communicating via a
shared bus. The executive controls the peripherals via a query-response
protocol (either Protocol A or the newer MDC protocol). Neither of these
protocols are particularly well-define in terms of exception handling.
Moreover, manufacturers' implementation of these protocols can differ
significantly (what a surprise).

The executive will tell the dispenser, for example, how much credit is
available and when to vend (but _not_ what to vend). If memory serves, the
protocols define the acceptable states of a peripheral. E.g., the dispenser
may not vend until it has received a 'credit' message. If one selects a
product before the dispenser has received such a message the dispenser will
(usually) display the product's price.

I'll leave it as an exercise to the reader to find as many RISKy (<groan>)
scenarios as (s)he can with this setup.

>The risks? I suspect that the software that went in to the machine was
>tested by the programmer and not tested in the field before being released
>-- though the only way to find out would be to ask. Not doing real-world
>testing is a common risk but this fault was dumb and should have been easy
>to catch before the software was released.

Hhmmm...i'm not so sure. As for all timing-related errors (such as this),
testing for them reliably can be tricky. Even worse is the differences
between different manufacturer's vending peripherals (and their 'adherence'
to the vending protocol). We've had the situation where our executive works
reliable in 2 different types of vending machines only to fail horribly in
the third type (from the same manufacturer).

> [Just wait until the thing starts accepting debit and credit cards. More
> good ways to make the software fail! }:-} ]

The company I currently work have an executive that uses a smartcard as the
payment token (in a closed payment system). At least this method has the
advantage of being offline (i.e. doesn't have to communicate with a bank to
authorise the payment) which supposedly reduces the risks of fraud (hah!).

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

Date: Thu, 23 May 2002 21:50:26 CET
From: Klaus Johannes Rusch <KlausRuschatmedia.net>
Subject: Re: S-P-A-M-demonium (Kevin, RISKS-22.09)

Of course there is an obvious risk with Vipul's Razor: corruption of the black
list, either by accident -- it just takes a single provider to pipe all mails
through the reporting script -- or on purpose, to prevent others from receiving
a certain message, such as a virus warning.

Collaborative filtering with trusted co-readers can be very helpful, not
just for spam tagging but general rating of information, yet I prefer to not
let every stranger in the world filter my e-mail.

Klaus Johannes Rusch KlausRuschatmedia.net http://www.atmedia.net/KlausRusch/

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

Date: Sat, 25 May 2002 15:18:44 -0700
From: "Karsten M. Self" <kmselfix.netcom.com>
Subject: Re: SpamAssassin + Vipul's Razor (Re: Kevin, RISKS-22.09)

As a ***VERY*** happy customer of SpamAssassin, I was interested to see
you've adopted it for the RISKS list.

Note that Kevin's (nobodytex.kom) advice should not be necessary --
SpamAssassin already incorporates (and scores appropriately) information
from the Vipul's Razor system.

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

Date: Sat, 25 May 2002 15:58:08 -0400
From: "Gavin Treadgold" <gavrediguana.co.nz>
Subject: Re: 5am call (RISKS-22.08)

> How did her mobile phone make a call by itself at 5am?

I have had a similar event occur, and often it is related to the phone call
blocking caller ID. Take my cell phone, a Nokia 6210 for example. It has
caller ID capability here in New Zealand. If the number is not blocked, it
will display the number and log in a register of the 10 most recent
received/missed numbers. If the number is blocked, then it is not added to
the register. However, if you miss a call, it will provide a 'list' command
that will display the number of the most recently missed call from the
missed call register. This works fine if last call had a called ID number
that was added to the missed calls register. If the last call had a blocked
caller ID, then no number was added to the top of the register, and if you
hit list, the top of the register displays the last valid caller ID number
before that.

So all that had to happen was for you mum's last recorded caller ID call to
be from her mobile to her home, and then then next call to be from a caller
ID blocked phone, and it is possible that the displayed number was the last
previous identifiable number, rather than the last actual call. Of course
this depends on her caller ID unit, and what I've noted from my cell phone,
my not be applicable towards her caller ID unit.

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

Date: Sat, 25 May 2002 12:33:37 -0400 (EDT)
From: simsongvineyard.net (Simson L. Garfinkel)
Subject: More on Klez

Largely as a result of the previous postings on this list, I decided
to get my act together and re-install the anti-virus scanning for my ISP.
(The last time I turned it on, a configuration error caused the anti-virus
to eat several thousand email messages, so in the meantime I had developed
some automated email testing tools.)

In any event, I'm stunned. My ISP has less than 1500 active mailboxes, but
we're receiving several copies of W32/Klez-G per minute. Some users are
actually receiving 30-60 copies of this virus every day. (Hopefully they are
running their own anti-virus...)

It just goes to show the danger of a monoculture.

More than 50% of the viruses are being sent by one or two people who
have cable modems. It makes you wonder if there should be any liability for
these individuals.

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

Date: Thu, 23 May 2002 15:33:30 -0400
From: Jonathan Kamens <jikkamens.brookline.ma.us>
Subject: Re: More on Klez (Brennan, RISKS 22.09)

This is very strange, because I have had exactly the opposite experience. I
have one confirmed case of the envelope address indicating the actual sender
of the infected message -- the envelope sender matched up with the Received
lines, and when I spoke to the envelope sender, who is a friend in town and
thus easily reachable, he confirmed that his computer was infected.

In the vast majority of the other copies of this virus I've received, the
envelope sender has matched up with the Received lines, and none of the so
identified individuals whom I've contacted have responded with a claim that
their machines were actually not infected (although they also have not
responded to confirm that they *were* infected).

Perhaps there is a new Klez variant that I haven't yet seen, which forges
the envelope sender as well?

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

Date: Thu, 23 May 2002 15:49:37 +1000
From: Martin Pool <mbpsourcefrog.net>
Subject: Klez and mail loops

A machine I co-administer recently suffered what at first looked like a
mailbomb attack. On further investigation, it seems that it was probably a
side effect of the Klez worm, possibly unintended but rather destructive.

As was explained in a previous issue, the Klez family send e-mail from an
infected computer A to an address B, with the From address forged as a third
party C. B and C are selected apparently at random from the address book of
A, or possibly other sources.

Any bounce messages caused by the attempted delivery to C will be sent to B.
Readers will probably have suffered over the last month mailboxes full of
not just Klez worms but also bounce messages or auto-generated virus
warnings. (Incidentally, one might hope that e-mail anti-virus vendors would
be smart enough to send notifications to A rather than B in this case, but
apparently many are not.)

If both addresses B and C are configured to auto-reply to messages, then a
rather more destructive mail loop can occur, producing network traffic and
also filling mailboxes or databases at both ends. In the particular attack
we observed, B was a robot that sent instructions about an FTP archive, and
C was a bug-submission address that sent automatic acknowledgements.

Of course, mail loops are always a risk when programs automatically generate
e-mail. They can be avoided if either program is sufficiently smart to
detect and break the loop: the BSD vacation program, and most mail
transports agents do this quite well, for example. However, many other
programs can't detect loops under some circumstances, particularly if the
other party is also somewhat RFC-ignorant: for example, if it drops the
X-Loop header, or does not set a Precedence or Sender appropriately.

"Untested code is broken code", and many of these bugs have never been
thrown up because bug databases don't normally get into arguments with FTP
robots. Because Klez picks addresses apparently at random, it kicks off
interactions between programs that might never normally occur.

In general, the most likely situation for an autoresponder loop is probably
an SMTP bounce message, but since most mailers try to avoid loops the
autoresponder can get away with only simple checks for loops. When two such
robots talk to each other, loops can easily occur.

Interestingly, the machines most affected by the event need not be
vulnerable to the worm, or even running Windows at all! Like some previous
DDOS attacks, the disruption is amplified by the autoresponders, so A sends
only one message to start the chain reaction.

It seems that some mail autoresponders need to be better defended against
conversations with poorly-designed or malicious remote parties.
Countermeasures might include setting the reply address to one that will not
cause more mail to be sent, and using a global or per-address rate limit.

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

Date: Mon, 27 May 2002 08:19:40 -0800
From: Rob Slade <rsladesprint.ca>
Subject: REVIEW: "CISSP All-in-One Certification Exam Guide", Shon Harris

BKCISPA1.RVW 20020503

"CISSP All-in-One Certification Exam Guide", Shon Harris, 2002,
0-07-219353-0, U$79.99
%A Shon Harris shonharrishotmail.com
%C 300 Water Street, Whitby, Ontario L1N 9B6
%D 2002
%G 0-07-219353-0
%I McGraw-Hill Ryerson/Osborne
%O U$79.99 905-430-5000 +1-800-565-5758 fax: 905-430-5020
%P 971 p. + CD-ROM
%T "CISSP All-in-One Certification Exam Guide"

Chapter one is a very reasonable review of the CISSP (Certified
Information Systems Security Professional) credential, and the (ISC)^2
(International Information Systems Security Certification Consortium)
exam process, including recertification. As with most of the chapters
in the book, it has a set of sample questions, and while I could
quibble with some, they cover a decent range of topics and a
representative extent of difficulty. There are resources listed in
this and other chapters, mostly Web sites. Web sites are, of course,
most easily accessible, but they also die on a regular basis, and it
might have been an idea to include references to other books on
specific topics. It is difficult to see the point of chapter two--an
opinion-piece level overview of various security related topics.

Chapter three begins the first of the ten domains of the Common Body
of Knowledge (CBK) with security management practices. It is obvious
that the material has been structured and based on the (ISC)^2 CBK
review course, even to the use of specific tables and diagrams, but
the material is, at least, enhanced and extended by narrative
discussion. Access control is explained clearly (and sometimes
amusingly) in chapter four (although biometrics is generally
considered to be a form of authentication, not identification). In
general, the coverage of security architecture and models in chapter
five is quite useful. However, there is too much emphasis on the old
"Orange Book" TCSEC (Trusted Computer System Evaluation Criteria) and
not enough on the newer Common Criteria. (The inclusion of a section
on computer hardware is also a bit odd.) Chapter six has many of the
blind spots about physical security common to most computer security
types (including some erroneous information about Halon from the old
CBK course). The telecommunications and networking material, in
chapter seven, presents the underlying concepts well, but for some
reason fails to address many of the security technologies. The
explanations of cryptography, in chapter eight, are problematic.
Fortunately, the content is not necessarily wrong. The author
obviously is not familiar with this area, and the text in such areas
as DES (Data Encryption Standard) modes and one way encryption doesn't
make sense, although it does not necessarily misinform the reader.
Chapter nine, dealing with business continuity and disaster recovery,
is reasonable, but not as detailed as other sections. Law,
Investigation, and ethics is pretty good, although some old crimes and
the insistence on the salami scam myth are some notable flaws in
chapter ten. Chapter eleven, applications development, contains the
basic information but does not always make the connections to
security. Operations security gets a sensible review in chapter
twelve.

The material is much more reliable and better structured than the SRV
Press books (cf. BKCISPET.RVW), and much more reliable and complete
than the Andress work (cf. BKCISPEC.RVW). Like the Krutz and Vines
volume (cf. BKCISPPG.RVW) it is quite obvious that the content and
organization is copied from the old CBK course (sometimes slavishly),
although Harris does put more explanatory and narrative substance into
the text. (Interestingly, there are some indications that this is
based on an even older version of the course than Krutz and Vines
used.) Even considering the noted weak areas in this book, it should
provide a reasonable basis as a study guide for the CISSP exam,
although those who use only this work should not expect to get a
particularly high mark.

copyright Robert M. Slade, 2002 BKCISPA1.RVW 20020503
rsladevcn.bc.ca rsladesprint.ca sladevictoria.tc.ca p1canada.com
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade

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

Date: 29 Mar 2002 (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 e-mail requests to <risks-requestcsl.sri.com> with one-line body
   subscribe [OR unsubscribe]
 which requires your ANSWERing confirmation to majordomoCSL.sri.com .
 If Majordomo balks when you send your accept, please forward to risks.
 [If E-mail address differs from FROM: subscribe "other-address <xy>" ;
 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-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 21" for volume 21]
 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 22.10
************************

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