Re: CVE-2009-0801

Emilio Casbas wrote:
> Kinkie escribió:
>> On Tue, Mar 17, 2009 at 2:19 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
>>
>>> Basically: Host header forgery meets interception.
>>>
>>> What ideas/patches do we have floating around to solve it? I understand it's
>>> an old problem.
>>>
>>> I'm throwing together a patch to verify the received dst IP is in the rDNS
>>> for the Host: domain. But that's only raising the bar of difficulty, not
>>> closing the hole.
>>>
> Same approach that SmootWhall is taking.
> http://www.kb.cert.org/vuls/id/MAPG-7M6SM7

Sounds like it is, yes.

I have however hit a snag or two:
  the place it currently needs to be done is in a branch off the
prepareTransparentUrl() function. And it also must be an async process
due to the rDNS lookup involved.

However the big snag comes with the grandparent caller of
prepareTransparentUrl() being clientParseRequest() with its looping
parse attempts and two exit states: hard fail or hard success.
There is also a LOT of code processing between prepareTransparentURL()
and the nearest earlier callback re-start point.

I think the good patch will take some major work to clean up the client
request parsing into a loose stateful context before it can be used.

One alternative I can see is to shift the whole prepare*Url() URI
modification to the first entry in ClientRequestContext::doCallouts().

The lesser snag here is an unknown quantity of code which require
http->uri before the doCallouts is run.

Anyone able to help point me in the right direction?

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE13
   Current Beta Squid 3.1.0.6