The RISKS Digest
Volume 21 Issue 14

Tuesday, 12th December 2000

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


Internet and Electronic Voting
PGN Rebecca Mercuri Lauren Weinstein
Re: Perspective on election processes
Ben Laurie
Arizona Motor Vehicle counterfeiting rings
Paul Nowak
Seattle Hospital Hacked
Lauren Gelman
A new Chinook inquiry?
Mike Ellims
Another Osprey crash
Space Station risks
Ben Hines
comp.risks considered harmful — by some
Thomas Roessler
REVIEW: "Hack Proofing Your Network", Ryan Russell et al.
Rob Slade
Info on RISKS (comp.risks)

IP: Internet and Electronic Voting

<"Peter G. Neumann" <>>
Tue, 12 Dec 2000 17:30:56 PST

  [Reproduced from Dave Farber's IP distribution,
  Date: Tue, 12 Dec 2000 20:36:19 -0500.]

A recurring mantra heard from some entities involved in the development and
promotion of Internet-based voting systems is that they have conducted
"public tests" and thus their systems are secure.  If hackers don't break
into such systems, the tests are declared a success.

This is of course illogical on its face, because it seems unlikely that
people (both U.S. and internationally based) with an interest in subverting
the U.S. election process would care to tip their hands by participating in
what are essentially publicity stunts.  These might attract your average
12-year old hacker, but not the pros who wait for production systems for
their carefully mounted attacks.

In fact, using such "tests" as any sort of validation technique runs
contrary to long-established computer and engineering verification
practices, and makes a mockery of the rigorous design and testing that is
required of systems that are to be deemed secure through extensive and
methodical processes (e.g., to gain certification under the ISO Common
Criteria or its predecessors TCSEC/ITSEC).  "I left my Porsche out in the
parking lot with the doors unlocked and the key in the ignition and since it
doesn't appear to have been stolen this must be a safe neighborhood," would
be an equally nonsensical statement of supposed validation.  All proposed
voting systems should be subjected to rigorous evaluation, public
inspection, and *open-source code* license agreements.  Some applicable
methodologies do exist, but have not been required.  For example, Level 4
Common Criteria should be a *minimum* standard, although even that is not

Security is only as strong as its weakest links.  Internet voting (I-voting)
will *always* be limited in its integrity by factors beyond the I-voting
algorithms.  For example, encryption can be an important part of an overall
election system.  However, although we have strong cryptographic algorithms,
we do not have systems with adequate security into which the cryptography
can be embedded.  Furthermore, voter authentication, vote integrity, voter
anonymity, auditability, accountability, recountability, and so on, are all
involved, and many of these requirements operate at cross-purposes with one
another.  The massive vulnerabilities of standard personal-computer
operating systems represent very serious concerns, in terms of hidden
viruses, worms, Trojan horses, and further surprises unknowingly downloaded
by the user with other packages, and waiting to pounce on election day.  One
proposed solution would be to boot a fresh system from external media in
order to vote, but even such an approach does not adequately address these
potential vulnerabilities.

Deficient network protocols and the opportunities for insider fraud and
accidental misuse abound.  In addition to the issues noted above are the
weaknesses that result from inadequate operational environments.  Neither
the client nor the server systems will be adequately secure under
foreseeable technology — including Internet Service Providers and Web
servers.  For example, proposals such as the use of rotating IP numbers and
multiple systems to try to defend against denial of service attacks can be
rendered impotent by similar attacks on network concentration points.

As always in any election environment, there are many opportunities for
fraud, mischief, and manipulation — despite ostensible checks and balances.
These problems are exacerbated with electronic and Internet voting, where
the lack of any physical ballots makes such manipulations impossible to
detect and correct — because there is no meaningful recount capability.
Extraordinary vigilance is necessary, but never sufficient.

In the wake of the recent Presidential election problems, the knee-jerk
reaction of "gee, can't we modernize and solve all this with electronic
and/or Internet voting?" is predictable, but still wrongheaded.  The shining
lure of these "hype-tech" voting schemes is only a technological fool's gold
that will create new problems far more intractable than those they claim to

Peter Neumann, Rebecca Mercuri, and Lauren Weinstein


Peter Neumann moderates the ACM Risks Forum, Chairs the ACM Committee
  on Computers and Public Policy, and is a cofounder of PFIR --
  People For Internet Responsibility <>.

Rebecca Mercuri is a Professor of Computer Science at Bryn Mawr College.
  She has provided expert testimony on voting systems throughout the past
  decade.  For information on her Penn doctoral thesis and other writings
  on this subject, see .

Lauren Weinstein <> and <> moderates the
  Privacy Forum <> and is a cofounder of PFIR — People
  For Internet Responsibility <>, and Member of the ACM
  Committee on Computers and Public Policy.

Information on the Common Criteria is at
An earlier statement on I-voting is at

Re: Perspective on election processes (RISKS-21.13)

<Ben Laurie <>>
Tue, 12 Dec 2000 13:17:26 +0000

  [From Dave Farber's IP]

> >Date: Sun, 10 Dec 2000 10:19:54 -0800
> >From: Ed Gerck <
> >
> >Dave Farber wrote:
> >
> > > >Date: Sun, 3 Dec 2000 9:59:37 PST
> > > >From: "Peter G. Neumann" <>
> > > >Subject: Perspective on election processes
> > > >
> > > ....
> > > >  * Voting by the Internet, even if only from well established polling
> > > >    places, is and will remain extraordinarily risky because of the
> > inherent
> > > >    untrustworthiness of computer systems attached to the Internet and
> > > >    indeed the networking itself.  It should not be recommended for use
> > > >    in the foreseeable future.
> > > >
> >
> >The concern is justified but Peter ignores that there is a hacker-proof way
> >to make an Internet-connected computer as secure as a non-connected one.
> >The method was made public in its details and fire tested in a week-long
> >24-hour-a-day open attack test — as reported in USA Today, Wired, and
> >in

"Hacker-proof"? Get real - cracker-resistant, perhaps, but what's new?
Safevote has a number of "snake oil" warning signs, including:

a) Use of multiple protocols: "in a real election Safevote would not
know which algorithm is being used for encryption at any precinct",
which is actually a rather silly claim - someone must know, or it would
not be possible to decrypt - but ignoring that point, use of multiple
algorithms merely adds a few bits to the keysize. Since there are not
that many algorithms that are actually any good, this really is very few

b) Use of proprietary algorithms (DVC and friends).

c) Mysterious claims of the properties of a small number of bits ("Each
DVC also contains independent, multiple secure communication channels
such as the voter's password, the ballot style to be used by the voter,
and an internal secret.", yet they are only 30 bits long!).

d) "Cracking test" without disclosure of algorithms ("The specifications
for Safevote's products and services under the Multi-Party technology
will be made fully public and documented with open protocols, protected
by flexible intellectual property rights that allow free non-commercial
use." [note use of future tense]).

e) Existence of this "hacker-proof" technology brought to our attention
by the owner - without bothering to mention this fact.

Of course, it could be great, but at this stage there's no way to tell.

Ben <>

Arizona Motor Vehicle counterfeiting rings

<Paul Nowak - SUPCRTX <>>
Tue, 5 Dec 2000 15:48:29 -0700

  [In the wake of voting irregularities, we have this another license
  fraud case.  Surprised?  PGN]

Thus far, 14 people have been indicted — including four AZ Motor Vehicle
Division customer service employees and an Arizona Department of
Transportation computer information worker.  Several more arrests are
expected, with more arrests expected.  Four groups are accused of issuing
bogus licenses and ID cards, at a cost over $1000 each.  "Buyers apparently
included criminals, illegal immigrants and motorists with suspended or
revoked licenses."  [Source: Article by Senta Scarborough, *The Arizona
Republic*, 25 Nov 2000]

<Lauren Gelman <gelman@EFF.ORG>>
Wed, 6 Dec 2000 19:26:05 -0500
Subject: Seattle Hospital Hacked

Seattle Hospital Hacked

Dutch hacker downloads thousands of patient records.
By Kevin Poulsen
December 6, 2000 3:54 PM PT

A sophisticated hacker took command of large portions of the University of
Washington Medical Center's internal network earlier this year, and
downloaded computerized admissions records for four thousand heart
patients, has learned.

The intrusions began in June, and continued until at least mid-July, before
network administrators at the Seattle teaching hospital detected the hacker
and cut him off. The medical center was purportedly unaware that patient
records were downloaded, and elected not to notify law enforcement agencies
of the intrusions.

"It's a story of great incompetence," said the hacker, a 25-year-old Dutch man
who calls himself "Kane." "All the data taken from these computers was taken
over the Internet. All the machines were exposed without any firewalls of any
kind." reviewed portions of the databases the hacker
downloaded. One of the files catalogs the name, address, birth date, social
security number, height and weight of over four thousand cardiology patients,
along with each medical procedure they underwent. Another file provides
similar information on seven hundred physical rehabilitation patients. A third
file chronicles every admission, discharge and transfer within the hospital
during a five-month period.

"I can say we're investing an incident," said hospital spokesperson Walter
Neary. "We are taking it very seriously."

In a telephone interview, Kane said he did not tamper with any hospital data,
and described his forays into the hospital's network as a renegade public
service aimed at exposing the poor security surrounding medical information.
A self-described computer security consultant by trade, the hacker's illicit
investigation was inspired by a conversation with a colleague, in which they
wondered aloud about how well highly sensitive computers were protected.
"The conversation came around to medical data, which is sensitive indeed,
and I thought I'd have a look around," said Kane.  <...>

Lauren Gelman, Director of Public Policy, Electronic Frontier Foundation
1-202/487-0420   <>

A new Chinook inquiry?

<Mike Ellims <>>
Mon, 4 Dec 2000 10:08:58 -0000

This is an update on an earlier series of postings. Apparently efforts to
have a new inquiry into the Chinook crash on the Mull of Kintyre have been
vetoed by the UK government.

The BBC quotes the  public accounts committee report as saying that " there
were repeated problems with the aircraft and the pilots should be
exonerated" and that "the refit process was flawed".

Full story at,

In an earlier news item they report that in an earlier incident with another
Chinook where no one was killed they report that there are "documents
showing that Boeing, the helicopter's manufacturer, had agreed with software
contractors that the FADEC was the cause of the 1989 accident and that the
system needed to be redesigned".

Full story at,

Mike Ellims
Pi Technology
phone +44 (0)1223 203 913 (direct)
phone +44 (0)1223 441 434 (reception)

Another Osprey crash

<"Peter G. Neumann" <>>
Tue, 12 Dec 2000 08:39:41 -0800 (PST)

Four Marines were killed on 11 Dec 2000 in North Carolina when another
experimental MV-22 Osprey tilt-rotor aircraft crashed.  The remaining eight
Ospreys have been grounded, pending review by an expert panel.  This
followed the loss of 19 Marines in Arizona in the spring 2000.  [Source:
PGN-ed from]

Space Station risks

<Ben Hines <>>
Wed, 6 Dec 2000 01:15:01 -0800

Jim Oberg has written a great article in November's *IEEE SPECTRUM* discussing
many risk issues and failure modes discovered during the recent space
station missions.

It can be found here:

Ben  <>

comp.risks considered harmful (by some)

<Thomas Roessler <>>
Fri, 8 Dec 2000 14:25:34 +0100

This site: <> lists
some results from a reverse-engineering effort against the black list used
by "SmartFilter".  Apparently, comp.risks is being blocked by that software
under the "Criminal Skills" category, as are comp.dcom.telecom,,, comp.protocols.tcp-ip,, and others.

REVIEW: "Hack Proofing Your Network", Ryan Russell et al

<"Rob Slade, doting grandpa of Ryan and Trevor" <>>
Mon, 4 Dec 2000 08:16:41 -0800

BKHPYNIT.RVW   20000831

"Hack Proofing Your Network", Ryan Russell et al, 2000, 1-928994-15-6,
%E   Ryan Russell
%E   Stace Cunningham
%C   800 Hingham Street, Rockland, MA   02370
%D   2000
%G   1-928994-15-6
%I   Syngress Media, Inc.
%O   U$49.95/C$77.50/UK#31.95 781-681-5151 fax: 781-681-3585
%P   450 p.
%T   "Hack Proofing Your Network: Internet Tradecraft"

According to the introduction, this book will teach you how to hack,
or break into computer systems.  With the best of intentions, of
course.  As it states, if you don't hack your system, who will?  The
intent is to teach you how to approach security breaking, with a view
to finding, and then patching, the holes in your network.

Being an educator, and fairly cynical about anyone who tells me
something is "safe," I have a lot of sympathy for this position.  In
theory.  The implementation, though, may leave something to be
desired.  After all, those who are charged with protecting systems
generally have other things to do.  They have limited resources.  They
don't have a lot of leisure, or interest, in testing every single
piece of software for any possible buffer overflow condition.  So
security managers may not be all that interested in spending all of
their non-existent free time obsessively hacking their own systems.

Well, having reviewed the book, and sent off the draft, the lead
author, Ryan Russell, informed me that security managers were not the
real intended audience.  This work was actually aimed at the keeners,
those few who *do* really want to get behind the user interface, and
poke about in the workings.  But it may have some use beyond that
rather select crowd.  In Russell's own words, this is what you do
after you've got good policies in place, and you've got your routine
down for applying patches, watching for new vulnerability
announcements, and so forth.

Part one, rather oddly entitled "Theory and Ideals," seems to
concentrate on basic concepts.  It also may seem strange that chapter
one, called "Politics," starts out by defining "hacker" and other
related terms.  On the other hand, any text that tries to argue for
the social value of criminals and frauds is bound to be considered
political.  Ultimately, this piece seems to be trying to justify
system breaking activities.  All the usual arguments are trotted out,
and make the normal amount of sense (very little).  (I should also
point out that this book started life as an electronic text.  This is
evident in the frequent citations of Web sites in the course of the
work.  They may support the content in the context of a Web page, but
in print they are annoying, since the relevant material is not
incorporated into the book.)  Chapter two, "Security Laws," is more a
set of cliches: what can go wrong will go wrong, security by obscurity
doesn't work.  Some of them are wrong (passwords can be securely
stored with one-way encryption, albeit still at some risk of brute
force attacks; and the NSA has goofed on an algorithm), some are naive
(the assertion that there is no guaranteed protection against viruses
makes no mention of Fred Cohen's work), and most are of questionable
utility.  The classes of attack listed in chapter three are neither
comprehensive nor fully explained.  (Most of the space in the chapter
is given over to source listings of attack tools.)  "Methodologies"
seems to be a collection of random thoughts on analysis in chapter

Part two describes some activities intended to be undertaken on a
computer over which you have complete control, mostly related to
decryption.  Chapter five looks at making small changes to a system,
and checking for modifications.  This is a useful function in any kind
of analysis, but the examples chosen will hardly be of use to
sysadmins.  The author admits that chapter six really does not explain
cryptography, it really only mentions some password cracking tools.
Both chapters seven and eight essentially deal with bad data, first in
general terms and then in the specific problem of buffer overflows.
While the discussion might be of interest to programmers, it is of
limited use to security managers.

Part three talks about attacks on remote systems.  There is a little
explanation about sniffing (which requires some level of local
access), session hijacking, and spoofing.  Chapters twelve and
thirteen list some security holes in server and client software
respectively.  Oddly, given all the problems in earlier parts of the
book, the material on viruses and malware, in chapter fourteen, isn't
too bad.  It's not great, it displays too much virus code to very
little effect, and has a few holes, but it is generally better than
the stuff found in standard security texts, and stands out above the
rest of the book.

Part four contains a single chapter.  Although the titular subject is
reporting, most of the material promotes the concept of "full
disclosure."  This is the tenet that security is best served by having
all security loopholes disclosed.  The discussion does take a fairly
responsible tack, recommending that vendors be contacted first, and
allowed some time to fix the problem, before the vulnerability or
exploit is released to the public.  The text is fairly reasonable,
although is does contain the full text of a number of email exchanges
which add little to the debate.  The remaining pages concentrate on
the importance of continual study in the security field.

The people who have contributed to this book are a step above the
usual "wannabes" who tend to write "hacker" security books.  The
information presented is also somewhat more reliable, and covers a
broader range.  However, both the thesis and the execution of the work
contain flaws.  The material still seems more interested in justifying
security breaking expeditions than in giving the security
administrator a complete and useful reference for protection.  Errors,
while less rampant than in other, similar texts, are still too common
for the content to be considered really dependable.  In particular,
basic concepts are too quickly dismissed in the eagerness to pass
along news of the latest "cool tool."  Experienced security managers
may find some helpful recent data in this volume, but probably already
have resources of their own.  Newcomers to the field are advised not
to rely too heavily on this as a single source of knowledge.

As noted, though, the authors were not really writing for managers or
novices.  For software engineers, programmers, and testers, there is
possibly more utility.  Those doing sophisticated software
evaluations, and particularly those with sufficient resources to
really "test to destruction," might get the most out of the book,
especially considering the concentration on breaking, rather than
fixing.  Still, some research in the RISKS and BUGTRAQ archives would
likely get you just as much.

copyright Robert M. Slade, 2000   BKHPYNIT.RVW   20000831    or

Please report problems with the web pages to the maintainer