191715 - PAC: did not work, after a external site is shown (fix Resolve)

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P1)

Description

[Sven Anders]

User-Agent:       Mozilla/5.0 (compatible; Konqueror/3; Linux)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.2.1) Gecko/20021130

Hi, 
we have a automatic Porxy Configuration Script.  
It looks like this: 
 
function FindProxyForURL(url, host) { 
 
    if ( isInNet(host, "172.16.0.0", "255.255.0.0") ) 
    { 
 
        return "DIRECT"; 
    } 
 
    if ( isInNet(host, "127.0.0.0", "255.255.0.0") ) 
    { 
 
        return "DIRECT"; 
    } 
 
    return "PROXY proxy.digitec:8080"; 
 
} 
 
I have a start page it is called http://apz.digitec/ (it's in our intranet, 
you can not reach it via proxy.) When I start the Browser the Page ist loaded 
okay.  
 
BUT when I connect to some server in the internet e.g. http://www.mozilla.org/ 
and return to http://apz.digitec/ . Mozilla connects to the Proxy, and get's 
an error from the Proxy. 
 
 

Reproducible: Always

Steps to Reproduce:
1. Get a proxy Server e.g. Squid  
2. Configure squid not to connect to one internal server.  
3. Get a internal server. e.g. Apache  
4. Put a Proxy Config File on the Apache, called proxy.pac:  
 function FindProxyForURL(url, host) {  
  
    if ( isInNet(host, "172.16.0.0", "255.255.0.0") )  
    {  
  
        return "DIRECT";  
    }  
  
    if ( isInNet(host, "127.0.0.0", "255.255.0.0") )  
    {  
  
        return "DIRECT";  
    }  
  
    return "PROXY proxy.digitec:8080";  
  
}  
5. Replace 172.16.0.0 and Netmask in the script above to your local ip 
adresses. Replace proxy.digitec:8080 to your squid adress. 
6. Change Proxy Configuration to use http://<internal-server-adress>/proxy.pac 
7. Change Homepage to http://<internal-server-adress> 
8. Restart Mozilla. It shall now display your (internal) Homepage 
9. Connect to www.mozilla.org, you should see the mozilla Homepage. 
10. Ckick on Homepage. You see (after you wait a while) a error from squid. 
 
Actual Results:  
You see (after you wait a while) a error from squid. 

Expected Results:  
Connect to local page and NOT connect to the proxy. 

This is a securtiy problem: The Proxy could be used for a man in the middle  
atack (e.g it is from my Internet-Provider, and i do not trust them). 
 
"Automatic Proxy configuration" is a major feature for our company, so it is a  
(for Digitec) a Major bug.

Comment 1

[Darin Fisher]

yup, i'm able to reproduce the problem as well.  investigating...

Comment 2

[Darin Fisher]

ok, this bug occurs because the DNS service is sometimes giving out IPv6 address
literals as the result of nsIDNSService::Resolve.  this happens when the IP
address is found in the DNS service's cache.  if not in the cache, then the DNS
service just calls PR_GetHostByName, which happily returns an IPv4 address.

iow, on initial load, PAC sees an IPv4 address, on subsequent load, PAC sees an
IPv6 address, and PAC doesn't know how to deal with IPv6 address literals.  in
this case there is no need for the IPv4 address to be expressed as an
IPv4-mapped-IPv6 address.

i'm not sure if isInNet even works with IPv6 address literals.. i'll have to
consult the code a bit more and probably take a peek at the PAC docs.

Comment 3

[Darin Fisher]

FWIW, nsIDNSService::Resolve is only called by PAC, and the PAC code has its own
DNS cache (1-level deep).. so, i think it would be best (in the short term at
least) to simply disable using the DNS service's cache to satisfy the Resolve
method.  patch coming up...

Comment 4

[Darin Fisher]

Attachment: patch: removes cache lookup on Resolve

this patch solves the problem for sites with IPv4 addresses.  i suspect we
still have problems w/ IPv6 addresses.	probably not security problems, since
we should always be handing back an IPv6 address in that case.	however, it
seems that isInNet doesn't handle IPv6 addresses anyways, so sites using IPv6
would presumably be rolling their own somehow or would just be plain broken. 
hmm...

Comment 5

[gordon]

Darin, I'm not getting it.  There shouldn't be any difference between what's in
the DNS cache, and what it would hand out if there wasn't.

Comment 6

[Darin Fisher]

gordon:

nsDNSService::Resolve calls PR_GetHostByName if the DNS cache is empty.
nsDNSService::Lookup calls PR_GetIPNodeByName and converts IPv4 addresses to
IPv4-mapped-IPv6 addresses before putting them in the cache.  as a result,
nsDNSService::Resolve will return IPv6 address if cached, and IPv4 if not cached.

Comment 7

[Bradley Baetz (:bbaetz)]

No, you need the cache. Stuff is really really slow without it, because we do a
synchronous lookup. On a page with lots of images, you have a sync dns lookup
(on the UI thread, IIRC) for every image. See bug 97097. (PAC had a one element
cache at one stage, as a workarround. Not sure if it still does)

Can't we just have IsInNet use the ipv4 address when its a mapped ipv4->ipv6
address, and return false otherwise?

(Theres also a pac function to lookup a dnsname; that should probablly return an
ipv4 address where possible too)

Then file another bug on an ipv6-aware isInNet function.

Comment 8

[Darin Fisher]

bbaetz: we still have the single element cache inside the PAC code :)  at any
rate, you're right... we should just add a conversion in the appropriate place.

Comment 9

[gordon]

darin:

PR_GetHostByName vs. PR_GetIPNodeByName.  Weird.

I guess we updated one of the calls, but not the other.  Almost time for spring
cleaning again...

Comment 10

[benc]

See bug 79242. 

Can I ask why this is marked as a security bug? If you don't trust your ISP
proxy, then you should not use them for anything except HTTPS tunneled via CONNECT:

Are you concerned about the ISP proxy receiving the URL of an internal resource?
There are probably many situations where this happens in PAC and elsewhere, like
bug 40082 #c27.

Comment 11

[Sven Anders]

> Can I ask why this is marked as a security bug? If you don't trust your ISP 
> proxy, then you should not use them for anything except HTTPS tunneled via 
> CONNECT: 
 
How do I do this, if mozilla do not take care about automatic proxy 
configuration? :-) 
 
> Are you concerned about the ISP proxy receiving the URL of an internal 
> resource?  
 
yes. e.g. a user use a programm which sends a session_id which can be also  
used from outside to get information from a server. The User use http,  in  
the internal network (he trust the people there). a bad ISP can get this  
session id and make e.g a "man in the middle attack", or use ist later (if  
the user do not logout).  
 
> There are probably many situations where this happens in PAC and 
> elsewhere, like bug 40082 #c27. 
 
Yes. I know there are more "security-sensitive bugs" out there. Do you think 
it's no security bug, because it happen's all the time? 
 
Sven 

Comment 12

[Brendan Eich [:brendan]]

Comment on attachment 113670 [details] [diff] [review]
patch: removes cache lookup on Resolve

Can we get some reviews, if this patch is worth getting into 1.3final?	If not,
please say so and I'll clear the blocking1.3+ mark.

/be

Comment 13

[Darin Fisher]

Comment on attachment 113670 [details] [diff] [review]
patch: removes cache lookup on Resolve

brendan: no, per comment #7 and comment #8, we don't want this patch if we can
help it.

Comment 14

[Brendan Eich [:brendan]]

What should we do for 1.3?  If the answer is nothing, please retarget to 1.4a
and I'll clear the blocking1.3+ flag.

Separate issue: I don't see why this is a security-sensitive bug.  Mitch, can
you open it up or say why it's sensitive?  Thanks.

/be

Comment 15

[Mitchell Stoltz (not reading bugmail)]

I'm not sure what the security risk is here, but Darin saw one and marked this
Sensitive. Darin, what's the security risk here?

Comment 16

[Darin Fisher]

mitch: no, the bug was reported with the "security-sensitive" flag set.  IMO,
the security risk is small here.  i suppose if you are using a public proxy
server (or one that you don't trust) on the internet for some purpose, and you
have an intranet, it could be bad if URLs from your intranet leaked onto the
internet.  that said, i don't see how someone could really use this to exploit
mozilla users.  at most, this bug is a privacy leak.  does that justify it being
marked security- sensitive?

Comment 17

[Darin Fisher]

i'm not sure we absolutely need to fix this for 1.3 final.  however, i wouldn't
be surprised if a good number of those folks using proxy autoconfig hit this
bug.  IsInNet seems like a function that would show up in a lot of PAC files.

Comment 18

[Asa Dotzler [:asa]]

moving out. 

Comment 19

[Darin Fisher]

Attachment: v2 patch

this patch makes it so that Resolve will never return an IPv4 mapped IPv6
address literal.  it will always return an IPv4 address as an IPv4 address
literal.

Comment 20

[Darin Fisher]

Attachment: v2.1 patch

slightly better version

Comment 21

[Darin Fisher]

*** Bug 140309 has been marked as a duplicate of this bug. ***

Comment 22

[Darin Fisher]

fixed-on-trunk