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
