The RISKS Digest
Volume 22 Issue 76

Friday, 13th June 2003

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…


Challenge to 'challenge-response' users: Be Careful!
Phantom voting in Israeli Knesset
Ed Ravin
Student hacks school, erases class files
Canadian firearm registration system overwhelmed by traffic
swabsox via Declan McCullagh
Sea King Helicopter crash - fire control system deployment failure
Stuart Lynne
Computer glitch causes traffic lights malfunction
Teemu Leppänen
Risks of trusting CORRECT dive computers and tables
Daniel P.B. Smith
Electric utility direct-debit fiasco
Jonathan Kamens
Incremental insecurity
Paul Wexelblat
Re: ATM time sync
David Lesher
Re: University of Calgary to teach virus writing
Nicholas Weaver
Dan Bornstein
Denial of Service via Algorithmic Complexity Attacks: Crosby-Wallach
Monty Solomon
REVIEW: "Mission Critical Security Planner", Eric Greenberg
Rob Slade
Info on RISKS (comp.risks)

Challenge to 'challenge-response' users: Be Careful!

<"NewsScan" <>>
Mon, 09 Jun 2003 10:01:34 -0700

EarthLink has begun offering its 5 million subscribers "challenge and
response" technology set up to send a "challenge" to any message from an
unknown source, requiring that source to "respond" (and thereby supposedly
proving it's from a human being rather than a spammer or pornographer).  But
many people who hate spam are saying the cure is worse than the illness;
anti-spam consultant Steve Adkins warns, "It's sufficiently tempting that
people will use it and will not realize all the bad things that will begin
happening.  Challenge-response is very, very unfriendly and rude to
legitimate senders of e-mail." [AP/*Seattle Post-Intelligencer*, 9 Jun 2003;
NewsScan Daily, 9 June 2003]

  [Note: If you sign up for challenge-response, then say goodbye to NewsScan
  Daily.  (The NewsScan editors)]

    [And say goodbye to RISKS also (unless you set up an alias address for
    RISKS issues that does not challenge.  (We will never reveal it.)  PGN]

Phantom voting in Israeli Knesset

<Ed Ravin <>>
Wed, 4 Jun 2003 17:44:15 -0400

An investigation is going on in the Israeli Knesset (Parliament) on how
votes are being cast on behalf of parliamentarians who are absent from their
seats.  It seems that electronic voting has problems even in a controlled
environment like the floor of a parliament...

  Knesset probe fails to reveal who voted in Likud
  By Gidon Alon, Haaretz Correspondent

  A special committee set up by Knesset Speaker Reuven Rivlin, has failed to
  discover which MK was responsible for voting in place of Likud MK Inbal
  Gavrieli, who was not present in the Knesset plenum during a debate
  concerning the new budget plan, even though computer records indicate a
  vote was cast from her seat.
  Israel Radio reported several Likud MK's saying they had observed MK
  Yehiel Hazan (Likud) voting on Gavrieli's behalf. The vote was conducted

  The incident follows another case of double voting, in which MK Michael
  Gorlovski (Likud) admitted to having voted on behalf of another Likud MK,
  Gilad Erdan, also during the vote on the economic plan.

Student hacks school, erases class files

Thu, 12 Jun 2003 08:35:00 -0400

A 17-year-old student in a networking course was arrested for breaking into
his school's computers and erasing folders of other members of the junior
class at Marion High School, near Rochester NY.  He apparently was sniffing
passwords with keylogging software.  [The school's fix for this is to have
students change their passwords every 60 days, and force them to use
passwords with a ``combination of letters, numbers, and at least one special
character''.  Whoopee!  That sure solves the problem!  Sure stops the
sniffer, which could be getting the new passwords as they are entered!!! PGN]

  [One of our correspondents suggested that perhaps his charges will claim
  that his keylogging software is in the WMD category, and ask for a life
  sentence.  PGN]

Canadian firearm registration system overwhelmed by traffic

<Declan McCullagh <>>
Fri, 06 Jun 2003 09:43:26 -0400

>Date: Fri, 6 Jun 2003 08:41:33 -0600
>From: swabsox <>
>To: Declan McCullagh <>
>Gun registry backfires after system exceeds capacity:
>  The CFC's IT woes really aren't that different from any other government
>department's, said Wendy Cukier, president of the Toronto-based Coalition for
>Gun Control. She noted that government projects are frequently plagued by
>things like budget and capacity issues, but the amount of vocal opposition to
>the gun registry and made the CFC a flashpoint for controversy.
>"The system was built on the assumption that it would have something like
>a 10% error rate and instead the error rate was 90 per cent. Some of that
>was because of the complexity of forms and some of that was deliberate" said
>Cukier, who's also a professor of information technology management at
>Ryerson University. "You'd be hard-pressed to find another program that faced
>such extensive efforts to undermine it."

Sea King Helicopter crash - fire control system deployment failure

<Stuart Lynne <>>
Wed, 4 Jun 2003 21:24:27 -0700

An article in today's *National Post* related that, when a Sea King
helicopter crashed on the deck of a Canadian Forces Iroquis destroyer
earlier this year, the first two fire control systems failed and only the
third finally worked.

The article does not say why the first system failed, but the second failed
because of an obviously (well, perhaps in hindsight, obvious to RISKS
readers) poor design of the operators console:

  An operator in the control room then pressed a button to active the second
  system. Nothing seemed to happen. He pushed the button again and again --
  a total of six times — but nothing happened.

  The operator "was not aware of the fact that as he repeatedly depressed
  the button to active the AFFF system, he was actually starting and
  stopping the system with every alternate push," a report from the
  subsequent technical investigation sayes.

  It also notes none of the indicator lamps on the system's console were
  working, so they did not light up when the button was pushed.

  And the crew may not have known about a 30-second delay from the the
  system is activated to the time the fire suppressant reaches the hose

1. Poor design of a critical system. A toggle or second switch to disarm
would have been a better choice perhaps.

2. Poor maintenance apparently leaving a critical system usable but not
apparently so when the operator wanted results right now.

3. Poor training so that the operator did not know what to expect when
activating the system.

Kudos that they did have a third fire control system that apparently was
deployed successfully.

Stuart Lynne <>
Belcarra, Embedded Linux USB Software 604-461-7532

Computer glitch causes traffic lights malfunction

<Teemu Leppänen <>>
Sat, 31 May 2003 11:25:24 +0300 (EEST)

In Oulu, Finland, computer glitch in central "traffic lights controlling"
computer caused traffic jams in city centre at 9am friday morning. The
computer transferred back to year 1991 and to night time (they did not
specify exact date and time), meaning some of the traffic lights were in
"night mode" and signaling "ignore me". Problem was solved in 90 minutes,
but the original cause of the glitch remains yet unknown. Authorities say
this was the first glitch ever experienced by the tax payers, also admitting
there has been "minor" ones before. Seems that the police was not used to
guide the traffic instead.

No accidents were reported, hence no need to clear the way for the emergency
medical teams.. perhaps with system which state is unknown, even requiring
reboot, or having technicians trying to fix the issue at the same time.

Original article (in Finnish)

Risks of trusting CORRECT dive computers and tables

<"Daniel P.B. Smith" <>>
Fri, 30 May 2003 23:15:39 -0400

Craig S. Bell submitted a note about dive computers with an alleged software
defect. Without minimizing the seriousness of the issue, or excusing the
alleged behavior of the manufacturer, I think there is another RISK as well.

The actual physiology and physical chemistry of decompression sickness isn't
understood precisely.  The models used to calculate dive tables and those
used in dive computers are rough.
cites a Dr. Gregory Emerson as saying, of decompression sickness, "We kind
of know why it occurs but we still don't really understand why some people
get it and other people don't."

A manual I downloaded from says that "Aladin Pro
Nitrox uses a new decompression calculation model known as the ZH-L8
ADT. This model uses eight compartments or 'tissue' groups with nominal half
time periods from 5 to 640 minutes." In another place, however, they make
the disclaimer "decompression modeling is an inexact science, and of
necessity must be based at least partly on certain unproven assumptions."
(I interpret this to mean that their "eight-compartment ZH-L8 ADT model" can
be regarded as an educated guess).

But even if the model were perfect, it would not be perfectly accurate
unless there were a way to measure the size of an individual diver's tissue
"compartments." The manual makes no reference to any way of matching the
device to the body characteristics an individual diver.  There is no way to
enter percentage of body fat, for example, let alone the other seven tissues
incorporated n the model.

And nitrogen is soluble in fat.  A person with more body fat will absorb
more nitrogen while breathing compressed air at depth, and release more of
it on ascent.  Thus, if two divers follow identical dive plans, their
computers will indicate the same results--but the diver with more fat will
be at greater risk for decompression sickness.

Uwatec's manual has a disclaimer for this, too: "each diver will vary in his
or her susceptibility to decompression sickness. Not only that, but each
individual diver's own susceptibility may vary from day to day."

These disclaimers need to be taken seriously.

A sufferer from decompression sickness
says he was told that "85% of people treated for decompression illness
were diving within limits imposed by tables or a dive computer (i.e., most
people struck by DCI are following the rules)." Dr. Emerson in the article
cited above noted scuba divers can suffer from decompression sickness even
if they religiously follow diving tables.

A sample chapter from a 1997 book by Lawrence Martin, MD, goes into
considerable detail, but the bottom line is that "For a given
individual, [decompression sickness] is unpredictable."

How do divers behave? The article Bell cites about about the allegedly
defective computers,
says that a pair of divers who "surfaced... then checked their computers
to make sure another dive was safe. 'I look at Mitch's computer and look
at mine,' said Iazdi in his throaty Portuguese accent. 'I say, "We're

Dive computers have the intrinsic RISK of false precision.  They do
calculations with great precision that simulate sophisticated models and
take care of dozens of details.  Unfortunately, the correspondence between
the models and reality is crude.

Even without software flaws, divers are subject to the RISK of believing
something must be true just because it's a "computer" that said so.

Electric utility direct-debit fiasco

<Jonathan Kamens <>>
Tue, 20 May 2003 20:58:09 -0400

Yet another direct-debit horror story....

Knowing that I was going to be out of town when my next electricity
bill came due, and not wishing to worry about having enough money in
my checking account to cover it while on vacation, I telephoned my
electric company (NSTAR) and asked them to suspend direct debit until
further notice.

They agreed, and indeed, the electricity bill which arrived while I
was on vacation said "please pay this bill" instead of "your account
will be debited on <date>."

Upon my return, I sent the electric company a check and then
telephoned them and asked for direct debit to be resumed as of my next
bill.  I was assured that payment for the bill which arrived while I
was on vacation would not be debited from my account.

Two weeks later, when my next bill arrived, I discovered that the
payment was, in fact, debited from my account.  Thus I had paid twice
for the same bill, and NSTAR was holding onto over $100 of my money to
which they were not entitled.  As luck would have it, I didn't bounce
any checks because of this, but I could have done so easily.

An additional wrinkle is that despite the fact that the total amount
due on the new bill was less than the overpayment, the bill still
claimed that they would be taking money from my checking account,
apparently because when they received my overpayment, they applied all
of it as an NSTAR credit and none of it to the supplier half of the
bill (I use a third-party electricity supplier).

I contacted the electric company by E-mail and asked them to return
the money to me.  First, they said that they could only refund the
difference between the debit and how much I owed on the new bill,
despite the fact that the amount on that bill was not actually due for
two more weeks.  When I responded that this was unacceptable, they
agreed to refund the entire debit amount, but said that it would take
two to three weeks for a check to be issued.  I said that, too, was
unacceptable — they had no right to that money in the first place,
and they should immediately either reverse the debit or issue me a
check and send it via overnight delivery.  They refused.  I instructed
them to immediately and permanently disable direct debit on my

I also informed them that I would not be sending any money in response
to the new bill, because I had a credit balance greater than the total
amount owed, and it was up to them to ensure that the appropriate
amount was transfered from that balance to the third-party supplier.
They responded that this would happen correctly as a matter of course,
i.e., that even though my bill told me to pay the third-party supplier
balance, I didn't really need to do so.  This is not the first time
that the amount due given on my NSTAR bill was different from what
they actually debited.

There are many risks here, including:

* It should be impossible for their billing system to debit an account
  to satisfy an unpaid balance after sending the customer a bill
  instructing him to pay the bill manually.

  Other utilities in my area get this right.  If the bill they send
  you says "please pay," then you need to pay it, regardless of
  whether you activate direct debit between when you receive the bill
  and when it is due.

* It should be impossible for their billing system to tell the
  customer that an amount will be debited automatically and then, with
  no prompting from the customer, debit a different amount or no
  amount at all.

  Putting it another way, the bill that gets sent to the customer
  should be correct (what a concept!).

* The billing system should have safeguards in place to automatically
  detect double payments and bounce them to a human for handling
  (e.g., contacting the customer and/or sending a refund for the

* They should have procedures in place for reversing unauthorized
  debits promptly.  The only things preventing them from doing this
  are bureaucracy and an inadequate billing system.  It is
  unreasonable for them to allow these to get in the way of promptly
  returning money that they stole from customers.

* The billing system should know how to reconcile credit balances with
  monies owed to third-party suppliers.

Incremental insecurity (Re: Cohen and Weiss, RISKS-22.75)

<Paul Wexelblat <>>
Fri, 30 May 2003 20:04:43 -0400

RISKS-22.75 had a couple of entries that illustrate another RISK:
* ISP resets password to an easily guessed one (Dawn Cohen)
* Sensitive data on Web sites reflects lack of security awareness (Rick Weiss)

They point out the insidious problem of secure systems spontaneously
becoming insecure through no action of the user.  This means that, no matter
how safe and secure any service that has your info may be now, tomorrow they
may change their system or be bought out — as illustrated in the two cases

What are the chances that either of these outfits will be either willing or
able to remove the compromised data?

...and what are the odds that complaints of violation of privacy statements
will be met with a claim that the "privacy statement" includes a term
equivalent to "we reserve the right to make any change we want to to these
terms at any time without notice"?

Re: ATM time sync (RISKS-22.73)

<David Lesher <>>
Tue, 3 Jun 2003 10:01:40 -0400 (EDT)

The arrest of the wrong party based on defective "money machine" timestamps
has also occurred in the District of Columbia.

From memory, there was brutal murder and the victim's card had been used
after the time of death. The ATM camera's photo got wide play on TV and in
the newspapers. The person pictured surrendered with his attorney AND the
receipt from his girlfriend's card; he had used it with her permission.

Despite that evidence and an alibi; he was still jailed for about a week
before the US Attorney would relent.

I would think there would be the potential for substantial civil litigation
against the bank, the ATM network and the machine manufacturer in these
cases. Judgments often have the effect of spurring correction of the design
errors...(Another RISK, perhaps — {system} validation by verdict?)

Re: University of Calgary to teach virus writing (Brunnstein, R-22.75)

<Nicholas Weaver <>>
Fri, 30 May 2003 17:44:47 -0700

I have to strongly second Klaus Brunnstein's comments in comp.risks

As a researcher who has analyzed existing worm strategies and developed
novel strategies (warhol worms, metaserver worms) and plausible defenses, I
find the notion of actual virus and worm writing as part of the educational
and research process both abhorrent and of effectively NO value.

For evaluating propagation behavior, simulation, "on-paper" evaluations, and
analysis of previous worms can tell us effectively all we need to know: How
worms and viruses spread, how they interact with many existing and possible
defenses, and some requirements (such as automatic reactions) required to
build robust defenses.

Simulation predicted the possibility of very fast worms and many of the
requirements for automated defenses.  Paper analysis insures that I will
never run KaZaA myself (the recent vulnerability could be used to take out
all supernodes in probably less than <2 minutes).  And analysis gives us a
treasure-trove of what works well for malicious coders, such as how to cross
firewalls and enter local Windows domains.

There are some surprises which come up, such as Slammer/Sapphire's speed,
but these are second-order effects.  Sapphire was still a scanning worm, so
automated defenses which could stop a 1 hour scanning worm should stop a
Sapphire-esque worm.  Likewise, there are numerous other techniques
(Hitlisting & permutation scanning, topological, metaserver) which can
create worms that spread to all vulnerable hosts in roughly the same

Likewise, to evaluate the defenses themselves, existing attacks can often
been used as long as the defense hasn't been pre-trained.  For worms which
exploit security vulnerabilities, such as Code Red, these are no longer
threats, as effectively all vulnerable machines have been patched and
effectively all of the remaining machines are infected.

And, if existing attacks, paper design, and simulation are all insufficient
to evaluate a defense-mechanism, the best solution is to create daemon
programs which run on test machines and who's behavior (eg, system calls,
network communication) MIMICS the behavior of a worm when communicating with
other copies of the program, as such program can not spread beyond the test

There is room for a good course on malicious code and defenses, but it need
not, and should not, include construction of self-propagating programs
(worms or viruses).

I do not need to write worms to understand the problem, construct, and
evaluate defenses.

Nicholas C. Weaver                       

Re: University of Calgary to teach virus writing (Brunnstein, R-22.75)

<Dan Bornstein <>>
Fri, 30 May 2003 16:37:06 -0700

I'm willing to give the U of C the benefit of the doubt here.

Many years ago I had a lot of fun writing programs for a game called Core
Wars.  The idea of the game (for those unfamiliar with it) was that your
program and an opponent's program get loaded into a single "core" and the
goal is for your program to subvert the other one such that the only threads
of execution left are ones that your program initiated.

This was (a) educational, (b) fun, and (c) arguably a helluva lot like
virus-writing. I don't think writing code for Core Wars games is immoral,
nor do I think it should be illegal; and I'd be hard pressed to tell you the
difference between doing that and writing any other code for use in a
controlled, quarantined computing environment, such as is proposed for the

  [When I was at Bell Labs in the early 1960s, there was a version of
  core wars that ran on the IBM 70x machines.  Doug McIlroy, Vic Vyssotsky,
  and perhaps Bob Morris will certainly remember that one.  PGN]

Denial of Service via Algorithmic Complexity Attacks

<Monty Solomon <>>
Sat, 31 May 2003 10:22:56 -0400

Denial of Service via Algorithmic Complexity Attacks
  Scott A. Crosby <>
  Dan S. Wallach <>
  Department of Computer Science, Rice University

We present a new class of low-bandwidth denial of service attacks that
exploit algorithmic deficiencies in many common applications' data
structures. Frequently used data structures have ``average-case'' expected
running time that's far more efficient than the worst case. For example,
both binary trees and hash tables can degenerate to linked lists with
carefully chosen input. We show how an attacker can effectively compute such
input, and we demonstrate attacks against the hash table implementations in
two versions of Perl, the Squid web proxy, and the Bro intrusion detection
system.  Using bandwidth less than a typical dialup modem, we can bring a
dedicated Bro server to its knees; after six minutes of carefully chosen
packets, our Bro server was dropping as much as 71% of its traffic and
consuming all of its CPU. We show how modern universal hashing techniques
can yield performance comparable to commonplace hash functions while being
provably secure against these attacks.

REVIEW: "Mission Critical Security Planner", Eric Greenberg

<Rob Slade <>>
Tue, 3 Jun 2003 12:00:58 -0800

BKMSCRSP.RVW   20030330

"Mission Critical Security Planner", Eric Greenberg, 2003,
0-471-21165-6, U$35.00/C$54.95/UK#25.95
%A   Eric Greenberg
%C   5353 Dundas Street West, 4th Floor, Etobicoke, ON   M9B 6H8
%D   2003
%G   0-471-21165-6
%I   John Wiley & Sons, Inc.
%O   U$35.00/C$54.95/UK#25.95 416-236-4433 fax: 416-236-4448
%P   416 p.
%T   "Mission Critical Security Planner"

In the introduction, Greenberg claims that his book provides guidance
on how to do quantitative security planning without calculations
(which sounds somewhat self-contradictory) using a new technique he
calls impact analysis (which doesn't sound too different from business
impact analysis).  A technical background is said to be unnecessary,
the process is worksheet based, and the target audience is security

Chapter one says that protecting information is not exact (a statement
that doesn't seem to fit well with the worksheet approach).  Random
security topics include planning, intruders, and a risk analysis
example which is, ironically in view of the introduction, more
computationally intensive than most.  An overview of planning, in
chapter two, majors on the minors.  Policies are not discussed until
twenty five pages into the material, and then the emphasis is on very
specific areas like exit (termination of employment) procedures,
leaving huge topics uncovered.  Twenty eight security elements are
listed, and all are important, but almost all are either over-vague or

Chapters three and four introduce the worksheets themselves.  Sixteen
topic areas have four sheets each, dealing with the technical,
lifecycle, business, and "selling to management" aspects of the
themes, while other domains may have only a single sheet.  The
questions listed may be helpful as reminders to address certain
aspects which are often overlooked, but the odd and arbitrary
structure is confusing, and the real work is definitely left as an
exercise to the reader.

A description and analysis of PKI (Public Key Infrastructure), in
chapter five, is vague and weak, and contains much unrelated material.
Chapter six is a recap of the book, along with a simple list of

While the advice in the book is not wrong or misleading, and many
important and useful points are buried throughout, poor organization,
a lack of consistent depth, and gaps in topical coverage ensure that
the text would only poorly repay the investment of time spent studying
it.  Certainly it should not be used as a major guide to structure the
security planning process.

copyright Robert M. Slade, 2003   BKMSCRSP.RVW   20030330    or

Please report problems with the web pages to the maintainer