New JavaScript Privacy Bugs In Communicator

Nando (no.spam@THANK.YOU)
Sat, 14 Feb 1998 23:09:52 +0100

--- Summary ------------------------------------------------------------

1. Description
2. Details about issues #1 and #2
3. Solutions for issues #1 and #2
4. Details about issue #3
5. Solutions for issue #3
6. About the source code of the exploits

--- 1. Description -----------------------------------------------------

I have discovered several security flaws in JavaScript for the Netscape
Communicator suite. These bugs are present (AFAIK) in all 4.x versions
for Win32 and Unix platforms (Mac platforms haven't been tested, but I
cannot see any reasons they wouldn't be vulnerable too). Prior versions
of Netscape Navigator (2.x and 3.x) are NOT vulnerable.

These bugs allow a webmaster to create a webpage that might steal from
visitors' systems high sensitive data like FTP and/or POP account
passwords as well as other possibly sensitive informations (visited
URLs, etc).

It's also possible to test whether a file or directory is present on the
hard drives of the visitors, but it's neither possible (using these
flaws) to read them, nor to upload them.

All three bugs were reported to Netscape 4 weeks ago. AFAIK, a fixed
release or a patch will be soon available.

--- 2. Details about issues #1 and #2 ----------------------------------

These attacks are directed against the preferences file, which contains
many sensitive informations like:
POP server name, user-id and password, (used by Messenger)
FTP servers names, logins and passwords (used by Composer)
recently visited URLs,
etc

Both attacks need 3 steps to be successfull. It must
1. locate or guess the location of the preferences file
2. execute it (it's a JS file)
3. send the collected information back to a desired location

Step #3 is very easy, using HTTP protocol for instance. I found two
different ways to achieve step #2, hence the two issues. Steps #1 and #3
are identical in both attacks. If successfull, the attack is completed
in the matter of seconds and completely unbeknownst to the victim. Even
users from behind firewalls risk exposing 'internal' information
if they use the same browser on both the intranet and the internet.

--- 3. Solutions for issues #1 and #2 ----------------------------------

Many actions can be taken to keep safe against these attacks. The
simplest one is:

Until a fixed release is available,
>>> deactivate JavaScript <<<
except when visiting known and trusted sites.

This will solve the problem for most users. For those that MUST run the
Communicator with JS enabled, the only other solution I know is to make
the location of the preferences file obscure or unguessable. I'll take
an example to explain to concerned users how they can do that.

On Win32 systems, a 'standard' installation of the Communicator suite
will create a directory structure like this one:

/ (root)
Program Files/
Netscape/
Communicator/
Users/
<userid>/ (by default, leftside of email address)
prefs.js (here's the target)
Mail/
Inbox
...

The fact that the user's profile directory is defaulted to the left-side
of the email address makes it easily guessable for an attacker that
already knows about the victim.
An other problem is the location of the downloaded emails. Emails may
contain HTML with embedded JS scripts. Scripts located on this kind of
mails may read the window.document.URL property, which contains the
complete path to the mail folder and, as you can see, reveals the path
to the prefs.js file (of course, only users which use Messenger as their
default mailer are concerned)

In conclusion, if you change the directory structure of your system to
the following (for example):

/ (root)
Program Files/
Netscape/
Communicator/
Users/
<obscure_string>/ (random or unguessable string)
prefs.js
My Documents/
Netscape/
<userid>/
Mail/
Inbox
...

... then you'll be safe, even running Communicator with JS enabled.

--- 4. Details about issue #3 ------------------------------------------

A new feature in Communicator's implementation of JavaScript (JS1.2)
used together with generated HTML makes it possible to a JS script
located on a networked document to test whether a file or directory is
present on the hard drives of visitors.

But it's neither possible to get access to the content of the files (to
read them), nor to upload them.

--- 5. Solutions for issue #3 ------------------------------------------

For users that care about it, I only know one way:

Until a fixed release is available,
>>> deactivate JavaScript <<<
except when visiting known and trusted sites.

--- 6. About the source code of the exploits ---------------------------

Because of the users' safety and privacy, I won't publish the source
code of any of these exploits until a fixed release of Communicator is
available from Netscape.

------------------------------------------------------------------------

I won't be easily reachable in the next two weeks. Be patient if you
mail me, I will reply to everyone, but later than I'm used to.

--
Fernand Portela
nando at mygale dot org
http://www.mygale.org/~nando