SQUID-2016_4 below; see also SQUID-2016_3.
Squid Proxy Cache Security Update Advisory SQUID-2016:4
Advisory ID: SQUID-2016:4
Date: April 02, 2016
Summary: Denial of Service issue
in HTTP Response processing.
Affected versions: Squid 3.x -> 3.5.15
Squid 4.x -> 4.0.7
Fixed in version: Squid 4.0.8, 3.5.16
Due to incorrect bounds checking Squid is vulnerable to a denial
of service attack when processing HTTP responses.
This problem allows a malicious client script and remote server
delivering certain unusual HTTP response syntax to trigger a
denial of service for all clients accessing the Squid service.
This bug is fixed by Squid version 3.5.16 and 4.0.8.
In addition, a patch addressing this problem for the stable
release can be found in our patch archives:
If you are using a prepackaged version of Squid then please refer
to the package vendor for availability information on updated
Determining if your version is vulnerable:
All unpatched Squid-3.0 versions are vulnerable.
All unpatched Squid-3.1 versions are vulnerable.
All unpatched Squid-3.2 versions are vulnerable.
All unpatched Squid-3.3 versions are vulnerable.
All unpatched Squid-3.4 versions are vulnerable.
All unpatched Squid-3.5 up to and including Squid-3.5.15 are
All unpatched Squid-4.0 up to and including 4.0.7 are vulnerable.
There are no good workarounds known for this vulnerability.
The following squid.conf settings can protect Squid-3.5 (only):
acl Vary rep_header Vary .
store_miss deny Vary
The following squid.conf setting can protect Squid-3.0 or later:
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
If your install and build Squid from the original Squid sources
then the email@example.com mailing list is your
primary support point. For subscription details see
For reporting of non-security bugs in the latest STABLE release
the squid bugzilla database should be used
For reporting of security sensitive bugs send an email to the
firstname.lastname@example.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.
This vulnerability was reported by Santiago R. Rincon of Debian.
Fixed by Amos Jeffries from Treehouse Networks Ltd.
2016-03-20 11:25:04 UTC Initial Report
2016-04-01 06:15:31 UTC Patch Released
@maintainer, please bump to 3.5.16. 4.x beta series is not in the tree yet.
@arches, please stabilize:
The mailing list has some interesting thread regarding 3.5.16:
Maybe we should take that into account.
Yes. The upstream patch http://www.squid-cache.org/Versions/v3/3.5/changesets/squid-3.5-14022.patch is also needed to resolve that minor regression in these CVE patches.
Arches, please stabilize
Target Keywords = alpha amd64 arm hppa ia64 ~mips ppc ppc64 sparc x86 ~x86-fbsd
This is confusing.
(In reply to Jeroen Roovers from comment #7)
> This is confusing.
3.5.16 came out as a security release, but it had a known and reported bug, so we needed to release 3.5.16-r1. While doing that, 3.5.17 as another security release came out.
(In reply to Tomáš Mózes from comment #8)
> (In reply to Jeroen Roovers from comment #7)
> > This is confusing.
> 3.5.16 came out as a security release, but it had a known and reported bug,
> so we needed to release 3.5.16-r1. While doing that, 3.5.17 as another
> security release came out.
That's nice, but why is this stable request still out when a newer version is also going stable, is what I was trying to suggest.
Yeah, I see your point. This stabilization should be stopped because this release is vulnerable and will be dropped anyway.
Squid 3.x before 3.5.16 and 4.x before 4.0.8 improperly perform bounds
checking, which allows remote attackers to cause a denial of service via a
crafted HTTP response, related to Vary headers.
Heap-based buffer overflow in the Icmp6::Recv function in icmp/Icmp6.cc in
the pinger utility in Squid before 3.5.16 and 4.x before 4.0.8 allows remote
servers to cause a denial of service (performance degradation or transition
failures) or write sensitive information to log files via an ICMPv6 packet.
Added to existing GLSA.
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).