Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 261208 (CVE-2009-0801) - <net-proxy/squid-3.2 access control bypass (CVE-2009-0801)
Summary: <net-proxy/squid-3.2 access control bypass (CVE-2009-0801)
Status: RESOLVED FIXED
Alias: CVE-2009-0801
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High minor with 1 vote (vote)
Assignee: Gentoo Security
URL: http://www.kb.cert.org/vuls/id/435052
Whiteboard: B4 [glsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-04 18:41 UTC by Stefan Behte (RETIRED)
Modified: 2013-09-27 09:52 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Behte (RETIRED) gentoo-dev Security 2009-03-04 18:41:37 UTC
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.
Comment 1 Alin Năstac (RETIRED) gentoo-dev 2009-04-15 21:33:21 UTC
Check if squid-3.0.14 fixes that.
Comment 2 Amos Jeffries 2009-04-19 03:28:11 UTC
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.
Comment 3 John Hardin 2011-08-29 02:40:23 UTC
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
Comment 4 Amos Jeffries 2011-08-29 11:02:31 UTC
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.
Comment 5 Amos Jeffries 2011-10-15 06:38:07 UTC
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.
Comment 6 Tim Sammut (RETIRED) gentoo-dev 2011-10-15 23:52:10 UTC
(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.
Comment 7 Sergey Popov gentoo-dev Security 2013-09-24 16:02:06 UTC
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
Comment 8 GLSAMaker/CVETool Bot gentoo-dev 2013-09-27 09:52:08 UTC
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).