Your message dated Thu, 30 Sep 2010 01:57:16 +0000
with message-id <e1p18oa-0001x6...@franck.debian.org>
and subject line Bug#534982: fixed in squid 2.7.STABLE3-4.1lenny1
has caused the Debian Bug report #534982,
regarding squid - DoS in external auth header parser
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
534982: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534982
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: squid
Version: 2.7.STABLE3-4.1
Severity: normal
My main squid reverse proxy suddenly stopped working after some days.
The last time it happened, I managed to dig a bit around and also got a
core dump and analyzed it as far as this works without debugging
symbols. This happened on my own rebuild with SSL enabled, but the
affected code region does not even consider SSL support.
Config excerpt:
| http_port 80 accel vhost defaultsite=example.com
| https_port 443 accel vhost defaultsite=example.com cert=/etc/squid/ssl/all
options=NO_SSLv2
| icp_port 3130
|
| logformat combined %>a %ui %un [%tl] "%rm %ru HTTP/%rv" %Hs %<st %Ss %Sh/%<A
"%{Referer}>h" "%{User-Agent}>h"
| cache_access_log /srv/squid/prod/log/access.log
| cache_access_log /srv/squid/prod/log/combined.log combined
| cache_log /srv/squid/prod/log/cache.log
| cache_store_log /srv/squid/prod/log/store.log
|
| acl accelerated_domains dstdomain example.com
| acl accelerated_protocols proto http https
|
| external_acl_type zope_auth ttl=0 %PATH %{Cookie:;__ac} /etc/squid/auth/auth
/etc/squid/zope_auth.conf
| acl zope_auth external zope_auth
|
| http_access allow accelerated_domains accelerated_protocols zope_auth
| http_access deny all
Available threads:
| (gdb) info threads
| 17 process 17096 0x00002b7100488bc8 in strcspn () from /lib/libc.so.6
| 16 process 17138 0x00002b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 15 process 17137 0x00002b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 14 process 17136 0x00002b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 13 process 17135 0x00002b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 12 process 17134 0x00002b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 11 process 17133 0x00002b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 10 process 17132 0x00002b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 9 process 17131 0x00002b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 8 process 17130 0x00002b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 7 process 17129 0x00002b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 6 process 17128 0x00002b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 5 process 17127 0x00002b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 4 process 17126 0x00002b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 3 process 17125 0x00002b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 2 process 17124 0x00002b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| * 1 process 17123 0x00002b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
So 16 threads suddenly waited for something shared and only the 17th did
something usefull.
Annotated backtrace of thread 17 (I had to reconstruct the function names from
a similar binary):
| (gdb) bt
| #0 0x00002b7100488bc8 in strcspn () from /lib/libc.so.6
| #1 0x0000000000456021 in ?? ()
0000000000455f80 g F .text 0000000000000191 strListGetItem
| #2 0x000000000045395e in ?? ()
00000000004538b0 g F .text 000000000000014a
httpHeaderGetListMember
| #3 0x000000000043923a in ?? ()
0000000000438e60 l F .text 0000000000000648 makeExternalAclKey
| #4 0x0000000000439f6b in ?? ()
0000000000439e70 g F .text 000000000000048c aclMatchExternal
| #5 0x000000000040a24c in ?? ()
0000000000409f30 g F .text 0000000000000eef aclMatchAclList
| #6 0x000000000040ae61 in ?? ()
000000000040ae20 l F .text 000000000000044d aclCheck
| #7 0x000000000042652b in ?? ()
| #8 0x0000000000431105 in ?? ()
| #9 0x00000000004601a0 in ?? ()
| #10 0x00002b710042c1a6 in __libc_start_main () from /lib/libc.so.6
Register dump to show the parameters for strcspn:
| (gdb) info registers
| rax 0x0 0
| rbx 0x199d93d 26859837
| rcx 0x3 3
| rdx 0x199d93d 26859837
| rsi 0x700690 7341712
| rdi 0x199d93d 26859837
| rbp 0x0 0x0
| rsp 0x7fffab99df88 0x7fffab99df88
| r8 0x199d93d 26859837
| r9 0x1 1
| r10 0x353a39353a333220 3835440933431882272
| r11 0x2b71005153a0 47764336628640
| r12 0x7fffab99e130 140736072376624
| r13 0x7fffab99e128 140736072376616
| r14 0x3b 59
| r15 0x7fffab99e13c 140736072376636
| rip 0x2b7100488bc8 0x2b7100488bc8 <strcspn+24>
Parameters are in rsi and rdi:
| (gdb) print {char[5]}0x700690
| $14 = "\";,\000"
| (gdb) print {char[50]}0x199d93d
| $16 = ", 31-Dec-97 23:59:59 GMT; Max-Age=0", '\0' <repeats 14 times>
So it calls
| strcspn("\";,", ", 31-Dec-97 23:59:59 GMT; Max-Age=0")
But suddenly the value starts with ",", which is defined as a field
delimiter in the Cookie-header, but incorrectly used in this case.
More data:
| (gdb) print {char[100]}0x199d910
| $18 = "statusmessages=\"deleted\"; Path=/; Expires=Wed, 31-Dec-97 23:59:59
GMT; Max-Age=0", '\0' <repeats 19 times>
It loops around this strcspn call all the time. As far as I know always
with the same parameters.
Bastian
--
There is an order of things in this universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1
--- End Message ---
--- Begin Message ---
Source: squid
Source-Version: 2.7.STABLE3-4.1lenny1
We believe that the bug you reported is fixed in the latest version of
squid, which is due to be installed in the Debian FTP archive:
squid-cgi_2.7.STABLE3-4.1lenny1_i386.deb
to main/s/squid/squid-cgi_2.7.STABLE3-4.1lenny1_i386.deb
squid-common_2.7.STABLE3-4.1lenny1_all.deb
to main/s/squid/squid-common_2.7.STABLE3-4.1lenny1_all.deb
squid_2.7.STABLE3-4.1lenny1.diff.gz
to main/s/squid/squid_2.7.STABLE3-4.1lenny1.diff.gz
squid_2.7.STABLE3-4.1lenny1.dsc
to main/s/squid/squid_2.7.STABLE3-4.1lenny1.dsc
squid_2.7.STABLE3-4.1lenny1_i386.deb
to main/s/squid/squid_2.7.STABLE3-4.1lenny1_i386.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 534...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Luigi Gangitano <lu...@debian.org> (supplier of updated squid package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.8
Date: Thu, 14 Jan 2010 23:10:06 +0100
Source: squid
Binary: squid squid-common squid-cgi
Architecture: source all i386
Version: 2.7.STABLE3-4.1lenny1
Distribution: stable-security
Urgency: high
Maintainer: Luigi Gangitano <lu...@debian.org>
Changed-By: Luigi Gangitano <lu...@debian.org>
Description:
squid - Internet object cache (WWW proxy cache)
squid-cgi - Squid cache manager CGI program
squid-common - Internet object cache (WWW proxy cache) - common files
Closes: 534982
Changes:
squid (2.7.STABLE3-4.1lenny1) stable-security; urgency=high
.
* Urgency high due to security fixes
.
* debian/patches/71-CVE-2009-2855
- Fix DoS vuln (Ref: CVE-2009-2855)(Closes: #534982)
.
[Steffen Joeris]
* Fix denial of service via invalid DNS header-only packets
Fixes: CVE-2010-0308
Checksums-Sha1:
ab93a45f872d6a2e35331c587d0b10b83e617227 1165 squid_2.7.STABLE3-4.1lenny1.dsc
0c99054d5fd6537da467acbf299ffe5f1a542ae3 1782040 squid_2.7.STABLE3.orig.tar.gz
18646954a58b9429955a7debe953af8294580e74 304919
squid_2.7.STABLE3-4.1lenny1.diff.gz
d3695cc6bb47f272b182e6e7a457aca8e4766e07 493526
squid-common_2.7.STABLE3-4.1lenny1_all.deb
f489a0cfe3b1850928bded323a5561bb2b0a970a 688540
squid_2.7.STABLE3-4.1lenny1_i386.deb
948c43ac408a887055da4925ac5baa83d7f10b77 117732
squid-cgi_2.7.STABLE3-4.1lenny1_i386.deb
Checksums-Sha256:
c3fc3dbe7375a94e6cf26c06c6558333318ba0f438eab0b61780a3d4daa353fe 1165
squid_2.7.STABLE3-4.1lenny1.dsc
d987578c6ca26ca8c8d6fad920580cc39b6ebe95c8ff727b1b6d3c5625fe428d 1782040
squid_2.7.STABLE3.orig.tar.gz
733555967e6cbd9c1b1cc6f6653a4b84b53a819676c7236badbfa58dc328ef47 304919
squid_2.7.STABLE3-4.1lenny1.diff.gz
43069bf07797f0a95e674a1f96deaf5bc22aed687111537e110f8791d7caa9af 493526
squid-common_2.7.STABLE3-4.1lenny1_all.deb
ea094591664aa9b1e2af44e554928ca12333080f302d5b34140849cdcfcd313c 688540
squid_2.7.STABLE3-4.1lenny1_i386.deb
71e23af41990dd19c43c39ff8bdf52b86d906f1409041b942f8ce2cfb95fc6ba 117732
squid-cgi_2.7.STABLE3-4.1lenny1_i386.deb
Files:
3d00959e8a0e1b88d81a1c3bdaef1676 1165 web optional
squid_2.7.STABLE3-4.1lenny1.dsc
a4d7608696e2b617aa5853c7d23e25b0 1782040 web optional
squid_2.7.STABLE3.orig.tar.gz
c9b0294c475b0d3118d25a60e8bb17d1 304919 web optional
squid_2.7.STABLE3-4.1lenny1.diff.gz
812524fc4efa57618ed4d1def3dcc720 493526 web optional
squid-common_2.7.STABLE3-4.1lenny1_all.deb
30387d06ef752feb274c3e3171028296 688540 web optional
squid_2.7.STABLE3-4.1lenny1_i386.deb
ae221ec979f6984ca5ed89b76239df13 117732 web optional
squid-cgi_2.7.STABLE3-4.1lenny1_i386.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAktpcPUACgkQ62zWxYk/rQeR2QCdGpM/AVZGiWPOEzDzNoN8PdJZ
dnEAnj53gWrrg7c+OjHLk2Qts8nmjtUu
=aRrj
-----END PGP SIGNATURE-----
--- End Message ---