precedence: bulk
Subject: Risks Digest 21.15
RISKS-LIST: Risks-Forum Digest Weds 20 December 2000 Volume 21 : Issue 15
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.15.html>
and by anonymous ftp at ftp.sri.com, cd risks .
Contents:
Wells Fargo computer network outage (PGN)
ATM network for voting: a non-starter (David Jefferson)
Re: Voting by machine (Fred Cohen)
Alaska Airlines flight 261 (Jim Horning)
NY State DMV canceling auto registrations (Danny Burstein)
Another DMV Break-in, in Oregon (PGN)
Healthcare data bank contains inaccurate and flawed information (Mike Beims)
Germany to rely on on-board diagnostics for vehicle emission checks
(Bernd Felsche)
High reliability (Adam Shostack)
Electrocution leads to more deaths (Martin Minow)
Spam as a denial of service attack? (Steve Bellovin)
Re: Seattle Hospital Hacked (Lynda Ellis)
Computers, Freedom, and Privacy CFP2001 Call for Participation (HIIP)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Sun, 3 Dec 2000 21:12:02 PST
From: "Peter G. Neumann" <
[email protected]>
Subject: Wells Fargo computer network outage
On 1 Dec 2000, the nationwide Wells Fargo computer network crashed for a few
hours, three days after WF had finished merging their computer networks with
those of Norwest (which bought WF in 1998). One of four Hitachi Tritium 400
mainframes in the Minneapolis data center shut itself down, apparently after
detecting some sort of anomaly. The result stopped all banking operations
that depend on real-time interaction. [Source: Article by Sam Zuckerman,
*San Francisco Chronicle*, 2 Dec 2000, PGN-ed]
------------------------------
Date: Tue, 19 Dec 2000 20:34:40 -0800 (PST)
From: David Jefferson <
[email protected]>
Subject: ATM network for voting: a non-starter
The suggestion to use the inter-bank ATM (automated teller machine) networks
for voting in public elections has has been floated in several places
recently. From a purely hardware point of view, the ATM network has some
very desirable security properties: It is a private, national-scale network,
unconnected to the Internet, and thus not subject to Internet-based attacks.
The terminals are hardened, and are often equipped with cameras and other
security devices for remote monitoring, and hence are resistant to tampering
(as befits machines carrying tens of thousands of dollars in cash). They
are very rugged and reliable. Many have touch-screens, which allows about
the simplest possible human interface.
However, in a number of other ways the ATM network is not appropriate
for voting. The first problem has to do with voter privacy, coercion,
and vote selling. When a person votes in a private situation (i.e. other
than a public polling place) there is opportunity either for the voter
to be coerced, or to sell his/her vote. Although we live with this fact
for absentee ballots, it is not a good idea to give up entirely on the
strongest election security and privacy measure ever invented: the Australian
secret ballot system in which people are required to vote alone in the
privacy of the voting booth, with public observers to assure that no one
accompanies them to influence them.
A related issue is voter authentication. It is not sufficient to simply
issue voters ID cards with magnetic stripes so they can authenticate
themselves using the ATM machine's bank card reader. This is a clear
case where the requirements for voter authentication are much stronger
than that for financial transactions. People are entitled to authorize
someone else to use their ATM card, since it is common for people to share
access to money accounts. But a voter authentication system must prevent
such sharing, even with a trusted person or a spouse, since the right
to vote is nontransferable. Furthermore, unfortunately, voter ID cards
and PINs can also be sold, opening the door to widespread vote selling.
Stronger authentication than the presentation of a card and PIN must be
required when there are no election clerks around to take voters' hand
signatures (which can be checked against registration records).
By far the greatest concerns, though, with the possible use of the ATM
network for voting, are reliability and security. Even assuming we have
confidence in our ability to design and build reliable, secure distributed
systems in general (a false assumption), an additional fundamental problem
arises in contemplating voting over the ATM network: an irresolvable conflict
in the need to run two independent secure systems (the election system
and the ATM banking system) on the same networked platform at the same
time.
An absolute requirement for the reliability and security of any voting
system is for election officials to control ALL of the hardware, software,
and networking of all clients and servers, including the operating systems
on the voting terminals. (This is the same argument showing why remote
Internet voting is today so hopelessly insecure.)
An exactly symmetric argument applies, of course, from the bankers' point
of view: the security of the ATM system also rests on the fact that they
control ALL of the hardware, software, and networking of their platforms.
If one tried to run both systems on the same terminals and network
concurrently, then either the banking software could act like a giant
Trojan horse inserted into the election system, or vice-versa. Election
officials would worry (rightly) that bank employees or contractors might
insert code to undermine the election; and banking officials would worry
(rightly) that election administrators or vendors would insert code to
steal money! Or the presence of either system might degrade the reliability
or performance of the other. It is a practical impossibility to prove
that the combined system has no bad interactions, and in general it is
just not hopeless to run two mutually-distrusting, mission-critical, high
security systems on the same network platform. The situation is made
even worse (if that is possible) by the fact that ATM software is totally
proprietary; and unless the principle of public source software is
established for elections, the same will be true for election software.
The bottom line, then, is that in order to permit secure voting over the
ATM network, the (many) network owners would have to be willing to turn
it over entirely to election officials for the duration of the election.
Since, quite reasonably, the owners are not about to do that even for
one day, let alone for enough time to build, test, debug, and certify
such a system, the suggestion to use the ATM network for voting is a complete
nonstarter.
David Jefferson, Compaq Systems Research Center, Palo Alto, CA
------------------------------
Date: Wed, 13 Dec 2000 05:09:05 -0800 (PST)
From: Fred Cohen <
[email protected]>
Subject: Re: Voting by machine
In order for any practical election process to really gain assured
trust, it must have several properties:
1) It must be sufficiently simple and open so that the average
person on the street can clearly see exactly how it works,
understand it clearly and fully, and participate in it.
2) It must be observable by all parties at all times so that
there can be no real question about its legitimacy that cannot
be answered by the individuals who were present at the scene.
3) It must produce evidence that cannot be easily altered or
destroyed, that can be judged by non-experts examining it, and
that is not separate from the actual vote - they must be one and
the same.
4) It must be very inexpensive to purchase, maintain, and operate.
The lifecycle cost must be on the order of pennies per vote or less
and it must be easily maintained by untrained people.
5) It must not depend on anything outside itself to operate, like
electrical power, telephone lines, servers, etc.
6) There must not be significant spoilage of supplies or recorded
results - either before or after the fact.
7) It must be physically securable on a local basis by local officials
and police officials.
8) Each voting location must be able to function independently of
all others in every vital aspect of the operation other than the
summarizing of overall votes that cross localities.
9) Each voting location must be able to have unique vote layouts and
candidates to accommodate the wide range of elections that run both
simultaneously and sequentially.
10) The voters must believe that the systems works.
At this point in time, and for the foreseeable future, computerized and
particularly Internet-based voting machines and networked voting systems
do not, and will not, fulfill the majority of these requirements.
1) They are far too complex and full of details for the average
person on the street tun understand at all.
2) The vote goes into a mystery thing and comes out somewhere else
as a total. Nobody at the scene sees it go in or come out.
3) The evidence they produce is easily altered and destroyed and it
requires substantial expertise to even view any evidence it leaves.
Furthermore, that evidence is not in any physical way linked to the
original vote.
4) They are expensive to purchase, maintain, and operate.
The lifecycle cost is on the order of dollars per vote and they
can only be properly maintained by experts.
5) They depend on electricity, network connections, servers, and so
forth.
6) There are no supplies (except power and hardware components that
require maintenance and replacement) but spoilage cannot universally
be detected.
7) The votes not physically securable on a local basis by local
officials and police officials because the system is networked.
8) Each voting location can not function independently of others.
9) Each voting location can have unique vote layouts and candidates
10) I don't believe that the systems work, but most voters may be
fooled into that belief by a sufficient perception management
process.
Fred Cohen at Sandia National Laboratories at tel:925-294-2087 fax:925-294-1225
Fred Cohen & Associates:
http://all.net -
[email protected] - tel/fax:925-454-0171
Fred Cohen - Practitioner in Residence - The University of New Haven
------------------------------
Date: Tue, 19 Dec 2000 10:47:48 -0800
From: Jim Horning <
[email protected]>
Subject: Alaska Airlines flight 261
[FW: Not a computer risk so much as a systemic risk, but interesting. JH]
AVflash Vol. 6, Issue 51a Monday, December 18, 2000
The Top Headlines From AVweb's Expanded, Illustrated News Coverage at
<
http://avweb.com/n/?51a>.
ALASKA AIRLINES FLIGHT 261: THE HEARINGS...
In the aftermath of the January 31 crash of Flight 261, where an Alaska
Airlines MD-80 plunged uncontrollably into the Pacific Ocean after failure
of part of the aircraft's stabilizer assembly, the NTSB is uncovering some
of the shortcomings of a number of systems currently in place. We found out
last week, through official FAA testimony, that the jackscrew assembly (a
1960s design) has outlived its paper trail. FAA officials testified that
they could not provide an account of how the part was approved -- nor could
they provide records of the process which approved it. So, what we are left
with is a part with some 35 years of flight history, but not a single
official record or word on how it came to be approved for installation in
the MD-80.
..WHAT WE KNOW, NOW...
While the design of the jackscrew assembly was supposed to assure that the
failure of any single part within the assembly can *not* result in complete
loss of control, the crash of Flight 261 explains with relative certainty
that the failure of a single part *is* capable of causing failure of other
parts in the assembly and that those multiple failures are quite capable of
bringing down the aircraft. Further, while the manufacturer was aware that
the assembly was subject to continuous wear, they were content in the notion
that regular maintenance could assure its operation. Alaska Airlines was
inspecting the jackscrews every 15 months, but the accident aircraft had
flown 8,874 hours since its last inspection -- well beyond the 7,200
suggested by Boeing. The hearings revealed that the FAA had "accepted" the
carrier's jackscrew maintenance schedule.
..AND WHAT THE CREW SAID, THEN
The pilots radioed their Seattle base seeking advice and relaying their
understanding of the serious nature of the situation. Portions of the
communication that were made public last week indicate that the base
operators were not immediately aware of the magnitude of the problem. This
may have induced some agitation in the cockpit as ground-based counterparts
second-guessed the captain's decision to divert to LAX and the problem
proved its ability to overcome each sequence of corrective measures set
forth by the flight crew. During the aircraft's final dive, the verbal
exchange between the pilots appears to imply that they attempted to
stabilize the aircraft in inverted flight and work with its gyrations to
help them roll it back over and keep the nose near the horizon with rudder
and elevator inputs. But all attempts by the crew to regain control proved
futile as the MD-80 made its final plunge to the ocean.
[PGN-ed: Article in *The New York Times* 18 Dec 2000 noted by Kevin Ziese,
who observed that
"Had the system operators realized that parts replacement is itself a
critical computing function, it's possible that safeguards would have
been in place to generate the appropriate alert in a more timely manner.
This underscores the importance of recognizing 'critical computing'
requirements in all organizations. Even though the system may not be
man critical, it may have a significant impact on safety. Integrated
systems, especially in a network-centric world, need better safeguards
and control mechanisms then the typical software developer provides."]
------------------------------
Date: Mon, 11 Dec 2000 03:29:36 -0500 (EST)
From: danny burstein <
[email protected]>
Subject: NY State DMV canceling auto registrations
The New York State Department of Motor Vehicles (DMV) has a new computer
system that is supposed to help locate uninsured motorists, based on
information provided electronically by insurance companies. Unfortunately,
the database includes drivers who are apparently properly insured -- and who
are very unhappy when they are arrested even if they are carrying valid
proof-of-insurance cards. The DMV blames drivers for not responding to
mailed warnings, although it certainly does not appear blameless, based on
the frequency of complaints. [Source, Ann L. Kim, Insurance Is No Insurance
Against State DMV Glitch *Newsday*, 10 Dec 2000; PGN-ed]
------------------------------
Date: Sun, 18 Dec 2000 22:00:11 PST
From: "Peter G. Neumann" <
[email protected]>
Subject: Another DMV Break-in, in Oregon
On the heels of Paul Nowak's RISKS-21.14 report of the Arizona Motor Vehicle
counterfeiting rings came this somewhat belated report of a break-in at the
Gresham, Oregon DMV office on 12 Dec 2000. The thieves were apparently
pretty well prepared, as they took less than two minutes to take computer
equipment containing personal information on 3,215 people who had recently
obtained licenses, plus blank cards and a machine for making bogus drivers'
licenses and ID cards. [Source: Stuart Tomlinson, *The Oregonian*; PGN-ed.
Was at
http://www.oregonlive.com/news/oregonian/metroeast_week.ssf
?/news/oregonian/00/12/metroeast/e6_dmv15.frame]
------------------------------
Date: Mon, 11 Dec 2000 10:01:55 -0500
From: Mike Beims <
[email protected]>
Subject: Healthcare data bank contains inaccurate and flawed information
From Reuters and Medscape (Reuters Health), 1 Dec 2000:
"The US government's warehouse of disciplinary records and malpractice
actions against physicians and other healthcare practitioners is incomplete
and inaccurate in many cases, congressional investigators conclude in a new
report."
http://managedcare.medscape.com/reuters/prof/2000/12/12.04/20001201legi001.html
The National Practicioner Data Bank is considered by this report to be
seriously flawed and raises a red flag regarding patient privacy.
Like other data banks mentioned in the Risks Digest, when used to track
social issues such as credit, criminal activity, and driving records, these
data banks can be useless and possibly dangerous to everyone involved.
Mike Beims <
[email protected]>
------------------------------
Date: Thu, 14 Dec 2000 09:46:38 +0800 (WST)
From: Bernd Felsche <
[email protected]>
Subject: Germany to rely on on-board diagnostics for vehicle emission checks
*Auto Motor und Sport*, 8 Dec 2000, [a motoring magazine published in
Germany] reports that the emissions compliance inspection of new vehicles
will be performed solely by reading the ODB (on-board diagnostic) codes.
The "testing" regime is to commence no later than July 1st, 2001.
All new gasoline-engined cars are already equipped with OBD, according to
DEKRA [a company which performs vehicle inspections] and all
diesel-engined cars from 2003.
OBD is a self-checking function of engine management systems that
determines whether there are excessive deviations in exhaust emissions
[amongst other factors] by checking plausibility and correlation with
other sensors. A check-engine warning usually alerts drivers of a problem
with various sensors and actuators.
Emission checks can also be performed simply by reading stored error codes
from OBD, specifically if the lambda sensor(s) [aka O2 sensor] functions
correctly and if the catalytic converter is still converting sufficiently.
The simplified "check" is expected to reduce inspection costs to
motorists; by some 70 to 80 German Marks according to DEKRA.
[Loose translation by Bernd from
http://www.autouniversum.de, PGN-ed]
Regular RISKS readers might observe that there are would longer be any
external checks to verify that the system is actually doing what it reports.
Bernd Felsche - Innovative Reckoning, Perth, Western Australia
------------------------------
Date: Mon, 4 Dec 2000 13:51:20 -0500
From: Adam Shostack <
[email protected]>
Subject: High reliability
An article on a new center to study high reliability computing
http://www0.mercurycenter.com/svtech/news/indepth/docs/nasa120300.htm
contains this text:
> current practices in the semiconductor industry. Both are enormously
> complex processes, but the semiconductor industry has figured out a
> way to produce chips with relatively few errors -- at least in
> comparison to the software industry, which typically has from 6 to
> 30 errors per line of code.
Not to mention the journalism industry, with an error rate of 1 error per 6
to 30 bits when reporting technical information... :)
------------------------------
Date: Mon, 18 Dec 2000 23:49:48 -0800
From: Martin Minow <
[email protected]>
Subject: Electrocution leads to more deaths
Two teenagers were electrocuted by "an energized streetlight." After the
electrocution, the county ordered all streetlights extinguished until they
could be rewired. Then, a man was struck and killed by a car while crossing
the darkened street and a motorist killed in a two-car collision in the same
area. [Summarized by Martin Minow,
[email protected]]
<
http://www.miamiherald.com/content/today/news/dade/digdocs/062954.htm>
Quoting from the article:
Some residents complained Sunday that the precautionary order by the
county to turn off the 92 streetlights has made matters worse. Now
passing motorists see only with the illumination from their
headlights. ... It's unclear how long the maintenance work on the
streetlights will take, Miami-Dade spokeswoman Rhonda Barnett said.
[When will they see the light in Miami-Dade? PGN]
------------------------------
Date: Sun, 10 Dec 2000 09:47:13 -0800
From: Steve Bellovin <
[email protected]>
Subject: Spam as a denial of service attack?
According to the AP, Verizon was bombarded by millions of spam messages,
slowing e-mail to its dial-up customers. Verizon believes that "it was a
malicious attack".
--Steve Bellovin
[Doneel Edelson cited *InformationWeek*, 18-25 Dec 2000, page 37:
<
http://www.informationweek.com/817/verizon.htm>
That article notes that 70,000 subscribers had delays up to several hours,
and this was the *third* spam attack against Verizon in two weeks. PGN]
------------------------------
Date: Wed, 13 Dec 2000 10:52:10 -0600 (CST)
From: "Lynda Ellis (LabMed)" <
[email protected]>
Subject: Re: Seattle Hospital Hacked (RISKS-21.14)
Here's the response from the University of Washington,
Health Sciences and Medical Affairs, News and Community Relations, 7 Dec 2000
The following statement is for attribution to Tom Martin, director and chief
information officer for University of Washington Medical Centers Information
Systems:
An Internet-based news service yesterday netcast a rumor that 'a hacker
took command of large portions of the University of Washington Medical
Centers internal network earlier this year.' Unfortunately, this rumor was
reported as fact. However, it is completely inaccurate.
Last summer, we halted an unknown hacker who had gained criminal entry
into portions of our academic computer system. This is the only incident
we are aware of that bears any resemblance whatsoever to the report in
yesterdays SecurityFocus News. While we have no evidence that confidential
data were obtained as part of that incident, we do know for certain that
no one has ever gained unauthorized entry into our separate and highly
confidential patient-care computer systems.
The UW and most other universities make limited use of firewall technology
and are under constant assault by recreational hackers. Recognizing this,
we take extraordinary measures to protect our clinical-based systems that
go well beyond the high security employed, for example, by most community
hospitals. These measures include the latest hardware and software,
encryption technologies, and strong host-based security.
As the incident we detected last summer illustrates, we are constantly
vigilant for hacker attacks on all of our computer systems. We believe
that rumors such as the one given credence in yesterdays netcast only
encourage recreational hackers to pursue their criminal activity."
For more information, contact L.G. Blanchard or Walter Neary, 1-206-543-3620
------------------------------
Date: Fri, 15 Dec 2000 14:37:45 -0500
From:
[email protected]
Subject: Computers, Freedom, and Privacy CFP2001 Call for Participation
CFP2001: The Eleventh Conference on Computers, Freedom and Privacy
Hyatt Regency Cambridge
Cambridge, Massachusetts, USA
March 6 - 9, 2001
CALL FOR PROPOSALS
The Program Committee of the Conference on Computers, Freedom, and Privacy
(CFP2001) invites your participation and proposals for the eleventh annual
CFP, which will be held at the Hyatt Regency in Cambridge, Massachusetts,
USA, on March 6 - 9, 2001.
CFP2001 is sponsored by the Association for Computing Machinery (ACM).
CFP is the leading policy conference for exploring the impact of the
Internet, computers and communications technologies on society. �For more
than a decade, CFP has anticipated the policy trends and issues and shaped
the public debate on the future of privacy and freedom in the online world.
Each year at CFP, key members of the technical, government, business,
education, non-profit, legal, law enforcement, security, media and
hacker/cracker communities gather together to address the cutting edge
questions in computing, freedom and privacy. �CFP themes are broad and
forward-looking. CFP explores what will be, not what has been.
Since this CFP will be held in 2001, the theme is the future of computing,
freedom and privacy, including the convergence of information and
communication technologies with other advanced technology areas and the new
challenges to freedom and privacy that they engender throughout the world.
The Internet is a global phenomenon with significant local impacts. We
encourage innovative and imaginative thinking on these topics and invite
you to submit proposals for CFP2001 conference activities. �Of particular
interest are proposals on:
GOVERNANCE, including impact of the Internet on governance; impact of
governance on the Internet; ICANN; voting; standards; antitrust and
competition policy; new models for governance; and stakeholders in
governance.
SOCIAL IMPACTS, such as the relationship between the individual and her
communities.
INDIVIDUAL AUTONOMY AND INTEGRITY, particularly human rights; freedom of
expression; censorship; free speech and access; freedom of association;
freedom of movement; and exploration of the roles of non-identifiability,
pseudonymity, and anonymity.
CONVERGENCE of information and communication technologies (ICT); of ICT and
content; of ICT with other advanced technology areas, including
biotechnology, biology and materials science; and related industry mergers,
consolidations and activities.
DIGITAL DIVIDE in the face of the growth of the ubiquitous information
environment; access to the network infrastructure; access to information;
broadband policy; education policy; and related telecommunications, cable,
intellectual property and freedom of information (FOIA) rules.
PRIVACY, including the growth and role of the chief privacy officer; privacy
as the default; US legislation; international developments and trends; and
an international privacy convention.
INTERNATIONAL ISSUES, especially the emerging issues of global privacy
protection; international principles of human rights; security of
information systems; intellectual property; objectionable content;
cybercrime; jurisdiction; regulation; and legislation.
ELECTRONIC COMMERCE, including consumer protection; and the impact of
payment systems, regulations, and technical standards on personal freedom
and privacy.
We encourage proposals not only on these subjects, but also on the border
areas between these topics, such as intellectual property protection and
privacy.
We strongly encourage proposals that involve leading experts, innovators,
policymakers, and thinkers.
CFP2001 PROPOSAL SUBMISSION GUIDELINES
Proposals should be submitted no later than January 5, 2001, via the
CFP2001 website at
http://www.cfp2001.org.
Proposals should include the following information:
1. PRESENTATION TITLE
2. PRESENTATION TYPE
Plenary conference sessions (30 minutes to 1.5 hours)
Lunch breakout sessions (1 hour)
Tutorials (3 hours)
BOFs ("birds of a feather" sessions) (no time limit)
3. PROPOSED LENGTH OF PRESENTATION
4. NAME(S) OF SPEAKER(S), PLUS BRIEF BACKGROUND DESCRIPTION FOR EACH
SPEAKER
5. A BRIEF DESCRIPTION (no more than 100 words) OF THE TOPIC AND FORMAT,
suitable for conference brochure and press release.
6. COMPLETE CONTACT INFORMATION (e-mail, phone, and mailing address). For
presentations with more than one speaker, please include complete contact
information for all the proposed speakers.
We encourage a variety of formats, including panels, debates, individual
speeches or keynotes, interviews, role plays, reverse role plays, case
studies, Socratic dialogues, etc.
DEADLINE FOR SUBMISSION OF PROPOSALS
All proposals must be received no later than January 5, 2001. Please
follow the submission guidelines above.
PLEASE SUBMIT PROPOSALS AT
HTTP://WWW.CFP2001.ORG.
For additional information about CFP2001, please visit the conference
website at
http://www.cfp2001org.
------------------------------
Date: 15 Aug 2000 (LAST-MODIFIED)
From:
[email protected]
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 <
[email protected]> 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 <
[email protected]> (Dennis Rears).
.UK users should contact <
[email protected]>.
=> 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
[email protected] 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/ .
==> PostScript copy of PGN's comprehensive historical summary of one liners:
illustrative.PS at ftp.sri.com/risks .
------------------------------
End of RISKS-FORUM Digest 21.15
************************
