1828374 - miss matching cache in Firefox could be result in network traffic hijacking or information leaking

Status: UNCONFIRMED

(Core :: Networking: Cache, defect, P3)

Description

[fragrant]

Attachment: cache.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36

Steps to reproduce:

Summary

When i access a web site for example https://www.baidu.com, firefox will open https://ip/nac/vsite/welcome_home.html?jumpurl=https://www.baidu.com since network access control will get a user authorization. firefox will save this site "https://ip/nac/vsite/welcome_home.html?jumpurl=https://www.baidu.com" in web cache.
Then I switch network to another network for example my personal hotspot with my iPhone, and access https://www.baidu.com, firefox will match this web site with https://ip/nac/vsite/welcome_home.html?jumpurl=https://www.baidu.com in cache, not open this website directly. If the web site https://ip/nac/vsite/welcome_home.html was compromised，the user can connect attacker website or leak private information to attacker

Steps to reproduce

1.connect a network which needs accessing control
2. open firefox and clear browsing history
3. input a url for example https://www.baidu.com;
and firefox get an authorization web page (https://ip/nac/vsite/welcome_home.html?jumpurl=https://www.baidu.com) which represents accessing succeed(nac.png).

4. switch to another network for example my personal hotspot on my iphone
5. open the before url https://www.baidu.com, The firefox open https://ip/nac/vsite/welcome_home.html?jumpurl=https://www.baidu.com without opening https://www.baidu.com directly(mismatch.png)
6. clear history(clearchache.png) and access https://www.baidu.com successfully(success.png)

Actual results:

Although I switch network, firefox should not open the web page cached in the lastest connected network before

Expected results:

open the https://www.baidu.com directly

Comment 1

[Daniel Veditz [:dveditz]]

After step 3, do you enter the authorization and continue on to baidu? If you don't. I can see why the redirect response itself was what was left in the cache. If you do go on to baidu after the authorization then the actual content for baidu should be cached and it shouldn't be redirecting.

Also, do you know what kind of redirect your authorization used? It should be using a temporary redirect, but if it issued a "permanent" redirect (e.g. 301 vs 302) that would also affect what we cache and would be a bug in the security appliance.

Comment 2

[fragrant]

Attachment: import argparse from http.server import HTTPServer, BaseHTTPRequestHandler from urllib.parse import urlparse from urllib.parse import parse_qs class S(BaseHTTPRequestHandler): def _set_headers(self): print("_set_headers") self.send_re

Hello Mr 	Daniel Veditz !
    Sorry to delay!

    After step 3, I didn't enter the authorization , so I think the redirect response itself was what was left in the cache.

    <<<After step 3, do you enter the authorization and continue on to baidu? If you don't. I can see why the redirect response itself was what was <<<left in the cache. If you do go on to baidu after the authorization then the actual content for baidu should be cached and it shouldn't be <<<redirecting.

      To imitate the situation, I build my own servers. One of servers issued a "permanent" redirect (301).

<<<Also, do you know what kind of redirect your authorization used? It should be using a temporary redirect, but if it issued a "permanent" redirect <<<(e.g. 301 vs 302) that would also affect what we cache and would be a bug in the security appliance.

    (1) I use my Mac as client . This client use hosts (/etc/hosts) as DNS server. And this client run a Apache web server.
         The initial settings in hosts file as follows :

        #127.0.0.1 www.server1.com
        192.168.163.184 www.server1.com
        192.168.163.135 www.server2.com

    (2)   Assume that location1 and location2 has two different network enviroments.   the machine ip addressed as 192.168.163.184 inimate NAC in location1 , so that any network traffic must through NAC . When I access www.server1.com ,  the http server running on 192.168.163.184 response a redirect to server2 to client  :
          
          http_server1.py
         """
           
         """

Comment 3

[fragrant]

Attachment: http_server1.py

http_server1.py used for reponse a redirect 301

Comment 4

[fragrant]

Attachment: http_server2.py

http_server2 used for response a http 200 to client and show PWN!

Comment 5

[fragrant]

Hello Mr Daniel Veditz !
Sorry to delay!

After step 3, I didn't enter the authorization , so I think the redirect response itself was what was left in the cache.

<<<After step 3, do you enter the authorization and continue on to baidu? If you don't. I can see why the redirect response itself was what was <<<left in the cache. If you do go on to baidu after the authorization then the actual content for baidu should be cached and it shouldn't be <<<redirecting.

  To imitate the situation, I build my own servers. One of servers issued a "permanent" redirect (301).

<<<Also, do you know what kind of redirect your authorization used? It should be using a temporary redirect, but if it issued a "permanent" redirect <<<(e.g. 301 vs 302) that would also affect what we cache and would be a bug in the security appliance.

The testing  environment settings:

(1) I use my Mac as client . This client use hosts (/etc/hosts) as DNS server. And this client run a Apache web server.
     The initial settings in hosts file as follows :

    #127.0.0.1 www.server1.com
    192.168.163.184 www.server1.com
    192.168.163.135 www.server2.com

(2)   Assume that location1 and location2 has two different network enviroments.   the machine ip addressed as 192.168.163.184 inimate NAC in location1 , so that any network traffic must through NAC . When I access www.server1.com ,  the http server running on 192.168.163.184 response a redirect to server2 to client  . The attachment http_server1 implement that.

(3)  The server2 IP is 192.168.163.135 and the domain name is www.server2.com. server2 response 200 and text "PWN" to client .the attachment http_server2 implement that.

The issue reproduce steps:
 (1) start up firefox and clear all cache on my mac client(127.0.0.1) .
 (2) start up http server with http_server1.py on an linux host (192.168.163.184 )
 (3) start up http server with http_server2.py on another linux host (192.168.163.135)
 (4) access http://www.server1.com in my firefox client.
 (5) since  server1 redirect 301 to server2 , now firefox access http://www.server2.com?jumpurl=http://www.server1.com
 (6) the server2 response 200 and text "PWN" to client.
 (7) modify DNS in hosts:
    127.0.0.1 www.server1.com
    #192.168.163.184 www.server1.com
    192.168.163.135 www.server2.com
 (8) open a new tab in firefox and access http://www.server1.com again, you will get text "PWN" .  The result is the same as (6). 
 (9)when I clear all the cache in firefox and access http://www.server1.com, firefox get "it works" from apache server on my mac(127.0.0.1)

that show that firefox cache the redirect contents.

And back to my first commit , since firefox cache this redirect result in location1 , when I access url www.baidu.com in location2 which has a different network environment, I always access the cached redirect result  without accessing directly. I think this is dangerous from security view.

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

From comment 5, it appears that this is DNS getting changed out from under us. DNS has a TTL for each entry, so clients/etc don't have to constantly request the address. Changing the hosts file means that if we have to resolve against the file, we'll get the new value - but until we think the TTL has elapsed well use the original DNS data we fetched.

If this is what's happening in your 'real' scenario, then we're acting correctly and caching the address until it expires. Note that clearing caches clears the content caches, not the internal DNS cache. We may throw away the cache if we think you're switched networks, but I'm not sure what triggers that.

Valentin, any thoughts?

Comment 7

[fragrant]

When I connect location1 network and access www.baidu.com and the network nac response a permanent (301) redirect (https://ip/nac/vsite/welcome_home.html?jumpurl=https://www.baidu.com) to my firefox client. for the permanent redirect , firefox will store this to cache. Although I switch network at location2 , when I access www.baidu.com again, firefox will bring me to the cached redirect.

I know firefox will cache permanent redirect. I suspected if this behavior is invasion of user privacy. Assume that I was monitored at location1 with nac network whatever I access , am I still being watched in location2 network ?

Comment 8

[fragrant]

Attachment: 301.jpeg

Comment 9

[fragrant]

this is permanent redirect from NAC

Comment 10

[Valentin Gosu [:valentin]]

I'm not very sure how the NAC is supposed to work, but indeed, the initial 301 redirect from baidu.com is cached - it is a permanent redirect, and assuming baidu.com has a valid certificate, and the response includes the right headers, I would think that is expected behaviour.
I think the situation here might be improved if the rediect included the proper Cache control headers - otherwise the redirect is cached permanently.
I expect you get the same behaviour in Chrome?

Comment 11

[fragrant]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #10)

I'm not very sure how the NAC is supposed to work, but indeed, the initial 301 redirect from baidu.com is cached - it is a permanent redirect, and assuming baidu.com has a valid certificate, and the response includes the right headers, I would think that is expected behaviour.

NAC (network access control) is used for user behaviors monitor in network environment 1. It is like to network gateway. Any access to network will go through NAC. when network1 environment switch to network2 environment , access in network2 environment should not go through NAC in network1. Because of permanent cache in network1 environment, access in network2 environment always make access to NAC in network1. In network1 environment , Users knows their behavivors was monitored by NAC in network1 , but they don't expect that in network2. So I don't think this is normal . Browser should feel this network change, It shouldn't always think this kind of redirect is safe

I think the situation here might be improved if the rediect included the proper Cache control headers - otherwise the redirect is cached permanently.
yep， If NAC in network1 send user an temperary indirect like 302， firefox will not cache this temperary redirect .

I expect you get the same behaviour in Chrome?

Since my environment changes , I cannot test this on Chrome in timely. If that is necessary， I will try later.

Comment 12

[Valentin Gosu [:valentin]]

Does baidu.com intentionally redirect the user to use NAC when connecting via network1, but not when doing so via network2?

If that's the case, then it's pretty much up to the site to fix its behaviour.
We did consider the cache redirect poisoning attack in the past, but that was mostly applied to non-https pages. Presumably if a page is loaded over HTTPS, we will always trust its responses and cache&reuse the responses accordingly.