Re: Squid DNS weaknesses reported on 26C3

On 01/19/2010 03:38 PM, Amos Jeffries wrote:
> On Tue, 19 Jan 2010 11:04:42 -0700, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:
>> On 01/15/2010 04:53 AM, Amos Jeffries wrote:
>>> Tomas Hoger wrote:
>>>> Hi Amos!
>>>>
>>>> On Fri, 15 Jan 2010 14:08:24 +1300 Amos Jeffries
> <squid3_at_treenet.co.nz>
>>>> wrote:
>>>>
>>>>> Thank you for pointing this out.
>>>> You're welcome.
>>>>
>>>>> Disappointingly, Fabian Yamaguchi has not mentioned anything about
>>>>> squid exploits to us prior to his publication either. It's not clear
>>>>> what version of Squid he was talking about. The code I've got all
>>>>> checks the DNS port constantly and discards unwanted packets
>>>>> immediately.
>>>> In my test, I'm using squid 3.1.0.15, which does not get any other
>>>> requests. Spoofed packet I send to it only is processed when I do
> some
>>>> other request to squid, which triggers DNS resolution.
>>>>
>>>>> Are you in any way able to test the header-only DNS attack he talked
>>>>> about? I have a patch now to remove the assertion but require
>>>>> confirmation that it will fix the DoS vulnerability without other
>>>>> side effects.
>>>> Attaching my test script. It takes host and (squid's DNS) port as an
>>>> argument and sends one header-only packet to it. For testing
> purposes,
>>>> I added "ignore_unknown_nameservers off" to squid.conf file so I don't
>>>> need to spoof source IP. After sending the packet, I do a normal
>>>> request to trigger processing of the packet, as mentioned above.
>>>>
>>>> HTH
>>>>
>>> Thank you very much. That helped a lot. I've now duplicated the
>>> assertion and verified the fix works.
>>>
>>> I'm dubbing the header-only issue SQUID-2010:1. An advisory will come
>>> out with the next release(s).
>>>
>>> The fix is already in 3.HEAD and 2.HEAD:
>>>
> http://west.squid-cache.org/Versions/v3/HEAD/changesets/squid-3-10235.patch
>>> http://west.squid-cache.org/Versions/v2/HEAD/changesets/12597.patch
>>>
>>> The other issues of Squid not actively reading the DNS port will take
>>> some time to sort out a good fix.

>> The source port randomization is also questionable (at least if it
>> becomes the only supported behavior) because it may have a noticeable
>> performance impact in busy environments. Many Squids are configured to
>> use dedicated private name servers and if that environment is properly
>> secured, there is no need to protect Squid from spoofing and similar DNS
>> attacks.
>>
>> Should this discussion be moved to squid-dev?
>>
>
> Mayhap. Not quite ready for a loud mention though.
>
> The fix I have been contemplating for the remaining issues is to test out
> how the new AcceptFD infrastructure handles UDP. Using that on the DNS port
> should resolve the sleeping issues.
>
> The previously discussed dns_outgoing_address option can be added easily
> to set the IP:port absolutely or partially (fixed IP + random port or fixed
> port + default IP). IMHO it may increase the vulnerability from the sleep
> if added by itself (removes the weak but working security-by-obscurity
> filter). If anyone is willing to disagree I'm open to a patch adding the
> option to 3.1 now (deadline Jan 28 anyway).

I think the concerned folks want random source port per packet, not per
Squid invocation so adding an option to set the port explicitly would
not help them. Supporting random-per-packet source ports is the
performance-heavy feature I was discussing above.

Cheers,

Alex.
Received on Tue Jan 19 2010 - 23:49:20 MST