mailing list archives
4 Netscape Navigator bugs
From: marcs () ZNEP COM (Marc Slemko)
Date: Sat, 11 Mar 2000 01:04:27 -0700
-----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:
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).
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.
Navigator can be convinced to embed newline characters in URLs
For example, consider the following:
This will cause Navigator to send a HTTP request of the form:
GET /xxxxxxx xx
User-Agent: Mozilla/4.7 [en] (...)
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
this is just the way I found to demonstrate it) such as:
This will make navigator send a request such as:
GET / HTTP/1.0
User-Agent: Mozilla/4.7 [en] (...)
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
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">
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
Suppose foo.example.com also runs a NNTP server. Suppose this server
allows users to post arbitrary content, as is quite reasonable for
enabled (which, AFAIK, it is by default; a very bad default), then
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.
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:",
For example, following a link of this type in Navigator:
Will result in Navigator popping up a view-source window and executing
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
(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,
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
-----END PGP SIGNATURE-----
- 4 Netscape Navigator bugs Marc Slemko (Mar 11)