Hi, Amos > Workarounds: > > Using all of the following steps are required to protect a > vulnerable Squid from this and other forms of DNS attack. > > * Ensuring the ignore_unknown_nameservers is turned on. > > * Ensuring that DNS packets cannot be sent to Squid from > untrusted nameservers or other machines. > > The most secure implementation of these requirements is to use > a nameserver running on the localhost IP dedicated for secure use > by Squid and any other services on the Squid machine. I'd like to make sure above. "The most secure implementation" mean that - The ignore_unknown_nameservers is turned on (default) - The /etc/resolv.conf on squid server is following nameserver 127.0.0.1 - The localhost nameserver on squid server is just only cache server which is like BIND. Is is correct ? Sincerely, -- Mikio Kishi On Tue, Feb 2, 2010 at 7:33 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > CHANGES from previous advisory: > * Corrected Squid-3.0 patch and release details. > > __________________________________________________________________ > > Squid Proxy Cache Security Update Advisory SQUID-2010:1 > __________________________________________________________________ > > Advisory ID: SQUID-2010:1 > Date: January 28, 2010 > Summary: Denial of Service issue in DNS handling > Affected versions: Squid 2.x, > Squid 3.0 -> 3.0.STABLE22, > Squid 3.1 -> 3.1.0.15 > Fixed in version: Squid 3.0.STABLE23, 3.1.0.16 > __________________________________________________________________ > > http://www.squid-cache.org/Advisories/SQUID-2010_1.txt > __________________________________________________________________ > > Problem Description: > > Due to incorrect data validation Squid is vulnerable to a denial > of service attack when processing specially crafted DNS packets. > > __________________________________________________________________ > > Severity: > > This problem allows any trusted client or external server who can > determine the squid receiving port to perform a short-term denial > of service attack on the Squid service. > > __________________________________________________________________ > > Updated Packages: > > This bug is fixed by Squid versions 3.0.STABLE23 and 3.1.0.16 > > In addition, patches addressing these problems can be found In > our patch archives. > > Squid 2.x: > http://www.squid-cache.org/Versions/v2/HEAD/changesets/12597.patch > > Squid 3.0: > http://www.squid-cache.org/Versions/v3/3.0/changesets/squid-3.0-9163.patch > > Squid 3.1: > http://www.squid-cache.org/Versions/v3/3.1/changesets/squid-3.1-9853.patch > > If you are using a prepackaged version of Squid then please refer > to the package vendor for availability information on updated > packages. > > __________________________________________________________________ > > Determining if your version is vulnerable: > > Squid still using the obsolete dnsserver are not vulnerable. > > The ignore_unknown_nameservers option affects the severity of > this vulnerability. When set to "on" (the default) risk is low. > When set to "off" the vulnerability risk is increased. > > All unpatched Squid-3.0 versions up to and including 3.0.STABLE22 > are vulnerable. > > All unpatched Squid-3.1 versions up to and including 3.1.0.15 are > vulnerable. > > All unpatched Squid-2.x versions are vulnerable. > > __________________________________________________________________ > > Workarounds: > > Using all of the following steps are required to protect a > vulnerable Squid from this and other forms of DNS attack. > > * Ensuring the ignore_unknown_nameservers is turned on. > > * Ensuring that DNS packets cannot be sent to Squid from > untrusted nameservers or other machines. > > The most secure implementation of these requirements is to use > a nameserver running on the localhost IP dedicated for secure use > by Squid and any other services on the Squid machine. > __________________________________________________________________ > > Contact details for the Squid project: > > For installation / upgrade support on binary packaged versions > of Squid: Your first point of contact should be your binary > package vendor. > > If your install and build Squid from the original Squid sources > then the squid-users@xxxxxxxxxxxxxxx mailing list is your primary > support point. For subscription details see > <http://www.squid-cache.org/Support/mailing-lists.html>. > > For reporting of non-security bugs in the latest STABLE release > the squid bugzilla database should be used > <http://www.squid-cache.org/bugs/>. > > For reporting of security sensitive bugs send an email to the > squid-bugs@xxxxxxxxxxxxxxx mailing list. It's a closed list > (though anyone can post) and security related bug reports are > treated in confidence until the impact has been established. > > __________________________________________________________________ > > Credits: > > Zero-Day attributed to work by Fabian Yamaguchi. > > The vulnerability was reported by Tomas Hoger of RedHat. > > __________________________________________________________________ > > Revision history: > > 2010-01-14 18:05 GMT Initial Report > 2010-01-16 03:51 GMT Patches released. > 2010-02-01 04:49 GMT Squid-3 bundled fixes and advisory released. > 2010-02-02 07:42 GMT Updated 3.0 patch and bundle > __________________________________________________________________ > END >
