Risks Digest 21.18

[risks@csl.sri.com]

[: hacktivism :]

RISKS-LIST: Risks-Forum Digest  Thursday 4 January 2001  Volume 21 : Issue 18

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

  Contents:
Revenge of Y2K, Norwegian trains halted 31 Dec 2000 (Jan L)
7-Eleven unable to process credit cards since 1 Jan 2001 (Steve Hutto)
Y2K+1 bug in Sharp Organizer? (Philip Berman)
Power cut hits hundreds of millions in India (Edelson Doneel)
Repeated computer outages for Swedish bank (Ulf Lindqvist)
Telephone outage caused by water-main break (Glenn C. Lasher Jr.)
Computer blamed for Russian rocket crash (Peter Neumann)
Chinook: key facts ignored by those who want to clear pilots (John O'Connor)
CIOs: "What, Me Worry?" (NewsScan)
Automatic firmware upgrades in home electronics (Andrew Klossner)
Hackers hack science exam (Winn Schwartau)
Re: Seattle Hospital Hacked (Daniel Theunissen)
Re: IBM and Intel push copy protection ... (Patrick P Gelsinger)
Re: IMPORTANT MESSAGE FROM EGGHEAD.COM CEO (Gary Lawrence Murphy)
Re: The risk of a seldom-used URL syntax (Crispin Cowan)
The top 10 privacy stories of 2000 (Richard M. Smith)
Stefan Brands: PKI, digital certificates, and privacy (PGN)
Submission Deadline for USENIX Security Symposium, 1 Feb 2001 (Monica Ortiz)
Call For Papers - RAID'2001 (Giovanni Vigna)
Abridged info on RISKS (comp.risks)

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

Date: Mon, 01 Jan 2001 17:12:21 +0100
From: janl@linpro.no
Subject: Revenge of Y2K, Norwegian trains halted 31 Dec 2000

Original story in "Dagbladet ... nettet" in Oslo (In Norwegian:
http://www.dagbladet.no/nyheter/2000/12/31/235007.html)

Abstracted:

In the morning of 31 Dec 2000, departures of the Airport Express train and
six "Signatur" departures were hit by a date handling problem.  The airport
trains were quickly back in action, the 07:28 Signatur departure from
Kristiansand was canceled, and the five other departures were serviced by
older trains.

Preben Colstrup, a spokesperson for NSB, verifies that the trains appears to
not handle the date 31 Dec 2000 at all, he has no idea why.  He promises
that all trains will be on schedule on 01 Jan 2001.  NSB adds that the
trains still have not passed acceptance and belongs to the contractor,
Adtranz.

Ronny Solberg in Adtranz says that the problem was solved by setting the
date on the trains back a month.  It only takes a few minutes, but it took
time to get service people around to all the trains.  He stresses that all
trains were Y2K tested, but that no-one thought of testing 31 Dec 2000.  He
promises that the problem will be found and fixed permanently.

Dictionary:

- NSB: Norges StatsBaner, the publicly owned train company in Norway
- Signatur and Airport trains: New high speed trains made for NSB by
  Adtranz. Presumably carrying the same computer systems.  Signatur is
  used for long inter city routes.

Addendum: Later in the day, on national radio news a technical person in NSB
speculated that the problem might have been that Y2K was a leap year and the
number of days at the end of the year baffled the computers which *did*
handle 29 Feb 2000 well.  There were no reports of non-starters on 01 Jan
2001.

  [Quite a few readers noted an AP story in various US sources, including
     http://www.nytimes.com/aponline/technology/AP-Norway-Y2K-Bug.html
  which roughly mirrors the dagbladet item.  PGN]

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

Date: Wed, 3 Jan 2001 13:43:51 -0700 (MST)
From: Steve Hutto <shutto@kata.chezns.org>
Subject: 7-Eleven unable to process credit cards since 1 Jan 2001

The Denver Post reported today
(http://www.denverpost.com/business/biz0103e.htm) that 7-Eleven stores have
not been able to process credit-card transactions since January 1, 2001.
The problem appears to be a faulty date-window fix for Y2K, reading the two
digit current year of "01" as "1901".  A programmatic check in the system
rejects credit cards with expiration dates 100+ years in the future.  One
wonders if they rushed to implement their new information system in order to
be Y2K compliant, deciding to skip low-priority system testing to make the
deadline.  Relevant excerpt from the end of the article:

  7-Eleven's retail information system, which handles almost all of the
  store's operations, from payroll to purchases, was implemented into all of
  its U.S. stores by late 1999.  It was deemed Y2K-compliant.  The home of
  the Big Gulp didn't spend any money to ensure its systems would roll over
  correctly from 2000 to 2001.  [...]

    [Also http://www.washingtonpost.com/wp-dyn/articles/A16320-2001Jan3.html]
       [More likely a special-case fix that worked *only* in 2000, to
       avoid Y2K, as suggested by Jeremy Epstein.  PGN]

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

Date: Wed, 3 Jan 2001 11:30:08 -0500
From: "Berman, Philip" <Philip.Berman@itt.com>
Subject: Y2K+1 bug in Sharp Organizer?

I turned my Sharp YO-550 Electronic Organizer on today for the fist time
since last year.  It displayed an error message that all data was corrupted
and will be erased.  About 4 years of notes and phone numbers lost (yes you
can back it up to a computer - The backup kit cost about the same as the
organizer).  After my initial reaction I turned the unit off and on and it
came up seemingly working correctly although it thought it was 1997.   I
reloaded the current time and date.  Upon turning the unit off and on the
same error condition resulted (Lost all data including current time and
date).  Several times I set the date to 2001 with the same error resulting.
I then (for some strange reason) tried setting the date to 1/1/2000.  The
unit worked correctly.  In fact with several dates prior to 2001 the error
condition never occurred.  If I set the date to 2001 or greater it goes into
error and loses all memory.

I write to RISKS to find out if other owners of Sharp Organizers have
experienced this problem.  I have been unable to reach anyone at Sharp
(Customer Service Phone is always busy) to comment on the problem.

Philip Berman <philip.berman@itt.com>

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

Date: Tue, 2 Jan 2001 12:06:09 -0500
From: "Edelson, Doneel" <doneel.edelson@eulergroup.com>
Subject: Power cut hits hundreds of millions in India

On 2 Jan 2001, the electrical grid for the entire northern region of India
collapsed, affecting 226 million people.  The outage began at a substation
in Uttar Pradesh, and spread to neighboring states (Punjab, Kashmir,
Rajasthan, Haryana and Himachal Pradesh) and to the capital, New Delhi.
Trains, signalling systems, and the New Delhi airport were affected.  Demand
is often greater than supply, but such widespread outages are apparently
unusual.  [PGN-ed; see also
  http://www.cnn.com/2001/ASIANOW/south/01/02/india.blackout/index.html]

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

Date: Thu, 4 Jan 2001 15:46:33 -0800 (PST)
From: Ulf Lindqvist <ulf@csl.sri.com>
Subject: Repeated computer outages for Swedish bank

As reported in various Swedish news media, The Swedish bank Nordbanken has
suffered repeated computer outages during late December and early
January. The outages, each with a duration of several hours, shut down ATMs,
Internet bank services, debit card purchases and office teller services for
Nordbanken's 3.5 million customers.

In an article on the Swedish CNN Web site (cnn.passagen.se) 4 Jan 2001,
Nordbanken CEO Magnus Falk says that the bank still does not know what
caused the outages, but that they are now able to restart their system
faster the next time it crashes...

Ulf Lindqvist, System Design Lab, SRI International, 333 Ravenswood Ave,
Menlo Park CA 94025-3493, USA +1 650 859-2351 http://www.sdl.sri.com/

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

Date: Thu, 28 Dec 2000 16:29:08 -0500 (EST)
From: "Glenn C. Lasher Jr." <glasher@nycap.rr.com>
Subject: Telephone outage caused by water-main break

On Thursday, 28 November 2000, 17 of the 21 telephone exchanges in the City
of Schenectady NY were taken out of service by a water-main break (for those
not familiar with the North American phone system, exchanges uniformly
contain a range of 10,000 phone numbers).  The Central Office serving
downtown Schenectady is located on the block between Franklin and State
Streets and Jay and Clinton Streets.  The water main break was on Clinton
St, and caused the closure of Clinton and State Streets.
The break occurred at 3 AM, and the phones went out around 9 AM.

The cellular telephone networks appear to be unable to cope with the
additional traffic.  I received a frantic call from my wife, who called me
at work from her cell phone to tell me the house phone was out.  The signal
quality was extraordinarily bad, as is the nature of CDMA digital when the
cell is overloaded.  One is left to assume that users of FDMA and TDMA-based
phones may have been cut off completely, especially analog phone users,
where the cells have a hard limit of 20 simultaneous calls.

Meanwhile, my Internet service, provided by TV cable, continues unabated.

So, where do we begin on this one?  Well, here are the RISKS:

1.  Placement of mission-critical equipment below ground level leaves it
susceptible to flooding.  One might assume that an unusually heavy downpour
might also have caused problems here.

2.  This is a good example of network stress, looking at the behaviour of
the cellular networks.

3.  This is also a classic demonstration of a single point of failure.  A
problem in one location has cut off a critical service to an entire
(although small) city.  It does not matter if your service is through the
IBOC (Verizon, in this area) or a CLEC (Sprint, AT&T, Met Tel, to name a
few), all fo the equipment is owned and maintained by the IBOC and housed
at the corner of Franklin and Clinton.

4.  It is also a classic demonstration of diverse paths, as my Internet
service continues to run.  It does not pass through that same building,
but is rather located a mile away on Eastern Parkway (or at least I
believe that is the location).

glasher@nycap.rr.com

  [As an addendum on 29 Dec 2000, the majority of the phone service in the
  city was restored as of this morning, 29 Dec.  During the outage, the city
  was being patrolled by police, DPW trucks, Amateur (HAM) radio operators,
  GMRS radio operators, and telco vehicles.  A command post was set up at
  the city police station to serve as a center of all of these diverse
  communications.

  It is further worth noting that the telco vehicles were equipped only with
  cellular phones for communications.  As mentioned before, the cellular
  networks were next to useless due to traffic overload.  For this reason,
  the ad-hoc radio network that was established became the primary means of
  emergency communication.  This information was gathered by listening on
  two of the frequencies used: 147.06 MHz (the local HAM repeater) and
  462.550 (the GMRS channel that was in local use).  Other frequencies could
  have been monitored as well, but since my monitoring was being sent back
  out through an MP3 broadcaster, the content needed to be constrained.  GCL]

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

Date: Mon, 1 Jan 2001 11:01:13 -0800 (PST)
From: Peter Neumann <Neumann@CSL.sri.com>
Subject: Computer blamed for Russian rocket crash

The Ukrainian space rocket design bureau blamed "computer faults" for the
failure of a Ukrainian Tsiklon-3 light booster rocket that carried 6 small
satellites for the Russian Defense Ministry and space agency Rosaviakosmos.
The rocket engines were shut down 367 seconds after lift-off (presumably
automatically).  [Source: CNN, 1 Jan 2001 (a.k.a. as 1/1/01!!!!); PGN-ed;
http://www.cnn.com/2001/TECH/space/01/01/space.russia.crash.reut/index.html]

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

Date: Wed, 03 Jan 2001 18:12:17
From: "John O'Connor" <jpoc@hotmail.com>
Subject: Chinook: key facts ignored by those who want to clear pilots

The risk of allowing techno mumbo jumbo to get in the way of the truth:

Whenever I read about the Chinook crash on the Mull of Kintyre, I observe
that a number of important facts are conveniently ignored. These particular
facts are not in dispute and they give incontrovertible proof that the
pilots were acting negligently.

Instead, the spectre of some mysterious fault is raised as an argument that
the pilots should be absolved of blame.

A few minutes before the accident, the helicopter was traveling at low level
across the open sea. It was flying under Visual Flight Rules. VFR involves
looking out of the window to see where you are going, which way up you are
and to make sure that you do not hit anything. To operate under VFR,
requires good visibility. (The actual requirements in terms of how many
miles you must be able to see and how far you must be from cloud varies with
aircraft type, pilot qualifications and where you are flying.)

The Mull itself was covered in fog and low cloud and, as the flight neared
the Mull, it entered this area of reduced visibility. Now, at this point,
the crew were in full command of their aircraft and had no technical
problems. There has been no dispute over this.

As soon as they encountered the cloud, the crew must have switched to
Instrument Flight Rules. That means referring to instruments to see which
way is up and to find out where you are and it also means operating at or
above the Minimum Safety Altitude. The MSA is defined as being one thousand
five hundred feet above the highest obstacle on your flight path or within
ten miles either side.

The purpose of these figures is, in part, to give a margin for error but
also to give pilots enough room to get out of trouble. For example, an
aircraft flying inside cloud might suddenly find that it is picking up ice
sufficient to mean that it cannot maintain altitude. By operating at the
MSA, the pilot will have enough room to either side to turn back and fly out
of the icing zone and shed the ice before being forced to the ground.

Now, when the pilots of the accident aircraft encountered the cloud and fog
around the Mull, they were not only below the MSA, they were actually below
the high ground which they were approaching. Given this, the crew were
required to make a 180 degree turn and fly out of the cloud. That is what
they were trained to do. That is what the law required them to do and that
is what the RAF rules required them to do.

Instead, they opted to fly on towards the high ground and attempt to climb
over it. Doing so was inarguably an act of negligence or recklessness that
endangered the aircraft.

The case that is made, that the aircraft may have suffered from some form of
systems glitch that made it incapable of out climbing the rising ground, has
no bearing on this. If the pilots had not made the decision to fly, in
cloud, towards high ground at an altitude lower than the tops of the hills,
the accident would not have happened. The decision that they made went
against both their training and the law.

Suppose that I decided to try to drive through the centre of my town as fast
as I could and that I found that my brakes failed and I crashed and caused
many deaths. Can I say that it was not my fault and that the accident would
have not happened if my brakes had not failed? Of course not. Whether or not
there is a problem with the Chinook is an important matter but it does not
absolve the crew of the helicopter from blame for entering cloud at such a
low altitude. Had they not decided to do that, the accident would not have
happened.

John O'Connor: http://www.jpoc.net

  [In some cases, but not this case, one could ask for a Mull-again
  (mulligan, or do-over, in golf parlance).  PGN]

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

Date: Thu, 04 Jan 2001 11:53:18 -0700
From: "NewsScan" <newsscan@newsscan.com>
Subject: CIOs: "What, Me Worry?"

A national poll of 1,400 CIOs reveals that 90% have confidence in their
network security, despite estimates that billions of dollars are lost every
year to cybercrime. The survey, conducted by RHI Consulting, has raised
eyebrows among security experts who point out that it's generally in a CIO's
best interest to keep quiet when security breaches occur. A recent survey
conducted by the Computer Security Institute indicated that more than half
of the respondents said they did not report the intrusions to law
enforcement out of fear of negative publicity or that rival companies would
use the information to competitive advantage. In addition, many CIOs may
feel that they must live with a "buffer of acceptable risk." "Just as credit
card companies accept some level of loss as a cost of doing business, so
some CIOs are saying, 'if I do a really solid job of protecting my systems,
then I can live with the low-level pain that some break-ins cause,'" says
one expert. Meanwhile, a 1999 survey found that Fortune 1000 companies lost
more than $45 billion in thefts of proprietary information that
year.  [*InfoWorld*, 3 Jan 2001; NewsScan Daily, 4 Jan 2001]

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

Date: Wed, 27 Dec 2000 09:42:45 -0800
From: Andrew Klossner <andrew@cesa.opbu.xerox.com>
Subject: Automatic firmware upgrades in home electronics

Consumer DVD (video) players are also adopting this "load firmware from a
data source" approach.  My Phillips-Magnavox DVD850 will slurp up a new
firmware load from a DVD.  Video DVDs include a good deal of active content,
and the industry seems to expand the programming environment on a regular
basis.  The DVD of the popular movie "The Matrix" wouldn't work at all on
half of the installed players when it shipped in 1999 because it used
up-to-the-minute constructs.

When the authoritarian software forbids me to skip past a
twenty-second copyright notice, it makes me nostalgic for the old
12-inch laser disks.

Andrew Klossner (andrew@cesa.opbu.xerox.com)

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

Date: Thu, 21 Dec 2000 10:36:20 -0500
From: Winn Schwartau <winns@gte.net>
Subject: Hackers hack science exam

Two 8th-grade honor students in Tampa, Hillsborough County, Florida, hacked
into the school computer and copied the final exam for one of their courses.
They have been suspended.  [PGN-ed]

We've wired up the country's schools, put the kids on the Internet, and only
a small handful of teachers have any clue as to what goes on behind the
mouse button. The teachers are not technically trained, they are underpaid
and underappreciated.  Is it any wonder?  And I doubt the kids have been
taught the first thing about CyberEthics by their schools or their parents.

Winn Schwartau

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

Date: Thu, 28 Dec 2000 19:05:17 -0500
From: "Daniel Theunissen" <dtheunis@earthlink.net>
Subject: Re: Seattle Hospital Hacked (RISKS-21.14)

The first response to intrusion news stories by most organizations is almost
formulaic:  deny the attack, make (often false) allegations that this could
never happen HERE, attack the credibility of the source of the news, and
lastly take a stand against such heinous activity.  The response by the UWMC
to the intrusion into their network generally follows the formula.

They started back-pedaling the next day:
"We have received the first tangible evidence from news-gathering
organizations that someone did, in fact, gain criminal access to a limited
number of administrative databases that contain some confidential
information on at least 5,000 cardiology and rehabilitation medicine
patients treated at our hospital," said Tom Martin, director and chief
information officer for University of Washington Medical Centers Information
Systems.
>From MSNBC:  "Hospital Confirms Hacking Incident" 2000-12-8

For more complete coverage, I recommend going to where the story broke:
www.SecurityFocus.com and search on "University of Washington Medical
Center"

The original UWMC announcement, however, is still true.  Read it carefully,
they worded it so that they never actually denied the attack.

Dan Theunissen, dan.theunissen.no.spam@ieee.org

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

Date: Tue, 26 Dec 2000 06:35:10 -0500
From: "Gelsinger, Patrick P" <patrick.p.gelsinger@intel.com>
Subject: Re: IBM and Intel push copy protection ... (Gilmore, RISKS-21.17)

  [Received via Dave Farber, whom Patrick had requested to post a correction.]

Content protection technology misinformation generates negative web-press
coverage:

An article on *The Register* website "Stealth plan puts copy protection into
every hard drive" contains false information that the 4C's (Intel, IBM, MEI,
Toshiba) Content Protection for Recordable Media (CPRM) is to be applied to
all PC hard drives.  It is misinterpreting a specification for use of CPRM
with the Compact Flash media format (which supports either semiconductor
flash memory or IBM microdrives) probably because Compact Flash uses the
same command protocol interface as standard PC harddrives.  The technology
is neither intended nor licensed for use with PC harddrives and is optional
even for the supported media types (flash memory and microdrives). John
Gilmore, a noted privacy and consumer advocate, has picked up the article
and further propagated the erroneous information and mentioned Intel
"IBM&Intel push copy protection into ordinary disk drives".  I have alerted
public relations at Intel and are disseminating accurate information within
Intel and among our industry contacts.

Pat

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

Date: 29 Dec 2000 10:23:55 -0500
From: Gary Lawrence Murphy <garym@canada.com>
Subject: Re: IMPORTANT MESSAGE FROM EGGHEAD.COM CEO (RISKS-21.16)

There is another implicit risk in these stories which I am always
quick to bring to the attention of my would-be B2C e-commerce clients.

Suppose you have 500,000 VISA/MC numbers in your computer, and suppose
you have strong cryptographic SSL connections and all that certificate
jazz to ensure the customer and the e-store are who they say they are.
Let's also say that I am an organized crime boss who knows you have
those charge card numbers and have the means and desire to rack up just
$20 worth of purchase from each of them for a cool fast million dollar
profit ... now (and here's the kicker) what is to stop me from offering
your system administrator some tidy sum (even 10%!) to just slip in
a floppy disk and grab me a copy of the data?

Related to this, I asked a leading e-commerce Web site architect if the DLL
that contained the personal information access username and password might
be used by _any_ program that ran on the server (in java, a class can be
made accessible _only_ to a restricted set of applications). The answer was
that they hadn't thought of that.

Gary Lawrence Murphy <garym@teledyn.com> TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com

  [Simson Garfinkel commented:
    I simply do not understand why companies insist on keeping the old
    VISA/MC numbers in their computers.]

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

Date: Wed, 27 Dec 2000 12:02:24 -0800
From: Crispin Cowan <crispin@wirex.com>
Subject: Re: The risk of a seldom-used URL syntax (Warnock, RISKS-21.16)

This is not new.  Spammers have been using these tactics (both @ in the
domain name, and decimal and octal IP numbers in place of DNS names) to
obscure the actual site hosting their spam content for at least a year.
It's annoying, because it takes extra effort to parse out the true host of
the web site being spammed.  Conversely, its convenient, because it provides
incontrovertable evidence that the post in question is a spam, because there
is no valid reason to obscure an URL in this way other than to hide the
guilty.

Crispin Cowan, Ph.D., Chief Research Scientist, WireX Communications, Inc.
http://wirex.com  Free Hardened Linux Distribution: http://immunix.org

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

Date: Thu, 28 Dec 2000 18:24:42 -0500
From: "Richard M. Smith" <rms@privacyfoundation.org>
Subject: The top 10 privacy stories of 2000

It's the end of the year and time for everyone's top 10 list.  The Privacy
Foundation just released today its top ten list of privacy stories for the
year 2000.

Our press release is online at:
   http://www.privacyfoundation.org/release/top10.html

Richard

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

Date: Fri, 15 Dec 2000 08:16:00 -0800
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: Stefan Brands: PKI, digital certificates, and privacy

Rethinking Public Key Infrastructures and Digital Certificates:
Building in Privacy
Stefan A. Brands
ISBN 0-262-02491-8
For more information, please visit
  http://mitpress.mit.edu/promotions/books/BRAUHF00
[from which this is taken.  PGN]

As paper-based communication and transaction mechanisms are replaced by
automated ones, traditional forms of security such as photographs and
handwritten signatures are becoming outdated. Most security experts believe
that digital certificates offer the best technology for safeguarding
electronic communications. They are already widely used for authenticating
and encrypting e-mail and software, and eventually will be built into any
device or piece of software that must be able to communicate securely.
There is a serious problem, however, with this unavoidable trend: unless
drastic measures are taken, everyone will be forced to communicate via what
will be the most pervasive electronic surveillance tool ever built. There
will also be abundant opportunity for misuse of digital certificates by
hackers, unscrupulous employees, government agencies, financial
institutions, insurance companies, and so on.

In this book Stefan Brands proposes cryptographic building blocks for the
design of digital certificates that preserve privacy without sacrificing
security. Such certificates function in much the same way as cinema tickets
or subway tokens: anyone can establish their validity and the data they
specify, but no more than that. Furthermore, different actions by the same
person cannot be linked. Certificate holders have control over what
information is disclosed, and to whom. Subsets of the proposed cryptographic
building blocks can be used in combination, allowing a cookbook approach to
the design of public key infrastructures. Potential applications include
electronic cash, electronic postage, digital rights management, pseudonyms
for online chat rooms, health care information storage, electronic voting,
and even electronic gambling.

Stefan A. Brands is Distinguished Scientist at Zero-Knowledge Systems,
Inc., Montreal, Canada.

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

Date: Thu, 04 Jan 2001 13:31:07 -0800
From: Monica Ortiz <monica@usenix.org>
Subject: Submission Deadline for USENIX Security Symposium, 1 Feb 2001

10th USENIX Security Symposium 2001 Conference
13-17 August 2001, Washington, D.C., USA
Conference URL: http://www.usenix.org/events/sec2001
Sponsored by USENIX, the Advanced Computing Systems Association
Paper submissions due: 1 February 2001
Program Chair Dan S. Wallach, Rice University
Invited Talks Coordinator Greg Rose, Qualcomm

For more details on the submission process, authors are encouraged to
consult the detailed author guidelines on the symposium website at:
http://www.usenix.org/events/sec01/cfp/guidelines.html

USENIX Security Symposium 2000 is sponsored by USENIX, the Advanced
Computing Systems Association, USENIX is an international membership society.

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

Date: Tue, 02 Jan 2001 07:03:57 -0800
From: Giovanni Vigna <vigna@cs.ucsb.edu>
Subject: Call For Papers - RAID'2001

Fourth International Symposium on Recent Advances in Intrusion Detection
10-12 October 2001, University of California, Davis, CA, USA

  [Abridged for RISKS.  See http://www.raid-symposium.org/Raid2001 for
  complete notice -- and by 31 Jul 2001, the preliminary  program.  PGN]

RAID executive committee chair: Marc Dacier (IBM Research, Switzerland)
Program co-chair: Wenke Lee (NC State University, USA)
Program co-chair: Ludovic Me (Supelec, France)

Full and short papers submitted [by 30 Mar 2001] to RAID must be original
contributions, not published or submitted to other conferences. Full papers
are limited to 6000 words, short papers to 2000, full page figures being
counted as 300 words.  [...]

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

Date: 26 Dec 2000 (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 DIRECT E-MAIL REQUESTS to <risks-request@csl.sri.com> with one-line,
   SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
   INFO     [for unabridged version of RISKS information]
 .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].
 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 21.18
************************


[: hacktivism :]
[: for unsubscribe instructions or list info consult the list FAQ :]
[: http://hacktivism.tao.ca/ :]