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)
