The WCCP recvfrom() call accepts more data than will fit in
the allocated buffer. An attacker may send a larger-than-normal
WCCP message to Squid and overflow this buffer.
The bug is important because it allows remote attackers to crash
Squid, causing a disription in service. However, the bug is
exploitable only if you have configured Squid to send WCCP messages
to, and expect WCCP replies from, a router.
Sites that do not use WCCP are not vulnerable.
An individual patch for this issues can be found in our
patch archive for version Squid-2.5.STABLE7:
If necessary, this short patch should also apply to previous
versions of Squid.
If you are using a prepackaged version of Squid then please
refer to the package vendor for availability information on
Determining if your version is vulnerable:
Your installation is vulnerable if you have configured Squid to
send WCCP messages to a router, and thus expect replies from a
router. Look for the 'wccp_router' dirctive in your squid.conf
file. Also, look for this line in cache.log:
Accepting WCCP messages on port 2048, FD 15
If WCCP is not essential to your operation, disable it
by commenting out the 'wccp_router' directive in
You may also compile Squid without any WCCP code at all
by giving the --disable-wccp option to the ./configure
Andrew please bump.
The date on squid-2.5.STABLE7-response_splitting.patch seems to have changed also. Did they change the patch?
See squid-2.5.7-r5 patchset 20050201
This one is ready for GLSA.
The patch was changed slightly in squid-2.5.7-r5 patchset 20050201:
< Index: squid/src/store_digest.c
< diff -c squid/src/store_digest.c:1.51 squid/src/store_digest.c:18.104.22.168
< *** squid/src/store_digest.c:1.51 Wed Oct 24 00:55:44 2001
< --- squid/src/store_digest.c Sun Jan 30 18:49:42 2005
< *** 387,392 ****
< --- 387,393 ----
< (long int) e->mem_obj->reply->expires, (int) (e->mem_obj->reply->expires - squid_curtime));
< httpReplySwapOut(e->mem_obj->reply, e);
< + e->mem_obj->reply->hdr_sz = e->mem_obj->inmem_hi;
< eventAdd("storeDigestSwapOutStep", storeDigestSwapOutStep, sd_state.rewrite_lock, 0.0, 1);