Bugzilla Bug 191912

lighttpd-1.4.18 got just released. It fixes a problem in mod_fastcgi which
could lead to remote code execution in FastCGI applications.
Patch:
http://www.lighttpd.net/download/lighttpd-1.4.x_mod_fastcgi_overrun.patch
Advisory: http://www.lighttpd.net/assets/2007/9/9/lighttpd_sa_2007_12.txt
http://secweb.se/en/advisories/lighttpd-fastcgi-remote-vulnerability/
Release announcement: http://www.lighttpd.net/2007/9/9/1-4-18-speeding-up-a-bit

Bumped, time for arches to stabilize...

archs: please mark www-servers/lighttpd-1.4.18 stable 

target KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 sh sparc ~sparc-fbsd
x86 ~x86-fbsd"

x86,amd64 already stable, really adding arches. :)

thanks opfer - the back button killed me...

also it appears that there is another release on the way. from the release
announcement:
> For all the packagers: if you wonder what happened to lighttpd 2007-SA:11 and
> lighttpd 2007-SA:10, they will be released in the next days.

alpha/ia64 stable

(In reply to comment #4)
> also it appears that there is another release on the way. from the release
> announcement:
> > For all the packagers: if you wonder what happened to lighttpd 2007-SA:11 and
> > lighttpd 2007-SA:10, they will be released in the next days.
No, only the advisories will get released in the next days. The bugs are
already fixed in 1.4.18 (I just contacted an upstream dev to clarify it :)).

Stable for HPPA.

ppc stable

Unless I missed something, this is exploitable without user intervention, so
rerating. Thanks for the report.

ppc64 stable

Stable for SPARC.

I request a GLSA request. :)  All security supported arches are done

this one slipped through all the bugspam, sorry :/
anyway, glsa request filed.

hoffie, is there a way to disable this mod fastcgi so we could add a workaround
in the GLSA?

(In reply to comment #14)
> hoffie, is there a way to disable this mod fastcgi so we could add a workaround
> in the GLSA?
Yes, it has to be removed from the server.modules list. On Gentoo, mod_fastcgi
is added to the list of modules in the config file
/etc/lighttpd/mod_fastcgi.conf.
lighttpd.conf (main lighttpd config file):
(line numbers not exact)
47:# uncomment for php/fastcgi support
48:#include "mod_fastcgi.conf"
So mod_fastcgi.conf and as such the module mod_fastcgi is not active by
default. If the user enabled it (i.e. removed the # in front of the include
line) then he could disable it again by adding a # of course.
Anyway, there are more possibilities to load mod_fastcgi (directly adding it to
server.modules in lighttpd.conf etc...) and having to do without mod_fastcgi is
a major loss of functionality.
Long story short: Yes, there is a workaround, but it will be a major loss of
functionality (using mod_cgi instead is usually not a valid alternative).


BTW, it should also probably be noted that the bug in lighttpd "only" allows
for injecting (broken) FastCGI protocol packets, there is no remote code
execution per se. The remote code execution vulnerability only exists when the
FastCGI application in question does not discard those invalid packets.
<php-5.2.4_p20070914 is known to accept those packets (bug 191034) and as such
allows for remote code execution (by changing CGI environment headers like
SCRIPT_FILENAME you can trick PHP into executing PHP code from any arbitrary
file e.g.).
So, if there is a remote code execution vulnerability the code is executed in
the context of the FastCGI application and not within lighttpd.

I hope this wasn't too confusing. ;)

GLSA 200709-16, thanks all! 

Bah mid-air collission :(

Seems to me that this sounds more like a C issue? (Default config is not
vulnerable).

Anyway thanks for getting the GLSA out so soon:)

(In reply to comment #17)
> Bah mid-air collission :(
> 
> Seems to me that this sounds more like a C issue? (Default config is not
> vulnerable).
> 
> Anyway thanks for getting the GLSA out so soon:)
> 

it depends whether you consider lighttpd to be a frequent package or not :)

btw it would have not changed GLSA severity (high)