CVE-2009-0801 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-0801): 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.
Check if squid-3.0.14 fixes that.
No, (with my release maintainer hat on) * 3.0 is not going to have a fix for that. * 3.1 has a very low chance for a fix. Why: the re-coding to fix it is very intrusive at critical part of the request processing and causes too much instability. Hope is still around for a fix in a development release (ie 3.2), but some expertise is needed to do it right.
3.2 is fixed, in release 3.2.0.11 Here is a patch for 3.1: http://www.squid-cache.org/~amosjeffries/patches/squid-3.1_CVE-2009-0801.patch My correspondence on the issue, with one of the more-active devs: From: Amos Jeffries <squid3@treenet.co.nz> To: John Hardin <jhardin@impsec.org> Date: Mon, 29 Aug 2011 08:47:00 +1200 On 29/08/11 07:06, John Hardin wrote: > On Mon, 29 Aug 2011, Amos Jeffries wrote: > > > __________________________________________________________________ > > > > Squid Proxy Cache Security Update Advisory SQUID-2011:1 > > __________________________________________________________________ > > > > Advisory ID: SQUID-2011:1 > > Date: August 27, 2011 > > Summary: Bypass of browser same-origin access > > control in intercepted communication > > Affected versions: Squid 1.x -> 3.1 > > Squid 3.2 -> 3.2.0.10 > > Fixed in version: Squid 3.2.0.11 > > __________________________________________________________________ > > > > http://www.squid-cache.org/Advisories/SQUID-2011_1.txt > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=2009-0801 > > __________________________________________________________________ > > Will this be fixed in the 3.1.x series? > Possibly. Of itself the change ports easily and does what its supposed to. The blocker problem is NAT reliability. * Linux works. * IPFW seems broken, with nobody around able to assist testing/fixing it. * IPF same deal. * PF 3.x seem to work (ie NetBSD, FreeBSD). * PF 4.x do not have Squid support at all. ie OpenBSD and children. * IPFilter seems obsolete. nobody admits to using it. If you would like to test it despite all that worry here is a 3.1 patch: http://www.squid-cache.org/~amosjeffries/patches/squid-3.1_CVE-2009-0801.patch Any feedback welcome. Particularly if you hit any more legit software doing bad things. Amos
Addendum to John Hardins update. You can ignore my comment 2 now. The final approach is radically different to what was being planned in 2009 and seems to work even better than the original design :) just that NAT stumbling block, which may not affect Gentoo. There is another issue I raised in the release announcement. Legitimate software mangling its own header output in ways that don't validate. I have not yet decided on how long a period to allow for 3.2 series users to flush this kind of problem out.
An updated version of the patch with a lot more testing is now available at: http://www.squid-cache.org/Versions/v3/3.1/changesets/squid-3.1-host-verify.patch This will do the Host header verification checks and raise the bar on attack difficulty. It does not include the destination IP pinning which depends on design changes in 3.2. So is not a full fix.
(In reply to comment #5) > An updated version of the patch with a lot more testing is now available at: > http://www.squid-cache.org/Versions/v3/3.1/changesets/squid-3.1-host-verify.patch > > This will do the Host header verification checks and raise the bar on attack > difficulty. It does not include the destination IP pinning which depends on > design changes in 3.2. So is not a full fix. @net-proxy, is this patch appropriate to include in our version of 3.1? Thanks.
According to upstream(http://bugs.squid-cache.org/show_bug.cgi?id=3243) this was fixed in 3.2 which is already marked stable Adding to existing GLSA draft
This issue was resolved and addressed in GLSA 201309-22 at http://security.gentoo.org/glsa/glsa-201309-22.xml by GLSA coordinator Sergey Popov (pinkbyte).
