Bugzilla Bug 214892

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

amd64/x86 stable

ppc stable

GLSA vote: YES.

Fixed in release snapshot.

I vote YES. GLSA request filed.

GLSA 200804-08