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 41

Thursday 3 June 2004

Contents

Computer breakdown in England affects air traffic
Debora Weber-Wulff
Privacy and Security Risks in Rampell's E-Mail Surveillance Service
Lauren Weinstein
France Telecom voice mail espionage
David F. Gallagher
USB risks
Gadi Evron
Whom do I tell?
Jerry James
An anatomy of a PGP Joe Job
Gadi Evron
Netgear/UWisc NTP mess
Hal Murray
Selling Web bugs
Neil Youngman
Re: Spam being rapidly outpaced by 'spim'
Gadi Evron
Info on RISKS (comp.risks)

Computer breakdown in England affects air traffic

<Debora Weber-Wulff <weberwu@fhtw-berlin.de>>
Thu, 03 Jun 2004 18:43:42 +0200

tagesschau.de has an in-depth update on the software failure at
http://www.tagesschau.de/aktuell/meldungen/0,1185,OID3328786_REF1_NAVSPM1,00.html
(in German), here my synopsis/translation:

NATS (National Air Traffic Control Service) was supposed to move from West
Drayton to Swanwick near Heathrow in 1996 and 1997 with a completely
modernized technology for air traffic control.  The system cost 623 million
Pounds Sterling (940 million Euros) and was not delivered by Lockheed Martin
until 2002.  It will take until 2007 for the move to be completed.

Four months after the system was initiated, there was a large breakdown in
May 2002 that caused an air traffic outage over England. "Experts" decided
that the problem was the technical communication between the ancient
computers in West Drayton and the new ones at Swanwick.

The current misfortune is attributed to an attempt on the night of 2 Jun
2004 to update the system. The update did not work, and the mainframe could
not be restarted.  Two hours were needed to get the backup system
functional.  In the course of the day, it was disclosed that the computer in
question is 30 years old. [actually, sometimes I trust older systems more
than I do these modern WinTel boxes... -dww]

The update that was to have been installed was ordered after an incident in
Jan 2004 in which there was almost an in-air collision in British airspace.
The air traffic controller had told two large passenger machines to move
apart.  The data came into the system reversed, so that the machines
actually moved closer to each other.  The error was recognized in time by
pilots and by the air traffic controller.

Prof. Dr. Debora Weber-Wulff, FHTW Berlin, FB 4, Treskowallee 8, 10313 Berlin
Tel: +49-30-5019-2320 http://www.f4.fhtw-berlin.de/people/weberwu/


Privacy and Security Risks in Rampell's E-Mail Surveillance Service

<Lauren Weinstein <lauren@vortex.com>>
Thu, 27 May 2004 13:00:00 PDT

PRIVACY Forum Digest  Friday, 28 May 2004   Volume 13 : Issue 03
( http://www.vortex.com/privacy/priv.13.03 )

Greetings.  There's been a lot of publicity over the last few days about
Rampell Software's DidTheyReadIt.com service.  There have been other
software tracking systems introduced before, but this one, by including
features that attempt to determine how long a message is kept open (as well
as whether it was received, who you forwarded it to, etc.) is worthy of
particular disdain and concern.

There's more than just basic privacy issues involved.  Many individuals,
businesses, and particularly government entities may have serious security
issues regarding capabilities that can expose information about when a
particular person has read a message, and perhaps potentially even if they
are still actually sitting there reading the message right now.  The
possible dangers are fairly obvious -- knowledge of the hours a person
works, when they tend to be in their office, etc. can be easily abused in
sensitive environments.

Some of these features not only depend upon invisible image "Web bugs" used
in a "conventionally invasive" manner, but also reportedly feed a slow
stream of data to your system during the entire interval you're reading a
message (that's how their "how long were you reading the message" function
apparently operates).

Luckily, there are several ways to protect yourself not only from Rampell
and their customers but also from other mail tracking services:

  - Use a text-based e-mail reader, not an html mail reader, for most mail.
    Do you really need to see all the fonts and associated frills in most
    e-mail?  What kind of mail is most likely to be full of such stuff?
    Spam of course!  When you need to display image or document attachments
    they can still be processed externally.  Text-based e-mail systems also
    can provide essentially complete protection against all virus, worm, and
    related attacks that use e-mail as their vectors.  I use a text-based
    e-mail system for 99.9% of all my mail quite successfully.  And I get a
    lot of e-mail.

  - Turn off image display in your html mail reader.  E-mail tracking
    systems that claim to work regardless of where mail is sent typically
    depend upon the recipient retrieving images (often invisible images)
    from central servers.  One way to stop that process is of course to read
    your e-mail offline, though that isn't practical for most of us.  But
    various html mail reading systems allow you to turn off image display
    (and typically retrieval as well) for e-mail messages (you can turn it
    back on when you really need it for particular items).  If you don't
    retrieve the images or Web bugs, e-mail tracking systems that need them
    won't work.  And of course, you should never allow javascript in e-mail
    messages to be processed, nor allow attachments to be executed.

  - Server blocking.  System administrators and others may choose
    to determine (from viewing e-mail raw source data) the names and/or
    IP numbers related to the servers used by Rampell or others to
    serve the tracking images.  If these servers are blocked at firewalls
    or other filters the tracking systems will be rendered impotent.

Until legislation and the legal system recognize the risks in such e-mail
tracking and provide appropriate restrictions and remedies, you need to
protect yourself.

Lauren Weinstein lauren@pfir.org lauren@vortex.com lauren@privacyforum.org
1-818-225-2800 http://www.pfir.org/lauren
PFIR, Fact Squad - http://www.factsquad.org
Moderator, PRIVACY Forum - http://www.vortex.com


France Telecom voice mail espionage

<"David F. Gallagher" <http://lightningfield.com>>
Sun, 30 May 2004 13:15:21 -0700 (PDT)

France Telecom, by far the largest phone company in France, offers its
customers a free voice mail service called Top Message. Users of the service
can sign up to receive an e-mail letting them know when they have new voice
mail -- useful for people with dial-up Internet connections. You activate
this feature by sending an e-mail to a designated address with your phone
number in the subject line.

I've found that France Telecom makes no apparent effort to determine whether
a particular person has the right to be receiving these alerts, which
include the phone number of the caller and the time they called. I was able
to activate alerts for the phone in my apartment in Paris even though the
phone bills are in the name of a previous tenant. It also worked when I used
the phone number of some friends here who also use the voice mail
service. The online instructions for the service say you're supposed to
receive confirmation by voice mail and e-mail when the alert service is
activated. When I signed up I found that this was not the case -- the alerts
just started arriving.

There are no doubt thousands of jealous ex-lovers in France who would love
to know who has been leaving voice mail for the objects of their
obsession. Perhaps France Telecom should start charging stalkers for this
service? (Following through on the promise to notify users when the alerts
are turned on would provide a minimal level of protection against this
potential creepiness.)

Top Message online help (in French):
http://www.agence.francetelecom.com/vfrance/esav/fixe/pages/services/3103/etre_averti_du_depot.shtml#3

SPLIT:
  http://www.agence.francetelecom.com/
  vfrance/esav/fixe/pages/services/3103/etre_averti_du_depot.shtml#3


USB risks

<Gadi Evron <ge@linuxbox.org>>
Tue, 01 Jun 2004 17:24:30 +0200

I got the idea of writing about this from a recent pen-test mailing list
thread I replied to.

In that thread, someone asked about the risks of using USB. The guy
described how he plugged in a USB device and was surprised to see it
auto-run. He was particularly worried about the potential theft of
information that can be caused by the malicious usage of USB devices.

Indeed.

This has been covered and demonstrated on several occasions, on TV shows
(Threat Matrix), Sci-Fi TV shows (Jake 2.0) and in actual _real_ security
discussions. I believe this was brought up before in both Slashdot and
Full-Disclosure, but only with actual solutions. I haven't personally seen
anyone discuss the risks.

Disabling auto-run might not be the solution for USB (although that is
always a good idea when hardening a Windows system). USB auto-run installs a
driver for itself on plug-in. A driver which is essential for the device to
operate. Auto-run on CD drives for example is not necessary, one can always
access the CD and execute whatever program is there (or even the auto-run),
manually.

On USB, there are a few concerns when it comes to drivers. The driver
can be:
1. Messed with, i.e. made to do things it shouldn't (Reverse
    Engineering, manipulation).
2. Built from scratch with one of *many* SDK's out there.

USB brings the threat of any user, maid, cleaner or hostile "whoever" to
plug it in, covertly gather whatever information/perform whatever action
they wish, and leave. They might not even have to be covert about their
actions as USB devices are more than legitimate in many organizations
and aside to not being notices for using a USB device one could alter
the driver for any USB device they usually use.

This brings up the issue of what hardware should be allowed in an
organization and whether users can bring their home hardware to work, but
that is beyond the scope of this write-up.

USB technology is both fast and convenient. More and more computer services
and devices move to work over USB as a fast-growing trend. It has been this
way for several years, and the technology usage is still showing signs of
growth.

I feel threatened enough by the fact that such small devices with such a
huge data capacity exist and can be smuggled into a building in so many
ways, automatic operations done "on-plug-in" or "on-connect" are just a
plus. You don't really need many tools other than copy, but I suppose tools
can be created.

There are many ways in which the exploitation of this technology can
progress, from simply connecting a USB drive and copying information as I've
mentioned above, through PDA's which would allow you to chose what you want
to steal and map the network, all the way to wireless devices which can be
remotely controlled by a laptop or through, say, a cellular device, whether
temporary for the sake of one illegal operation, or permanently, providing
an hidden backdoor to a network.

Disabling USB all-together, virtually, by domain policy or removing the USB
devices themselves, maybe even just filling the plugs with silicon or glue
physically are some more drastic options which some organizations *might*
take, but I don't see it as a very viable option for most.

As always when it comes to security, it all depends on your risk analysis.
Cost vs. benefit. Is it worth it?

Do you have an opponent that could threaten you in this way? Do you have
anything to hide and how much do you care about hiding it?

There exist several tools to monitor a domain for when and if a USB device
is connected to any remote machine, and of what kind. A simple web search
should help you find some examples.

I suppose simple tools could be easily created, but as there are several
commercial options it might be worth a look.

The security risks of USB are more than this short email can convey, but I
think I gave you enough to get started and to think about. This issue is of
paramount importance and I don't see much *noise* about it.

Thoughts, anyone?

ge@linuxbox.org gadie@cbs.gov.il  +972-50-428610 (Cell).


Whom do I tell?

<Jerry James <james@eecs.ku.edu>>
Tue, 01 Jun 2004 15:08:15 -0500

I've had two telephone annoyances over the past year that are RISKS
related.

First, a major home improvement chain came to town about a year ago.  While
the store was still under construction, I started receiving telephone calls
at my home number, with the caller asking for this particular store.  Upon
questioning the callers, I found that someone in the construction trailer
was giving out my number.  I called up the construction trailer and had a
"Did, too!", "Did not!" type of conversation with the person who answered.
Even after construction finished, the calls continued.  Now the callers
claimed to be getting my telephone number from the store's web site.  I
confirmed this.  The telephone book shows that the first 5 digits of the
correct number are the same as mine.  The last two digits are completely
different.  This is not a case of transposition or accidentally repeated
digits.  Someone got the last 2 digits completely wrong.  This should be
easy to fix, right?  I sent e-mail to the webmaster.  No response.  I called
up the store.  "We don't manage the web site.  Our corporate office does
that."  Nobody knows how to fix the problem.  A year later, I am still
receiving calls for this store.  I have taken to telling callers that this
store is so badly managed that they can't even figure out how to fix a wrong
telephone number.  We'll see if that gets any action.

Second, something is amiss with my telephone company's software.  I have
two pieces of evidence to support this claim.

- Two or three times a week, when I dial a number I know is good, I get the
  message that I am calling a disconnected number.  When that happens, I
  just hang up, then hit redial, and the call usually goes right through.

- I get a lot more wrong numbers than I did at my last place of residence.
  When I ask the callers what number they were attempting to call, I get the
  usual transpositions and repeated digits, but I also get a fair number of
  answers that have no obvious connection with my telephone number.  I
  usually suggest to these callers that they try hitting redial, and I've
  never had any of them ring back.

(Oddly enough, I don't seem to be calling wrong numbers myself, unless that
is what is causing the "disconnected number" messages.  But then why am I
not hitting valid, but wrong, numbers as well?)

So I called the operator and told her about it.  She had absolutely no idea
what to do.  "Surely there is some way to report problems of this nature?" I
asked.  She didn't know.  She didn't even know who to ask.  The telephone
book yielded no clues.

In both cases I, a member of the public, knew about a problem, tried to
report it, and found that those responsible either have no problem reporting
mechanism in place, or have successfully hid its existence from their own
employees.

Jerry James http://people.eecs.ku.edu/~james/ james@eecs.ku.edu jamesj@acm.org


An anatomy of a PGP Joe Job

<Gadi Evron <ge@linuxbox.org>>
Sat, 29 May 2004 09:47:51 +0200

How my PGP signature ripped off, and for what purpose

On May first I e-mailed a couple of mailing lists, announcing a new spam
research related mailing list.

Due to knowing that many viruses and kiddies spoof my e-mail address on a
regular bases, I signed the post.

So far I received about one e-mail a day from people who Googled the PGP
signature that was in a SPAM they got (right through their filters).

That signature was my signature from the spam mailing list.

Irony? Attempted Pay-back? Oh well.

As the e-mails don't stop and as it happens with Joe Jobs, you must reply
and be nice while you do it.. I decided I'd put this in a short write-up
describing:
1. What happened (the story).
2. A few of my opinions on the subject.
3. A full analysis of the SPAM message. Quite interesting, although
    there is nothing completely new there.

PGP is used exactly for this purpose. Even if my signature was ripped,
it should be pretty obvious it wasn't made by me. Still, this is a risk
(which isn't completely new either

What _is_ new is the very targeted nature of this PGP Joe Job.

Here is the write-up that was supposed to be sent as e-mail. I figured that
with all the spam elements quoted in it though - it might get caught in
filters:
"An anatomy of a PGP Joe Job"
http://www.math.org.il/PGP-JoeJob.txt

ge@linuxbox.org  gadie@cbs.gov.il  +972-50-428610 (Cell).


Netgear/UWisc NTP mess

<Hal Murray <hmurray@suespammers.org>>
Mon, 10 May 2004 02:54:17 -0700

There is a category of bugs that can be summed up as (re)try too hard.

They are much more interesting when they involve positive feedback.  Suppose
some networking code works fine normally but an environmental problem causes
retransmissions.  If those retransmissions make the problem worse they will
cause more retransmissions which will...

Last summer, Netgear demonstrated a spectacular example of this type of bug.  I'm surprised it hasn't been covered here yet.

Dave Plonka has an excellent writeup at:
  http://www.cs.wisc.edu/~plonka/netgear-sntp/
He has links to several media web pages at the end.

Here is a highly abridged summary:

Netgear added an NTP client to some of their routers so log entries would
have the correct time.  They hardwired the IP address of the NTP server at
UWisc into their code.  They shipped many many thousands of those routers.
The total load was too much for the NTP server and/or network at UWisc so
packets started getting lost.  The code had a bug.  If it didn't get an
answer, it retransmited once per second.  (One request per hour would be
reasonable.)  The UWisc network collapsed on May 14th, 2003.  In early June,
they were discarding 250K packets/second, 150 megabits of NTP traffic!
That's an impressive load for such a simple protocol.

A similar bug in SMC routers knocked the NTP server at CSIRO (Australia) off
the net.
  http://mailman.anu.edu.au/pipermail/link/2003-April/049684.html

I know of a few other examples of try-too-hard bugs:

Consider a UDP request/response protocol running over a slow phone line.
Suppose that requests are tiny, the response takes a 1/2 second on the phone
line, and the retransmit timer is 1 second.  If there is no other traffic,
things work cleanly.  Suppose some other traffic causes an additional 1/2
second of delay.  The retransmit timer goes off and that puts a second copy
of the response in the queue.  The client will continue when it receives the
first (delayed) response.  If the client generates more work for the server,
that response will be delayed by the retransmission that is still in
progress.  A little more shared traffic can cause things to snowball.  Note
that once a few retransmissions are in the pipeline the system doesn't need
any more outside traffic to cause troubles.  It's own queued up
retransmissions will keep causing more retransmissions.

That's just a simple example of a retransmit/retry timer being set too
short.  Variations involve the server having to do a lot of work and not
being smart enough to cache the answer.

The next two examples don't involve any positive feedback.

Consider the typical client-server setup that uses several servers for
reliability.  What happens if a particular data pattern issued by a client
finds a software bug that crashes a server?  If the client retries again
using another server, that one will crash too.  If the client keeps retrying
it can kill all of the servers - embarrassing if you thought you were
building a reliable system.

When forwarding mail, some servers retry right-away on a temporary error.
That turns into a denial-of-service attack if the receiving server returns a
temporary error.  Anti-spam defenses sometimes return temporary errors
because that gives the operator of a mis-configured server a chance to fix
things without any bounced mail.

RISKs related issues:

* Why didn't Netgear learn from the SMC/CSIRO event?  Why didn't that event
get more publicity?  (I can't find any reference in RISKS.)

* If you are outsourcing work or hiring contractors/consultants, how can you
tell if they are good enough to avoid problems like this?  How would you
write a contract to avoid bugs like this?  Is requiring "good engineering
practices" good enough?

* Could you explain this issue to your management?  What would they do if
this bug was discovered when the product was about to ship?  How much would
it cost your company to recover from a bug like this?  (Looks to me like
Netgear got off lightly on the bad-PR area.)

* Should specifications mention this problem?  Or would that just be clutter
and distract from the main purpose of the spec?  Note that "specifications"
includes RFCs, product specifications, and contracts.  Does the answer
change if the protocol/product is widely deployed, or likely to be widely
deployed?

* How do you update implementations out in the field when problems like this
are discovered?  You can't even contact most of the owners because people
don't fill out product registration cards.  (Probably because they get too
much junk mail when they do.) In this case, the ISPs should know which of
their customers are using these routers.  Even if you could contact the
owners, would they bother to update their firmware?  They don't see the
symptoms of any problem.

* How can we uncover bugs like this?  The Netgear bug is somewhere between
very hard and impossible to find by traditional testing.  The lab gear
required is too extensive/expensive.  You could probably provoke it in a
lab, if you already knew about it so you could build an artificial
environment that would be more sensitive.  Would that type of testing be
cost effective?  (Or should that testing effort be devoted to other areas?)

* How can schools teach students about this type of problem?  Is repeating
this war story in a lecture good enough for somebody to get it?  Where
should this come on the priorities?  [I hope this event becomes required
reading for a CS degree, but I'm a network geek.]

* Hardwiring some parameters is asking for troubles.  How can we recognize
(and teach) which parameters are OK to hardwire and which ones require
configuration?  Is there a middle ground where a parameter has a sensible
default as long as configuration is possible?

* What responsibility do corporations have to the Internet community as a
whole?  How can we encourage them to do the right thing when it costs a
little more?  Corporations includes hardware manufacturers, software
vendors, ISPs/ASPs, web site operators...  (Maybe we should include home
users too, but I think it makes sense for their ISP to be responsible for
their actions.)  For example, why didn't somebody at Netgear do the
back-of-envelope calculations and figure out how many routers their
customers (ISPs) could install before they should install NTP servers too?

* ISPs should be running time servers for their customers rather than
freeloading off the net.

The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other
addresses.  These are my opinions, not necessarily my employer's.  I hate
spam.


Selling Web bugs

<Neil Youngman <n.youngman@ntlworld.com>>
Fri, 28 May 2004 20:27:33 +0100

The latest LWN security section (http://lwn.net/Articles/86022/) discusses a
service called DidTheyReadIt.com. In short, the service adds web bugs to
e-mail to try to determine whether the e-mail has been read.

(NOTE: that link is currently subscription only. It will probably become
freely available when the next edition is published on Thursday. Ed Felten
also comments at http://www.freedom-to-tinker.com/archives/000607.html)

To me the key excerpt is

"This, of course, has some not-so-pleasant implications for personal privacy.
While the company assures its potential customers that it respects their
privacy, nothing is said about the privacy of the recipient who may not wish
to divulge whether or not they've read a particular e-mail or where they've
read it from. On the company's About Us page, they identify what kinds of
people might want to find out whether an e-mail has been read -- including
some that make DidTheyReadIt sound like a must-have for potential stalkers:

Users of online dating services such as match.com who want to know if their
potential dates are reading their messages...or ignoring them."

The articles do a good job of identifying the RISKS.


Re: Spam being rapidly outpaced by 'spim' (RISKS-23.39)

<Gadi Evron <ge@linuxbox.org>>
Fri, 28 May 2004 00:30:07 +0200

"Spim" is nothing new, but it is indeed a growing concern.

In recent years we have seen more and more security issues that we've
encountered before repeat themselves on different mediums and
technologies. Spam is no different.

In this case, though, it is much simpler. As asked by many people in the
past: Would you stay with a service that you get 40 SMS spam messages
every day with?

No. You'd switch a provider.

I am much more concerned with other security issues regarding cell phones,
which are rapidly changing from privacy and eavesdropping concerns to Trojan
horses and buffer overflows. That is an issue to be discussed in a different
post, though.

As to spam, there is no danger of it disappearing. In fact MessageLabs came
out with some interesting statistics this week saying that 70% of all e-mail
is spam:
  http://news.bbc.co.uk/1/hi/technology/3746023.stm.

Please report problems with the web pages to the maintainer

Top