Risks Digest 21.10

[risks@csl.sri.com]

[: hacktivism :]

RISKS-LIST: Risks-Forum Digest  Tuesday 7 November 2000  Volume 21 : 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/21.10.html>
and by anonymous ftp at ftp.sri.com, cd risks .

  Contents: [Election Day special edition]
Pennsylvania county wins $1M for faulty computer voting machines
  (David Banisar)
Thoughts on computers in voting (Douglas W. Jones)
Security of electronic voting in public elections (Avi Rubin)
Saturn made a bad assumption in my engine (William Colburn)
I crashed because my phone was ringing (Scott Gregory)
Unplanned roll in NASA's X-38 (James H. Paul)
*Lack* of barcode causes train to trap passengers (Jeff Stieglitz)
No security in Internet-connectable laboratory instrument controller 
  (Stephen D. Holland)
Risk of using 'meaningful' file names (Charles Bryant)
Re: Typo+"strange glitch"=private files world-readable (Steve Summit)
REVIEW: "Virus Proof", Phil Schmauder (Rob Slade)
Abridged info on RISKS (comp.risks)

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

Date: Thu, 2 Nov 2000 09:24:10 -0500
From: David Banisar <banisar@2rad.net> 
Subject: Pennsylvania county wins $1M for faulty computer voting machines

A federal jury awarded Montgomery County, Penn., more than $1 million 
Wednesday in a suit against an Indiana company that sold the county 
900 computer voting machines that repeatedly broke down. The jury 
found MicroVote Corp. breached its implied warranties, but rejected 
all of the county's other claims, including fraud and breach of 
contract. The county had sought $4.3 million against the company.
[Source: *The Legal Intelligencer* <from http://www.law.com>]

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

Date: Tue, 7 Nov 00 16:43:41 CST
From: "Douglas W. Jones" <jones@cs.uiowa.edu>
Subject: Thoughts on computers in voting

It's election day, and as chair of the Iowa State Board of Examiners for
Voting Machines and Electronic Voting Systems, it seems like a fair time to
pause and think about the state of the art.

Over the past several years, an important trend has been evident in the
voting machines that have come before our board for approval in Iowa.  This
is the replacement of custom-built software with off-the shelf commodity
software, usually some variant of Windows and largely dependent on Microsoft
Office.

Computers in voting machines are old technology at this point, whether
they're used for central count systems based on punched cards or mark sense
readers, or whether they're precinct count systems based on mark sense or
direct recording electronic voting machines.  There are still lever machines
in use, of course, but those haven't been changed in years and therefore, we
don't see them coming up for examination.

Under the current Federal Election Commission guidelines for electronic
voting systems, all custom-built software is subject to examination by an
independent third party.  On the other hand, "industry standard components"
are acceptable, as is.  The FEC has no enforcement power, but the FEC
guidelines have been enacted into the voting law of numerous states.

The reason this concerns me is that we see a larger and larger fraction of
the software inside the voting system becoming proprietary product of a
third party and exempt from the requirement that it be available for a
source code inspection.  Furthermore, the size of commercial operating
systems is immense, so an effective inspection is very hard to imagine!

What threat does this present?

If I wanted to fix an election, not this year, but 4 years from now, what I
might do is quit my job at the University of Iowa and go to work for
Microsoft, seeking to insinuate myself into the group that maintains the
central elements of the window manager.  It sounds like it might be fun,
even if the job I'd need would largely involve maintenance of code that's
been stable for years.  My goal:

I want to modify the code that instantiates a "radio button widget" in a
window on the screen.  The specific function I want to add is: If the date
is the first tuesday after the first monday in a year divisible by 4, and if
the window contains text containing the string "straight party", and if the
radio buttons contain, at least, the strings "democrat" and "republican",
one time in 10, at random, switch the button label containing the substring
"democrat" with any of the other labels, at random.

Of course, I would make every effort to obfuscate my code.  Obfuscated
coding is a highly developed art!  Having done so, what I'd have
accomplished is a version of windows that would swing 10 percent of the
straight party votes from the Democratic party to the other other parties,
selected at random.  This would be very hard to detect in the election
results, it would be unlikely to be detected during testing, and yet, it
could swing many elections!

This is just one example attack!  There may be similar vulnerabilities, for
example, in the off-the-shelf database packages being used for ballot
storage and counting.

I don't mean to this example to reflect any ill feelings toward Microsoft,
but it is true that their software is used in the vast majority of new
voting systems I've seen.  This threat does not require any cooperation from
the vendor of the window manager or other third party component exempt from
source code inspection.  All it requires is a mole, working their way into
the vendor and producing code which is not detected by the company's
internal testing and inspection.  Obfuscation is easy, and the art of the
"easter egg" in commercial software makes it very clear that huge numbers of
unofficial features are being routinely included in commercially released
software without the cooperation of the software vendors.  (OK, I know that
some easter eggs are officially approved.)

Having said this, it is worth noting that Microsoft has indicated a
preference about the outcome of today's presidential election, and there are
excellent reasons to treat proprietary software produced by a partisan
agency with great suspicion when it is included in a voting system!

My conclusion?  The time has come for computer professionals to press for a
change to the guidelines for voting machines, asking that all software
included in such machines be either open source, available for public
inspection, or at least open to inspection by a third party independent
testing authority.  There are no technical obstacles to this!  Linux, Free
BSD and several other fully functional operating systems are available and
will run on the hardware currently being incorporated into modern voting
machines!

But, this is not the end of the problem!  How do you prove, after the fact,
that the software in the voting machine is the software that was approved by
the board of examiners and tested by the independent testing authority?  No
modern machine I'm aware of makes any real effort to allow this proof,
although several vendors do promise to put a copy of their source code in
the hands of an excrow agency in case a question arises.

Doug Jones <jones@cs.uiowa.edu>  http://www.cs.uiowa.edu/~jones/voting/

  [Note: Doug, Rebecca Mercuri <Mercuri@gradient.cis.upenn.edu> is just
  putting the finishing touches on her PhD thesis on the subject of
  electronic voting, at the University of Pennsylvania.  I highly recommend
  you contact her for a copy, which should be available very soon.  For
  everyone else, we will announce it here when the thesis is ready.  Also,
  my book *Computer-Related Risks* has lots of background on risks in
  electronic elections and what to do about them.  Rebecca has carried the
  analysis much further than I did.  Her thesis will be a very valuable
  contribution that significantly raises the bar as to what should be
  demanded, not just hoped for, plus an analysis of the residual risks that
  would still remain.  PGN]

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

Date: Fri, 20 Oct 2000 15:46:02 GMT
From: rubin@research.att.com (Avi Rubin)
Subject: Security of electronic voting in public elections

I recently participated in an interesting workshop sponsored by the NSF by
request of President Clinton on the feasibility of e-voting in public
elections.  The workshop web page is http://www.netvoting.org/

>From the Web site: 

"On October 11 & 12, 2000, the Internet Policy Institute (IPI) will conduct
a workshop to examine the issues associated with conducting public elections
via computer networks.  Sponsored by the National Science Foundation (NSF)
and chaired by C.D. Mote, Jr., president of the University of Maryland,
this workshop is part of a request by the White House to study the
feasibility of Internet voting."

It was a collection of technical experts, Social Scientists, election
officials, the Department of Justice, and the NSF.  The workshop was
fascinating. The technical participants were:

Erich Bloch, Washington Advisory Group
Lorrie Cranor, AT&T Labs - Research
Michael Fischer, Yale University
Dan Geer, @Stake, Inc.  
Lance Hoffman, George Washington University
David Jefferson, Compaq Systems Research Center
Carl Landwehr, Mitretek Systems, Inc.
Raymond Miller, University of Maryland
Adam C. Powell, III, The Freedom Forum
Ron Rivest, Massachusetts Institute of Technology 
Avi Rubin, AT&T Labs - Research
Barbara Simons, Association for Computing Machinery 

I spoke about security challenges/risks associated with remote
electronic voting related to host security and Internet
availability. I was asked to write up my comments. The paper
is available at http://avirubin.com/e-voting.security.html

Avi Rubin  http://avirubin.com/

  [Added at PGN's request]

The workshop (http://www.netvoting.org/) held in October in DC was
sponsored by the NSF by directive from President Clinton to study the
feasibility of electronic voting in public elections. Subject matter
experts were invited from the social science community, the technical
and security community, election officials, and representatives from the
department of justice. The meeting was chaired by Dan Mote, the
president of the University of Maryland.

Panels were held discussing issues such what e-voting means, whether or
not e-voting would improve accessibility, whether it would widen the
digital devide, and whether more people would vote. On the technical
side, there were panels about the security requirements, the current
state of security on desktops as related to voting.

The mandate was to cover the following issues:

* How to ensure the security and reliability of the voting process; 
* How to protect the privacy of voters; 
* How to authenticate voter identity; 
* How to achieve broad and equitable access to online voting systems; 
* How to assess the impact of online voting on representative democracy
  and community; and 
* How to ensure that online voting systems are convenient, flexible, and
  cost-effective. 

The group is going to produce a report that will be submitted to the White
House and to Congress and to election officials all over the country.

My participation was as a panelist on security. I wrote up my comments.
They are available at http://avirubin.com/e-voting.security.html 

Avi

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

Date: Tue, 7 Nov 2000 13:33:56 -0700
From: "Schlake ( William Colburn )" <schlake@nmt.edu>
Subject: Saturn made a bad assumption in my engine

I have a 1-year-old Saturn.  As a safety feature, my Saturn will prevent me
from going faster than is safe with my suspension or tires.  When I first
got the car, I had to try this feature out, so I found a long straight road
and floored it.  When I got to 105MPH the engine lost power and I slowed
down.  Experimentation revealed that I couldn't regain power until I dropped
below 100, then I could accelerate again.

A couple of days ago I drove through a fairly steep chasm with a road
straight down one side and up the other.  I figured I needed as much
momentum as possible, so I pushed the clutch in and coasted down.  Somewhere
along the way I hit 105MPH.  Just as I was starting up the opposite side I
noticed that virtually all of my warning lights were on, and the engine was
at 0RPM.  A still engine means no power steering and no power brakes.  I'm
quite glad there weren't any turns or traffic that might have forced me to
turn or brake.

The problem was the assumption that I got to an excessive speed by using the
engine to accelerate.  The default action works great when the clutch is
engaged.  In my case, I ended up with a car that suddenly became very hard
to control when I was already doing something unsafe.

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

Date: Mon, 23 Oct 2000 13:44:00 -0400
From: "Gregory, Scott" <Scott.Gregory@CIBC.CA>
Subject: I crashed because my phone was ringing

On Yahoo news today, they carried this message from the Reuters feed 
"Smart Tires to Warn Drivers Via Mobile Messages". 
http://dailynews.yahoo.com/h/nm/20001023/tc/tires_phones_dc_1.html
     
It details impending tire developments from Finland to put Bluetooth enabled
chips in their product.  The tire will phone the driver if the pressure
drops too low.  Future developments include detection of wear, as well as
hydro-planing (tire losing contact with the road due to water).
     
Standard security type risks, which phone gets the message?
     
Even better, timing and distraction risks.  Like the fighter pilot with so
much information that they cannot cope, the modern driver may soon have a
phone ringing that they are losing control of the car.
     
"Really officer, it was an important call from my car that I had to answer.
And see, I did hit the tree it told me I was going to."
     
Reading my analog speedometer.  sdg

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

Date: Mon, 6 Nov 1972 16:46:10 -0500 (EST)
From: "James H. Paul" <jpaul@CapAccess.org>
Subject: Unplanned roll in NASA's X-38 

*Aviation Week & Space Technology*, 6 Nov 2000, p. 24

"NASA's X-38 Vehicle 131R did a slow, 360-deg. roll after release from its
B-52 carrier aircraft on Nov. 2.  It was the first free flight of the
vehicle, which automatically stabilized under the preprogrammed deployment
of a drogue chute and made a successful landing under parafoil on a dry
lakebed runway, as scheduled, at Edwards AFB, Calif.  The vehicle sustained
no damage in the test.  Project officials said they would have to do some
trouble-shooting to figure out why the Crew Return Vehicle (CRV) prototype
rolled at an estimated average rate of about 20 deg. per sec. during its 24
sec. of scheduled free flight.  A software problem in the vehicle's flight
control system was suspected, although project officials were also looking
at whether aerodynamic disturbances immediately after separation might have
played a role.  Actual separation from the B-52 was clean, and the flight
control system maintained angle of attack throughout the 18-sec. roll.  The
vehicle is an 80%-scale version of the CRV designed to provide emergency
escape for International Space Station crews."

There's an F-16 test pilot somewhere thinking, "Been there, done that."

James Paul  Annandale  Virginia <jpaul@capaccess.org>

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

Date: Fri, 20 Oct 2000 15:09:22 -0700
From: Jeff_Stieglitz@toyota.com
Subject: *Lack* of barcode causes train to trap passengers

  Dozens of travelers were stuck on an underground passenger train at Denver
  International Airport on 19 Oct 2000 after a computer problem sent the
  train shooting past the main terminal.  It took workers about 20 minutes
  to move the train to a station, where passengers got off. No one was
  injured.  A circuit board on the automated train lost its memory and
  failed to read a bar code that signals it to stop.  The train overshot the
  station and safety mechanisms kicked in.  [Source: AP item, 20 Oct 2000,
  PGN-ed]
  http://www.cnn.com/2000/WORLD/europe/france/10/20/france.trial/index.html

The RISKS archives are of full of engineering designs without fail-safe
features.  One would think that the train would have a hardware interlock to
stop the it if something disturbed the computer.  Fail-safe also suggests that
sensor events are required to enable and maintain motion rather than stop it.
The lack of sensor input or keep-alive should result in a graceful shutdown.

I'd guess that this train requires a computer to unlock the doors, rather
than a fail-safe design that would require the computer to keep them locked.

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

Date: Fri, 20 Oct 2000 15:36:25 -0400
From: "Stephen D. Holland" <sdh4@tam.cornell.edu>
Subject: No security in Internet-connectable laboratory instrument controller

National Instruments (http://www.ni.com) sells a device for gatewaying
between ethernet (TCP/IP) and the IEEE-488 (GPIB) bus commonly used for
controlling laboratory instruments, such as oscilloscopes, voltmeters,
motion-controllers, etc.

I was somewhat astounded, upon purchase of this device, to find that it had
no security whatsoever. That is, if you properly configure it and attach it
to your instruments, anyone in the world with the proper software can
control your lab equipment. Worse, there is no mention in any of the
documentation or marketing materials that security is an issue.

The manual even suggests "If you are directly linked to the Internet... you
can contact the... support department to update your firmware." without any
consideration of the risks of the device being connected. Marketing
materials also promote Internet-connected use without discussion of the
risks involved.

Securing this device requires putting it on its own ungatewayed ethernet
segment. This is not mentioned in the manual, and reduces the utility of the
device (cannot share existing wiring).

The RISKS:
     - End users could unknowingly assemble systems that are open to
       attack or accidental disruption by intruders. Most laboratory
       scientists are not particularly well-versed in the minutiae of
       network security. As GPIB is commonly used for mechanical control,
       there is the real danger of physical damage. 
     
     - Security issues are still sufficiently esoteric that a respected 
       and generally competent company such as National Instruments 
       can develop (and market for several years) a device for the 
       Internet that has no security whatsoever. 

I am hoping that National Instruments can develop a firmware update 
that adds at least a minimal passcode for access control. 

Steve Holland, Dept. of Theoretical and Applied Mechanics, Cornell University
sdh4@tam.cornell.edu

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

Date: 5 Nov 2000 23:36:26 -0000
From: Charles Bryant <ch@chch.demon.co.uk>
Subject: risk of using 'meaningful' file names

A Milton Keynes Council worker sent a reply to one or more people who were
commenting on proposals for a travelers' halting site. The letter had an
embarrassing addition to the intended text. In small letters at the bottom
was the file name: "H:\Gypsy letter to whingers.doc".

Of course this risk is equally the risk of not proof-reading a printed copy.

Charles Bryant - ch@chch.demon.co.uk

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

Date: Sat, 4 Nov 2000 06:30:37 -0800 (PST)
From: scs@eskimo.com (Steve Summit)
Subject: Re: Typo+"strange glitch"=private files world-readable (RISKS 21.09)

I'm not sure why "no one was sure exactly what triggered the glitch".  It's
reasonably obvious what happened: a sensitive file was accidentally left in
a directory the web server could get to, the local search engine dutifully
indexed it, and from then on it was sitting there just waiting for someone's
search to unearth it.

Steve Summit <scs@eskimo.com>

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

Date: Mon, 23 Oct 2000 08:18:27 -0800
From: "Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca>
Subject: REVIEW: "Virus Proof", Phil Schmauder

BKVRSPRF.RVW   20000711

"Virus Proof", Phil Schmauder, 2000, 0-7615-2747-8,
U$34.99/C$48.95/UK#32.49
%A   Phil Schmauder
%C   3875 Atherton Road, Rocklin, CA   95765-3716
%D   2000
%G   0-7615-2747-8
%I   Prima Publishing/Jamsa Press
%O   U$34.99/C$48.95/UK#32.49 800-632-8676 www.primapublishing.com
%P   273 p. + CD-ROM
%T   "Virus Proof: The Ultimate Guide to Protecting Your PC"

On the very first page of this book we are told that viruses are written to
steal or destroy "information that resides on your disk."  (Viruses are
written to reproduce.)  The text then contradicts itself by saying that
viruses may just print a message.  Then we are told that you should never
run programs downloaded from the Internet (downloading infected program
files has always been a relatively trivial vector).  Along the way we are
told such vital information as that viruses must get into your computer's
RAM in order to do damage (*everything* has to get into your computer's RAM
in order to do anything) and that viruses are exchanged on disks or
transferred files (that pretty much covers the field of data transport,
wouldn't you say?)

Welcome to "Virus Proof," a collection of mistaken, valid, useless, and
repetitive information.  Sharp-eyed readers will have noted the inclusion of
"valid" in that list.  Unfortunately, you will have to be much more acute to
pick out the true facts from the volume under discussion.  As the old saying
goes, if you can tell good advice from bad advice, you don't need any
advice.

Some of the errors in the book simply show that the author has not done his
homework.  (There is no evidence to suggest that the Michelangelo virus was
written to "commemorate" the birth of Michelangelo the artist.  The
researcher who first reported the existence of the virus learned that the
target date of March 6 was Michelangelo's birthday, and so used that name as
a convenient label.)  Some of the errors in the book are more seriously
misleading.  (The Michelangelo virus did not "occur" on March 6, 1992.  It
was, fortunately, discovered long before, possibly existed before March of
1991, and still results in regular computer erasures every March 6th to this
date.)

The author does keep telling the reader not to use any data file, or run any
program, until it has been scanned for viruses.  That is good advice, as far
as it goes.  Unfortunately, it isn't very useful advice, and the constant
repetition of that single injunction is likely going to dull the reader to
the necessary finer points.

The directive to scan everything isn't the only thing that gets repeated in
the book.  The first chapter manages to tell us once per page that computer
programs are lists of instructions.  Now, that statement is true: programs
are sets of commands.  But that bald assertion provides the normal computer
user with no insight that could help with virus protection.  One would think
that the space dedicated to this piece of trivia could more helpfully be
employed in presenting an accurate definition of viruses, or a list of the
ways that you are more likely to get a virus these days.

In only four pages, chapter two presents serious misinformation.  A boot
sector does not show up on a list of files on a disk.  Boot sector infectors
can infect non-bootable, and even "blank" disks.  Trojan horse (or just
"trojan") programs do not reproduce.  A file infecting virus is not referred
to as a "Trojan Horse virus."  The definition given for a worm (if you are
making a distinction the term "worm virus" makes no sense) clearly
contradicts the declaration that a worm could also be a file infector.  Most
macro languages are not capable of supporting a successful virus: to date,
only those written for Microsoft applications have presented any danger.

And so it goes.  Virus writers don't need your password, and system security
breakers (who dearly love the confusion of the term "hacker") don't bother
with viruses.  Being the first on your block to upgrade to new versions of
programs can have drastic security risks itself.  If you are not supposed to
run anything you download from the Web, why are you supposed to upgrade your
software over the Internet?  Since viruses are appearing at the rate of
hundreds per month, keeping up with the few that make it into [large AV
corporation]'s press releases is unlikely to be very useful.  Mailing lists
and newsgroups are recommended without any analysis.  Most recent email
viruses and worms harvest addresses for regular correspondents, so the
direction to avoid email attachments from someone you don't know is almost
worthless.  Firewalls have nothing to do with viruses.  If a virus infects a
system file, knowing what programs are running on your computer is useless.
Many loopholes have been found in the security of ActiveX controls:
restricting operation to signed controls provides very little protection.
Backups will help you recover if hit, but provide no inherent virus
protection.  Knowing how to break into systems will not protect you from
viruses, nor will seven pages of C source code for a variant of the Crack
program.  (For those script kiddies eager to learn how to break into
systems, save your money.  It doesn't tell you that, either.)  Phone
phreaking isn't that easy, trying the stuff in the book can get you
arrested, and it has nothing to do with viruses.  (And John Draper's own
account, given on the site illustrated, contradicts the story in the book.)
Chernobyl is a variant of CIH, and not the other way around.  Backing up the
Registry provides no inherent virus protection.  Anonymizers for email and
Web browsing have nothing to do with viruses.  Cookies have nothing to do
with viruses.  (Many of the points made about cookies are incorrect as
well.)  Happy99 used Usenet news, as well as email.  Spam has almost nothing
to do with viruses (and most of the recommended actions are not only
useless, but will annoy people who have better things to do).  The material
on virus hoaxes is limited, physically hard to read (small print), and has
no real analysis.  Chat has nothing to do with viruses.  Denial of service
attacks have little to do with viruses, chapter sixteen has *nothing* to do
with viruses, and neither do six pages of SYNattack source code.  Privacy
has nothing to do with viruses (and chapter seventeen has little to do with
privacy).  Email encryption has nothing to do with viruses.  The Melissa
virus was not polymorphic.  Polymorphic viruses do not change their
payloads.  Virus "families" result from virus writers taking a given virus
and making very minor changes to it.  Digital signatures have little to do
with viruses, and chapter nineteen does not discuss key management at all.
JavaScript is not a "cut down" version of Java, and does not have Java's
security model.  E-commerce does not have anything to do with viruses.  Y2K
does not have anything to do with viruses.  And, fortunately, the code
presented in chapter twenty five is nowhere near sufficient to create a
working virus.  (It is enough is create serious problems for the person who
tries to use it.)

Now, of course, a number of the items mentioned do have something to do with
general security.  Unfortunately, the level of detail given in the book is
far from sufficient to protect the user against these threats.  Indeed, the
threats themselves are not described particularly well, and I could go
through a very similar exercise in pointing out the weaknesses in the
general security material.

Given the total size of the book it really isn't a work on viruses.  It
throws together a random assortment of information (and misinformation)
about a variety of security related topics.  Nothing is covered in depth,
and nothing is covered completely accurately.  Approximately half of the
book is occupied with screenshots of miscellaneous Web sites, not always to
do with the topic under discussion (and a number of which are repeated at
random through the work) so this detracts even more from the material that
could have been provided.

A pamphlet on viruses surrounded by some opining on security issues
buried within a lot of careless research.

copyright Robert M. Slade, 2000   BKVRSPRF.RVW   20000711
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: 15 Aug 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/textfiles/risks-digest/ .
==> PostScript copy of PGN's comprehensive historical summary of one liners:
    illustrative.PS at ftp.sri.com/risks .

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

End of RISKS-FORUM Digest 21.10
************************


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