The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 23 Issue 6

Tuesday 9 December 2003

Contents

Electronic car doors trap man in Australian flood, nearly drown him
Tony Healy
New official self-service litigation system available in England/Wales
Tony Ford
Software paraphrases sentences
Justine Roberts
The Eight Fallacies of Distributed Computing
Peter Deutsch via Roger Z
Human Factor?
Dave Brunberg
This number's ready for prime time
NewsScan
Re: Another large gas bill
Tom Hayhurst
Big money on the line, but no source code...
D G Rossiter
Nevada to apply slot-machine security to e-voting hardware?
David Brunberg
Re: Diebold ATMs hit by Nachi worm
Russ Cooper
Elinor Mills Abreu via Lillie Coney
Voter-verified breadcrumb trail?
Dave Brunberg
PGN
Voting machines
William Ehrich
Re: "In-Security clearance"
Eric Dobbs
Re: Real purpose behind In-Security clearance program
Daniel Suthers
Nigerian scams
Ted Lemon
The Internet and the right to communicate
Monty Solomon
The Structure of an Accident
William Langewiesche via Monty Solomon
REVIEW: "Linux Security Cookbook", Barrett/Silverman/Byrnes
Rob Slade
Info on RISKS (comp.risks)

Electronic car doors trap man in Australian flood, nearly drown him

<Tony Healy>
Thu, 4 Dec 2003 12:06:39 +1100

The driver of a Honda CRV 4WD found himself trapped in his stranded vehicle
in recent floods in Melbourne, Australia. The electrically driven windows
would not wind down since the electrical system was underwater and, for some
reason, he couldn't open the doors either. This might have been due to the
pressure of the water outside or to other artifacts of the electrical system
failing.
  http://www.news.com.au/common/story_page/0,4057,8052562%255E1702,00.html


New official self-service litigation system available in England/Wales

<Tony Ford <tony.ford@net.ntl.com>>
Sat, 26 Jan 2002 15:43:09 +0000

Today's *Daily Telegraph* carries a *potentially* disturbing report
describing a new service, "Money Claim Online", whereby individuals and law
firms (solicitors) can issue most simple legal proceedings (where a sum less
than UK pounds 100,000 is claimed, = US$140K)) and enforce judgments via a
Web browser. The new service has been set up without publicity by the Lord
Chancellor's Department, which runs the courts system in England and
Wales. It seems that the system is accessible to the public now, although it
has not been officially launched.

People using the service are (oddly) referred to as "customers" .... and
there is a Customer Help Desk ...

The newspaper report is also viewable at this Daily Telegraph link on-line:
  http://www.telegraph.co.uk/news/main.jhtml
  ?xml=/news/2002/01/26/nsue26.xml&sSheet=/news/2002/01/26/ixhome.html

The service can be seen on-line at:
  http://www.courtservice.gov.uk/mcol/
    [CORRECTION IN ARCHIVE COPY RESULTED FROM on-line *Telegraph* change,
    thanks to Trevor Zacks via Lindsay.Marshall.  PGN]

No details are apparent of what measures are taken to validate the identity
of the claiming party or prevent other gross miscarriages of justice ....
but it would appear that the potential exists for significant trouble ....
even though the site warns that "vexatious litigants" are not allowed to us
it (these are people who have abused the litigation system in the past to
such an extent that they have been declared "vexatious litigants",
restricting their ability freely to issue legal proceedings).

PS: I am a lawyer myself, although I don't practise in this area .. but do
work in-house for a large IT company ... these comments are offered purely
in a personal capacity.

Tony Ford, Guildford, Surrey, UK  MailTo:tony.ford@net.ntl.com


Software paraphrases sentences

<Justine Roberts <jr4939@itsa.ucsf.edu>>
Fri, 05 Dec 2003 07:48:00 -0800

"Software paraphrases sentences" is the headline of a long story by Kimberly
Patch in the 3/10 Dec 2003 issue of Technology Research News.  Worth a look.
Although the research is presented as entirely benign and useful, I find its
implications & goals rather scary, starting, perhaps, with the problem of
student plagiarizers.
  http://www.trnmag.com/Stories/2003/120303/Software_paraphrases_sentences_120303.html
  [http://www.trnmag.com/Stories/2003/120303/
  Software_paraphrases_sentences_120303.html  SPLIT]


The Eight Fallacies of Distributed Computing

<"r z" <roger@darkhorsemail.net>>
Tue, 09 Dec 2003 09:33:10 -0800

The Eight Fallacies of Distributed Computing
Peter Deutsch

Essentially everyone, when they first build a distributed application, makes
the following eight assumptions. All prove to be false in the long run and
all cause big trouble and painful learning experiences.

1.  The network is reliable
2.  Latency is zero
3.  Bandwidth is infinite
4.  The network is secure
5.  Topology doesn't change
6.  There is one administrator
7.  Transport cost is zero
8.  The network is homogeneous

http://web.archive.org/web/20030208015752/http://java.sun.com/people/jag/Fallacies.html


Human Factor?

<Dave Brunberg <DBrunberg@FBLEOPOLD.com>>
Wed, 3 Dec 2003 09:35:42 -0500

Seeing Mike Smith's review of "The Human Factor" reminded me of a phrase we
have in the municipal water and wastewater treatment industry--we refer to
"The Bubba Factor."

Bubba is not merely human, he is the incarnation of Murphy's Law.  Bubba
doesn't bother to check that the tank's too full.  Bubba caps off a
pneumatic control line to a valve because he likes to operate it manually.
Bubba figures that it's a good idea to change the plant's operating rate
from 10% of capacity to 95% by manually making a step change in the feed
pump setpoint.  Bubba forgets that when the clarifier sludge overflows into
the reverse osmosis system that you can't just let the daylight shift take
care of it.

Most water/wastewater plants are not yet highly automated, and frequently,
operators resist the trend to automate.  Bubba's clever, and he always finds
a way to break the fail-safe.  In these situations, you walk a very fine
line between making the plant so inflexible that operators cannot respond to
unforeseen problems and giving Bubba a little too much latitude.


This number's ready for prime time

<"NewsScan" <newsscan@newsscan.com>>
Wed, 03 Dec 2003 09:08:52 -0700

Michigan State University grad student Michael Shafer has succeeded in
identifying the largest known prime number to date, using a distributed
computer network of more than 200,000 computers located around the world.
The new number is 6,320,430 digits long and is only the 40th Mersenne prime
to have ever been discovered (Mersenne primes are an especially rare breed
that take the form of 2-to-the-power-of-P minus one, where P is also a prime
number).  Shafer was taking part in the Great Internet Mersenne Prime Search
(GIMPS) project, when the new number popped up. "I had just finished meeting
with my advisor when I saw the computer had found a new prime. After a short
victory dance, I called up my wife and friends involved with GIMPS to share
the great news," said Shafer.  [*New Scientist*, 2 Dec 2003; NewsScan Daily,
3 Dec 2003] http://www.newscientist.com/news/news.jsp?id=ns99994438

  [I suppose all of the contributors of machine time would be known as
  Mersenne-aries -- oxymoronically, because they were most likely unpaid.
  PGN]

    [Typo fixed in archive copy.  PGN]


Re: Another large gas bill (Shapir, RISKS-23.05)

<tom.hayhurst@reuters.com>
Thu, 04 Dec 2003 13:25:52 +0800

> It's possible Mr Purdey has been charged for the gas used up
> during the explosion that destroyed his house."  (*The Daily Telegraph*)

Good joke, but sadly not true. While there are many web pages that attribute
this story to the *Telegraph*, it doesn't appear in their archives.  A search
of the Factiva news archives finds six references to Arthur Purdey in print,
all in the comedy clippings sections of newspapers ("Girl floats out to sea
on inflatable teeth; is rescued by man on giant lobster" and the like). The
earliest reference, from a York local paper, in February 2003, gives no
source, although the same publication attributes it to an unnamed Lancashire
newspaper three months later.  Subsequent appearances give the original
source as the *Telegraph* three times and the *Bangkok Post* once.
  [So it got more Bangkok for the buck in the latter paper.  PGN]


Big money on the line, but no source code...

<D G Rossiter <drossite@twcny.rr.com>>
Thu, 4 Dec 2003 08:10:04 +0000

Not quite as important as electronic voting programs, but still with
big consequences.

"In the College Bowl Race, the Crucial Players Are the Programmers".
Apparently, the Bowl Championship Series rankings, which determine which
lucrative post-season games a college can play, are partly determined by
computer rankings.  The programmers refuse to give their algorithms, let
alone their source code.  One complains: ""Now you want to look under the
hood of my car" when asked about this; another says "The more you specify,
the more you annoy the readers."
  [*The New York Times*, 04 Dec 2003]
  http://www.nytimes.com/2003/12/04/technology/circuits/04foot.html


Nevada to apply slot-machine security to e-voting hardware?

<David Brunberg <brunberg@zoominternet.net>>
04 Dec 2003 19:43:27 -0500

According to *The Reno Gazette-Journal* (link below), Nevada Secretary of
State Dean Heller "plans to enlist the expertise of the Nevada Gaming
Control Board to ensure the machines are secure and accurate."  The state
maintains strict control and oversight of slot machines, presumably because,
as the state's most visible industry, gambling must be seen by the public to
be untainted.  One hopes that people will consider that getting a fair shake
at the election box is at least as important as whether the quarter slots
are on the up-and-up.  Avi Rubin (Johns Hopkins University) said he found
major security flaws with the system used by one of the companies that is in
the running for a contract to provide voting machines across Nevada.

  http://www.rgj.com/news/stories/html/2003/12/02/58202.php?sp1=3Drgj
  &sp2=3Du=mbrella&sp3=3Dumbrella&sp5=3DRGJ.com&sp6=3Dnews&sp7=3Dnews_front


Re: Diebold ATMs hit by Nachi worm (RISKS-23.04)

<"Russ" <Russ.Cooper@rc.on.ca>>
Sat, 29 Nov 2003 00:31:01 -0500

Lest we forget, this is the "Risks Forum", not some weekday morning kids show.

Steve Summit is "astonished" that a commercial product running on a Windows
platform was affected by Nachi. This after how many months? This despite the
fact that I could attribute problems with an infinite number of commercial
IT products to the effect Nachi created? Oh, I'm sorry, but this is the
"Risks Forum".

Are many here surprised that Diebold sold "default installations" of its
product on a Windows platform which was improperly designed? Are many here
surprised that people bought the equivalent of the "off-the-shelf" version?

Since they affirm the ATM was "infected", that means it accepted an inbound
connection to TCP135. Now maybe some don't know, but I can see no reason why
anything should be querying an ATM, for any reason, least of all via such a
sensitive protocol. Now if you didn't know before, you may have learned from
recent discussions about the August 2003 blackout, you don't query the
endpoint. It either tells you its status, or you assume its dead. Either
way, you're in control. Do I want to control an ATM's status, or do I want
it to explain its status to me? If I'm not getting expected information from
such a front line device, I, as a backend server, am simply going to stop
listening to it and page a tech. Not sending expected info, or sending
unexpected info, denote a problem...send the technician. I can't think of a
reasonable design that involves the backend sending uninitiated queries to
the ATM, ergo, there's no reason the ATM was left listening for inbound
TCP135 queries. That's a design problem, not a problem with the OS or its
components.

That such devices are now placed on the same network as devices to which can
be attached Nachi infected systems is, well, a problem. Its one thing to
shut down ATMs because their backend servers can't be reached due to network
congestion, its another thing to have an ATM compromised directly. Diebold's
designed default installation clearly isn't intended to minimize risk, its
intended to minimize support problems from customers who attempt to
implement their product insecurely.

Imagine if they disabled inbound TCP135 attempts. During implementation
they'd get a surge of support calls from less than qualified implementers
claiming they couldn't connect to the ATM remotely in order to configure
it...;-]

Bottom line, is the risk here just not the unfortunately common risk that if
I'm stupid I can blame someone else for not telling me I was stupid? If that
isn't the risk, then the risk is that commercial vendors still allow me to
shoot myself in the foot, and the media could make such wounds fester.

Russ - NTBugtraq Editor


Re: Diebold ATMs hit by Nachi worm (RISKS-23.04)

<Lillie Coney <lillie.coney@acm.org>>
Tue, 09 Dec 2003 11:00:36 -0500

Computer security experts predicted more problems to come as Windows
migrates to critical systems consumers rely on.  Bruce Schneier is quoted:
"Specific purpose machines, like microwave ovens and until now ATM machines,
never got viruses.  Now that they are using a general purpose operating
system, Diebold should expect a lot more of this in the future."  John
Pescatore, an analyst at Gartner, agreed.  "It's a horrendous security
mistake," he said, of specific-purpose machines like ATMs running Windows,
written for general purpose computers and for which Microsoft Corp. releases
security fixes on a regular basis. "I'm a lot more worried about my money
than I was before this."  Diebold switched from using IBM's OS/2 on its ATMs
because banks were requesting Windows, said Steve Grzymkowski, senior
product marketing manager at Diebold.  [Source: Experts Worried After Worm
Hits Windows-Based ATMs, Elinor Mills Abreu, Reuters, 8 Dec 2003; PGN-ed]


Voter-verified breadcrumb trail?

<Dave Brunberg <DBrunberg@FBLEOPOLD.com>>
Wed, 3 Dec 2003 09:23:42 -0500

The subject of e-voting has been hot of late (for very good reason) and many
have pressed for the voter-verified paper trail.  This may be a good first
step, but could also be a serious insecurity of the false-sense-of-security
type.  When one votes for Joe Blow and gets a paper saying her vote went to
Joe Schmo, she knows something went wrong.  Neglecting the fact that
election officials may not be required to address the discrepancy, this at
least gives the voter the knowledge that the system is broken.

But what happens when you vote for Joe Blow and get a paper that says "Joe
Blow"?  Is there any guarantee that the vote for J.B. is registered on the
disk, or over the network?  What guarantee is there that no alterations
occurred between the touchscreen station and the recording station?  Or that
the software in the station hasn't been compromised to change 10% of the
votes for J.B. to J.S. before recording but after printing?

Once you get out of the actual voting station and the printer, what, if
anything, guarantees that votes aren't swapped or dropped?  And, for areas
where physical intimidation may be a factor, how can the voter be assured of
anonymous voting when the printer spits out the name of their selections for
anyone to see?

The next obvious solution will be to require independent auditing of open
operating code for all voting systems.  Can we do this without ensuring that
we must have one programmer from each political party (and there are many)
go over every single voting system?  Can we be sure that the auditors are
honest?  Can we have multiple vendors or should we have a single, open
design for every precinct in the country?

Why not just admit that e-voting cannot be made secure without adding in so
much complexity that it becomes prohibitively expensive or self-defeating?

For simple punch-card systems, you could have a reader on site through which
the electors would feed their cards.  The reader would report their choices
back to them through a private interface (e.g., the video replay hoods used
at U.S. football games).  If there was a problem, the voter would be given a
new card to punch again.  Certainly, the readers could be compromised as
well, but they could not actually change the punched votes.  If enough
voters found discrepancies, that precinct would be deactivated until the
cause was found.


Voter-verified breadcrumb trail? (Re: Dave Brunberg, RISKS-23.06)

<"Peter G Neumann" <neumann@csl.sri.com>>
Wed, 3 Dec 2003 14:42:46 PST

Responding to the above message by Dave Brunberg:

ONE.  COUNT THE PAPER, and let the electronics appease the media only for an
      UNOFFICIAL PRELIMINARY count.  The official count would be paper.
      (Vendor arguments that paper is unreliable are largely bogus.  Vendor
      arguments that their systems CANNOT have erroneous results are of
      course COMPLETELY BOGUS, ignoring insider fraud, programming screwups,
      and configuration errors.  Instead, they tend to argue that no
      "hackers" can break in, which is not the primary concern for polling
      place voting -- although it would be a serious concern for Internet
      voting.)

TWO.  IF THERE IS A DISCREPANCY, the machine should be IMMEDIATELY DISABLED
      for the duration of the election.  No fooling around with machines
      that indicate on the screen that your vote has been recorded for a
      candidate you did not vote for, where you are told that it is an error
      on the screen but is correct in memory -- as happened in Florida in
      2002.)

THREE.  Why have electronic voting machines at all?  GOOD QUESTION.  The
      most compelling arguments are providing a nice voter interface and
      avoiding overvotes -- although we have reported cases of blank
      positions being counted as votes by miscalibrated optical scanners (or
      tampered ballots?), and there are also reports of chad knocked out of
      punchcards because of too-deeply-prescored chad slots, suggesting that
      some of the card-system overvotes are not the voters' faults.  But see
      the next message from William Ehrich, which has been said before but
      is worth saying again.  PGN


Voting machines

<William Ehrich <ehrich@mninter.net>>
Tue, 2 Dec 2003 02:59:53 -0600

All the technical people seem to agree that a voting machine has to produce
a piece of paper for audit trail, and some feel that that piece of paper
should be the primary record of the vote.

It seems an obvious extension of this idea to have the voter simply mark the
piece of paper with a felt marker.

That is in fact how we have been voting here.  [Minnesota.  PGN]
It works well.

There is a counting machine at the voting place to count the ballots.  If I
don't trust that machine I can (in principle) recount them with a different
machine or count them by hand.

There is a RISK in using a computer where it is not needed and can do more
harm than good.


Re: "In-Security clearance" (RISKS-23.04)

<"Eric Dobbs" <edobbs@freemode.net>>
Tue, 2 Dec 2003 15:23:20 -0500 (EST)

Since I've had to use the EPSQ program that the author of the "In-Security
clearance" article talks about, I understand his frustration.  The process
of finding, downloading and installing the program is rather Byzantine.
In its defense, though, there's some rather carefully-thought-out access
control and encryption used to protect the personal data that's entered
into the program - see the link below for details.
  http://www.dss.mil/epsq/epsqfaq/epsqfaq13.htm

It's a pain to use, however; the interface was designed using 16-bit Windows
controls, so it looks horrid on anything newer than Windows 3.11, it can be
rather unstable under Windows NT 4.0 and 2000 (better under XP), and the
whole rigamarole of a website is a classic example of government IT in
action.


Re: Real purpose behind In-Security clearance program (RISKS-23.04)

<Daniel Suthers <dbs__usenet@tanj.com>>
Sun, 30 Nov 2003 12:59:45 -0800

An unknown poster detailed the process for applying to the US government for
a security clearance.  After he followed all the steps, he was required to
run a program on his PC which did.... nothing.

It's not to hard to imagine that the program was assisting the clearance
process by scanning the hard drive for signs of illicit activity or setting
up a back door so the Feds could check it later.  Of course, one would have
to be paranoid to even imagine the US government doing such a thing in the
name of national security.

I've noticed this trend in Federal programs.  They expect us to accept the
risk of running unverified programs on our PCs as a requirement for doing
business with them.  The have produced several "infection detection"
programs that were released in executable form only.

Since the Patriot Act was passed, there is a very real risk that some of the
computer programs supplied by government agencies are, in some way, spyware.
I can imagine wording in the "acceptance agreement" that would waive your
rights to privacy upon installation of the various programs.

I don't have a security clearance, and don't expect to need one, so you can
include my name.  :-)


Nigerian scams

<Ted Lemon <mellon@nominum.com>>
Sat, 29 Nov 2003 23:03:28 -0600

I think that many of the younger readers of RISKS are unaware that there is
no need for an "addiction" or "mental illness" in the usual sense for
someone to fall prey to these scams.  All you really need is to be old, and
to have the maladies of old age.  A stroke, incipient Alzheimer's, whatever,
and suddenly your mom or dad has been taken by the scammers, probably for
everything they're worth.  This really could happen to someone you love, and
it's no joke.


The Internet and the right to communicate

<Monty Solomon <monty@roscom.com>>
Mon, 1 Dec 2003 22:51:18 -0500

by William J. McIver, Jr., William F. Birdsall, and Merrilee Rasmussen

The development of the Internet challenges traditional conceptions of
information rights. The discourse surrounding these rights and the Internet
typically deals with each right in isolation and attempt to adapt long
established understandings of each right to the new technological
environment. We contend there is a need to address information rights within
a comprehensive human rights framework, specifically, a right to
communicate. This paper examines the development of a right to communicate
and how it can be defined and implemented.

Contents

Introduction
Basis for a human right to communicate
Satellites and communication rights
Mass media mentality
UNESCO and the right to communicate
Politics and policy
Definition
National initiatives
Soft law
Communicative law
Opposition to a right to communicate
Conclusion

  http://firstmonday.org/issues/issue8_12/mciver/index.html


The Structure of an Accident

<Monty Solomon <monty@roscom.com>>
Sun, 30 Nov 2003 04:30:47 -0500

The Structure of an Accident
Atlantic Unbound, 22 Oct 2003
William Langewiesche, the author of "Columbia's Last Flight," talks
about the fundamental problems within NASA that led to the space
shuttle's demise.
  http://www.theatlantic.com/unbound/interviews/int2003-10-22.htm


REVIEW: "Linux Security Cookbook", Barrett/Silverman/Byrnes

<Rob Slade <rslade@sprint.ca>>
Tue, 9 Dec 2003 08:31:39 -0800

BKLNSCCB.RVW   20031019

"Linux Security Cookbook", Daniel J. Barrett/Richard E.
Silverman/Robert G. Byrnes, 2003, 0-596-00391-9, U$39.95/C$61.95
%A   Daniel J. Barrett dbarrett@oreilly.com
%A   Richard E. Silverman res@oreilly.com
%A   Robert G. Byrnes byrnes@oreilly.com
%C   103 Morris Street, Suite A, Sebastopol, CA   95472
%D   2003
%G   0-596-00391-9
%I   O'Reilly & Associates, Inc.
%O   U$39.95/C$61.95 707-829-0515 fax: 707-829-0104 nuts@ora.com
%O  http://www.amazon.com/exec/obidos/ASIN/0596003919/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/0596003919/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0596003919/robsladesin03-20
%P   311 p.
%T   "Linux Security Cookbook"

In the introduction, the authors state that this is not a security text, but
a list of practical and individual pointers for improving security in
specific areas.

Chapter one covers how to take system snapshots with Tripwire, in order to
detect changes that might indicate an intrusion or a virus.  The
establishment of a firewall, using the iptables and ipchains utilities, is
dealt with in chapter two.  Chapter three examines the control of access to
various network services.  Authentication techniques and infrastructures are
detailed in chapters four and five.  Protecting outgoing network
connections, files, and e-mail are described in chapters six, seven, and
eight respectively.  The material on testing and monitoring, in chapter
nine, is the most extensive in the book, and provides a good introduction to
Snort as well.

This is good, practical advice, and makes an excellent reference for anyone
dealing with the security of Linux in a networked environment.  In one sense
the authors are right, for they stick to the nuts and bolts, without
discussing security frameworks or theories.  In another sense they are
wrong: this text does what the "hacking" books only pretend to do.  The
authors of the genre of "Teach Total Idiots How to Hack and They Will
Automatically Turn Into Security Experts" texts all imagine that they teach
you how to harden/secure a system, but don't.  This does.

copyright Robert M. Slade, 2003   BKLNSCCB.RVW   20031019
rslade@vcn.bc.ca      slade@victoria.tc.ca      rslade@sun.soci.niu.edu
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Please report problems with the web pages to the maintainer

Top