Bug#534982: squid - DoS in external auth header parser
I see Bug No longer marked as fixed in versions squid/2.7.STABLE7-1 and reopened. above. Is this correct and 2.7.STABLE7 still showing the vulnerable behaviour? Terry: If possible I'd like to see some details of the event, for my interest. Amos Squid Team -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534982: squid - DoS in external auth header parser
reopen 534982 severity 534982 critical This bug has recently hit us hard resulting in repeated DoS of a production web service running on Debian Lenny. What is the intended mitigation strategy for this DoS for users of Debian Stable who rely on Squid support for external_acl_type? For the time being I have had to rebuild appropriately patched squid packages for Lenny to guard against this. Since there will redoubtably be many production web servers running Debian that are vulnerable to CVE-2009-2855 the patch should be backported into the squid packages shipped with Lenny and released through the security repository. Thanks, Terry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534982: squid - DoS in external auth header parser
* Terry Burton: This bug has recently hit us hard resulting in repeated DoS of a production web service running on Debian Lenny. Do you know if this was triggered accidentally or deliberately? Since there will redoubtably be many production web servers running Debian that are vulnerable to CVE-2009-2855 the patch should be backported into the squid packages shipped with Lenny and released through the security repository. Luigi, do you plan to prepare an update for (old)stable? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534982: squid - DoS in external auth header parser
On Wed, Sep 30, 2009 at 5:49 PM, Florian Weimer f...@deneb.enyo.de wrote: * Terry Burton: This bug has recently hit us hard resulting in repeated DoS of a production web service running on Debian Lenny. Do you know if this was triggered accidentally or deliberately? Florian, Probably accidentally, though it may possibly have been deliberate. (I will disclose further information privately as a follow up to this message.) Many thanks, Terry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534982: squid - DoS in external auth header parser
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 0x2b7100488bc8 in strcspn () from /lib/libc.so.6
| 16 process 17138 0x2b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 15 process 17137 0x2b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 14 process 17136 0x2b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 13 process 17135 0x2b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 12 process 17134 0x2b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 11 process 17133 0x2b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 10 process 17132 0x2b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 9 process 17131 0x2b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 8 process 17130 0x2b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 7 process 17129 0x2b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 6 process 17128 0x2b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 5 process 17127 0x2b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 4 process 17126 0x2b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 3 process 17125 0x2b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| 2 process 17124 0x2b70ffd60d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
| * 1 process 17123 0x2b70ffd60d29 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 0x2b7100488bc8 in strcspn () from /lib/libc.so.6
| #1 0x00456021 in ?? ()
00455f80 g F .text 0191 strListGetItem
| #2 0x0045395e in ?? ()
004538b0 g F .text 014a
httpHeaderGetListMember
| #3 0x0043923a in ?? ()
00438e60 l F .text 0648 makeExternalAclKey
| #4 0x00439f6b in ?? ()
00439e70 g F .text 048c aclMatchExternal
| #5 0x0040a24c in ?? ()
00409f30 g F .text 0eef aclMatchAclList
| #6 0x0040ae61 in ?? ()
0040ae20 l F .text 044d aclCheck
| #7 0x0042652b in ?? ()
| #8 0x00431105 in ?? ()
| #9 0x004601a0 in ?? ()
| #10 0x2b710042c1a6 in __libc_start_main () from /lib/libc.so.6
Register dump to show the parameters for strcspn:
| (gdb) info registers
| rax0x0 0
| rbx0x199d93d26859837
| rcx0x3 3
| rdx0x199d93d26859837
| rsi0x700690 7341712
| rdi0x199d93d26859837
| rbp0x0 0x0
| rsp0x7fffab99df88 0x7fffab99df88
| r8 0x199d93d26859837
| r9 0x1 1
| r100x353a39353a333220 3835440933431882272
| r110x2b71005153a0 47764336628640
| r120x7fffab99e130 140736072376624
| r130x7fffab99e128 140736072376616
| r140x3b 59
| r150x7fffab99e13c 140736072376636
| rip0x2b7100488bc8 0x2b7100488bc8 strcspn+24
Parameters are in rsi and rdi:
| (gdb) print {char[5]}0x700690
| $14 = \;,\000
| (gdb)
