Re: [squid-users] Squid 3.2.1 is available

On 16.08.2012 09:15, Eliezer Croitoru wrote:
> Downloaded the source from JP mirror and compiled.
> Works like a charm with http interception and http cache_peer.
>
> On 8/15/2012 2:29 PM, Amos Jeffries wrote:
>> * CVE-2009-0801 : NAT interception vulnerability to malicious
>> clients.
> about this "bug" i tried to read about it just of curiosity but i
> didnt understood the actual vulnerability.
> in the bugzilla it states:
> ##start
> Due to Squid not reusing the original destination address on
> intercepted
> requests it's possible (even trivial) for flash or java applets to
> bypass the
> same-origin policy in the browser when Squid intercepts HTTP
> requests.
>
> The cause to this is that such applets are allowed to perform their
> own HTTP
> stack, in which case the same-origin policy of the browser sandbox
> only
> verifies that the applet tries to contact the same IP as from where
> it was
> loaded at the IP level. Squid then uses the Host header to determine
> which
> server to forward the request to which may be different from the
> connected IP.
>
> Applies to all Squid releases.
> ##end
>
> well this is the basic expected behavior of a proxy to verify the
> destination host and NAT interception.
>
> even if the destination IP is not the same as the connected one it
> still validates the same host\domain so what is the problem?

The browser is 100% unaware of the proxies existence and the page being
fetched from a different server than its TCP connection was sent to.
All the IP level security the browser uses to check same-origin is
bypassed silently. All the DNSSEC, IP-based firewall rules, etc which
the LAN administrator may have setup for that client to make use of are
also bypassed silently unless replicated in proxy config.
  I'm not sure which of the two is more serious, but leaning slightly
towards the firewall bypasses being worse nowdays since browsers have
improved their checking a bit too along the same lines as the squid
checks.

It is possible for a website JS (ie advert) to fetch a malicious page
using a benign TCP connection to a safe IP address and a Host: with
malicious server name. The result corrupts the browser cache with a
phishing-style page and gives open access to any private details
(credentials, cookies, local browser state) to the malicious website
server.

The only real solution is to avoid using an interception or transparent
proxy completely (or use it only to bounce clients to a "how to
configure your browser" page as per the ZeroConf wiki example). But the
3.2 changes raise the difficulty for attackers and go a long way towards
avoiding collateral damage to the rest of the LAN clients from such
attacks.

Amos
Received on Wed Aug 15 2012 - 23:38:28 MDT