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 21 Issue 47

Wednesday 13 June 2001

Contents

Computer train trauma
Lord Wodehouse
Elevator emergency override drowns woman
Daniel Norton
ATM network center flooded
Daniel Norton
Supreme Court ruling on thermal-imaging scanners
PGN
And you thought Keith Lynch was kidding!
PGN
DoD declares unclassified hard drives no longer need be destroyed
PGN
Risks of URL-forwarding services
Justin Mason
New technology for sneaky advertising
Greg Searle
ScanMail's "sophisticated" filtering blocks PRIVACY Forum Digest
Lauren Weinstein
Risks of heuristics and marketers
Dan Birchall
Re: Dutch government to act against virtual child pornography
George Dinwiddie
Security notice for recent EarthBrowser purchasers
Matt Giger via Ben Laurie
Excel date munging: what a difference --four years and-- a day makes
Tom Walker
Dead men produce no documentation
Kirt Dankmyer
REVIEW: "Inside Internet Security", Jeff Crume
Rob Slade
Info on RISKS (comp.risks)

Computer train trauma

<Lord Wodehouse <w0400@ggr.co.uk>>
Tue, 12 Jun 2001 13:10:42 +0100

>From *Computer Weekly* 7 Jun 2001, on the back page.

... a tale of cutting edge IT going off the rails.

It reads, "I had an interesting journey home from London last night. I was
onboard a new 100% computer-controlled train. In the middle of the Chester
countryside, the train ground to a halt. The automated station-announcement
system then ran through its program of station announcements in quick
succession until it said the final destination."

"It then attempted to open the doors (in the middle of nowhere). The guard
ran to the driver's cab. The driver and the guard then ran through the
carriages muttering that the computer had gone berserk and was telling them
that the rear of the train was on fire. After checking, the driver, in a
state of mild panic ran back to the cab, turned off all the engines, cut off
all the power (leaving us in pitch darkness), and yes, you've guessed it,
waited the customary - 10 seconds and rebooted the train.

I wonder if anyone can confirm this wonderful story. The risks are
self-evident.

SCS Global Services Internet/Intranet Operations, GlaxoSmithKline,
Medicines Research Centre, Gunnels Wood Road, Stevenage SG1 2NY UK


Elevator emergency override drowns woman

<Daniel Norton <Daniel@DanielNorton.net>>
Sun, 10 Jun 2001 20:50:28 -0400

cf. http://www.chron.com/cs/CDA/story.hts/metropolitan/936841

Though not mentioned in this article from the *Houston Chronicle*, NPR
reported (via KUHF?) that the elevator detected an emergency situation
and automatically attempted to move to the ground floor.  While that's
often a good idea in case of a fire, in a flood it's the *worst* way to
respond and, in this case, tragically lethal.

  [I was in an elevator at BBN in Rosslyn VA once when the control computer
  crashed.  The elevator very slowly worked its way to the TOP floor, which
  might seem to make sense -- *except* in a fire.  Thus, we need an
  intelligent system that figures out which way to go, and therein lie even
  more risks -- especially in a fire that results from a short caused by a
  flood.  PGN]


ATM network center flooded

<Daniel Norton <Daniel@DanielNorton.net>>
Sun, 10 Jun 2001 20:59:46 -0400

The Pulse EFT network's main and backup power systems in Houston were
flooded by Tropical Storm Allison, disabling their 22-state ATM network.

  "PULSE Enacts Disaster Recovery Program
  Early Saturday morning, the PULSE electronic funds transfer system
  experienced a major disruption of both our primary power source and our
  emergency back-up supply system, as a result of unprecedented flooding in
  Houston. A disaster recovery program has been instituted and efforts are
  underway to resume operations at a remote processing center located in
  Dallas. Until technical connections in the system can be restored,
  disruption of ATM and point-of-sale services at some locations will be
  experienced.  PULSE has a proud record of 99.99% availability and we
  regret any inconvenience to our financial institutions, merchants,
  processors and cardholders that this extraordinary event may have caused.
  [...]  http://www.pulse-eft.com/


Supreme Court ruling on thermal-imaging scanners

<"Peter G. Neumann" <neumann@csl.sri.com>>
Tue, 12 Jun 2001 12:12:13 -0700 (PDT)

In the Kyllo case, the Supreme Court ruled 5 to 4 that using an Agema 210
thermal-imaging device to scan for unusual heat sources in someone's house
(i.e., searching for marijuana growing activities) is unlawful search if
carried out without a warrant, violating the Fourth Amendment.

  http://www.supremecourtus.gov/opinions/00slipopinion.html
  http://supct.law.cornell.edu/supct/html/99-8508.ZS.html
  http://www.wired.com/news/politics/0,1283,44444,00.html


And you thought Keith Lynch was kidding! (Re: RISKS-21.42)

<"Peter G. Neumann" <neumann@csl.sri.com>>
Mon, 12 Jun 2001 12:17:11 -0700 (PDT)

  http://www.utm.edu/research/primes/curios/48565...29443.html

One of the strangest consequences of the DMCA is that it would seem to
outlaw possession of certain integers.  The above URL gives the decimal form
of a prime number whose HEX form just happens to be the gzip-ed C source
code for DeCSS (which breaks the DVD Movie encryption -- see RISKS-21.37).
This observation is due to Phil Carmody.

  [Thanks to Mark Brader for the Subject: line!]


DoD declares unclassified hard drives no longer need be destroyed

<"Peter G. Neumann" <neumann@csl.sri.com>>
Sat, 9 Jun 2001 23:17:52 -0700 (PDT)

  http://www.cnn.com/2001/TECH/ptech/06/08/pentagon.computers.ap/index.html

The aggregation, inference, and sensitive-unclassified stuff is ubiquitous
and often damning.  This could be a harbinger of future RISKS stories.


Risks of URL-forwarding services

<jm-risks@jmason.org (Justin Mason)>
Thu, 07 Jun 2001 12:44:09 +0100

I'm the maintainer of a free-software application called sitescooper, which
reformats Web sites for viewing on PDAs.  When I started writing sitescooper
a few years ago, I hosted it on my ISP at
  http://www.clubi.ie/~jmason/software/sitescooper/ .

Since this URL was quite cumbersome (especially when read on a PDA screen!)
I also set up a forwarding URL with a domain called "tsx.org", which offered
free URL forwarding.  At that stage, tsx.org was a reasonably reputable
URL-forwarding service.

Since then, sitescooper has grown in popularity, and has moved to the
easier-to-remember sitescooper.org domain.  I left the tsx.org forwarding in
place, updated to its new address, to catch old links and avoid link-rot,
and forgot about it.

This morning I received a mail from a potential user, who'd decided to
download sitescooper and take a look. The mail stated:

    I'm writing about your Web site.  [...]

    If you are aware of the way your site behaves then you should just
    close up shop and leave the Web because no contribution to software
    development is worth the hassle your site causes.

    If not, then I apologize for the above and I'll describe it for you.

    If your site:  sitescooper.tsx.org  is opened using a script-enabled
    browser (e.g., IE or NS), from a windows platform,  it proceeds to
    plaster the screen with windows full of trashy ads that CANNOT be
    deleted.  The windows have no controls and right-clicking the taskbar
    icons is disabled.  THE ONLY WAY to delete this trash is to bring up
    the Task Manager via ctrl-alt-del, and kill the processes.  NO WEBSITE
    SHOULD BE THIS INVASIVE.

    This is blatant abuse of the trust a user puts in you when they click
    a link to your site.  Hopefully, you're not involved in it and it's
    being done by tsx - In which case I STRONGLY advise you to dump them
    as fast as possible and find a new Web host.

I surfed over to sitescooper.tsx.org and took a look.  Sure enough, it
popped up 5 windows - 1 with no frame masquerading as a Windows alert,
asking if I want to visit the BEST ADULT SITES AROUND, 2 full-screen
unclosable windows, 1 normal(ish) ad window with a normal window frame, and
(finally) the page I *wanted* to go to.

Gah.  Needless to say, sitescooper.tsx.org is now no more.  I'd prefer if
people hit a 404, and were forced to search Google, than run into this.

The risk?  There ain't no such thing as a free lunch, I guess.  I'd assumed
that the forwarding system would offer a consistent quality of service over
several years; instead, in my opinion, they took advantage of their
situation to increase their ad revenues at the expense of their users.


New technology for sneaky advertising

<"Greg Searle" <gsearle@s1.com>>
Thu, 7 Jun 2001 14:42:57 -0400

First came SPAM, with its authors finding more and more sophisticated
methods of hiding themselves from their victims so they could send out
massive amounts of advertising without fear of retribution.  Then came
pop-up window ads.  These are bad enough, but now a company,
www.fastclick.com, has come up with a way to sneak these pop-up windows onto
your screen without you knowing where they came from.  Worse, established
corporations such as The NY Times (www.nytimes.com), AltaVista
(www.altavista.com), and Epinions (www.epinions.com) are using the
technology.

The trick involves a timer, a cookie, and a pop-up window that quickly hides
itself *behind* your browser windows.  This usually happens too fast for
your computer to render the window on your display, so you see nothing.  You
don't know when the ad will appear, and you won't see it until you close all
of your browser windows.  By then, you have opened a few more windows and
browsed to other Web sites.  This keeps you from knowing which Web site
spawned the window in the first place.  I only know about the above three
corporations because I was lucky enough to catch the window popping up when
I first opened my browser to these sites, or because it was the only site I
went to.  I caught a glimpse of "fastclick.net" in the status bar, and it
all fell into place.

The only solution is to turn JavaScript off completely.  If you don't want
to do this, then add the offending sites to your "Restricted Sites" list.  I
have sent a complaint to these corporations as well, letting them know that
I don't appreciate this "sneaky" advertising, and have disabled these ads.


ScanMail's "sophisticated" filtering blocks PRIVACY Forum Digest

<Lauren Weinstein <lauren@vortex.com>>
Sun, 10 Jun 2001 09:46:49 -0700 (PDT)

Greetings.  The manufacturers of e-mail filtering and blocking systems
continue to claim that their products have vastly improved over time --that
the incidents of false negatives and false positives are greatly reduced
from earlier versions.  Much empirical evidence has continued in general to
contradict these assertions, and here's yet another example of what happens
in the real world as these systems are actually configured by users.

My most recent PRIVACY Forum Digest was blocked by the popular "ScanMail"
product as configured within at least one site.  I only learned about this
since the particular configuration was in a "quarantine for review" mode
that sent out a warning.  Other sites may be configured to simply delete
flagged messages without such a reply to the sender.

What was it about the PRIVACY Forum Digest that aroused ScanMail's ire?  In
the nine years since I originated the Digest, each issue has included a
"quote of the day"--which usually is an interesting or amusing quote from a
feature film.  In the case of the most recent Digest
(http://www.vortex.com/privacy/priv.10.04) I chose a quote from Peter
Sellers' 1968 classic "I Love You, Alice B. Toklas!"

Ah hah!  The phrase "I Love You" appeared in the text of the message.  It
must be a virus!  Or perhaps a spam?  Indeed, the Digest was blocked via
ScanMail's "ILOVEYOU" policy!  This was done even though the message was not
encoded in any way and was not an attachment.  It was just simple, plain,
ordinary, ASCII text, with the "offending" phrase well down within the
message (not in the header).

Presumably, ScanMail at various sites will be blocking *this* issue of RISKS
because (horrors!) the forbidden phrase "I Love You" appears in this message
as well!

With such a level of "stone club" analysis at work, one can only imagine what
other innocent e-mail is being injected, inspected, detected, infected,
neglected, and selected by the "sophisticated" algorithms of filtering
programs to be flagged, reviewed, dropped, banned, burned, or trashed.

Lauren Weinstein <lauren@pfir.org> lauren@vortex.com lauren@privacyforum.org
Co-Founder, PFIR: People For Internet Responsibility - http://www.pfir.org
Moderator, PRIVACY Forum - http://www.vortex.com


Risks of heuristics and marketers

<Dan Birchall <djb@scream.org>>
Wed, 6 Jun 2001 18:04:36 -1000

For some years, I have been concurrently involved in countering spam and in
designing, implementing and administering e-mail lists for marketing
purposes.  In both of these endeavors, as in much of life, heuristic
(trial-and-error) methods are commonplace.

Heuristic approaches to the development of spam filters tend to be somewhat
effective.  If one receives 100 pieces of spam over a reasonable period of
time containing a given word or phrase, and no legitimate mail containing
it, it is statistically probable that filtering mail based on that word or
phrase will block at least some spam, and little or no legitimate mail,
going forward.

Of course, such simple heuristics are not without their risks.  We recently
sent an issue of our periodic customer newsletter which contained the phrase
"sizzling summer."  The marketers love their alliteration -- in fact, the
exact same phrase appeared a few days earlier in a mailing by another
company in our market segment!

Unfortunately, a small number of sites using simple heuristic filtering like
that I described above took offense at our use of the word "sizzling," which
apparently now indicates pornographic material.

A better method might combine heuristics with the scoring capability in some
mail server software (I'm personally familiar with Exim), incrementing or
decrementing a counter based on the occurrence of given words or phrases,
with actions depending on the final value of the counter.  Thus, if
"sizzling" is a +1 word, "video" a +2 word, and "sex" a +3 word, a threshold
of 3, 4 or 5 might be used for blocking.

Dan Birchall - Palolo Valley - Honolulu HI - http://dan.scream.org/
Peruse my opinions, at http://dbirchall.epinions.com/user-dbirchall

  [Still too many false positives and false negatives.  PGN]


Re: Dutch government and virtual child pornography (de Geus, R-21.45)

<"Dinwiddie, George" <George.Dinwiddie@arbitron.com>>
Thu, 7 Jun 2001 10:20:31 -0400

How do you ascertain the age of a virtual individual in an electronically
synthesized image?  In the real world, you can ask for some identification.
My sister was frequently carded in bars (when the legal drinking age was 18)
until she was 26, because she looked young.  My son told me a story of not
being carded at 16 when the guy in front of him was carded at 20 (when the
legal drinking age was 21).  Obviously you cannot reliably determine age by
appearances.  Perhaps you could look at the creation date of the file? ;-)

  [That's not very reliable either.  PGN]


Security notice for recent EarthBrowser purchasers (via Ben Laurie)

<Matt Giger <mgiger@lunarsoft.com>>
Wed, 6 Jun 2001 21:49:05 -0700

My name is Matt Giger and I write the EarthBrowser software that you have
recently purchased us.  I am writing to inform you of about a recent scam
being run on our customers.  This first report was about 5 PM on 6/6/01 from
a customer who purchased EarthBrowser just yesterday.

Apparently some files with customer information on our server have been
accessed.  Let me assure you that your credit card information is safe since
we never store that information on our server.  Also we purge all customer
information on a daily basis so the amount of information they obtained was
minimal, just your name, address, e-mail address and EarthBrowser serial
number.

The reported scam e-mail looks something like this:

  Please confirm [its] registration.  Correct Purchase Information You
  account: http://www.earthbrowser.by.ru/3004001065-010605214102678/index.htm

This poorly written e-mail sends you to a Web site in Russia which is an
exact copy of our purchase page and presumably sends the information you
enter to the thief.  If you enter your credit card number on this page, they
will then have it so please do not enter any information.  Hopefully the
poorly worded e-mail and the suspicious Web address will alert most to the
fact that this is bogus.

If you have received an e-mail like this one, please let me know as soon as
possible so I can trace exactly how long ago they gained access.

I apologize for having to warn you of this, I am taking steps to insure that
our customer information remains safe.  I promise to let you know of any
such scams in the future, but please help me out by letting me know if you
get any strange contact trying to use our relationship with you to obtain
any information.

Matt Giger, Lunar Software, Inc. mgiger@lunarsoft.com


Excel date munging: what a difference --four years and-- a day makes

<timework@vcn.bc.ca (Tom Walker)>
Sun, 10 Jun 2001 07:33:20 -0700 (PDT)

A couple of months ago I was replying to a expert-witness report in an
arbitration and found that his years of service calculations were wrong by
four years. Then last week I received an excel file from the other side's
lawyers in the case and noticed that when I cut and paste a column of dates
they all automatically went back four years and a day. The problem arises
from incompatibility between the 1904 date system used by excel in mac and
the 1900 date system used in windows. This is a known and documented feature
of excel:

  http://support.microsoft.com/support/kb/articles/q180/1/62.asp

However, a quick search on the Web and in the Risks Forum archives suggests
the risk isn't that widely appreciated. Even if one knows about the anomaly
and checks for date system compatibility before cutting and pasting dates,
one still could receive files from a source that already had corrupted
dates. There would be no way of knowing (other than common sense if the
results are not credible).

It seems to me that the errors introduced into spreadsheet calculations will
tend to be systematic rather than random because: 1. they will often occur
when two or more sets of data are being consolidated and thus the errors
will apply to the population of one set but not to the other and 2. the
direction of the error will be influenced by the prevalence of macs or pcs
in different institutional settings and fields, e.g., macs in universities &
design and pcs in businesses & finance. Thus, for example, dates
systematically advance from businesses to universities and recede from
design to finance. This makes collaborative work between institutions and
professions especially vulnerable.

The first time (that I know of) that I encountered the problem was a
practical instance with a potentially significant economic impact on several
thousand employees. The fact that the data was presented in the course of an
adversarial process was probably crucial to the error having been detected.
I am wondering why there aren't more reports out there of encounters with
this problem. Is this bug flying under the radar?

Tom Walker, Bowen Island, BC  1-604-947-2213


Dead men produce no documentation

<"Dankmyer, Kirt" <Kirt.Dankmyer@csoconline.com>>
Fri, 8 Jun 2001 14:59:11 -0500

I was recently assigned to take over a system that processes and sends data
to a wide variety of scientific agencies that depend on said data. In
particular, I've been asked to understand the system well enough to maintain
and troubleshoot it.

Naturally, the system, both software and hardware, was created "in-house" by
contractors. Nothing like anything I'd experienced before. When I requested
documentation, I was told there was none. The last person who had to work on
the system had produced a draft of user documentation, but it was
incomplete.

So, I contacted the poor soul who had worked on this system before me, the
one who had produced the incomplete documentation. (We'll call her Joan.)
Joan was only familiar with the part of the system she had worked on (the
user interface, really). So I asked her about the two people who had
designed and implemented the system in the first place. I thought that they
could perhaps help me with some of the questions I had.

One of them had left the company that originally employed her, and wouldn't
return phone calls. So I asked Joan about the other designer, who seemed to
have done the bulk of the work anyway.

"He's dead," Joan told me. "Heart attack."

The risk? If you skimp on documentation while designing a custom system, you
may find that you don't have time to go back and do it later, with serious
consequences for those who follow you. This problem should be familiar to
most readers of RISKS, but it bears repeating. As I write this, a problem
has come up with the system and no one is even sure if it is hardware or
software. When dealing with such a system, you cannot guarantee you will be
able to talk to the original designer (and the only one who understands the
system fully), and it might be because they've left more than just the
company that originally produced the equipment. Sic transit gloria mundi...

Kirt Dankmyer -- 757-824-2283 -- kirt.dankmyer@csoconline.com
CSOC UNIX System Administrator -- Wallops Flight Facility

  [Of course, Wallops Island is where a lightning strike hit the missile
  launch platform when a missile was waiting to be launched to test the
  effects of lightning -- and resulted in the missile accidentally being
  launched.  PGN]


REVIEW: "Inside Internet Security", Jeff Crume

<Rob Slade <rslade@sprint.ca>>
Mon, 11 Jun 2001 18:21:13 -0800

BKININSC.RVW   20010511

"Inside Internet Security", Jeff Crume, 2000, 0-201-67516-1, U$29.95
%A   Jeff Crume crume@us.ibm.com
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D   2000
%G   0-201-67516-1
%I   Addison-Wesley Publishing Co.
%O   U$29.95 416-447-5101 fax: 416-443-0948 bkexpress@aw.com
%P   270 p.
%T   "Inside Internet Security: What Hackers Don't Want You to Know"

Recently I started teaching a new class.  During the introductions, one
student admitted that he wanted to learn how to break into systems since
that would teach him how to protect them, right?  In the first place, I
don't believe him.  In the second, his thesis is seriously flawed.  Yet that
is the type of argument Crume seems to be making in the introduction to this
book: learning how to hack will teach you how to protect yourself.  It
doesn't work that way.  Knowing how to exploit a buffer overflow in
Microsoft's Internet Information Server doesn't teach you anything about the
type of systems development practices that will keep you from leaving buffer
overflow loopholes in your own programs.

Crume does, however, present some good, if basic, security advice.  After a
bit of a rocky start.

Chapter one says that there are weaknesses in the net.  Big surprise.
Chapter two says that the Net is possibly dangerous.  About the only
reliable information you'll get out of chapter three is that hackers differ.

By chapter four, though, the book has settled down.  Here we get a decent
introduction to risk analysis, stressing that some risks are not worth
protecting against.  There is some solid advice about security policies in
chapter five, most notably, have one.

Chapter seven lists some good general points to keep in mind, which then
become the titles of the remaining chapters.  There is a clear, if not
terribly detailed, explanation of what firewalls are and do, in chapter
eight.  We are warned to be wary of insiders in chapter nine, which also
points out that not all "insiders" are actually inside.  Chapter ten
outlines some of the aspects of social engineering.  A detailed discussion
of passwords, in chapter eleven, even covers tokens and biometrics.  Network
and packet sniffing is explained in chapter twelve.  Chapter thirteen is
weak.  Ironically, it is the first chapter to touch closely on the items
Crume implied in the introduction, and looks at software vulnerabilities.
But these loopholes are very difficult to deal with, and the material here
isn't much help.  Chapter fourteen is helpful in pointing out that factory
set defaults can be dangerous.  The title of chapter fifteen ("it takes a
thief to catch a thief") seems to be suggesting that you hire hackers.
Actually, it merely suggests that you learn the vulnerabilities that they
know.  However, it isn't very useful in pointing the reader in the right
direction.  Chapter sixteen offers a grab bag of anecdotal reports of
recently exploited vulnerabilities.

And, of course, I have to pay special attention to chapter seventeen,
on viruses.  Well, Crume makes mistakes, but he doesn't make any
really important ones.  The background is reasonable, and the advice
is sound.

Chapter nineteen provides a good overview of cryptology, but some of the
more important points get buried in the stories.  (There is more material
provided in appendix A.)  Backdoors and end runs are discussed in chapter
twenty.  Chapter twenty one points out that even "harmless" defacement of a
Web site can have serious consequences, while twenty two says the information
is valuable and a good defence.  Chapter twenty three finishes off with a
look at some emerging technologies that are bringing forward new security
concerns.

One note that I should make: the text doesn't have all that much to say
about the Internet, as such.  Most of the points deal with security on a
general basis.  Which doesn't necessarily make it any less useful.

This book can be read completely in a day.  And, for most managers and
business people it would be a day very well spent.  While some chapters are
weak, roughly three quarters of the material is both reasonable and
technically sound, a match that happens less often than one might wish.
This is definitely a volume to get to pass around among all employees--and
to provide to all newly hired managers.

copyright Robert M. Slade, 2001   BKININSC.RVW   20010511
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Please report problems with the web pages to the maintainer

Top