Alex Rousskov
Tue, 19 Jan 2010 15:50:47 -0800
On 01/19/2010 03:38 PM, Amos Jeffries wrote: > On Tue, 19 Jan 2010 11:04:42 -0700, Alex Rousskov > <rouss...@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 > <squ...@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.