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 20 Issue 70

Sunday 19 December 1999

Contents

o ResearchIndex: a digital library of computer science papers
Ursula Martin
o Where do you want to go today ? And... when exactly ?
Nick Brown
o Another appalling Web security story
Nick Brown
o Risks of US-Euro date conversion
Terje Mathisen
o Re: Melissa perpetrator faces five years in prison
Russ Cooper
o Y2K fear vs. Common sense
identity withheld
o Browsers should only display what is requested?
Dick Shelton
o Netscape and the risk of two accounts
Steven J. Greenwald
o RST discovers defective crypto in Netscape mail
Zygo Blaxell
Raymond Michiels
Michael Kohne
Gary McGraw
John Viega
Dan Foster
o Info on RISKS (comp.risks)

ResearchIndex: a digital library of computer science papers

Ursula Martin <ursula@csl.sri.com>
Thu, 16 Dec 1999 12:01:02 -0800
ResearchIndex http://citeseer.nj.nec.com/cs is a digital library that
harvests documents from web pages (220,000 so far), builds a citation index
(over 2.5 million so far) and provides text search.  Each document has a
page which gets you the original URL, a cached copy of the document,
backwards citations, forward citations in context and links to other
documents that are related or have substantial matching text.

On the one hand this is a fascinating, audacious and extremely useful
resource.  On the other such digital libraries and research tools (and this
research prototype in particular), and the radical new model of
accreditation, access, and authentication for scientific information that
they can potentially support, raise significant and far reaching security,
rights and privacy questions for the scholarly community.

For example look again at some features of ResearchIndex :

* Anyone, apparently without authentication, can add so-called
"Authors" comments and "Title correction" to any document record or
suggest new URLs for ResearchIndex to harvest.  Digital libraries need
robust security and authentication mechanisms if they are to be a
trusted part of the scientific process.

* A "most cited" list: pause a moment, before awarding "J Smith"
tenure on the basis of that spectacular Number 16 position, which is
the result of concatenating several different people, to reflect on
the problems of name reconciliation and the dangers of relying on
unauthenticated data, particularly in matters that may be subject to
legal challenge.

* It provides a listing of what "Users who viewed this document also
viewed": so think twice before using ResearchIndex to investigate that
potential patent involving a novel application of YYY to the entirely
unrelated ZZZ. Wonder about the "right of a scholar to the privacy of the
study", and recall the privacy conventions about access to library borrowing
records in your own state or country.  Consider what such a service could or
should track and analyse, what use might be made of such tracking
information and who has rights to it: for example what if analysing usage
patterns made a connection that beat someone else to a patent?

* It caches copies of the documents, which are then available for download.
Question exactly what versions of which documents have been harvested from
where, and how accurate the analysis is: ResearchIndex gives one of my
papers a bizarre ``Abstract'' consisting of the paragraph following an
occurrence of the word ``Abstraction''.  Wonder what happens when a document
is later removed from the URL it was harvested from, for example for
copyright reasons.  Then figure out the authentication and rights issues.

* Think about what is not there: for example citations of Turing's papers
(he is Number 4101 in the most cited list), but not the papers themselves,
and reflect on the future of our paper archives and libraries.

We expect our on-line documents to be located, read and analysed by people
and machines, that is why we put them on-line.  Sooner or later there will
be a production version of something like ResearchIndex that addresses these
problems, but meanwhile we all have a chance to debate what we want, and the
authentication, security, rights, privacy, legal and political implications
of the "harvesting", mining and distribution of the world's on-line research
documents.

Starting points for further reading:
The Coalition for Network  Information has many relevant reports at
http://www.cni.org/projects/

Henry Gladney, Safeguarding Digital Library Contents and Users,
Interim Retrospect and Prospects, D-Lib Magazine, July/August 1998
http://www.dlib.org/dlib/july98/gladney/07gladney.html

Ursula Martin University of St Andrews/SRI


Where do you want to go today ? And... when exactly ?

BROWN Nick <Nick.BROWN@coe.int>
Fri, 19 Nov 1999 10:19:19 +0100
Microsoft Outlook has a feature which allows you to tell the Exchange server
to deliver a mail after a certain time.  For example, you could use this to
send your company's quarterly results to the press at 7am tomorrow and be
sure they would not go out until the figures are officially published.

However, due to a problem in the definition of time (!), it is possible for
the delivery time to be an hour late or an hour early.  An hour late is
perhaps not so bad - after all, you said "do not deliver before 7am", and
it's true, 8am is not before 7am.  But an hour early ?  Can you say
arbitrage ?

The problem is that all events in Exchange are scheduled in GMT, but
Exchange does not correctly handle the automatic changes in the Windows NT
system clock when daylight savings time kicks in.  The result is that, after
daylight savings time starts or ends, and until you reboot your Exchange
server:

- deferred mails sent in the fall, when the clocks go back, will be
  delivered an hour later than you expected.

- deferred mails sent in the spring, when the clocks go forward, will be
  delivered an hour earlier than you expected.

The workaround is, of course, to reboot your Exchange server (or completely
restart Exchange, which involves more or less the same level of user
downtime) when the time changes.  But on sites which have a policy to reboot
only one major server at a time (there are several good reasons to do this),
this could take several days (Exchange servers are notoriously slow to
shutdown).

Doubtless Microsoft's preferred permanent fix is to lobby governments to
abolish daylight savings time.  Hmmm... isn't the French government pretty
keen on that right now ?  Is that what Bill was talking to Chirac about ?

Nick Brown, Strasbourg, France.
for more information, http://dct.coe.int/info/emfci001.htm


Another appalling Web security story

BROWN Nick <Nick.BROWN@coe.int>
Fri, 10 Dec 1999 10:49:36 +0100
The home exchange organisation to which I belong has decided to put its
catalog online.  Anyone will be able to view the homes which are offered,
but contact address and phone number details will be provided for members
only.

Today I received the instructions for logging on.  Hoo boy - here we go
again:

- The Username is your country code followed by your membership number
within the country.  This is published in the paper catalogue.

- The Password is "xxxxxxxx" (I have censored it).  But - the password is
the SAME for EVERY username.  You read that correctly.

So, the usual list of RISKs:

1) Member US1234 can log on as Member US5678.  In theory this is no big deal
because currently all you can do is read information which you could have
obtained as the other member, although for auditing reasons I'm sure they'd
like to know who is really logging on.  But we are promised that in future
versions, we will be able to update our site entries ourselves...

2) Non-member Z can very easily obtain a member number.  And even if the
site managers notice that Member US1234's account is being used by 500 PCs a
day after someone posted it to DejaNews, and they close that account, it
will not require a degree in computer science to work out that US1235 etc
are worth a try, since there's none of the usual hassle to guess the
password.

Needless to say, I have asked the organisation to remove me from the Web
site immediately.

Nick Brown, Strasbourg, France.
for more information, http://dct.coe.int/info/emfci001.htm


Risks of US-Euro date conversion (Re: Ben Hines, Risks Digest 20.67)

Terje Mathisen <Terje.Mathisen@hda.hydro.com>
Wed, 08 Dec 1999 12:48:21 +0100
This is really just another of the risks we face from not adopting
proper standards (i.e., satellite failure caused by US/Metric conversion error)

In the case of dates, we have had an international (ISO) standard for many
years now, according to this dates should be displayed as 1999-12-10 instead
of 12/10/99 or 10/12/99 or even (heaven forbid!)  01/02/03.

Here's one page showing some of the problems related to our current mess,
and why all countries, not just Japan and Sweden, should switch to ISO
8601. This page also have links to the full standard text.

 http://www.saqqara.demon.co.uk/datefmt.htm

Terje

PS. The corporation I work for, Hydro, very sensibly decided some years
ago to switch to ISO dates, even though this is different from the
Norwegian standard.

<Terje.Mathisen@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline


Re: Melissa perpetrator faces five years in prison (RISKS-20.68)

Russ <Russ.Cooper@rc.on.ca>
Wed, 15 Dec 1999 09:27:09 -0500
IMO, there many risks that the case against Mr. Smith for Melissa may
bring to reality.

1. That a GUID may be accepted in court as a "signature" uniquely
identifying a particular human being. At best the GUID is circumstantial,
and it is far to easy to show GUIDs belonging to others (mistakenly or
intentionally) resident on your machine.

2. That it may be accepted as possible to prove the route which a particular
virus has traveled to get to the point where its deemed "in the wild", and
presumably therefore actionable, solely on the basis of computer evidence.

  2a. What is the crime? Making the virus, or releasing it "in the wild"?
Surely making a virus is not a crime, so the test comes down to proving who
released it "in the wild". Since that action must be done with intent,
computer data alone, demonstrating that a particular file originated from a
particular disk, still does not prove intent. If I were to co-opt Peter's
machine and use it to send a virus to a Usenet list, should Peter be held
liable for the damages of the virus?

  2b. How is it proven? Computer data is malleable, and while Word documents
may store revision information, and even information from RAM totally
unrelated to the original document, it is possible that all of that
information can be placed into another file either in addition to, or
replacing, the 2nd document's original information.  As such, its again
circumstantial evidence of origin and even ownership.

It is quite easy to villainize virus writers and infectors in the same way
"two Arab men" were responsible for the Oklahoma bombing. An entire industry
is available for testimony as to the damage suffered by Corporate America
every day as a result of the actions of the few virus writers. The NIPC, and
therefore the FBI, are desperate to show they have the savvy to catch
Cyber-criminals and justify their stance and actions.

IOWs, there's a significant weight against Mr. Smith if we allow prosecution
testimony to go unchallenged for the vapor-thoughts it may well be. It must
be shown that such conclusions, based solely on computer data, can easily be
manufactured against anyone.

I have thought long and hard about how it may be possible to prove an
individual is guilty of a particular computer crime. A confession, today,
could be given simply to garner the publicity and reap the benefits after
the jail term is served (do you think any conference would not pay to have
Mr. Smith talk after he was released, if he could speak intelligibly?
... book deals ... guest spots ...) Criminals used to take the rap and not
talk in order to get the loot when they were released ...;-]

Without another human being present during each of the steps required to
release a virus into the wild with malicious or harmful intent, a conviction
on circumstantial computer evidence would lead to many serious problems,
IMO.

If the above evidence, assuming its present and the basis of the case
against Mr. Smith, is accepted in court and the jury finds its credible, it
will be far too easy to convict innocent individuals of computer crimes in
the future.

Smith may well be guilty, and he is not my focus here. We must ensure that
his conviction does not establish the wrong precedence's, lest we give the
"enemy" the ammunition to get each and every one of us convicted of
something, somewhere, based on the same quality of evidence.

I remind you that I, like most of you, have not seen the evidence against
Mr. Smith and this is based solely on the media reports about its content
... therefore, I may be totally off-base ... but the risk is real no matter.

Russ - NTBugtraq Editor


Y2K fear vs. Common sense

identity withheld <>
Fri, 17 Dec 1999
I work for a large health maintenance organization.  We share our campus
with about a dozen other assorted companies. All of our upper management is
absolutely terrified of the end of this year.  They are convinced that there
is going to be a major disaster at the stroke of midnight.

To deal with a potential loss of power, we have installed a generator
onsite.  A storage tank next to the generator holds 1,500 gallons of fuel.
An additional 2,000 gallons of fuel will be parked next to the generator the
entire weekend of the new year.

The risks?

1) The generator is in a hastily built wooden hut secured with a padlock.
The hut is located on the outside wall of our data center.  3,500 gallons of
boom.

2) One of the other clients on a campus constantly gets bomb threats.
Often the threats are real.  Who needs a Rider Truck?

3) Disaster recovery planning has taken a back seat to Y2k planning.  We
would not survive the loss of our data center.  The disaster plans have not
been updated to reflect our move from VMS to Unix over the last 5 years.

4) People ignore the large "No Smoking" signs posted on the generator
shed.  See #1.  Who needs terrorists?

The Unix team has started parking on the far side of the parking lot
in the 'blast shadow' of another building.


Browsers should only display what is requested? (Re: Galt, RISKS-20.66)

Dick Shelton <dicks@shavliktechnologies.com>
Mon, 13 Dec 1999 16:22:19 -0600
"No browser has any business ever loading a URL unless the user requests it!"

That sounds non-controversial -- but what constitutes a request?

o  Typing it in the navigation window?  Surely.

o  Clicking on a hyperlink?  Probably (else hypertext becomes rather lame)
-- but what if the user doesn't recognize it as a link?  And how many users
routinely screen the reference before clicking the link?  Typically there is
not enough information available to know just what a link will get you into.

o  Automatically loading images for embedded <img> tags?  Well, there are
times you wish it wouldn't, given the image bloat on the net, but the
alternative is not very attractive either.

o  What about loading a URL in response to an onclick event?  Or loading a
new image in response to a mouseover event?  As these are embedded in script
or applets or components, it would be hard for the browser to distinguish
between "requests" from the program and requests from user interaction.  The
alternative seems to be restricting user interaction to clicking on anchor
tags.  This is akin to restricting computer interaction to TTY mode.  Sorry,
but we've passed that stage.

In the current state of the net there is no incontrovertible notion of what
constitutes a request.  There will always be a natural tension between the
convenience (and power) of the user interface and the problems of letting a
program decide how to proceed.  You can push the extremes too far in either
direction.

Dick Shelton, Shavlik Technologies  dicks@shavlik.com


Netscape and the risk of two accounts

"Steven J. Greenwald" <sjg6@gate.net>
Sat, 18 Dec 1999 00:16:37 -0500
I use Netscape running on a Win95 platform to read most of my mail from a
particular account with a particular ISP.

Recently I needed to get a second account from that same ISP (for a
civil-rights group I'm working with).

I set up another Dial-up Networking connection using Win95, with this
new user name and new password.

To test it, I connected to the new account. Everything seemed fine. I then
clicked on the "Get Mail" icon in Netscape Messenger to get any mail that
might be in the new account (typically there is a welcome message from the
ISP).

Imagine my surprise when what came in was all the mail from my first
account!

Of course, it turns out that Netscape stored (without my knowledge) the
password to my first account internally (as has been noted previously in
RISKS - I've just gotten around to reading that digest). Okay, I can
understand that (but not agree with it).

But why did it use the first user name and password when the Win95 dial-up
networking program connected to a completely different account (I called my
ISP, and I was indeed connected to the new account)?

The risks are obvious. In any event, users should be told that their
passwords are being stored by application code and that mail can be
retrieved from one account via another without doing anything so
esoteric as using telnet.

There just no accounting for this.

--Steve Greenwald    http://www.gate.net/~sjg6


RST discovers defective crypto in Netscape mail (McGraw, R-20.68)

Zygo Blaxell <uryse0d5@umail.furryterror.org>
Wed, 15 Dec 1999 05:56:47 GMT
> Unfortunately, the encryption algorithm used by Netscape to scramble
> passwords is exceptionally weak.

Even if it weren't weak, it would still be equivalent to a plain text
password.  Netscape has to be able to send the password in the clear over
the IMAP/POP3 protocols, so no matter what encryption mechanism is used,
Netscape can always be reverse-engineered to retrieve the encryption
algorithm and/or keys required to extract the password.


Re: RST discovers defective crypto in Netscape mail password saver

Raymond Michiels <raymond@frontier.nl>
Thu, 16 Dec 1999 21:42:38 +0100 (MET)
In defence of Netscape, I would like to point out that the only viable
alternative to Netscape's "exceptionally weak" encryption is "security
through obscurity." Storing passwords locally is inherently insecure.

Once again, those UNIX people have solved this one in a particularly elegant
way using the ".netrc" file: store unencrypted passwords in a file which may
only be readable to the owner. The level of security is immediately obvious
to the user; the user can then make an informed decision to live with this
security or to type the password whenever needed.


RST discovers defective crypto in Netscape mail (McGraw, R-20.68)

Michael Kohne <mhkohne@discordia.org>
Thu, 16 Dec 1999 07:46:05 -0500
Not to seem silly but: So what? I'm no crypto expert, but it seems obvious
to me that if the password is being stored on your machine and requires no
other input from you for Netscape to provide the password to the other end,
then it's by definition insecure.

No matter what crypto algorithm Netscape uses, ALL the secrets are on your
machine - the encrypted password AND the code and secrets needed to decode
it. Yes, it would take more time to reverse engineer the relevant portions
of Netscape code than to simply break the algorithm the way you did, but
only one person has to do so - then security is blown just the same.

It doesn't matter that Netscape's local password storage isn't secure - ANY
local password storage is going to be insecure. No matter how complicated
the lock, if you hang the keys (or a technical manual on the lock's
operation) on a hook next to the door, it doesn't do you much good. The only
thing that encryption of the stored password prevents is accidental
revelation during registry browsing.

And yes, the only workaround is to not allow Netscape to remember your
passwords. But that's what you need to do. In all programs. Always.

It should also be noted that if I'm not mistaken, the POP protocol (I don't
know about IMAP) transmits the password in clear text. So all someone needs
is a sniffer somewhere in between you and your mail server (like your local
lan) and the results are the same.

It is a good thing to have folks like you point out security holes in well
known applications, but I'd have to say that Netscape isn't as terrible as
you make out on this one. All they did is decide that protecting the
password in the local cache wasn't worth a lot of effort. And I have to
agree with that sentiment.

On the flip side, Chris Saito's statement about recovery was just silly, as
you rightfully point out.

One other point: In Risks you mention a Javascript based attack. Are you
referring to using one of the known Javascript attacks to capture the user's
encrypted password entries, or do you have something new?

Michael Kohne <mhkohne@discordia.org>


RST discovers defective crypto in Netscape mail (McGraw, R-20.68)

Gary McGraw <gem@rstcorp.com>
Thu, 16 Dec 1999 09:30:15 -0500
You are correct Michael, there is NO perfect solution here. However, we
believe using a well known crypto algorithm like DES and hiding the key
material throughout the code is orders of magnitude better than Netscape's
current approach. In other words, you raise the bar significantly by forcing
people to reverse engineer for an attack (to find the key) and get much
lower risk that way.  The current approach is just too risky.

Along those lines, Avi Rubin (ATT Research) said it best when he said
Netscape needs to run out and get a bar so they can raise it!  We agree.  Of
course the "one attacker is all it takes" comment you made remains
completely accurate.

With regards to the Javascript attack, we were referring to an old
(presumably fixed) Javascript attack which was able to snag the "encrypted"
password and lots of other private information from the prefs file.  Because
of Netscape's "patch through release" approach, the attack still works
against Netscape 4.0 through 4.04.  Yet another reason to update your
browser.

Yesterday we were informed that Dave Edis of Interactivetools created a
Web-based password cracker (which requires someone to enter the obscured
password through a dialog box) at least a year ago. We were not previously
aware of his work.  Though his code does not work against current versions
of Netscape, the algorithm currently used (and cracked by us) is very
similar.  See: <http://www.thewebmasters.net/mailpass.html> One might wonder
whether this implies that Netscape is taking an arms race approach to
obscuring the POP3 password.  If so, why the heck not use DES??

As for sniffers, I believe you are correct about POP3 and plaintext
passwords.  Yet another serious risk, but compounding not mitigating the one
we raised. Ain't shrinkwrap wonderful?

Gary McGraw, Ph.D, Vice President, Reliable Software Technologies, Dulles, VA
gem@rstcorp.com  <http://www.rstcorp.com/~gem>  <http://www.securingjava.com>


RST discovers defective crypto in Netscape mail (McGraw, R-20.68)

John Viega <John@list.org>
Thu, 16 Dec 1999 09:20:03 -0800
Let's be honest, the only thing you need to do to exploit this bug even
without a JavaScript flaw in the person's browser is to trick the user into
running some code on his machine.  That's not too tough.  I can e-mail all my
friends a "dancing pigs" demo, and 90% of them will run it. That's a given.

Of course, if you can run code on other people's machine, there are lots of
things you can do.  The reason why this bug is a bigger problem is that
POP/IMAP account info often doubles as a unix account.  Also, people reuse
their passwords on multiple accounts.  Basically, this bug makes it much
easier for a hacker to spread to new machines once one machine has been
compromised.

> Yesterday we were informed that Dave Edis of Interactivetools created ...

I think that current WINDOWS versions might be more accurate.  We only
broke Windows encryption.  Unix and Mac versions were slightly
different; Windows pre-4.0 or so was different as well.  We could tell
it was similar, but not quite as complex.  The primary difference
seemed to be that there was no permutation of the bits.

When we talked to Netscape, we were told they knew the algorithm could
be a lot better, but they were hoping it was unlikely anyone would
target it and break it. They never indicated that they knew about
their old cipher being broken, either, but I'd bet they knew about it,
prompting the changes that led to the current algorithm.

> As for sniffers, I believe you are correct about POP3 and plaintext ...

I didn't catch the original message, so I hope my response is appropriate.
Sniffers are a big problem, but they generally require a person to have
compromised administrative access on one machine on the local network to
exploit.  It can also be hard to mine the data, and there are reasonable
detection techniques for sniffers (see l0pht's antisniff).  In short, I
think it'd be a fair bit easier for script kiddies to take advantage of this
problem (assuming someone has given them a nice compact exploit) than to
break in, install a sniffer, and retrieve and mine the results.


Re: RST discovers defective crypto in Netscape mail password saver

Dan Foster <dsf@gblx.net>
Wed, 15 Dec 1999 02:57:21 -0500
That's an excellent advisory regarding seemingly securely encrypted passwords
by Netscape Communicator. Unfortunately, that particular issue was already
previously discovered by others, as evidenced by BUGTRAQ mailings around
November 7th and 8th, 1998 by Holger van Lengerich <gimli@uni-paderborn.de>
and Thievco <thievco@sprite.netnation.com>. Credit where it's due and all.
I seem to recall having also seen a C source file via BUGTRAQ before to
decode the stored password, too.

Also, the referenced link at http://www.rstcorp.com/news/bad-crypto.html
returns a 404 Not Found error.

I'm not sure that saving passwords is a bad thing per se; it is possible
to approach this through technological means, but seems it would be better
addressed by policy means such as user education and policies on diversity
of passwords for various accounts, as well as better suggestions for
(user) memorizable passwords. Or in the very least, put up an initial
one time dialog box strongly discouraging the use of the option.

That said, XOR'ing the password does seem somewhat weak, and the RISKS
of employing either poor choices for passwords or storing them in a less
than secure manner without making noise about it to users seems obvious.

Dan Foster <dsf@gblx.net>

Please report problems with the web pages to the maintainer

Top