lighttpd-1.4.19 and earlier contain a bug which can be exploited by a malicious user to forcefully close foreign SSL connections. To exploit this, the server has to have SSL support enabled and the attacker has to trigger an SSL error on his own connection (connecting and disconnecting before the download has finished is enough). Original ticket: http://trac.lighttpd.net/trac/ticket/285#comment:19 Fix: http://trac.lighttpd.net/trac/changeset/2136 lighttpd-1.4.19 was supposed to fix the problem, but the fix did not work as expected, so it is still vulnerable. The damage, which can be caused by this bug is rather low, I'd say: Firstly, users can simply reconnect after their connection has been killed, and secondly, it is hard for an attacker to meet the exact point of time to crash a user's connection, it is mostly a problem when there are longer-pending connections such as downloads or keepalive.
1.4.19-r1 is in the tree
Arches, please test and mark stable: =www-servers/lighttpd-1.4.19-r1 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 release sh sparc x86"
amd64/x86 stable
I fail, sorry. The fix does not seem completely right again... it makes lighty enter some kind of infinite loop in case of SSL errors, printing lots of SSL error messages and consuming lots of CPU. Working on it. Drop stable again? p.mask?
amd64, x86, please read above.
amd64/x86 unstable :)
bangert, I commented on the upstream ticket [1] with a possible new patch against 1.4.19 [2]. It works fine for me, but I'd rather have the OK from a lighty dev (they've been very responsive today, so I think we should get one pretty soon). Sorry again for all the confusion and b0rkage. :( [1] http://trac.lighttpd.net/trac/ticket/285#comment:21 [2] http://trac.lighttpd.net/trac/attachment/ticket/285/06_all_lighttpd-1.4.19-closing_foreign_ssl_connections-dos.diff
http://trac.lighttpd.net/trac/ticket/1601 should be taken in account too :)
Bertrand, thanks for the pointer, I saw that one already and I don't think it should be considered a vulnerability. It's a bug that lighty does not handle this situation more gracefully, but I don't see how an attacker could gain something by "exploiting" this bug. After setting up lighty or making config changes, one will immediately (after trying to send a request) see that the new config is wrong (as lighty crashes). Or... expressed differently: No working site will have such a config and as such nobody can exploit it. At least that's my interpretation. =)
You're right, I didn't see the "only security" point. My fault.
please add "CVE-CVE-2008-1531"
New patch from upstream [1], see the relevant ticket [2]. I created a diff against 1.4.19 [3] which is what we'll probably need. :) Hopefully I tested it well enough this time. :p [1] http://trac.lighttpd.net/trac/changeset/2139 [2] http://trac.lighttpd.net/trac/ticket/285#comment:26 [3] http://trac.lighttpd.net/trac/attachment/ticket/285/committed-patch-1.4.19.patch
(In reply to comment #7) > [2] http://trac.lighttpd.net/trac/attachment/ticket/285/06_all_lighttpd-1.4.19-closing_foreign_ssl_connections-dos.diff That patch flooded my error.log with gigs of following errmsg bringing my server to start swapping and stopping to respond: 2008-03-30 20:39:10: (connections.c.1684) SSL: 5 error:00000000:lib(0):func(0):reason(0) devnull ~ # emerge -pv lighttpd These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] www-servers/lighttpd-1.4.19-r1 USE="bzip2 fam fastcgi gdbm pcre ssl xattr -doc -ipv6 -ldap -lua -memcache -minimal -mysql -php -rrdtool -test -webdav" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB devnull ~ # emerge --info Portage 2.1.4.4 (hardened/x86/2.6, gcc-3.4.6, glibc-2.7-r2, 2.6.23-hardened-r9 i686) ================================================================= System uname: 2.6.23-hardened-r9 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ Timestamp of tree: Sat, 29 Mar 2008 20:00:04 +0000 app-shells/bash: 3.2_p33 dev-lang/python: 2.5.1-r5 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.7.9-r1, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.24 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe -march=k8 -fomit-frame-pointer -fforce-addr" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -pipe -march=k8 -fomit-frame-pointer -fforce-addr" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.mesh-solutions.com/gentoo ftp://ftp6.uni-muenster.de/pub/linux/distributions/gentoo http://distfiles.gentoo.org" LANG="en_US.utf8" LC_ALL="en_US.utf8" LDFLAGS="-Wl,-O1" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl berkdb bzip2 caps cgi cli crypt expat fam fastcgi ftp gd gdbm glibc-omitfp gmp hardened hash iconv idn imap ithreads jpeg libwww logrotate md5sum mhash mime mmap mysql mysqli ncurses nls nocxx nptl nptlonly pam pcre perl pic png posix python readline sasl sharedmem sockets sse2 ssl symlink sysfs tcl tcpd threads tiff truetype ucs2 udev unicode urandom x86 xattr xml xmlrpc xsl zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_default authn_file authz_default authz_groupfile authz_host authz_owner authz_user autoindex deflate dir env expires ext_filter filter headers include log_config mime negotiation rewrite setenvif" APACHE2_MPMS="worker" ELIBC="glibc" INPUT_DEVICES="mouse keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I'm not sure if I undestood you correctly -- are you using lighttpd-1.4.19-r1 from the tree, as indicated by the emerge -pv output? Then this is expected, as I already noted. Someone should commit -r2 with the new patch, as noted by me in comment #12. bangert, I can do it if you want me to, but I'll leave for holidays in some hours, so... ;)
hoffie: feel free to do any bumps on lighttpd. as the metadata indicates, i'm not considering myself the/a maintainer for lighttpd - i just do bumps as necessary / my time permits. anybody is more than welcome to have his take at the ebuild (especially in situations like these). 1.4.19-r2 is in the tree. as i didnt test ssl, please do so!
Joe, can you please confirm which patch you used and retry with the committed -r2? Really appreciated.
Yes i used 1.4.19-r1, with the new 1.4.19-r2 its fine for me. Thanks.
Thanks for clearing that up. Arches, please test and mark stable: =www-servers/lighttpd-1.4.19-r2 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 release sh sparc x86"
Stable for HPPA.
alpha/ia64/sparc stable
ppc64 stable
ppc stable
GLSA vote: YES.
Fixed in release snapshot.
I vote YES. GLSA request filed.
GLSA 200804-08
