602513 - https favicon request can be redirected to unencrypted http third party page

Status: RESOLVED DUPLICATE of bug 437014

(Firefox :: Tabbed Browser, defect)

Description

[S.P.]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10

If Firefox is not directed to explicitly load icon for a site, it will attempt to load /favicon.ico by default. Apparently if the request for the default favicon is sent through https and the server replies with status 302 Found, the Location response header could redirect Firefox to load a different file from third party site using only http, while still considering the connection to the original server encrypted with high-grade encryption.

Reproducible: Always

Steps to Reproduce:
1. Firefox opens encrypted connection to a site (https://one.example.com)

2. If not explicitly directed to load the site icon, Firefox will at some point request favicon (at https://one.example.com/favicon.ico).

3. one.example.com server replies with 302 Found and sets Location response header to http://www.notsame.com/noticon.html. Note that the server name changed and now the completely different file is requested through http instead of https.

4. Firefox will load http://www.notsame.com/noticon.html and store it in disk cache device, but it appears that it’s not parsing the content at the time. As a side issue, the initial favicon request and the redirect are not going through content policy.

5. Page Info still specifies that Firefox is connected to one.example.com through encrypted connection. It does not report that anything else is loaded in any other (non encrypted) way. Firefox does not list in its Media tab that it loaded http://www.notsame.com/noticon.html, which is now stored in its disk cache.
Actual Results:  
If favicon request through encrypted connection is redirected with status 302 Found to unencrypted connection, the new document will be downloaded and stored in Firefox disk cache.

The Firefox will still consider the connection to the original server encrypted with high-grade encryption.

Expected Results:  
Firefox should not consider this connection secure. Request for the original favicon and redirected document should be listed in the Page Info.

Setting browser.chrome.favicons preference to false prevents this scenario.

Requests for the default favicon should go through the same security and content policy checks as all other requests. That way the redirect from the encrypted to the unencrypted connection would be noted and treated as usual. This is already noted in bug 437014.

I’m not familiar enough with Firefox source code to know for certain that this scenario is exploitable, but I’m going to mark it as such just in case. If this bug is confirmed non-exploitable, feel free to remove the mark.

Comment 1

[Brandon Sterne (:bsterne)]

I don't think this needs to be hidden.

Comment 2

[Daniel Veditz [:dveditz]]

Thanks for pointing out bug 437014, that's a problem and should be fixed and it appears to have gone unnoticed.

The rest of it doesn't seem to be a bug at all. The favicon isn't "in" the page, it's just decorative; it in no way compromises the security of the page contents. In fact, some people argue that only sub content like scripts and style should be forced to be https and that static images are perfectly fine even as content. I'm not one of them, and thankfully processing power has increased to the point that fewer people are trying to argue that case.

But favicons are not part of the page content. If you'd like to continue to argue that case please take it up in our development newsgroups. The audience for any given bug is small, and it's not going to be very effective if we don't believe it to be a bug in the first place. mozilla.dev.platform or mozilla.dev.security might work. The latter is perhaps more appropriate, but you'll reach a larger audience with .platform.

Rather than close wontfix or invalid on the summary part I'll dupe to bug 437014 based on the actionable points to give that one a little juice.