Date: Sat, 11 Mar 2000 01:04:27 -0700
From: Marc Slemko <[email protected]>
To: [email protected]Subject: 4 Netscape Navigator bugs
-----BEGIN PGP SIGNED MESSAGE-----
Over the past month or so, I have 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://www.cert.org/advisories/CA-2000-02.htmlhttp://www.apache.org/info/css-security/
for details.
The below were all tested with Communicator 4.7 on Unix. I do not
think that any more recent versions fix any of them, although I
can't say for sure and I haven't tested them on all platforms.
I have reported or attempted to report most of these to Netscape. I don't
know if they care or if they plan to fix them or even if 4.72 contains
fixes for any of them (it is possible, since I think I reported some of
them before then, but don't think it was done).
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
Details:
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 my 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
I don't know 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. I'm not sure if the security context that
Navigator runs such pages in is special or not and I haven't found any way to
exploit this to do anything useful. But I am definitely no javascript
(or even client...) expert, so I don't understand the details.
I note that you can set cookies in this empty domain, which could
be used for cross-site tracking in a very odd way by using this
bug to set them on one site, then using it on another site to
retrieve them and request a URL on that site that sends the value
of the cookie to the site. I don't view this as a real threat,
however.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQCVAwUBOMn+D1Qv/g4Arev1AQHUQAP9GeUsedFIn87KlCrnhNf9NEHjxE4PHEVH
VGnzZyQtotLIVI0UKReQVXWutZwuPSzc6Usf2rzlOF0TP99368AUmVbgWQxJC80j
z1AfnpIiy1BiESiuv6tGPNDZurzCZP4EAEZ98gD0LtjigFblRbkHI6sZ7Py88y9H
4w1g2moXLnc=
=USwR
-----END PGP SIGNATURE-----
