[2822] in RISKS Forum
Risks Digest 23.43
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Mon Jun 28 13:36:39 2004
From: RISKS List Owner <risko@csl.sri.com>
Date: Mon, 28 Jun 2004 10:36:19 PDT
To: risks@mit.edu
RISKS-LIST: Risks-Forum Digest Monday 28 June 2004 Volume 23 : Issue 43
ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy
***** 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/23.43.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
AOL worker sold customer list for spam, US charges (via Monty Solomon)
Swedish social insurance computers disabled by virus (Peter Håkanson)
Terror over Internet Protocol? (NewsScan)
Canada's largest bank has "processing disruption" (Yves Bellefeuille)
PFIR "Preventing the Internet Meltdown" Conference Info Online
(Lauren Weinstein)
Attacking the attackers: maybe not a good idea (NewsScan)
Shocking laptop horror stories (Aahz)
Hacker hits South Korean defense (NewsScan)
/Not/ keeping security information up to date (TFB)
Wyoming woman arrested on false federal charges (Dirk the Daring)
Exploding vending machine emits phosgene gas (Cheryl Hoefelmeyer)
Irresponsible traffic announcement (Steve Friedman)
Who am I? (Erann Gat)
Re: Autorun evil? (Thomas Wicklund)
Risks of testing (Thomas Wicklund)
Re: Whom do I tell? (Chris Brand)
REVIEW: "Security Warrior", Cyrus Peikari/Anton Chuvakin (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Fri, 25 Jun 2004 13:37:21 -0400
From: Monty Solomon <monty@roscom.com>
Subject: AOL worker sold customer list for spam, US charges
An America Online employee, Jason Smathers, has been charged with
stealing AOL's list of 92-million customers and selling it it to an
Internet spammer/marketer/online-gambling purveyor Sean Dunaway (who
then resold it for $52,000 a pop). Dunaway was also charged.
Smathers has been fired.
[Sources: Monty provided several items, which were PGN-ed.]
Reuters, 23 Jun 2004
- http://finance.lycos.com/home/news/story.asp?story=42133939
Andrew Orlowski, 24 June 2004, UNITED STATES v. JASON SMATHERS, SEAN DUNAWAY
http://news.findlaw.com/hdocs/docs/cyberlaw/ussmthrs604acmp.pdf
http://www.theregister.com/2004/06/24/aol_spam_insider/
]
------------------------------
Date: Wed, 23 Jun 2004 18:38:32 +0200
From: Peter Håkanson <peter@hk.ipsec.se>
Subject: Swedish social insurance computers disabled by virus
Today Riksförsäkringsverket (the central authority that pays all
social benefits and illness-related salary-supplements) was disabled
by virus attacks.
This concerns all of Sweden's population of 9M persons. Not all of us
rely on this money, but every Swede who happens to be eligible for any
payments is.
A lot of errors seem to contribute. One of the larger is basing a
national insurance system on computers that are defenseless against
any external threat, another that those "toy-computers" are exposed to
external threats.
Maybe the golf-tours made the difference during the purchasing procedures??
There's never money to do it right, but always money to do it
again ... and again ... and again ... and again.
( Det är billigare att göra rätt. Det är dyrt att laga fel. )
------------------------------
Date: Thu, 17 Jun 2004 08:45:44 -0700
From: "NewsScan" <newsscan@newsscan.com>
Subject: Terror over Internet Protocol?
A senior Justice Department official has told a Senate committee that
law enforcement faces new threats from Internet-based telephone
services, and warned that legislative efforts to deregulate VoIP
(Voice over Internet Protocol) services could undermine the ability of
law enforcement officials to investigate criminal or terrorist
activity. The Justice Department has asked the FCC to require Internet
phone companies to design electronic conduits in their networks that
would make it easier to tap conversations. James X. Dempsey of the
Center for Democracy and Technology says that a better approach would
be for investigators to work cooperatively with Internet phone
providers. (*The Washington Post*, 16 Jun 2004; NewsScan Daily, 17 Jun
2004]
http://www.washingtonpost.com/wp-dyn/articles/A47882-2004Jun16.html
------------------------------
Date: Sun, 20 Jun 2004 22:46:47 -0400
From: Yves Bellefeuille <yan@storm.ca>
Subject: Canada's largest bank has "processing disruption"
[Written on 4 June, but only sent now because of a problem with my
Usenet server. :-(]
Canada's largest bank, the Royal Bank of Canada, has been unable to
process deposits or report balances for the last five days. The bank is
blaming "a processing disruption during a routine programming update to
one of our computer systems".
Direct deposit to a bank account is a common way to pay salaries here,
especially for large employers, and among those affected are employees
of the Government of Ontario, Canada's largest province, which
apparently uses the Royal Bank for its payroll.
The Royal Bank has 10 million customers, about a third of Canada's
population. It says that it "processes tens of millions of transactions
each day". The bank confirms that "the processing disruption was
national in scope so we expect a significant number of clients have been
affected".
The bank promises that: "We will fully refund any service fees or
overdraft interest charged to RBC clients' accounts due to this
processing delay. Any other reasonable costs incurred as a result of
this delay will be handled on an individual basis". It also says that:
"All the other banks are aware of this situation and we have asked them
to be as accommodating as possible". (There are seven major banks in
Canada.)
More information at:
http://www.royalbank.ca/client_faq.html
http://www.globeandmail.ca/servlet/story/RTGAM.20040604.wrbc0604/BNStory/Business/
------------------------------
Date: Sat, 26 Jun 2004 10:01:44 -0700
From: Lauren Weinstein <lauren@vortex.com>
Subject: PFIR "Preventing the Internet Meltdown" Conference Info Online
Peter,
I'm pleased to announce the availability of detailed registration,
schedule, program, hotel, and other information relating to our People
For Internet Responsibility (PFIR) "Preventing the Internet Meltdown"
conference here in L.A. from July 26 through 28, 2004. The
registration period for the conference commences immediately.
The conference information is all available from the Meltdown
official announcement document and related linked pages via:
http://www.pfir.org/meltdown
In the time since you, Dave Farber, and I originally suggested this
conference, the situation with many issues related to the Internet
have become even more complex and controversial. These range from
Internet governance and control to Homeland Security issues; from
VoIP, WHOIS, DNS, and privacy to spam, viruses, and other attacks on
the Internet infrastructure and its users; and much more. The
Internet and the global populations who depend upon it are at real
risk.
We hope that this gathering will aid in mapping out some specific
courses of action that can help us all avoid the many negative impacts
that an Internet meltdown would impart.
We're looking forward to a most interesting and productive
event. Thank you very much. Be seeing you!
--Lauren--
Lauren Weinstein
lauren@pfir.org or lauren@vortex.com or lauren@privacyforum.org
Tel: +1 (818) 225-2800
http://www.pfir.org/lauren
Co-Founder, PFIR - People For Internet Responsibility - http://www.pfir.org
Co-Founder, Fact Squad - http://www.factsquad.org
Co-Founder, URIICA - Union for Representative International Internet
Cooperation and Analysis - http://www.uriica.org
Moderator, PRIVACY Forum - http://www.vortex.com
Member, ACM Committee on Computers and Public Policy
------------------------------
Date: Mon, 21 Jun 2004 09:00:56 -0700
From: "NewsScan" <newsscan@newsscan.com>
Subject: Attacking the attackers: maybe not a good idea
A company called Symbiot Security has created "Intelligent Security
Infrastructure Management Systems" (iSIMS) that not only provide
traditional defensive measures against viruses, worms, and other kinds
of network vandalism -- but also offer the victims of vandalism a
gradual escalation of retaliation measures. These include the ability
to flood the attacking computers with data. However, some experts say
that retaliatory actions could be a very bad idea. Adrian Vanzyl of
the security firm Seclarity comments: "So you are in effect breaking
into each of those systems as you follow this person back. Are you
legally liable for that? It's a very, very good question." And Dorothy
Denning, professor of defense analysis at the Naval Postgraduate
School, warns: "We've seen worms that have had major impact like
causing delays in airline schedules, shutting down ATM machines, 911
systems and so on. Putting any kind of worm out there would be
dangerous." (AP/*San Jose Mercury News*, 18 Jun 2004; NewsScan Daily,
21 Jun 2004]
http://www.siliconvalley.com/mld/siliconvalley/8957335.htm
------------------------------
Date: Mon, 21 Jun 2004 23:07:05 -0400
From: Aahz <aahz@pythoncraft.com>
Subject: Shocking laptop horror stories
Press release dated June 11 (plus other stories found through Google):
http://www.newsroom.ucla.edu/page.asp?RelNum=5275
The story says that a laptop was stolen from the University of
California, Los Angeles in 11/2003, containing a database of 145,000
blood donors that was password-protected but not encrypted. The database
contained names, birthdates, and social security numbers. The victims
were not notified until a week before the story was filed, roughly six
months after the theft.
The laptop was stolen from a locked van. A second laptop was stolen in
late May from an office, putting another 62,000 people at risk -- UCLA
will notify these people, "...in the next few weeks."
Nothing really new here. Question is, when will these stories stop
getting resurrected from the grave? Of even more interest to me is that
none of my usual sources have popped up with this story; I learned about
it during a trip to LA this past weekend, more than a week after it hit
the news. Are we getting that blase about this?
Aahz (aahz@pythoncraft.com) http://www.pythoncraft.com/
------------------------------
Date: Tue, 22 Jun 2004 10:03:31 -0700
From: "NewsScan" <newsscan@newsscan.com>
Subject: Hacker hits South Korean defense
A network vandal has broken into computers at sensitive South Korean
research institutes and government agencies, infecting more than 60
PCs with a variation of the Peep Trojan program. The National Cyber
Security Center (NCSC) said the hacker had broken into computers at
the Agency for Defense Development, which develops weapons, the Korea
Atomic Energy Research Institute, the Korea Institute for Defense
Analysis and three other government agencies. [*The Australian*, 21
Jun 2004; NewsScan Daily, 22 Jun 2004 ) Rec'd from John Lamp
http://tinyurl.com/24wyw
------------------------------
Date: Mon, 28 Jun 2004 12:04:21 +0100
From: tfb@cley.com
Subject: /Not/ keeping security information up to date
Some time ago, in 2003, CERT announced a WAP service, so you could
check current CERT alerts and so on from your phone, at
http://wap.cert.org/. WAP hasn't been wildly successful, of course,
but all phoes have it, at least in the UK. Since I'm away from home a
lot, and I'm responsible for the security of our machines (and
sometimes of clients' machines too), I thought it would be useful:
it's nice to be able to check that there is nothing to panic about
from a device I carry all the time anyway. This is also potentially a
nearly-ideal use of a phone-type interface - the amount of information
needed is absolutely tiny (`sendmail issue, patch now!'), and
promptness is very important. Push would be better than pull, but you
can't have everything.
Fortunately, although I put the URL in my bookmarks, I didn't use it
very often, because something completely toxic happened. For whatever
reason, CERT obviously lost interest in the WAP interface, and *left a
static version of it in place*. If you check that URL (from a phone)
now, you'll find some information from November 2003, and *no
indication at all* that all the information is hopelessly out of date.
This is the worst possible scenario for a system like this. A system
which is meant to be providing alerts of some kind needs to either
work, or fail in such a way that its users know it's failed. This is
the equivalent of the coolant level meter reading `full' while coolant
pours from some fractured pipe and the core melts. If the coolant
meter is broken it's way better to have sparks and smoke pouring from
it than for it to quietly repeat the last reading...
I'd urge anyone who provides security information over the net to
arrange life so that when the system breaks or they lose interest, it
fails in a way that is extremely visible to its users.
------------------------------
Date: Sat, 19 Jun 2004 18:01:27 -0400 (EDT)
From: Dirk the Daring <dirk@psicorps.org>
Subject: Wyoming woman arrested on false federal charges
http://www.billingsgazette.com/index.php?id=1&display=rednews/2004/06/19/build/wyoming/55-arrest.inc
Summary: A vacationing Wyoming teacher's aide was rousted from her
cruise ship bed, shackled and dragged into federal court based on
information in a federal warrant database that wrongly accused her of
failing to pay a fine after she was cited in a US national park last
year.
The RISKS: Federal agents apparently blindly relied on the database,
even though the court had a copy of the citation showing she had paid.
The US Attorney even continued to ask for the woman to have to appear in
court in Wyoming after being told that the citation showed she had paid,
and standard procedure for the park is that visitors must pay fines
before they can leave.
Clearly, federal law enforcement authorities continue to place too much
reliance in computer databases and not enough on the information in
front of them. Further, the fine was a matter of US$50 for failing to
properly store her hot chocolate and marshmallows, yet the federal
authorities saw fit to drag the woman out of bed, shackle her like a
mass-murderer, and haul her into court.
------------------------------
Date: Sat, 26 Jun 2004 01:14:51 +0000
From: "Cheryl Hoefelmeyer" <hoefelmeyer@hotmail.com>
Subject: Exploding vending machine emits phosgene gas
A repairman working on a soft drink vending machine in Park Place
Medical Center in Port Arthur, Texas apparently triggered an explosion
which converted the freon in the machine to phosgene gas, a poisonous
gas that was used in WWI as a weapon.
Reference: (*Houston Chronicle*)
http://www.chron.com/cs/CDA/ssistory.mpl/metropolitan/2647290
------------------------------
Date: Thu, 3 Jun 2004 13:51:03 -0400 (EDT)
From: Steve Friedman <steve@adsi-m4.com>
Subject: Irresponsible traffic announcement
On the way to work this morning, around 9:45 am I heard a surprising
traffic announcement on the radio (WAMU). On this road, one is
legally allowed to drive on the right shoulder (aka breakdown) lane
until 10am. To indicate when it is permissible, lights over the lane
either indicate a red X or a green arrow.
Apparently, today the lights were showing red (thus closing down one
lane). The announcer indicated that, since it was still legal to
drive on the right shoulder until 10am, motorists should ignore the
computerized signs and drive on the right lane anyway.
It wasn't clear whether the insight into letting motorists decide to
ignore the signs was made by the announcer or Virginia state police;
however, it doesn't seem like a good idea to train motorists that the
only reason why the lane might be closed is because of computer
malfunction and thus ignore the signs when the motorist "knows" that
the lane should be open.
------------------------------
Date: Fri, 18 Jun 2004 11:35:41 -0700 (PDT)
From: Erann Gat <gat@flownet.com>
Subject: Who am I?
I just completed the process of legally changing my name. I am no longer
Erann Gat. I am now Ron Garret.
The interesting thing (I have been reading RISKS far too long for this to
be shocking or even surprising) is that the only time during the entire
process that I was asked to produce any identification was when I tried to
pay the court fees with my credit card. If I had paid in cash I could
have gone through the entire process without ever having to produce an ID.
And, of course, so could anybody else.
Ron Garret f.k.a. Erann Gat
------------------------------
Date: Mon, 21 Jun 2004 09:20:05 -0700 (PDT)
From: Thomas Wicklund <wicklund@eskimo.com>
Subject: Autorun evil? (Re: da Silva, RISKS-23.42)
Peter da Silva questions who would think autorun a good idea. The
answer should be obvious. Most computer users aren't technically
sophisticated and want to have "plug and play" devices. A few minutes
with market research or support personnel will show that a typical
consumer wants to plug a device into a computer and user it. The
consumer doesn't want to have to perform a software installation step
using a CD which was probably lost months ago, nor answer a bunch of
"do you want to enable this device you just plugged in" questions.
Anybody with non-technically inclined relatives who's been asked to
help setup a system should also see the reasons for plug and play
features.
Obviously this opens up security concerns. Autorun is subject to
abuse. So is the lack of autorun (just create a CD with a virus named
"setup" and tell the user to install it).
There is a fundamental conflict between security and convenience. Many
common system features are security holes such as programmable access
to network features, copy/paste clipboards, I/O redirection, and
allowing default "other read" file access. Most features which allow
one to do useful work can also be abused. Similarly, the feature of
the automobile which allows one to travel faster than a walk also
allows one to be more easily killed in a collision.
In the same Risks edition, Aahz objects to labeling Verity technology
as data mining software. Yet in some sense, any search program is a
form of data mining. And as with any search, it can be used (find the
best price for product X) and abused (find all information about John
Doe).
------------------------------
Date: Mon, 21 Jun 2004 09:25:08 -0700 (PDT)
From: Thomas Wicklund <wicklund@eskimo.com>
Subject: Risks of testing (Cohen, RISKS-23.42)
Fred Cohen mentions wanting to be able to prove things like "the green
lights will not be on in non-parallel directions at traffic lights".
One thing software professionals must always remember, and may easily
forget, is that software is dependent on hardware. No amount of
software will protect against a short in the hardware, and even with
fault tolerant techniques one must ultimately ensure that the hardware
is properly designed or provides the proper interlocks.
In the traffic light case, while software may be cheaper, hardware
interlocks may ultimately be the most reliable solution.
------------------------------
Date: Fri, 18 Jun 2004 10:21:11 -0700
From: "Chris Brand" <Chris_Brand@spectrumsignal.com>
Subject: Re: Whom do I tell? (Jerry James)
> ... when I dial a number I know is good, I get the
message that I am calling a disconnected number.
This sounds similar to a problem I have. Here in BC, in November
2001, we switched to 10-digit dialing, where you always have to dial
the area code even if your area code is the same. If you get it
wrong, you get a polite message telling you that you need to redial
with the "604".
The problem is that I occasionally get the same message when I have
dialed the 604. Just as Jerry described, I hang up, press "redial" and
the call goes through.
I haven't actually bothered trying to report it. In this age of
Windows, "try it again", "it worked that time", "well ok,
then. Goodbye" seems to have become the norm.
------------------------------
Date: Thu, 24 Jun 2004 12:48:24 -0800
From: Rob Slade <rslade@sprint.ca>
Subject: REVIEW: "Security Warrior", Cyrus Peikari/Anton Chuvakin
BKSECWRR.RVW 20040509
"Security Warrior", Cyrus Peikari/Anton Chuvakin, 2004, 0-596-00545-8,
U$44.95/C$65.95
%A Cyrus Peikari
%A Anton Chuvakin
%C 103 Morris Street, Suite A, Sebastopol, CA 95472
%D 2004
%G 0-596-00545-8
%I O'Reilly & Associates, Inc.
%O U$44.95/C$65.95 800-998-9938 fax: 707-829-0104 nuts@ora.com
%O http://www.amazon.com/exec/obidos/ASIN/0596005458/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0596005458/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0596005458/robsladesin03-20
%P 531 p.
%T "Security Warrior"
The preface isn't a really clear piece of writing, but does,
eventually, get around to stating that the book focuses on security
from an attack, rather than defence, perspective. I have, in numerous
other reviews, pointed out the errors and limitations in this
position.
Part one deals with cracking software, primarily involved with
breaking copy protection. Chapter one explains a few concepts about
assembly language quite well, and then ends abruptly. Some Windows
tools for reverse engineering are listed in chapter two, plus a couple
of poorly explained examples. The material on reverse engineering in
Linux is longer and more detailed, but still has very limited tutorial
value, and is padded with extensive code listings of dubious worth.
Chapter four is supposed to deal with reverse engineering for
Windows CE, but contains an odd mix of CE operating system
architecture, a partial list of ARM CPU opcodes, and a description of
how to crack the registration code check in a program written solely
to allow you to crack the registration code check embedded within it.
Overflow attacks, in chapter five, explains buffer and other overflow
conditions, and gives an example of a buffer overflow as a crack in
another fake program.
Part two presents information about networks. Chapter six is a rather
unstructured overview of TCP/IP and a listing of some sniffing tools.
(TCP is explained before IP itself, and the relationship of the
various protocols in the suite is not discussed. A section on "covert
channels" emphasizes a strange misuse of header fields, and then
drifts into something like session hijacking.) Social engineering can
be used in a variety of ways, so it is strange that chapter seven
should be here rather than in the "Advanced Defence" of part four.
The random content provided has little organization and a fair number
of errors: the authors insist that social engineering attacks can be
divided into active and passive types, but, by its nature, social
engineering is almost entirely active. (The book does seem to tacitly
admit this: there is a list of example "active" attacks, but no
corresponding "passive" list.) Chapter eight mentions a few methods
of reconnaissance with differing levels of detail. Some more advanced
techniques for identifying the operating systems in chapter nine, but
the particulars are similarly inconsistent.
Part three lists attacks against specific platforms. The authors
betray their lack of study once again in chapter eleven: UNIX is *not*
"reborn from" MULTICS (although it was heavily influenced), and TCSEC
(the Trusted Computer System Evaluation Criteria) is definitely *not*
the Common Criteria. The various security related aspects, tools, and
hardening of UNIX are not bad, but lack definition. The UNIX attacks
listed in chapter twelve are good: ironically, because of the generic
nature of the descriptions the examples are probably useful as a guide
to defensive measures, rather than being outdated tricks. The Windows
client attacks listed in chapter thirteen, because they are specific,
have limited the material both in scope and utility. Chapter
fourteen, listing Windows server attacks, notes some interesting
security bugs in Server 2003 and other programs (and one bit on
smartcards.) "SOAP XML Web Services Security," in chapter fifteen, is
a long title for a short piece on XML digital signatures. "SQL
Injection," in chapter sixteen, has some examples of malformed data
attacks, and also points out the dangers of adding programming
functionality to applications. As with social engineering, the tie to
networks is thin, seemingly limited to the PHPNuke program. Some
aspects of wireless antennae, sniffing, and a brief review of the
weaknesses in WEP (Wired Equivalent Privacy) are in chapter seventeen.
Part four looks at more advanced defence. Miscellaneous thoughts on
logging are in chapter eighteen. Chapter nineteen has a confused
explanation of intrusion detection systems (IDS). There is no mention
of rule (or activity monitoring) based engines, signature based
engines are said to be restricted to net-based IDS, different terms
are used for anomaly detection engines on hosts versus networks, and
there is a muddled attempt to tie Bayesian analysis to odd
mathematical ratios of false positive (false rejection) and false
negative (false acceptance) errors. The installation of a simple
honeypot is described in chapter twenty (which probably *should* be in
part two). There is a good initial outline of incident response in
chapter twenty one, but it breaks down when getting into specifics.
Forensics and antiforensics, in chapter twenty two, gives some
background and tools for data recovery and obfuscation.
It is ironic that the book starts out with a quotation from "The Code
of the Samurai," stating that "[a]ll samurai ought certainly to apply
themselves to the study of military science. But a bad use can be
made of this study to puff oneself up and disparage one's colleagues
by a lot of high-flown but incorrect arguments that only mislead the
young ..." This assessment fits Peikari and Chuvakin's work almost
perfectly. There is a lot of interesting information in this volume:
if you have limited technical background in the fields examined, you
will find that a quick perusal will provide you with some superficial
familiarity with the topics. However, the uneven coverage ensures
that the information is spectacular, rather than tutorial. The
disjointed jumps from one subject to the next prove the technical
erudition of the authors, but do not help the reader very much.
copyright Robert M. Slade, 2004 BKSECWRR.RVW 20040509
rslade@vcn.bc.ca slade@victoria.tc.ca rslade@sun.soci.niu.edu
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
------------------------------
Date: 2 Jun 2004 (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. To subscribe or unsubscribe via
e-mail to mailman your FROM: address, send a message to
risks-request@csl.sri.com
containing only the one-word text subscribe or unsubscribe. You may
also specify a different receiving address: subscribe address= ... .
You may short-circuit the process by sending directly to either
risks-subscribe@csl.sri.com or risks-unsubscribe@csl.sri.com
depending on which action is to be taken.
Subscription and unsubscription requests require that you reply to a
confirmation message sent to the subscribing mail address. Instructions
are included in the confirmation message. Each issue of RISKS that you
receive contains information on how to post, unsubscribe, etc.
INFO [for unabridged version of RISKS information]
.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>
The full info file may 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.
*** NOTE: Including the string "notsp" at the beginning or end of the subject
*** line will be very helpful in separating real contributions from spam.
*** This attention-string may change, so watch this space now and then.
=> ARCHIVES: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i]
<http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive
http://catless.ncl.ac.uk/Risks/VL.IS.html gets you 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/> .
==> 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 23.43
************************
