COMMAND
Netscape
SYSTEMS AFFECTED
Netscape Navigator
PROBLEM
Marc Slemko found following. Over the past month or so, he has
run into a number of relatively small security related bugs in
Navigator. They are small in that, in most situations, they
don't matter. But in some situations they matter a _LOT_. Most
of the vulnerabilities relate to the cross site scripting issue,
so to understand why they matter please be sure you are familiar
with that issue. See the previously posted links to:
http://oliver.efri.hr/~crv/security/bugs/mUNIXes/css.html
http://www.cert.org/advisories/CA-2000-02.html
http://www.apache.org/info/css-security/
for details. The below were all tested with Communicator 4.7 on
Unix. Summary:
1. Navigator can be convinced to embed newline characters in
URLs
2. Navigator will, in some situations, send out a referer over
a non-SSL connection for links from framed SSL documents
3. Communicator treats news:foo.example.com as the same as
http://foo.example.com/ WRT cookies, etc.
4. Navigator will interpret javascript in a lot of its
internal pages, eg. view source
Navigator can be convinced to embed newline characters in URLs
==============================================================
For example, consider the following:
<script>
document.location='http://server/xxxxxxx xx\n'+'<'+
'script>alert(document.cookie)<'+'/script>';
</script>
This will cause Navigator to send a HTTP request of the form:
GET /xxxxxxx xx
<script>alert(document.cookie)</script> HTTP/1.0
Referer: http://server/somedocument.html
User-Agent: Mozilla/4.7 [en] (...)
Host: server
This particular request is a problem as it relates to the "cross
site scripting" problem, due to a bug in versions of Apache prior
to 1.3.12. If you sent a request with a request header line
without a ':' in, then Apache will spit back the request line in
an error message, unencoded. This is a bug in Apache and was
fixed in 1.3.12, however normally it wouldn't matter since you
shouldn't be able to make a client send such a request; remember,
that sending it yourself with a custom client (eg. telnet) doesn't
matter, due to the nature of the cross site scripting issue.
But because of this bug in Navigator, the related bug in Apache
is more significant.
But this issue goes further. It also means that all virtualhosts
on the same IP address can spoof each other; not from the server
side of things, but by convincing Navigator to make ae bogus
request. So, for example, one vhost on an IP address could steal
cookies from another if the user can be convinced to run
javascript (this isn't necessarily javascript related, and isn't
a scripting bug, this is just the way I found to demonstrate it)
such as:
<script>
document.location='http://vhost1.example.com/ HTTP/1.0\n'+
'Host: vhost2.example.com\n\nx';
</script>
This will make navigator send a request such as:
GET / HTTP/1.0
Host: vhost2.example.com
x HTTP/1.0
Referer: http://server/somedocument2.html
User-Agent: Mozilla/4.7 [en] (...)
Host: vhost1.example.com
Cookie: vhost1_secret_cookie=my_secret_info
The server will stop reading headers at the blank line, and think
it is a request for vhost2, yet the client thinks it is talking to
vhost1 so it sends cookies, HTTP basic authentication info, etc.
along with it. Now, with this example the cookie, etc. for vhost1
will be lost, but it is possible to slightly change the request so
that it would be saved by something running on vhost1. The issue
here is it violates the separation between vhosts which, in some
situations, may matter.
Navigator will, in some situations, send out a referer for framed SSL documents
===============================================================================
Normally, most popular web browsers do not send refer information
for SSL encrypted documents. The rationale behind this is that
this could reveal sensitive information such as session IDs, etc.
You can argue this shouldn't be relied on, but it is. I noticed
this problem when using my online broker; a third party non-SSL
site that they linked to from a SSL page was actually setting a
cookie(!) that contained my session ID which, when used from your
IP address, gives someone access to my account.
The cause for this is frames. If you have frames in a document
retrieved via SSL such as:
<FRAMESET ROWS="50%, 50%">
<FRAME SRC="frame1.cgi?sessionid=39482847" NAME="top">
<FRAME SRC="http://server/frame2.html" NAME="bottom">
</FRAMESET>
Then frame1 will be loaded via SSL, but frame2 will not. That
will cause Navigator to not display the closed lock at the bottom
left of the window. That is reasonable. Unfortunately, it
appears that Navigator uses this same metric to decide if it
should send a referer header or not. So if you follow a link
from the "top" frame to a non-SSL site, it will send the referer
(containing the URL of the "top" frame) unencrypted to the other
site; in this case, it includes the private sessionid.
Communicator treats news:foo.example.com as the same as http://foo.example.com WRT cookies, etc.
================================================================================================
Suppose http://foo.example.com/ sets a cookie to be sent back to
foo.example.com. Suppose foo.example.com also runs a NNTP server.
Suppose this server allows users to post arbitrary content, as is
quite reasonable for a NNTP server to do. If you have "Enable
JavaScript for Mail and News" enabled (which, AFAIK, it is by
default; a very bad default), then any javascript that is posted
will be executed in the same context as a page loaded from
http://foo.example.com/ would be. So anyone can post a message
that will steal cookies (and perhaps do other things it shouldn't
be able to) from http://foo.example.com.
A more likely case may be where http://www.example.com/ set a
.example.com domain cookie, and then a NNTP server on
news.example.com is used to exploit it.
Note that you can cause Communicator to load a particular news
message simply by giving it the proper URL; it doesn't require
the user to manually add the news server, go to the group, etc.
There may be related issues with other protocols like ftp, etc.
In some cases, you may be able to make an error message come back
in the right form to exploit this. This is highly dependent on a
lot of things.
Navigator will interpret javascript in a lot of its internal pages, eg. view source
===================================================================================
Not sure if this is a security problem or not, but it seems worth
of bringing up. It seems that when Navigator itself outputs
information in pages such as "about:memory-cache", and
"view-source:", it doesn't encode output properly and executes
javascript. For example, following a link of this type in
Navigator:
<A HREF="view-source:http://server/?sucka=</title><script>alert(document.domain)</script>">Navigator Only</A>
Will result in Navigator popping up a view-source window and
executing javascript in it. As you can see when you try it, it
has an empty domain associated with it. Not sure if the security
context that Navigator runs such pages in is special or not and
Marc hasn't found any way to exploit this to do anything useful.
SOLUTION
Nothing yet.