[squid-users] CVE-2009-0801

[dc]

Thank you very much for this detailed explanation!

I have a setup where squid doesn't know about the original destination
IP address, so I tried to enforce using DNS responses as destination
addresses for any request, without success. Looking at the relevant code
I found the limitation (and CVE) to be quite obscure, but now I know why
it's there.
Since the vulnerability can't be exploited in my case anyway, I have
altered the code to allow the replacement of the destination address
regardless of a mismatch of the original dst.

Best regards
Nikolaus

Am 18.12.2015 um 23:14 schrieb Amos Jeffries:
>
> The problem(s):
>
> With CVE-2009-0801 the ORIGINAL_DST signals arriving at Squid look like
> TCP IP:port for some ServerA.example.net domain. But the HTTP message
> contains something different like:
>
>  GET /logo.jpg HTTP/1.1
>  Host: attacker.example.com
>
> The browser Same-Origin and sandbox Origin security protections ensure
> that sandboxed scripts can only open TCP connections to the same origin
> server(s) they are scoped for. But scripts can send any header values
> they like, including fake Host on that connection once it is open.
>
> If Squid were to use the Host header to route the message in any
> situation where the ORIGINAL_DST details do not match the Host DNS
> records. Then Squid would be fetching and delivering some content into a
> browser sandbox from a server that sandbox did not permit.
>
> The fix for that is to simply fetch form the ORIGINAL_DST server
> IP:port. Acting as if the proxy were not there.
>
> BUT ... the proxy actually is there, so the cache has to be accounted
> for. That stores things by URL. This causes Vuln #2 below if we use the
> Host value as domain name like it is supposed to be. And if we don't the
> proxy outgoing Host header is mandatory to re-write to the URL host
> portion. Meaning the outbound traffic would have raw-IP:port for the
> domain name.
>
>
> Vuln #2:  the attacker script can cause hijacking of popular content
> URLs simply by fetching the above request from its own malicious server
> with Host:google.com.
> [no CVE for this bit since no published Squid was ever vulnerable].
>
> This is not just bypassing the its own sandbox protection, but causing
> its attack payload to be delivered in future to another sandbox (on its
> own machine OR any other machine using the proxy) in the followup proxy
> cache HITs. That payload has escaped its own origin sandbox and now runs
> with whatever permissions and data access the victims domain normally
> has access to (plus the ability to jump again buy hijacking any of that
> sandboxes valid servers/URLs).
>
> The fix we chose to use is not to cache anything where the Host vs DNS
> is not matching.
>
> BUT ... PAIN ... it turns out rather a *lot* of content have been using
> systems where the Host and origin server DNS do not match all the time.
> Everything using Akamai CDN, Google web hosting, Geo-based DNS services,
> so called "client-based HTTP routing" as done by some popular AV
> vendors, and many other smaller sites for odd reasons. Or at least they
> dont match when the DNS is looked up through two different DNS routing
> paths.
>
>
> The alternative would be to use raw-IP port on the URL and outgoing Host
> value. That latter is mandatory but breaks Virtual Hosting on these
> messages. Given the particular providers whose actions cause the pain;
> breaking virtual hosting would be far worse than not caching. The common
> cases are anyway low-HIT content or major providers with high speed
> networks (very low MISS latency).
>
> So the fix we use is to verify the DNS and Host details match. Only
> allowing cache storage and/or Host message routing when they do.
>
>
> This still leaves us with pain in all those situations where non-match
> happens. There are no fixes for that, just workarounds to iprove the
> chances of matching.
>
>
> PS. The two vulnerabilities have been known about since at least 1990's.
> The original choice was to leave the CVE-2009-0801 behaviour happening
> to improve caching (and same-origin, sandbox etc did not exist back
> then). But nowdays the browser protections do exist, and in 2009 active
> malware was found using the proxy behaviour to escape it. So the CVE got
> allocated and we had to fix. Opening the second vulnerability was never
> an option, so we are where we are now.
>
>
> PPS. ideas or attempts at resolving the HIT side effect is welcome. Just
> be aware that every attempt so far has lead to one or other
> vulnerability being re-opened and neither is acceptible behaviour. So
> having what appears to be a good idea shot down and rejected is normal
> when attacking this problem (it took a good year to get the fix as far
> as it is).
>
> Amos
>