A flaw was reported [1] in how Squid parsed responses from Gopher servers. This flaw could result in a buffer overflow if a Gopher server were to return a line longer than 4096 bytes, leading to memory corruption and a crash. This flaw is an extension of SQUID-2005:1 (or CVE-2005-0094) in Squid 3.x, due to increased packet read sizes. A malicious user could setup a fake Gopher server and forward requests to it through Squid. A specially crafted response from that server could cause Squid to restart. This has been corrected in upstream versions 3.2.0.11, 3.1.15, and 3.0.STABLE26. Patches for 3.0 [2], 3.1 [3], and 3.2 [4] are available. [1] http://www.squid-cache.org/Advisories/SQUID-2011_3.txt [2] http://www.squid-cache.org/Versions/v3/3.0/changesets/squid-3.0-9193.patch [3] http://www.squid-cache.org/Versions/v3/3.1/changesets/squid-3.1-10363.patch [4] http://www.squid-cache.org/Versions/v3/3.2/changesets/squid-3.2-11294.patch
Created squid tracking bugs for this issue Affects: fedora-all [bug 734584]
This was assigned the name CVE-2011-3205.
Henrik, is there a reason why your upstream patch duplicates this code? + if (!lpos) { + /* there is no complete line in inbuf */ + /* copy it to temp buffer */ + /* note: llen is adjusted above */ + memcpy(gopherState->buf + gopherState->len, pos, llen); + gopherState->len += llen; + break; + } + if (!lpos) { + /* there is no complete line in inbuf */ + /* copy it to temp buffer */ + /* note: llen is adjusted above */ + memcpy(gopherState->buf + gopherState->len, pos, llen); + gopherState->len += llen; + break; + } It looks harmless, only redundant (albeit probably optimized-out by clever compiler). As you're also quite familiar with the issue, can you confirm that the 2.x vs. 3.x difference is due to read_sz value change in gopherReadReply? Or is that not the reason for the previous fix being incomplete in 3.x?
The duplicated code is a harmless copy-paste error when the change was forward ported from Suqid-2. Now killed. Thanks for noticing! The original patch is http://www.squid-cache.org/Versions/v2/2.HEAD/changesets/12710.patch and is on it's way to Squid-2.7 shortly as a normal maintenance/bugfix patch. And yes, the security issue opened up in Squid-3 due to the change in read buffer size. Both versions failed to parse gopher responses when a line is split over more than one large packet. But only Squid-3 had an buffer overflow. Fixing the line parser fixes both.
Thank you for clarifying / confirming! I've managed to reproduce the overflow, even though it does not trigger crash on RHEL-6 x86. Apparently adjacent BSS memory does not get used by anything important in my test.
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2011:1293 https://rhn.redhat.com/errata/RHSA-2011-1293.html