Squid Proxy Cache Security Update Advisory SQUID-2016:2 __________________________________________________________________ Advisory ID: SQUID-2016:1 Date: February 23, 2016 Summary: Multiple Denial of Service issues in HTTP Response processing. Affected versions: Squid 3.x -> 3.5.16 Squid 4.x -> 4.0.7 Fixed in version: Squid 4.0.7, 3.5.15 __________________________________________________________________ http://www.squid-cache.org/Advisories/SQUID-2016_2.txt __________________________________________________________________ Problem Description: Due to incorrect bounds checking Squid is vulnerable to a denial of service attack when processing HTTP responses. Due to incorrect error handling Squid-4 is vulnerable to a denial of service attack when processing malformed HTTP responses. __________________________________________________________________ Severity: These problems allow remote servers delivering certain unusual HTTP response syntax to trigger a denial of service for all clients accessing the Squid service. HTTP responses containing malformed headers that trigger this issue are becoming common. We are not certain at this time if that is a sign of malware or just broken server scripting. Details of a trivial attack are already circulating publicly. __________________________________________________________________ Updated Packages: These bugs are fixed by Squid version 3.5.15 and 4.0.7. In addition, patches addressing these problems for the stable release can be found in our patch archives: Squid 3.5: http://www.squid-cache.org/Versions/v3/3.5/changesets/squid-3.5-13990.patch http://www.squid-cache.org/Versions/v3/3.5/changesets/squid-3.5-13991.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: All Squid-3.2 and older have not been tested but are expected to be vulnerable. All unpatched Squid-3.3 versions are vulnerable. All unpatched Squid-3.4 versions are vulnerable. All unpatched Squid-3.5.14 and older are vulnerable. All unpatched Squid-4.0.6 and older are vulnerable. __________________________________________________________________ Workaround: There are no good workarounds known for these vulnerabilities. The following squid.conf settings can protect Squid-3.5 (only) against the publicly published attack. But unpatched Squid remain vulnerable to other known attacks: acl Vary rep_header Vary . store_miss deny Vary Or, The following squid.conf settings can protect against the publicly published attack. But unpatched Squid remain vulnerable to other known attacks: cache deny all __________________________________________________________________ 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@lists.squid-cache.org 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://bugs.squid-cache.org/>. For reporting of security sensitive bugs send an email to the squid-bugs@lists.squid-cache.org 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: The bounds checking vulnerability was identified and reported by Mathias Fischer from Open Systems AG. The bounds checking vulnerability was fixed by Alex Rousskov from The Measurement Factory. The error handling vulnerability was found and fixed by Alex Rousskov from The Measurement Factory. __________________________________________________________________ Revision history: 2016-02-17 06:51:25 UTC Initial Report 2016-02-18 04:15:33 UTC Patches Released 2016-02-19 23:15:41 UTC Additional Patches Released 2016-02-23 16:37:27 UTC Attack PoC becomes public knowledge 2016-02-23 18:23:00 UTC Packages Released __________________________________________________________________ END
net-proxy/squid-3.5.15 added to the tree. Arches, please test and mark stable =net-proxy/squid-3.5.15 Target Keywords = alpha amd64 arm hppa ia64 ~mips ppc ppc64 sparc x86 ~x86-fbsd
Stable for HPPA PPC64.
amd64 stable
arm stable
x86 stable
Stable on alpha.
ppc stable
sparc stable
ia64 stable. Maintainer(s), please cleanup. Security, please vote.
Arches, Thank you for your work. New GLSA Request filed. Maintainer(s), please drop the vulnerable version(s).
CVE-2016-2572 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-2572): http.cc in Squid 4.x before 4.0.7 relies on the HTTP status code after a response-parsing failure, which allows remote HTTP servers to cause a denial of service (assertion failure and daemon exit) via a malformed response. CVE-2016-2571 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-2571): http.cc in Squid 3.x before 3.5.15 and 4.x before 4.0.7 proceeds with the storage of certain data after a response-parsing failure, which allows remote HTTP servers to cause a denial of service (assertion failure and daemon exit) via a malformed response. CVE-2016-2570 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-2570): The Edge Side Includes (ESI) parser in Squid 3.x before 3.5.15 and 4.x before 4.0.7 does not check buffer limits during XML parsing, which allows remote HTTP servers to cause a denial of service (assertion failure and daemon exit) via a crafted XML document, related to esi/CustomParser.cc and esi/CustomParser.h. CVE-2016-2569 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-2569): Squid 3.x before 3.5.15 and 4.x before 4.0.7 does not properly append data to String objects, which allows remote servers to cause a denial of service (assertion failure and daemon exit) via a long string, as demonstrated by a crafted HTTP Vary header.
This issue was resolved and addressed in GLSA 201607-01 at https://security.gentoo.org/glsa/201607-01 by GLSA coordinator Aaron Bauman (b-man).