Bug 488502 (CVE-2009-0801) - CVE-2009-0801 squid: remote bypass of access controls
Summary: CVE-2009-0801 squid: remote bypass of access controls
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2009-0801
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL: http://web.nvd.nist.gov/view/vuln/det...
Whiteboard:
Depends On: 488503 488504 488505 488506 488507 488508 865991 1303061
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-03-04 17:51 UTC by Vincent Danen
Modified: 2019-09-29 12:28 UTC (History)
4 users (show)

Fixed In Version: squid 3.2.0.11
Doc Type: Bug Fix
Doc Text:
It was found that when transparent interception mode was enabled in squid a remote attacker could bypass access controls implemented for certain web elements like Flash and Java and communicate with restricted intranet sites via crafted Host headers.
Clone Of:
Environment:
Last Closed: 2016-04-07 11:17:10 UTC


Attachments (Terms of Use)
Upstream patch (4.92 KB, patch)
2011-07-27 15:39 UTC, Josh Bressers
no flags Details | Diff

Description Vincent Danen 2009-03-04 17:51:01 UTC
Common Vulnerabilities and Exposures assigned an identifier CVE-2009-0801 to
the following vulnerability:

Name: CVE-2009-0801
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0801
Assigned: 20090304
Reference: CERT-VN:VU#435052
Reference: URL: http://www.kb.cert.org/vuls/id/435052
Reference: BID:33858
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.

Comment 2 Vincent Danen 2009-03-04 17:57:27 UTC
Some additional references:

http://www.theregister.co.uk/2009/02/23/serious_proxy_server_flaw/
http://marc.info/?l=squid-dev&m=123542836103750&w=4

And some additional notes:

This seems to have low impact due to a user having to visit a malicious untrusted site to load active content, or to load malicious active content from a trusted site.  It only affects proxies in transparent mode and same-origin policies in browsers should prevent an attacker from re-using auth credentials like cookies, and does NOT affect proxies in reverse mode (active content being flash or javascript). As well, this should only be able to affect regular HTTP connections since HTTPS does not use Host headers.  There are some good comments on theregister (#8 and #9) that discuss why this may not be overly serious in real-world use.  Also, there is nothing yet from the squid devs.

Comment 3 Henrik Nordström 2009-03-05 12:39:10 UTC
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...

Comment 4 Vincent Danen 2009-12-04 22:25:04 UTC
From what I can see, there is still no upstream fix for this.

Comment 5 Josh Bressers 2011-07-27 15:32:15 UTC
This is being tracked upstream here:
http://bugs.squid-cache.org/show_bug.cgi?id=3243

Comment 6 Josh Bressers 2011-07-27 15:39:44 UTC
Created attachment 515548 [details]
Upstream patch

Comment 7 Josh Bressers 2011-07-27 15:44:30 UTC
Statement:

(none)

Comment 8 Vincent Danen 2011-08-30 17:55:12 UTC
Upstream has corrected this in 3.2.0.11:

http://www.squid-cache.org/Advisories/SQUID-2011_1.txt

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."

Comment 9 Tomas Hoger 2011-08-31 17:20:37 UTC
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.

Comment 11 Henrik Nordström 2011-08-31 20:39:00 UTC
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 squid-dev@squid-cache.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..)

Comment 13 Vincent Danen 2012-05-28 15:41:53 UTC
Fedora 16+ have 3.2.0.16, which contains the fix.


Note You need to log in before you can comment on or make changes to this bug.