Red Hat Bugzilla – Bug 488502
CVE-2009-0801 squid: remote bypass of access controls
Last modified: 2017-03-13 08:00:27 EDT
Common Vulnerabilities and Exposures assigned an identifier CVE-2009-0801 to
the following vulnerability:
Reference: URL: http://www.kb.cert.org/vuls/id/435052
Reference: URL: http://www.securityfocus.com/bid/33858
Squid, when transparent interception mode is enabled, uses the HTTP
Host header to determine the remote endpoint, which allows remote
attackers to bypass access controls for Flash, Java, Silverlight, and
probably other technologies, and possibly communicate with restricted
intranet sites, via a crafted web page that causes a client to send
HTTP requests with a modified Host header.
Some additional references:
And some additional notes:
As in most matters there is a tradeoff between efficienty, simplicity and "security" in this matter.
Imho (as an individual) the main security flaw is allowing untrusted "applets" direct network access bypassing the HTTP stack of the browser they run within. Having a browser plugin implement their own HTTP stack is...
From what I can see, there is still no upstream fix for this.
This is being tracked upstream here:
Created attachment 515548 [details]
Upstream has corrected this in 184.108.40.206:
Regarding older squid versions, the advisory states:
"Due to the design of request handling processes in older Squid patches and fixed releases for older versions of Squid are not being provided at this time."
Upstream bug also indicates that the fix is not backportable to pre-3.2 versions, as it depends on other internal changes done during the 3.2 development. SQUID-2011:1 is less clear, as it says upstream does not provide any backports to older version as this time, not saying if it's planned for the future.
As for patch in comment #6, it seems incomplete and missing all the hostHeaderVerify() code.
Henrik, do you know of any good place that describes what checks exactly are now performed by Squid? Based on my reading so far, it seems the core is the check of client TCP connection destination IP / port against HTTP header info for consistency. Though I don't think that info is always available to Squid (e.g. when connections are dnat-ed to proxy from gateway host). Any pointer or corrections are appreciated.
(In reply to comment #6)
> Created attachment 515548 [details]
> Upstream patch
This seems to be:
While these are also part of the fix:
Release notes change with some brief info:
I have not kept a close eye on these changs. If you need some clarification I think the best is to post your question to firstname.lastname@example.org.
As you correctly note this won't work at all if you DNAT externally to the Squid box as you then overwrite the original destination IP:port irrecoverably. Such setups is considered broken and have always been. Better to use policy routing and do the IP interception on the Squid box preserving data properly (i.e. WCCP, route maps, policy routes etc on the gateway..)
Fedora 16+ have 220.127.116.11, which contains the fix.