The RISKS Digest
Volume 21 Issue 25

Wednesday, 21st February 2001

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…

Contents

Millennium bug in travel agent system
Debora Weber-Wulff
Again: German government plans extensive surveillance
Stefan Kelm
Are free ISPs free? Juno says users must donate processor time
Lenny Foner
The old ones are the best ones: Hidden info in MS Word documents
Paul Henry
Modem misdialing seemingly at random
Chiaki Ishikawa
On paper-size standards
Andrew Klossner
More on the Friendly Skies of United
Steve Bellovin
Re: Risks inside my Jan 2001 American Express Bill
Paul Green
Re: SiteGuest unauthorized address capture
Jean-Jacques Quisquater
Re: Organiser Bugs
Dennis Parslow
Peter B. Ladkin
Re: It's the wolf! It's the wolf!
Martin Jost
Andrew Jackson
When will they EVER learn?
Geoff Kuenning
REVIEW: "Building Internet Firewalls", Zwicky/Cooper
Rob Slade
Info on RISKS (comp.risks)

Millennium Bug in Travel Agent System

<Debora Weber-Wulff <weberwu@tfh-berlin.de>>
Wed, 21 Feb 2001 08:18:04 +0100

A friend with a travel agency sent me an article about the German Travel
Reservation System Merlin.  It seems that all the reservations made through
the system were not credited to the January 2001 account, but to the January
2000 account.  The problem was that Merlin was sending data to a back office
system from Bewotec. Merlin, however, had not managed to change the year
from 00 to 01.  A speaker remarked: We didn't know that someone else was
using the data too [for statistical purposes], but it is not a real problem,
as no other cooperating systems have reported problems [!!!] "Only" 200
travel agencies are affected, the ones that use Bewotecs Jack and Merlin
from DCS.

Gee, that makes me feel better, then, if no one else has complained ...

Prof.Dr. Debora Weber-Wulff, Techn. Fachhochschule Berlin, Luxemburger Str. 10
13353 Berlin, Germany weberwu@tfh-berlin.de  http://www.tfh-berlin.de/~weberwu/


Again: German government plans extensive surveillance

<"Stefan Kelm" <kelm@secorvo.de>>
Wed, 21 Feb 2001 09:47:49 +0100

Once again, plans by the German government to force ISPs to install
surveillance interfaces for LEA access became known earlier this week. This
is the third draft already, and a few things have changed.

Interestingly, the government itself (i.e., the Federal Ministry of
Economics and Technology) has published the new drafts, which up to now are
only available in German:

  http://www.bmwi.de/Homepage/Politikfelder/Telekommunikation
  %20%26%20Post/Telekommunikationspolitik/Sicherheit.jsp#TKÜV
  [broken URL, and may not work anyway...  PGN]

Stefan Kelm, Secorvo Security Consulting GmbH, Albert-Nestler-Strasse 9,
D-76131 Karlsruhe  +49 721 6105-461  kelm@secorvo.de, http://www.secorvo.de


Are free ISPs free? Juno says users must donate processor time

<Lenny Foner <foner@media.mit.edu>>
Fri, 2 Feb 2001 12:01:36 -0500 (EST)

See section 2.5 of http://help.juno.com/privacy/agreement.html

There are obvious privacy implications of being "volunteered" in this manner
(hey, whaddya want for nothin'?).  There are also obvious security
implications, since Juno says absolutely nothing about what this distributed
computation might be.  ("Hi, we're Microsoft and we'd like to run a
distributed computation that looks for duplicate copies of serial numbers in
our products, and your user agreement says that we can format the disks of
any machines that might possibly be infringing.  Actually, we'd also like to
format any disks that seem to have non-Microsoft operating systems
installed.")

I'm also rather intrigued by their "we will run screensavers with ads and
you're not allowed to turn off your machine."  Seems to me that this will
cost users -lots- of extra electricity if they're used to a screen saver
that blanks the monitor and puts it in a low-power mode---and obviously the
-computation- doesn't require the -screen- to be displaying anything; that's
only the advertising function...  And I'll bet there's some reasonable
subset of users who don't know that they can turn off just the monitor, or
don't realize that they're saving power when their screen blanks...  With a
"free" base of 14.5 million subscribers, and 100W/monitor (probably an
underestimate), this is an entire nuke plant of extra load just to keep
those monitors from screensaving.  I'll bet that's just -exactly- what
California wants to be happening right now...

- - - Begin forwarded message - - -

Date: Fri, 02 Feb 2001 10:17:25 -0500
>From: Declan McCullagh <declan@well.com>
Subject: FC: Are free ISPs free? Juno says users must donate processor time

[As one science fiction writer would say, TANSTAAFL. This is merely the
natural evolution of the market for "free" services, and is hardly
objectionable. True, it raises some privacy and security questions, but
nobody's forcing you to use Juno, and pay ISPs are hardly expensive. --Declan]

http://www.cluebot.com/article.pl?sid=01/02/01/2249220&mode=thread

    How Free Are Free ISPs?
    posted by vergil on Thursday February 01, @05:06PM
    from the check-that-clickwrap dept.

    Free ISPs have been especially hard hit by the current dot-com
    downturn. Juno Online Services (recently smacked by a Temporary
    Restraining Order involving a patent infringement scuffle with rival
    NetZero) has developed a novel way of extracting megahertz — and
    potential megabucks — from its subscriber base. According to a
    2/1/2001 InternetNews article, Juno's "Virtual Supercomputer Network"
    aims to replicate the success of SETI@home by pooling the processing
    potential of its new subscribers and selling the combined
    computational power. According to Juno's new service agreement, Juno's
    subscribers "agree" to let Juno download, upload and run software from
    their PCs, and may be required "to leave" their computers "on at all
    times."  [...]

[Lenny later added the following note.  PGN]

Actually, given that it -could- be the case that such a distributed
computation might be set to initialize every machine at a particular time,
I can just see it now when all those zillions of monitors come out of
screen-save simultaneously:

    "California power grid destabilized by Juno, news at 11..."

(Even an earthquake doesn't move mice all over the state...)


The old ones are the best ones: Hidden info in MS Word documents

<"Paul Henry" <emmo@hotmail.com>>
Fri, 16 Feb 2001 16:03:49 -0000

OK, this is an old one (dating back to 1994 according to the RISKS archive),
but it was new to me when I came across it recently, and thought people
might be interested in a couple of real life scenarios:

I received an MS Word document from a software start-up regarding one of
their clients. Throughout the document the client was referred to as "X", so
as not to disclose the name. However I do not own a copy of Word, and was
reading it using Notepad of all things, and discovered at the end the name
of the directory in which the document was stored — and also the real name
of the client!

I checked on a number of other word documents I had for hidden info,
especially ones from Agencies who are looking to fill positions — and yes,
again I was able to tell who the client was from the hidden information in
the documents.

Finally, I had a look at the Lockerbie Judgment document:

http://www.scotcourts.gov.uk/html/lockerbie.htm

Hoping to find something that would cause international uproar — alas, no,
just an ironic hidden message: "Are you surprised?".  Yes, I was, actually
-- I thought Ahmed Jibril did it.

Risks: What potentially damaging information is hidden in published
documents in Word, PDF and other complex formats?

Mitigation: Use RTF when you can — no hidden info, no viruses.

Paul Henry, emmo@hotmail.com


Modem misdialing seemingly at random

<Chiaki Ishikawa <Chiaki.Ishikawa@personal-media.co.jp>>
Tue, 6 Feb 2001 20:28:13 +0900 (JST)

Modem misdialing seemingly at random

RISKS has seen its share of mis-configured modem setup forced PCs calling
somebody's house (in some cases police station?) unintentionally at random.

Here is a new twist from Japan.

Modem chips used in about 6 million PC units of 24 million PCs shipped in
Japan after the summer of 1998 has shown a peculiar problem.

When the modem is asked to dial telephone line using so called "Pulse Dial"
mode, it fails to properly dial the requested number, and instead calls
wrong number (!)  seeming at random under high load of the OS (Windows 98),

Pulse dialing (as opposed to tone dialing) is used in many Japanese
telephone subscriber lines.  How many users of the affected 6 million units
use pulse dialing is anyone's guess: one educated guess puts the number at
about 2 million users.  This high concentration of the pulse dial telephone
subscriber lines in Japan has caused quite a problem with the modem.

I noticed that a large Japanse ISP, @nifty, (URL: www.nifty.com) has been
warning the user for quite some time by sending periodic warning and
mentioning various manufacturers comments, whose PCs may or may not dial
incorrectly sometimes.  This happened since early last summer if I recall
correctly.

*Mainichi Shimbun* newspaper Web site lately announced the problem in its
IT-related Web page and it mentions the following PC manufacturers whose
products are affected: Fujitsu, NEC, Toshiba, Sony, Japan IBM, Hitachi, and
Epson.

	http://www.mainichi.co.jp/digital/index.html (in Japanese)

Gateway Japan was quoted as investigating the situation, and it seems that
Apple didn't answer the inquiry from the newspaper yet.

The problematic symptoms occur under windows 98.  It seems that the modem
tries to use the software timing to produce proper number of pulses per
seconds to generate correct dialing signals.  However, obviously, Windows 98
can't let the software driver have enough CPU time under high load, and the
software timing becomes bogus, thus the wrong dial number.

Some people have receive these bogus calls many times and it seems that
their tenacity uncovered the problem.

The modem chip in question is build by Conexant.  Their Web site mentions
that the drivers ought to be provided by their OEM customers, which makes
sense.  (Warning: before trying to access Conexant Web site, you might want
to check out your browser's cookie setting.  The Web site tries to set many
cookies as if there would be no tomorrow.  I had enabled "Warning before
accepting cookies", and I had to kill my browser! I had to disable the
warning to access the URL. My browser is Netscape. YMMV. )

Affected PC manufacturers have begun offering modified drivers that add
"dial number verification step"(?) according to Mainichi Web page.  (From
what I gathered by reading an attached file from IBM Web site, the driver
checks the system load before dialing and if it expects that the load is too
high to perform pulse dialing reliably, it aborts the dialing and hangs up.
Various PC vendor sites mention that the cause of the high load is
mentioned: CD drive, FDD, HDD, etc..)

Although the mis-dialing is reported to occur very rarely per modem, the
problem seems grave enough and the affected PC vendors and one industry
association obviously sends a joint press release to let the users become
aware of the new modified drivers.  If you have 2 million users trying to
dial the access points of the ISPs, my guess is that the incorrectly dialed
numbers tend to fall in a select few ranges and thus irate complaints.

Tone dialing users are not affected at all.

(I wonder if the same problem may be observed elsewhere where pulse dialing
is used by a large user base and the same Conexant chips are widely
used. The Mainich page left the impression that pulse dialing is not used
widely anymore.)

Chiaki Ishikawa Personal Media Corp. Shinagawa, Tokyo, Japan 142-0051
ishikawa@personal-media.co.jp.NoSpam


On paper-size standards (Re: Kuhn, RISKS-21.21)

<Andrew Klossner <andrew@user2.teleport.com>>
Fri, 26 Jan 2001 10:58:37 -0800

Markus Kuhn, in writing about ISO standards for numbering weeks, also makes
mention of a reference to ISO paper sizes, which includes this statement:

  "Conversion to A4 as the common business letter and document
  format in North America would not cause any significant cost."

This pronouncement considers only the cost of computing equipment such as
printers.  It ignores the substantial amount of non-computer infrastructure.
As one example, my neighborhood elementary school has hundreds of three-ring
binders and clipboards as well as non-metric paper trimmers, book binders,
hole punchers, and ancient duplicating equipment.  Anyone familiar with the
state of U.S. public education understands that money to convert all this to
metric paper sizes will not be available in the foreseeable future.

The RISK here concerns enthusiasm for elegant technical solutions which
overlook the cost of abandoning current practice.

Other disparaging remarks, such as the "bizarre" way that we norteamericanos
measure paper density, would perhaps be more compelling if they did not come
from an island where everyone drives on the wrong side of the road.

Andrew Klossner (andrew@teleport.com)


More on the Friendly Skies of United (RISKS-21.24)

<Steve Bellovin <smb@research.att.com>>
Mon, 19 Feb 2001 22:38:23 -0500

I just saw an update on CNN that says United Airlines has decided to honor
the tickets [purchased on their Web site, e.g., for less than $30 — instead
of $300...  PGN].

Steve Bellovin, http://www.research.att.com/~smb


Re: Risks inside my Jan 2001 American Express Bill

<Paul Green <Paul.Green@stratus.com>>
Tue, 20 Feb 2001 10:00:33 -0500

I can provide the likely answer to Thomas Maufer's question as to how the
dates became corrupted on his American Express bill. First, I have no
connection with American Express (other than as a long-time holder of
several of their cards), so this is an educated guess. But I have been the
Y2K coordinator for one of the Stratus Computer operating systems. We warned
our customers in December 1999 that if they continued to use 2-digit years
after January 1st, 2001, they might into the precise interpretation problem
described in Thomas's letter. The details are specified at
ftp://ftp.stratus.com/pub/vos/doc/y2k/sray2k21.htm. I have no idea whether
this error arose on one of our products, or on a different vendor's product.

When a date in the format MM DD YY is converted using a rule in the format
YY MM DD you will get exactly the conversion noted in this report.

01-02-01 is interpreted as 2001-Feb-01 rather than Jan-02-2001.
01-04-01 is interpreted as 2001-Apr-01 rather than Jan-04-2001.
and so on.

Things will get interesting after January 12th; I wonder what Thomas's bill
looks like for items charged on the 13th and beyond?  Who would have thought
that computers would be susceptible to triskaidekaphobia!

Paul Green, Stratus Computer, 111 Powdermill Road, Maynard, MA 01754-3409
Senior Technical Consultant  TEL +1 (978) 461-7557  FAX +1 (978) 461-3610


Re: SiteGuest unauthorized address capture (Russell, RISKS-21.24)

<Quisquater <jjq@dice.ucl.ac.be>>
Fri, 16 Feb 2001 10:56:27 +0100

http://www.privacyfoundation.org/advisories/advEmailWiretap.html
gives an exploit that allows the spying ("wiretap") of written messages and
used addresses when forwarding privately a received message with embedded
code ...

Jean-Jacques Quisquater


Re: Organiser Bugs (Ladkin, RISKS-21.21)

<"Parslow, Dennis" <Dennis.Parslow@FMR.COM>>
Wed, 21 Feb 2001 06:46:49 -0500

Peter Ladkin points out the difficulty in discovering and recovering from
slow corruption of data.  In fact, in some sense, the most dangerous
computer viruses are the ones (thankfully relatively few) that simply flip
characters, slowly and at random.  One of the first of these did so in Excel
Spreadsheets...where two characters being flipped can clearly have a huge
impact further along in calculations.

This also calls into light the backup strategies being used.  Many keep
their regular backups for approximately a month, and may or may not keep a
full backup for longer.  But if the problem was two months ago, give or
take, many places that even do keep monthly backups may not have the
information available to them from the incrementals in between, and a lot
changes in a month.  But management of more tapes may not be practicable in
a large environment either...


Organiser Failures (RISKS-21.18,19,21.23)

<"Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>>
Wed, 31 Jan 2001 08:26:21 +0100

Unfortunately, it seems as if the good points about backup housekeeping made
by Tyler Rosolowski and Mike Cepek (RISKS-21.23) miss the main point that I
tried to convey.

My experience showed that devices can fail "live", with what I called a
disgraceful degradation. I have no evidence of any misbehavior from the
backup software (although this is not ruled out). The measures suggested by
Rosolowski and Cepek are appropriate as protection against one-time
catastrophic events. It is unclear to me how they would protect against my
type of failure.

Although Rosolowski's point about making regular comparisons between new
data and old data is well taken, he doesn't suggest any time interval at
which the differences might have overcome my perceptual threshold for
noticing problems. Indeed, it is hard to see how he could, for the general
case.

Mike Cepek suggested there were two main differences between his case and
mine, but omitted what I suggested is the crucial feature.

As measures against failure, the suggestions from both contributors fall
into the category of "good housekeeping" (GH). There is a general problem
with such methods. Car drivers know that, for each accident, there is at
least one prophylactic measure that would have avoided that individual
accident; the problem is to devise one single measure that would avoid every
accident.

For backups, this is a solved problem. Backups are an example of a
dependable database. There are algorithms well-analysed in the literature to
ensure such dependability (either perfectly, or to a known very high degree
of reliability). The solution to all backup problems is to use such a
procedure (implemented through humans, software, whatever). In contrast, the
dependability of most GH procedures is anecdotal only. Provided that one
assures conformance of the backup machine itself (which may well be
administratively out of control of the PDA user, therefore of higher backup
software), one could use verified backup software which implements the
appropriate part of a demonstrably dependable algorithm.

Except there isn't any for PDAs. One has to wonder why not.

Peter Ladkin


Re: It's the wolf! It's the wolf! (Bell, RISKS-21.24)

<Martin Jost <Martin.Jost@icn.siemens.de>>
Fri, 16 Feb 2001 15:45:23 +0100

> [...] I know of other sites with multiple names, and secure connections,
> and this is the first time I've ever seen the wrong certificate presented.

Why should they get it right, if (even (?)) HP fails at it ?
Try https://www.itrc.hp.com
(this is HPs IT Resource Center)

You start with a warning from Netscape:
  ---------------------------
  Warning! You have requested an insecure document that was originally
  designated a secure
  document (the location has been redirected from a secure to an
  insecure document). The document
  and any information you send back could be observed by a third party
  while in transit.
  ---------------------------
(_I_ had to read this slowly to get it the first time; now I routinely
click the 'Ok'-Button (Risk !))

Clicking 'Ok' carried me to
http://home1.itrc.hp.com
Clicking "Maintenance and Support" on this page got me on to
https://europe-support.external.hp.com
(Note: To get there, you will need an account)
I usually check this URL and the 'lock' icon in netscape.

This time no warning. (Certificate belongs to
europe-support.external.hp.com; 40 Bit)

And I remember having seen problems in the past of the sort:
Something like https://europe-support.external2.hp.com in Netscape, but
https://europe-support.external.hp.com in certificate
(Looks like load balancing to me)

Martin Jost


Re: It's the wolf! It's the wolf!

<"Andrew Jackson" <amj@trustis.com>>
Sat, 17 Feb 2001 18:17:23 -0000

I agree that there are ways to present a certificate so that it matches the
Web site name used, which would reduce the chance of receiving less than
helpful warning messages.

However, the site in question _is_ capable of using 128 bit SSL encryption -
I would guess that the 40 bit problem (and therefore a risk) results from
having an out of date browser as all the current ones are capable of 128 bit
encryption - even on this side of the Atlantic.

On a related tack, what gets me annoyed is Webservers that won't let me
submit a PKCS#10 certificate request without putting something in the
"State" field :-(  ("Frustrated" is never accepted, either.)

Andy  amj@trustis.com


When will they EVER learn?

<Geoff Kuenning <geoff@cs.hmc.edu>>
Thu, 15 Feb 2001 23:00:40 -0800

I just signed up with netflix.com, which among other things allows you
to purchase DVD movies.  Within two days, I received an e-mail that
helpfully told me — in cleartext — the password that I had just set
up for the account.

Since movies are moderately expensive, there are literally tens of
thousands of titles available, and it's not unreasonable to order 2-3
copies of one title, this seems to put my account at a rather high
risk of being abused by anyone with a sniffer.  I immediately changed
the password, and so far I haven't been told *it* in cleartext.  But
when will people figure out that there's not a lot of point in using
SSL if you fling sensitive information around in unencrypted e-mail?

Geoff Kuenning   geoff@cs.hmc.edu   http://www.cs.hmc.edu/~geoff/


REVIEW: "Building Internet Firewalls", Zwicky/Cooper

<"Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca>>
Mon, 19 Feb 2001 08:30:48 -0800

BKBUINFI.RVW   20010105

"Building Internet Firewalls", Elizabeth D. Zwicky/Simon Cooper/D.
Brent Chapman, 2000, 1-56592-871-7, U$44.95/C$65.95
%A   Elizabeth Zwicky
%A   Simon Cooper
%A   D. Brent Chapman
%C   103 Morris Street, Suite A, Sebastopol, CA   95472
%D   2000
%G   1-56592-871-7
%I   O'Reilly & Associates, Inc.
%O   U$44.95/C$65.95 707-829-0515 fax: 707-829-0104 nuts@ora.com
%P   869 p.
%T   "Building Internet Firewalls, Second Edition"

Cheswick and Bellovin's "Firewalls and Internet Security" (cf.
BKFRINSC.RVW) has been, and probably will continue to be, seen as the
classic reference with the seriously technical crowd.  Chapman and Zwicky,
however, created the first reference for the more normal run of system
administrators: those whose lives do not revolve around hacking the UNIX
kernel.  This expanded edition fulfills the same task, and maintains the
same reasonable stance.  It is refreshing, for example, to find a work that,
even if it doesn't know much about viruses, admits that firewalls can do
very little to protect against them.

There is now a more general and introductory part one, discussing the basic
concepts before getting deeply into technical details.  Three chapters look
at a rationale for firewall usage, Internet services and requirements, and
universal security strategies.

Part two (part one in the original edition) is an introduction to firewall
technology and structure.  It could easily stand as a separate book, itself,
clearly explaining the operation of, and reasoning behind, functions that
other firewall books merely mention.  More, it is a very down-to-earth and
practical guide to evaluating security needs and planning for security
systems and practices.  The writing is completely clear, and the
explanations first-rate.  Two chapters look at the packet structures of
Internet protocols and basic firewall technologies.  Chapter six, on
firewall architectures, is a perfect introduction for the manager who, while
not having a technical background, must lead or administer a security
project, and is followed by a short but useful outline for a design process.
The detailed chapter on packet filtering is the longest in the book, but
there is also solid coverage of proxy systems and bastion hosts.  The
section concludes with valuable particulars of tools for securing UNIX (and
Linux) and Windows (NT and 2000) systems.

Part three reviews various Internet services, the reasons for having them,
risks associated with them, and details that can be used to secure them.
There is an introduction to the subject, and then coverage of intermediary
protocols, the World Wide Web, e-mail and news, file and print transfer and
sharing, remote access, and real time conferencing systems.  Each chapter
also deals with related issues and technologies, such as the various
specific mail protocols and active content for Web pages.  As well, the
topics of naming and directory services, authentication, administrative
services, and databases and games are examined.  Two sample firewall
configurations, using the previous material, close off the division.

Part four provides quick but decent guidance on general security issues.
There is a look at security policies, firewall maintenance, and responding
to security incidents.

The appendices are useful, outlining resources for further information,
tools, and a brief but reliable explanation of cryptography.  The resource
list, unlike the usual table of titles and URLs, contains quality works, and
is annotated.

This was the first book to truly explain, to the non-specialist, the various
factors and functions involved in firewall choice and construction.  I still
have not found another of similar quality.  This new edition is not just an
update, but a valuable extension and expansion.  For those building their
own and for those evaluating vendor proposals, this book is a must.

copyright Robert M. Slade, 1995, 2001   BKBUINFI.RVW   20010105
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

x
Top