The RISKS Digest
Volume 23 Issue 67

Monday, 17th January 2005

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…


Loss of data from Huygens Probe
John Murrell
130 most common bugs — and counting
Peter Ludemann
Cellery worm plays games with victims
Hollywood Sign Security
Bruce Schneier
Problems with Chicago-area toll road transponders
GPS used to arrest snowplow driver
David Tarabar
Re: A Comedy of Errors
Rex Black
Yet another route map software problem
Nick Brown
MapPoint explains Vikings?
Adam Shostack
Re: Risks of lenient parsing
Doug McIlroy
Walter Roberson
Roger Burton West
Jonathan Kamens
Russell Smiley
Sander Tekelenburg
Copyright and reverse engineering
Rob Slade
Re: High Tech Crimes Revealed"
Steven Branigan
Re: A Kafka day at the Los Angeles traffic ticket office
Paul Robinson
Info on RISKS (comp.risks)

Loss of data from Huygens Probe

<"John Murrell" <>>
Sat, 15 Jan 2005 20:38:57 -0000

It appears that data was only received from one of the two semi-redundant
communications channels from Huygens by the Cassini spacecraft. At this
morning's press conference it appears that one of the two receivers on
Cassini was not turned on due to a software error.

This has not caused a major loss as most data was duplicated between
channels - the only two losses are that 50% of the images are lost but most
of these will overlap with images sent on the other channel.

Also the 'Doppler Wind' experiment relied on the carrier signal from the
channel that was not switched on however it is believed that this
information can be reconstructed from the radio telescope observations that
were tracking Huygens.

ESA has set up a board of enquiry into why the receiver was not turned on.
It is interesting to know why 'end to end' system tests did not find this.

130 most common bugs — and counting

<Peter Ludemann <>>
Sat, 15 Jan 2005 12:13:33 -0800

Bruce Tognazzini has started collected well-known bugs at ... many of these have shown up
before in Risks, such as "Harassing Confirmations & Missing
Confirmations" and "'Smart' functions that aren't smart".

Readers might also enjoy (if that's the right word) Tognazzini's article
on Security D'ohlts:'ohlts.html
and an older article on how inconvenience and security are confused:

Cellery worm plays games with victims

<"NewsScan" <>>
Fri, 14 Jan 2005 06:19:58 -0700

Users are being warned about the Cellery worm — a Windows virus that
piggybacks on the hugely popular Tetris game. Rather than spreading itself
via e-mail, Cellery installs a playable version of Tetris on the user's
machine. When the game starts up, the worm seeks out other computers it can
infect on the same network. The virus does no damage, but could result in
clogged traffic on heavily infected networks. "If your company has a culture
of allowing games to be played in the office, your staff may believe this is
simply a new game that has been installed — rather than something that
should cause concern," says a spokesman for computer security firm
Sophos.  [BBC News, 13 Jan 2005; NewsScan Daily, 14 Jan 2005]

Hollywood Sign Security

<Bruce Schneier <>>
Sat, 15 Jan 2005 02:50:05 -0600

From Bruce's CRYPTO-GRAM, January 15, 2005

In Los Angeles, the "HOLLYWOOD" sign is protected by a fence and a locked
gate. Because several different agencies need access to the sign for various
purposes, the chain locking the gate is formed by several locks linked
together. Each of the agencies has the key to its own lock, and not the key
to any of the others. Of course, anyone who can open one of the locks can
open the gate.

This is a nice example of a multiple-user access-control system. It's
simple, and it works. You can also make it as complicated as you want, with
different locks in parallel and in series.

  [Ah, a wonderful new use for the switching theory of relay circuits that
  takes me back to Howard Aiken's switching course in 1953!  Boolean
  switching functions and even bridge networks, where current can flow in
  either direction in some links, provide for nifty multilock combinations.

Problems with Chicago-area toll road transponders

Wed, 5 Jan 2005 12:03:06 -0600 (CST)

[Source: Activating I-PASS hits a roadblock; Online demand blamed for delay
Virginia Groark, *Chicago Tribune*, 4 Jan 2005; PGN-ed],1,5273675.story

The Illinois State Toll Highway Authority raised the tolls at 12:01 on New
Year's Day 2005 for drivers paying cash, which caused floods on both the
phone lines (with typically a 15-minute wait) and the Web site, with 65,000
requests for I-PASS accounts over the weekend.  Officials warned that it
might take up to eight hours for activated transponders to work.

GPS used to arrest snowplow driver

<David Tarabar <>>
Tue, 11 Jan 2005 18:39:03 -0500

For the past several years, the Massachusetts Highway Department has
required that private snow-removal contractors carry a GPS equipped mobile
phone. The purpose is to allow the department to better schedule plowing and
to verify that the roads are actually being plowed.

  "The state found another use for the global positioning satellite network
  ...", according to the *The Boston Globe*, 11 Jan 2005.  At 3:45 AM on 10
  Jan, a snow-removal truck stopped at a local coffee shop, where the driver
  ordered coffee and allegedly exposed himself to a female employee. The
  Highway department tracked a truck from a local depot and by later that
  day, the driver had been arrested and charged with multiple offenses.

Re: A Comedy of Errors (Lamport, RISKS-23.66)

<Rex Black <>>
Sat, 15 Jan 2005 19:39:16 +0200

I don't know about whether all professional programmers would necessarily
catch this error, but any programmer doing competent unit testing and/or any
tester doing competent input-handling testing would have caught it.
Equivalence class partitioning would identify at least three classes of

 1. Null string (sometimes valid)
 2. Non-null strings that contain no special characters (valid)
 3. Non-null strings that contain at least one special characters (valid)
 4. Malformed string (always invalid)

In each those classes--excepting perhaps the null string--a competent
programmer or tester should be able to identify multiple subclasses and
other interesting tests (e.g., using boundary value analysis), such as the
non-null string of minimal length, the non-null string of maximum length,
the non-null string exactly one character longer than the maximum length, a
non-null string long enough to overflow a buffer, etc.

Since these types of tests tend to be effective at finding bugs during
system testing by independent test teams, I conclude that many programmers
do not cover these tests during unit testing.  With the advent of some of
the so-called agile methodologies, that may well change, provided that
programmers take the time to study and apply well-established testing

Rex Black Consulting Services, Inc., 31520 Beck Road, Bulverde, TX 78163 USA
1 830 438-4830

Yet another route map software problem

<Nick Brown <>>
Sat, 15 Jan 2005 00:31:13 +0100

This kind of thing has been discussed in RISKS before (20.62, 23.20), but
apparently the problems are still there:

1. Go to
2. In the Start section, select "Norway" from the listbox
   and enter "Haugesund" into the "City" field
3. In the End section, select "Norway" from the listbox
   and enter "Trondheim" into the "City" field
4. Click on "Get Directions"

Interestingly, inverting the cities in the request produces "less
spectacular" results.

What was fundamentally the same service (Microsoft Expedia Maps, now called
MSN MapPoint) figured in article in RISKs 20.62, more than five years ago.

MapPoint explains Vikings?

<Adam Shostack <>>
Sat, 15 Jan 2005 12:06:55 -0500

(Or, that wrong turn at Djupaskarvegen again!)

When going from Haugesund, Rogaland, Norway, to Trondheim,
S=F8r-Tr=F8ndelag, Norway, be aware that  following Microsoft MapPoint's
directions, will take you through England, France, Belgium, the
Netherlands, Germany, Denmark, Sweden, and finally back into Norway.
While this may be culturally sensitive and respectful of historic
Viking routing, rooting, or looting, it is somewhat less efficient than
other routes, as a quick glance at a map will show.

Start: Haugesund, Rogaland, Norway

End: Trondheim, S=F8r-Tr=F8ndelag, Norway

Total Distance: 1685.9 Miles, Estimated Total Time: 47 hours, 31 minutes
(This is listed as the "quickest" route.)

[.gif file deleted]

Re: Risks of lenient parsing (Horning, RISKS-23.66)

<Doug McIlroy <>>
Sun, 16 Jan 2005 16:05:39 -0500

Following up on Jim Horning's remarks that rightfully blame the prevalence
of bad HTML, which works here but not there, on browsers' silently "fixing"
errors, I note that this behavior was officially encouraged:

  HTML user agents should be liberal except when verifying code.
  - Berners-Lee, Connolly et al, "HyperText Markup Language
    Specification - 2.0", Internet Draft, November 28, 1994

Browsers — the only ubiquitous tools for seeing that a web page works --
are rarely built for verification, and this sentence lets them off the hook.
It has always ranked high on my list of misguidances in language design.

  [Doug's message is right on.  Jim's posting created quite a flurry, both
  in-band and out-of-band.  I have selected a few, despite some overlap,
  which by no means covers the waterfront, but may exhaust the reader.  PGN]

Re: Risks of lenient parsing (Horning, RISKS-23.66)

<Walter Roberson <>>
Sat, 15 Jan 2005 02:07:48 -0600 (CST)

In RISKS-23.66, Jim Horning contended that "*all* of the browsers were wrong
not to indicate clearly the presence of a syntax error."

In my experience, pages *without*  HTML syntax errors are quite uncommon.

I usually use an older browser that does less automatic fixups of incorrect
HTML. If I hand-edit nonconformant HTML to make it compliant, the browser
almost always works.

I find that an increasing number of sites are insisting on IE6, or Firefox,
or Netscape 7, supposedly because "We use advanced HTML features not
supported in older browsers".  In *every* such case that I have
investigated, if I grab the content elsewise and fix its broken HTML, the
pages have worked fine on the old browser.

Sites almost never fix their HTML in response to my reports.
It has become clear to me that requiring IE6 has become a euphemism
for "Our HTML is nonconformant and we have no intention of fixing it."

Re: Risks of lenient parsing (Horning, RISKS-23.66)

<Roger Burton West <>>
Sat, 15 Jan 2005 12:52:42 +0000

Mr Horning may find it useful to be aware of the Dillo browser
(, which not only gives detailed information on errors
in HTML but uses a clearly-specified set of heuristics in trying to correct

Re: Risks of lenient parsing (Horning, RISKS-23.66)

<Jonathan Kamens <>>
Mon, 17 Jan 2005 10:21:29 -0500

I had a "those who fail to learn from history" moment when I read Jim
Horning's account of his difficulty tracking down an HTML syntax error
because all of the browsers used to display the page with the error silently
corrected it.

Years ago, early on in the browser wars when Netscape was still king, I
heard a similar rant from one of my friends who is an SGML / XML / HTML
expert.  The very controversial question the browser developers and early
adopters were asking then was, should HTML be treated as a structured
language which must parse correctly to be displayed, or should it be treated
as a markup language which browsers should obey as much as possible even
when it's broken?

Clearly, the browsers have chosen the latter.  As uncomfortable as that
decision may make the technology purists among us, it is a reasonable
application of Postel's rule to "Be generous in what you accept and
conservative in what you generate."

Developers who regularly encounter difficulties with HTML syntax errors
which the browsers make difficult to locate may wish to avail themselves of
one of the numerous free and commercial HTML validation tools that are

Re: Risks of lenient parsing (Horning, RISKS-23.66)

<"Russell Smiley" <>>
Mon, 17 Jan 2005 11:01:18 -0500

> A friendly browser would even have made some
> attempt to indicate the approximate location on the page of the error.

Personally I'd be rather annoyed if my favourite browser started generating
prompts for "general syntax error at line x" on every poorly formed web page
out there and I suspect most general users would as well.

It seems to me that browsers try to cleanly and silently work around
problems in HTML to ease the experience for users who simply don't
understand the issues with writing good HTML, or don't want to. In a general
sense this seems particularly reasonable when most of the time the error can
be worked around without any noticeable problem for the user.

However Mr Horning's experience suggests there is a specific class of users
who actually need the error reporting to validate the HTML they are
generating. Rather than "enhancing" browsers to report all errors as Mr
Horning suggests I would suggest that browsers should have a debug mode
which is by default disabled to facilitate the present user-friendly
experience. When enabled the debug mode could report all HTML errors for the
benefit of those users who need to know about such errors.

Re: Risks of lenient parsing (Horning, RISKS-23.66)

<Sander Tekelenburg <>>
Sat, 15 Jan 2005 13:45:05 +0100

> So what is the lesson?

The 3 lessons are:

1. There is no excuse for publishing invalid HTML as there are plenty of
HTML validators available. (Once you use them you will notice that there are
(almost?) no CMS tools, blogs, 'WYSIWYG HTML editors', etc. that output
valid HTML. At best they output minor errors (like not encoding ampersands)
but usually they'll just output crap, relying on browsers' ESP engines to
guess what was meant.)

Note that some of those tools, like HTMLTidy, are useful but are not

2. When a Web page shows a problem, the first thing to do is make sure its
HTML is valid. It's no use wasting time on any other aspect as long as it is
not. For some reason most Web designers seem to be unaware of this.

3. You were using the wrong tools. (iCab, see below, would have been a right

> Given the frequency of errors in HTML, it would be unreasonable for
> renderers to refuse to display pages with errors.

IMO this is open for debate still. Browsers refusing to display invalid HTML
would be the ideal solution, as it would force authors to ensure valid HTML.
However, I recognise that, given that easily 95% of the Web contains broken
HTML, a user agent that would refuse to display such pages would never become
popular. It is simply too late now. Users expect Web pages to 'just work'.
They expect browsers to guess what the author meant, and to guess right.

Still, indicating to the user that a page contains invalid HTML, and that
therefore what is rendered is no more than a best guess at what the author
intended *would* be realistic. It would be a very useful tool for those who
care, and it would not get in the way of those who don't. Give it time, and
more users will hopefully begin to realise that indeed it does matter. The
Web browser iCab has offered this for many years.

A way to make this even more useful, perhaps even to popularise this, might
be to have browsers score pages. The less HTML errors, the better the score,
thus indicating that the user can be more confident that what is being
displayed is what the author intended.

If that becomes popular enough, then maybe, just maybe we can finally arrive
at a point where users will appreciate browsers that refuse to display
invalid Web pages. Probably the right way (both to make it a smooth step from
the previous step, and to popularise it) would be to allow users to define
the threshold at which their browser should simply refuse to display a page.

Of course you would need to come up with a sensible algorithm to be able to
score HTML in a useful way. This won't be easy given that 1 error will
influence the effect of another error...

> We stumbled around blindly because *none* of the browsers we were using
> gave any hint that there was a syntax error on the page.

There is at least one browser that does contain a HTML syntax checker, and
has so for many, many years: iCab. See <>. When it
considers a document's HTML to be good, it shows a green smiley in the
toolbar. When it considers a document to contain 1 or more errors, the green
smiley turns into a red sad face, which you can click to get a list of all
the errors it found (including a hint as to what is wrong about it and
sometimes even what it probably should have been) and in turn
double-clicking individual errors makes it show the document's source code,
with the relevant portion highlighted.

This tool has been available since about 1998 (provided you have a Mac to run
it on). AFAIK to this date no other browser vendor has been smart enough to
copy this function.

iCab 3.0, which is currently in 'limited public beta testing' phase not only
validates HTML 4.0.1 but also XHTML 1.0, CSS 2.1 and javascript.

> Each just silently "corrected" the error. Unfortunately, but predictably,
> they didn't all "correct" it in the same way, meaning that Peter and his
> testers were consistently getting one result, and I was consistently
> getting another.

Although I agree, IMO you're forgetting an even more (and far more common)
danger: that silently fixed HTML errors can easily lead to output that is
wrong, but *not obviously wrong*.

Also note that this goes beyond just HTML. For instance, many Web sites do
not provide any or the correct character repertoire that applies (and
sometimes even claim 2 different charsets!), and browsers will often silently
guess which character repertoire to use. This can lead to outright nonsense
which is easily recognised, but can just as well lead to just the odd
character being wrong. You bet that in some cases that 'wrong' character
could make perfect sense and can thus go by undiscovered, even though it
could change the meaning of the content completely. AFAIK no browser will
warn the user in this case.

So use iCab, and/or put pressure on the makers of your favourite browser to
make their product useful.

Sander Tekelenburg <>

Copyright and reverse engineering

<Rob Slade <>>
Tue, 11 Jan 2005 11:31:25 -0800

> A French security researcher who published exploit codes that could
> take advantage of bugs in an anti-virus application, could be
> imprisoned for violation of copyright laws.

I warned ya.

OK, well not quite the same situation, but on page 21 of "Software
Forensics" I noted that this type of situation might one day result in a
malware author challenging evidence obtained by forensic examination on the
basis of the laws supposedly supporting copyright by inveighing against
reverse engineering.    or

Re: High Tech Crimes Revealed" (Slade review, RISKS-23.65)

<Steven Branigan <>>
Sun, 16 Jan 2005 18:21:10 -0500

I am honored by the fact that Robert Slade took the time to do a review of
my book, "High Tech Crimes Revealed", back on December 29th, 2004. It covers
a few high tech crime cases from "inside the investigation", based upon
actual cases with which I was involved.

I believe that these stories are very relevant in today's society. We need
just look at the recent story about hackers breaking into T-Mobile to read
e-mails of an ongoing investigation to see that hackers are still getting
past computer security.

I just wanted to address a couple of small points that I spoke with Robert
about prior to his publishing this review.

(1) steganography

The quote from my book is...  "Rumors persist that Al-Qaeda style terrorist
groups have used steganography to hide their communications out in the
open. Using steganography, a person can hide a secret message inside a
picture that is sent via e-mail or even posted on a website. All that is
needed from the person receiving the picture is to extract the hidden
message from it."

Rumors do persist that terrorist have looked at using steganography for
clandestine communication.

Let me state that I have not seen any conclusive evidence that steganography
has been used for terrorist communications. I do wish to point out, though,
that some in the government are concerned about it and are not looking into

(2) Salami scam

I had a discussion with Robert and I believe that his view is that the
salami scam is all hype because there are very few documented cases of it.
I respect that point of view, but I believe that the following documented
cases are sufficient to be concerned about it as a potential crime.

Re: A Kafka day at the Los Angeles traffic ticket office (R.23-66)

<Paul Robinson <>>
Mon, 17 Jan 2005 11:14:44 -0500

  [Open letter to Mark Frauenfelder:]

I saw the discussion of your problem with your wife's traffic ticket which
was also reported in RISKS-23.66.  I am not a lawyer but I have some idea on
what your wife needs to do if you can't resolve the ticket because the
system won't record it:

Call (or preferably write) the headquarters office for the district attorney
for Los Angeles County.  If you write, you explain the situation; if you
call you ask to speak to the district attorney or get an appointment,.saying
you need to discuss the disposition of a court case.  You do not inform the
secretary of what the case is unless she says she has authority to negotiate
a plea bargain herself (which she won't of course).  You'll get some lawyer
in the office but that's fine, because that's what you want..

If you can get a lawyer on the phone or you get an appointment, you explain
the circumstances of the situation and ask them to agree to dismiss the
charge and not prosecute this particular ticket because the case office is
not posting the ticket and you can't be put in a position where you are
"twisting, turning in the wind," waiting for an unknown and unknowable
filing to be made which places you in jeopardy of even more serious criminal
penalties when you can't get the current one resolved.

If they won't or you can't get someone, you file suit in Superior Court
against the District Attorney's office (you will probably have to sue the
D.A. personally by name) for a writ of mandamus prohibiting them from
prosecuting the original ticket.  You may even be able to sue for damages
but I think all you're interested in is to get rid of the matter, either by
converting it off of a moving violation or getting it dismissed.  I don't
think it would be that difficult to file for an order even without a lawyer
since you're only trying to solve the problem and the government, by its
incompetence or misconduct is placing you in a position in which you are
being denied the right to a constitutionally guaranteed speedy trial and
quite possibly to and possibly other issues.  Even if you
don't get the order you've got grounds to have any potential penalty for not
paying the ticket and not appearing canceled.

Please report problems with the web pages to the maintainer