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 25

Thursday 4 March 2004


Leap Year Strikes Again
Chuck Weinstock
Pssst, wanna buy a spambotnet?
Rob Slade
July 2002 air collision revisited
Michael Bacon
Damaging consequences of response to password-protected viruses
Vassilis Prevelakis
Spring '04 Sun Outage Notification
starband via Mich Kabay
SPAM Countermeasures
Scott MacQuarrie
Re: RFID tags in new US notes explode when you try to microwave them
Michael Borek responding to Paul Schleck
And Another E-Voting Problem
David Bolduc via Dave Farber's IP
Moseley Braun paper
Peter Zelchenko
Avi Rubin on e-voting after yesterday's primary
Dave Brunberg
Denial of service in criminal justice
Dick Mills
REVIEW: "Hiding in Plain Sight", Eric Cole
Rob Slade
Info on RISKS (comp.risks)

Leap Year Strikes Again

<Chuck Weinstock <>>
Tue, 2 Mar 2004 18:36:45 -0500

I do not know the attribution for this:

  "America's Railroads!  Ya gotta love 'em!"
  "I have learned from two separate sources that the original software
  update-related outage scheduled for Sunday was indeed to be 1 1/2 hours.
  Normal, anticipated work done by the computer was finished ahead of time
  so the outage would have a minimal effect.  In tests, the software was
  found to function properly.  They started the update, deleting the old
  software and installed the new, and then...

It was Leap Year, and the date was 29 Feb 2004.  Whoever wrote the new
software didn't take that into account, so nothing was working.  Realtime
dispatching on the railroad, using a separate system, was not affected; but
the disabled system was down for more than four hours longer than originally

Perhaps related, perhaps not: BNSF, like Amtrak, has outsourced its IT
operation to a company which has in turn off-shored the work to the other
side of the International Date Line; perhaps it should now be caused India
Business Machines."

  [Our local Y2K patch for Columbia-MM failed on 1 Jan 2004, adding one
  day to the date of each message in the summary listing.  It had already
  been re-patched for 2001.  PGN]

Pssst, wanna buy a spambotnet?

<Rob Slade <>>
Thu, 4 Mar 2004 13:39:18 -0800

You probably will have heard of the bickering going on between the authors
of the Bagle, Netsky, and MyDoom virus families.  (This type of thing goes
on all the time.  Frequently the insults are directed at virus researchers
and antivirus companies.  I haven't yet been libeled in a virus: the vxers
prefer to use Amazon to put up "reviews" of my books :-)

The fight made the front page of our local paper, *The Vancouver Sun*, this
morning, albeit below the fold.

The article is a bit over the top in places, referring to "the first cyber
struggle for world domination of the Internet."

The assertion that most concerns me is:

  "At stake are vast armies of Internet-connected computers that virus
  makers are trying to control. Once under their control, they sell access
  to the computers to spammers, who use them to send out a constant barrage
  of junk mail."

We know that a large number of recent viruses and worms install limited
backdoors into the machines that they infect.  We also know that a very
large proportion (most, according to some studies) of spam is coming from
individual machines, and therefore probably distributed nets.  The article
later goes on to point out that the recent trend towards having "expiry
dates" in a number of viruses can be interpreted as an attempt to ensure
that the networks of infected machines can only be used for a limited time,
thus creating a renewable market.

All of this does suggest that virus writers are creating such networks, and
the recent discoveries out of Germany do confirm that attempts are being
made to market spamming nets.

I doubt that the trend will continue for long.

vxers will undoubtedly continue to create networks of backdoored machines.
For one thing, it provides a terrific means for "seeding" your creation out
into the world.  (MyDoom, Bagle, and Netsky have all enjoyed "instant"
success out of any proportion to their design.)

But virus writers have never been able to get along with anyone, including
each other.  (I think I can safely make this assertion in view of the
current fight going on.)  This characteristic is somewhat detrimental to
getting a business organized.

At this point, I think the "selling to spammers" business is working, but
not very structured.  Soon the vxers will start to realize that you have to
advertise in order to get work, and contact your customers in order to get

In the meantime, I suppose that law enforcement types could round up more
than a few vxers with sting operations ...    or

July 2002 air collision revisited (Cox, RISKS-23.23)

<"Michael \(Streaky\) Bacon" <>>
Wed, 3 Mar 2004 07:35:55 -0000

In RISKS 23.23, Paul Cox wrote: "The specific scenario that was
predicted, and which apparently happened in the Switzerland crash, was
this: Two aircraft are in conflict.  Their TCAS systems activate and
proscribe a course of action for each aircraft which, if followed,
should separate them."

Surely the course of action is prEscribed, not prOscribed?

  "In the worst-case scenario, the TCAS tells one plane to climb and another
  to descend; ATC tells the first plane to descend and the pilots follow
  THAT instruction, which only makes matters worse as both planes are now
  trying to descend below the other.  Planes smack, everyone in the air

I must be missing something.  Surely this is the "pass to starboard"
scenario designed to avoid collisions at sea?  If one plane is commanded to
climb and the other to descend, they will not (assuming immediacy of commit)

  "Unfortunately, the possibility for confusion still exists.  In this case,
  it was probably exacerbated by the fact that the Russian plane's pilots
  came out of an aviation system which heavily emphasized ground control and
  discouraged pilots making "their own call" in the air; the Russian pilots
  were (apparently) predisposed to follow the ATC instructions instead of
  the TCAS instructions."

It was reported at the time that Russian pilots are trained (rather than
"discouraged") to ignore the TACS - which accords with the old Soviet air
discipline in general.

It has also been my experience, and that of many pilots flying
internationally, that many Russian pilots have an apparently poor command of
English.  As those who speak more than one language can relate to, this can
be easily exacerbated by stress.  I was in the jump-seat of a British
Airways 757 bound for Rome when the crew became aware that there were severe
misunderstandings between an Aeroflot captain and an Italian ATC controller
(with a thick accent).  Our captain begged permission to assist and during a
40 minute period acted as liaison and interpreted the ATC instructions to
the Aeroflot captain.  The aircraft landed safely and our captain entered a
report on the incident.  Later that same week, a similar tale was related to
me by another BA captain of a common-language communications failure off the
coast of North Africa involving another Aeroflot captain and a Moroccan ATC

Thre is an ever present RISK stemming from any lack of fluency in the
language of ATC in circumstances of both normality and stress.

Damaging consequences of response to password-protected viruses

<Vassilis Prevelakis <>>
Wed, 3 Mar 2004 10:47:58 -0500 (EST)

A new variant of password-protected viruses is circulating, I won't bother
you with the details as you are probably well aware of them by now.  What is
dangerous in my mind is the response to such viruses: for example, Drexel's
computer support decided unilaterally to remove all password protected

"This morning, Drexel IRT has configured the central mail antivirus scanners
to remove all attachments which require a password to open them."

Mercifully they do not do that, they only remove password protected ZIP
files. However, if people just go and ahead and remove any encrypted
attachment, then that will cause severe disruption to secure communications
over e-mail.

I think we should resist such efforts and prevent the spammers and
virus writers do to us what the government failed to do.

Vassilis Prevelakis, CS Dept. Drexel University

Spring '04 Sun Outage Notification (via Mich Kabay)

Tuesday, March 02, 2004 15:15

Dear StarBand Member,

What is a sun outage?  The sun never goes out!  Well that is not what we are
referring to.  A sun outage is what happens when the sun positions itself
directly behind and in line with your satellite antenna and the satellite in
the sky.

How does that cause an outage?  The reference to an "outage" is when your
satellite antenna cannot hear the signal from the satellite.  The satellite
signal did not go away, but the sun overpowered your receiver with "noise".

Look at it this way, imagine you are at a party trying to hear a story your
friend is telling you, but the guy next to you is shouting.  Your friend is
still talking to you, but because of the shouting, all you hear is "noise".

Sun outages usually occur two times a year, in the spring and the in the
fall.  The time and length of the outage varies from day to day and depends
upon where in the United States you live, but will occur for only a few
minutes at a time.

If you live in Atlanta and your StarBand system is looking at the satellite
AMC-4 (99-101 degrees) you may experience the event on March 2nd from 2:02
PM until 2:06 PM and again on the 4th, 5th, 6th, and 7th at about the same

Since Telstar 7 (129 degrees) is at a different place in the sky than AMC-4,
the first sun outage in Atlanta when looking at this satellite will be from
3:08 PM to 3:10 PM from March 5th to March 6th.

The duration of the outage will start out short and build to a peak of about
7 to 8 minutes at a time, then diminish as the days go by.  Again, this is
an example based on a satellite antenna positioned in Atlanta, Georgia.

For all other StarBand customers within the continental United States, these
sun outages may occur between March 2nd and March 7th.  The time of day
depends upon your location in the US and which satellite your system is
using.  For customers in Hawaii, these outages may occur between March 8th
and March 13th.

Please be patient and bear with us, as we have no control over this natural
phenomenon.  Thank you.

The StarBand Team

SPAM Countermeasures

<Scott MacQuarrie <>>
Tue, 02 Mar 2004 23:52:55 -0500

I am surprised at some of the ideas put forward to prevent spam and feel
many of them, such as charging for e-mail, are worse than the problem
itself. Ultimately, this is matter of using definitions to focus on the
actual problem, rather than trying to apply massive architectural changes to
"carpet-bomb" the problem.

By definition, spam is simply e-mail from unidentified sender(s). The
solution is to require senders to identify themselves, either by e-mail
address or domain before accepting their e-mail. There is no need to filter
e-mail from people you know or domains you trust. It's strangers you need to

Anti-spam lists, such as the Blackhole list and others are following this
strategy, but offering to act as an intermediary. The better, and simpler,
solution is at the individual layer, using tools such as choicemail from
Digiportal. (Note: I am simply a satisfied customer and, in no way represent
the company). This tool filters e-mail, based on if I allowed them or their
domain to e-mail me. If you are not know, you are sent an e-mail asking who
you are. The response (via digiportal's website - a trusted URL) is sent to
me and I can decide if I want to receive it. If you never respond, your
e-mail is quietly deleted. For mailing lists, such as this one, I can
authorize the domain or the individual e-mail address in advance.  During
the installation, It also happily reads my address file and adds anyone
found there to the authorized list (since I obviously know them).

After using this tool for almost a year, I have enjoyed a spam-free
existence. This has also not required a significant architectural change or
additional billing models to implement. This is simply the implementation of
the same process used if you ring my doorbell. If I don't know you, I may
not answer it.

Of course, I still have the bandwidth of the e-mail being sent, but this is
my ISP's problem, not mine.

Scott MacQuarrie, ZWCX Computer Corp.

Re: RFID tags in new US notes explode when you try to microwave them

< (Michael Borek)>
Thu, 04 Mar 2004 15:02:07 -0500

I received the following in reference to my submission in RISKS-23.24.

  [RISKS received a large number of similar debunkings: Most of the bills
  depicted were old-style, there is no RFID tag, no bump in the vicinity
  of Andrew Jackson's right eye, etc.  I did not believe it either, but
  thought I'd see what responses it inspired.  Thanks to all of you whose
  contributions I did not include.  PGN]

In response, I didn't believe or disbelieve the story.  The main point I
intended was a risk of the rumour that one can microwave RFIDs to destroy
them.  Coupled with a belief that the notes contain RFIDs (I understand some
countries are at least considering this), this could lead to some less than
safe activities.

If, as Mr. Schleck states, a bundle of new US$20 notes can set off
anti-theft systems because of the contained metal, I can see other risks:

* Thieves targetting those who set off an anti-theft system but who are not
  detained by store security (customer risk)

* 'the boy who cried wolf' syndrome leading to only cursory checks of those
  who set off an anti-theft system (store risk)

What would be the effect on anti-theft systems of carrying about a handful of iron filings or chopped steel wool?  Could this become an interesting version of DoS (denial of service)?

Michael Borek

"Paul W. Schleck" <> wrote:

>It was not clear from the RISKS submission whether or not the story was
>believed by the submitter (or the editor, for that matter).  Several
>people have debunked the assertion that RFID tags are in current
>U.S. currency.  Even if they existed, microwaving such RFID tags (often
>with resonant frequencies much lower than microwave) might not disable
>them.  Debunking links include:
>The explanation for what happened is that current U.S. notes, including
>the new $20 bill, have metallic content.  Stacking a large number of
>them could set off anti-theft systems, or cause large burn marks in the
>metallic regions of the notes when microwaved.
>Paul W. Schleck

And Another E-Voting Problem (via Dave Farber's IP)

<David Bolduc>
Tuesday, March 02, 2004 12:47 PM

One that hadn't occurred to me, but should have:

UPDATE: Athena Runner e-mails from California:

My husband and I went to vote this morning at 7 a.m. in Carlsbad, CA (San
Diego County) and the new and improved *cough* electronic voting system
wouldn't boot up. I went back twice and at 8 a.m., they still weren't
working.  Apparently it's a sporadic problem county wide.

When voter turnout is so low already, forcing people to try and come back
multiple times is a huge problem. I miss my paper ballot.

Bryon Scott also e-mails:

At least the machines in Maryland are working. Here in San Diego the local
radio stations are reporting that more than a dozen areas in the county
can't even get the machines up and running.

Paper always works.

ANOTHER UPDATE: Reader Bruce Bender e-mails:

New voting machines were down in at my polling place in Oceanside, CA (next
door to Camp Pendleton). Many people here leave for the day to work in San
Diego and Orange and will either try again tonight or not vote. It is a
strange feeling to be denied the chance.

Several other readers are reporting problems in various locales. You can't
expect any system to work perfectly, of course, but this really doesn't seem
ready for prime time.

IP Archives at:

Moseley Braun paper

<Peter Zelchenko <>>
Wed, 18 Feb 2004 04:31:42 -0600 (CST)

Since Carol Moseley Braun has dropped out of the presidential race, it's
safe for me to put out the draft of her position paper on voting systems:

As it was my draft, Carol didn't have an ounce of input on this paper. She
was to go to Georgia with voting systems in her platform, but she never
found time for it. In fact, this paper is primarily a provider of background
for the public and concludes with my own prejudices about electronic
voting. Therefore, it should be interesting to this community as it comes
from the perspective of a technological conservative.

Over the years, after too many hours logged troubleshooting polling places
in minority areas rife with both low machine competency and election fraud,
and having sat in on a lot of discussions about what to do about the
undervote crisis, absentee balloting, fraud, and so on, I have to say I am
even more reluctant than most about the prospect of putting computers into
every booth. I am still struggling with how to express this.

As an initial exercise into these questions, I obtained some punch systems
from the Chicago Board of Elections and threw together a rudimentary
feedback-enhanced punch booth, employing a few flip-flops set by punching
through with a micro-mini phone plug (replacing the stylus), which
flip-flops drive colored LEDs on a bigboard in front of the voter. With a
few pennies invested, a part of the punch feedback problem was solved.

This is obviously not a real solution, since it operates on a fundamentally
flawed concept. Punch, while to a great degree implemented with astonishing
elegance, loses all credibility, in my opinion, at the die-cutting
operation, in which a printer must make 2,000 precise incisions into a small
card. Its second major flaw is the fact that the text is not displayed on
the ballot. Enough is enough: It's long since time for punch to retire. But
the exercise demonstrates that the technology we need to solve the problems
may be far simpler than we think.

Setting punch aside, paper as a source document should not be discarded out
of hand. Obviously, the DRE companies are eager to bury paper, but my belief
is that we cannot improve on it in the booth. I sat for two days with a
sketch pad attempting to devise a foolproof scrolling and selection metaphor
using what I felt were solid principles of industrial and interface
design. This was after reviewing a spate of elegant looking but woefully
inadequate, deeply flawed interfaces by even well-funded names like Diebold
and Hart. I couldn't come up with something that approached the rudiments of
pen contacting paper.

I decided that a combination platform of hand-marked optical (for 90% of the
population) should be coupled with computer-aided booths (for the remainder)
which print out ballots for optical reading; hand-marked ballots should be
scannable and reviewable by any voter if he or she so chooses, and possibly
even committed to tabulation by the voters themselves. My efforts led me to
conclude that a proper solution must assume a consistent rendering of the
ballot, whether a voter is marking the ballot by hand, it is being displayed
on a DRE, or it is being reviewed on some reviewing device. How in the

What is interesting about this usability problem is that it involves such
surprisingly simple stimulus and feedback atoms - the basic checkbox or
radio-box metaphor - but they must be executed on a potentially very complex
display and selection plane, calling for either paging or
scrolling. Multiple selection, deselection, reselection is a huge additional
problem, possibly unsolvable in two dimensions without a dialog. The
interface needs to be instantly and plainly usable by every voting-age
individual. The device must be highly configurable.

Elevator, vending machine, microwave, cash station, VCR - a voting system is
unprecedented in its demands, and we are attempting to solve all of the
demands in too short a period. This is not a place where experimentation
should be welcome. Feeling rushed, everyone is grasping at replicating the
historical experience on screen rather than coming up with something new
that works.

I hope to elaborate on this when time permits.

I also want to thank David Dill, Rebecca Mercuri, Doug Jones, Avi Rubin, and
Lorrie Cranor for the successful phone conference we had with Moseley Braun
and Bruce Crosby back in October.

Peter Zelchenko (  1-312-RED-BIRD

Avi Rubin on e-voting after yesterday's primary

<"Dave Brunberg" <>>
Wed, 3 Mar 2004 13:07:50 -0500

Avi Rubin's experiences as an election judge in Baltimore yesterday both
relaxed and confirmed some of his fears about electronic voting.  He came
out of the experience with the impression that the Diebold systems are still
flawed, but with greater faith in the other election judges he worked with.

Whole story here:

Denial of service in criminal justice

<Dick Mills <>>
Wed, 3 Mar 2004 12:58:40 -0500

Elliot Spitzer, Attorney General of New York was interviewed on the radio
this morning about the potential prosecution of Jason West, mayor of New
Paltz, who has been performing same-sex marriages.  Mr. Spitzer said,
"Although this case is important, we have many other cases more important,
involving violence, child abuse and so on.  We can't prosecute them all."

The statement made me think immediately of denial-of-service hacker attacks.
It suggests that elected officials could arrange for the prosecutor's office
to be permanently overloaded so that those officials could steal without
fear of being prosecuted; even if caught.

However, Mr. Spitzer's very next statement suggested the cure for the
problem.  He said that if abuses become serious enough that his office makes
exceptions to the priorities. It might make an example of an abuser to send
a signal to others.  Of course, the radio interview itself was sending just
such a signal.

Human institutions utilize adaptability, psychology and publicity.  Try to
imagine a Web server changing it's priorities, or launching retaliatory
attacks, or of making public threats.  That level of machine intelligence is
not in the foreseeable future (thank goodness.)

There is a risk if we expect the security of unsupervised machines,
regardless of design, to be comparable to human institutions.

REVIEW: "Hiding in Plain Sight", Eric Cole

<Rob Slade <>>
Thu, 4 Mar 2004 08:25:42 -0800

BKHDPLST.RVW   20031205

"Hiding in Plain Sight", Eric Cole, 2003, 0-471-44449-9,
%A   Eric Cole
%C   5353 Dundas Street West, 4th Floor, Etobicoke, ON   M9B 6H8
%D   2003
%G   0-471-44449-9
%I   John Wiley & Sons, Inc.
%O   U$35.00/C$53.95/UK#24.50 416-236-4433 fax: 416-236-4448
%P   335 p. + CD-ROM
%T   "Hiding in Plain Sight"

Part one explores the world of covert communication.  Chapter one suggests
that covert communication is all around us, but weakens its case by
providing only fictional examples.  The author also states that he has
detected huge numbers of files which contain embedded steganographic
materials.  He doesn't seem to understand that this hurts his argument: what
good is steganography if you can detect its effects?  There is a confused
and incomplete introduction to cryptography in chapter two.  To be fair, it
does make some good practical points, such as the difference between an
algorithm and an implementation.  The basics of steganography are provided
in chapter three but the explanations and examples may not make clear the
distinction between steganography and covert channels or codes.  The
definition and illustration of digital watermarking, in chapter four, does
not present a rationale as to why the invisible marking data cannot be
removed.  The example is confused and unconvincing.

Part two is supposed to take us into the hidden realm of steganography.
Chapter five outlines miscellaneous computer crimes and intrusions with only
the most tenuous ties to steganography, fabricated by the author.  A list of
steganographic programs (almost all of the insertion type) are provided
without details in chapter six.  There are more examples of the same
illustrations, a couple of related programs, and some mislabelled figures (a
graphical layout of an IP header rather than the promised sniffer example)
in chapter seven.  Cole uses an instance of hiding a virus with
steganography, but the dangers of inventing your own cases becomes evident:
the virus, as described, wouldn't work anymore.

Part three purports to show you how to make your own communications secure.
Chapter eight lists cryptanalytic and steganalytic techniques, but does not
delineate them well.  A rehash of previous ideas and weak examples
substitutes for the strategy promised in chapter nine: the main illustration
has a complete failure of forward secrecy.  Chapter ten pledges that
steganography will get better.

Although Cole is more entertaining than Katzenbeisser and Petitcolas manage
to be in their "Information Hiding Techniques for Steganography and Digital
Watermarking" (cf. BKIHTSDW.RVW), his information is sketchy and suspect.
In comparison, his work is little more than a pamphlet.

copyright Robert M. Slade, 2003   BKHDPLST.RVW   20031205    or

Please report problems with the web pages to the maintainer