If mod_userdir is enabled but not configured, then userdir.path default to ".". Since the homedir for the nobody account is "/" on gentoo, you can access files remotely by pointing a web browser to e.g. http://server.tld/~nobody/etc/passwd. Reproducible: Always Steps to Reproduce: 1. Install lighttpd 1.4.18 2. Add mod_userdir to modules list 3. Remove any userdir.* option if present 4. Open http://your.server.tld/~nobody/etc/passwd in a web browser. Actual Results: You can grab /etc/passwd (or any world-readable file) from the server. Expected Results: You should not be able to :-) This is fixed in lighttpd's source control. The patch is here: http://trac.lighttpd.net/trac/changeset/2120
Since the bug is fixed upstream, the Gentoo package maintainer should get the patch and a glsa should be created.
This totally doesn't work on default Gentoo install; just emerge it, leave the default configuration as is and try it. Actual result: 404 - Not Found
Did you change lighttpd.conf? I have the bug with this: var.basedir = "/var/www/localhost" var.statedir = "/var/lib/lighttpd" server.modules = ( "mod_access", "mod_accesslog", "mod_userdir", "mod_auth", "mod_setenv" ) server.username = "lighttpd" server.groupname = "lighttpd" server.document-root = var.basedir + "/htdocs" server.pid-file = "/var/run/lighttpd.pid" server.errorlog-use-syslog = "enable" server.follow-symlink = "enable" server.event-handler = "linux-sysepoll" accesslog.use-syslog = "enable" auth.debug = 0
The actual bug here is that userdir.path defaults to ".". Uncommenting the "mod_userdir" line without properly configuring the module will serve every user's $HOME and / I would consider this mostly a configuration error, because using a module without actually testing it on a server facing the public is not responsible. I'm pulling in the www-servers herd for advice.
I agree this is a configuration error, but the lighty team accepted this one as a bug and fixed it in their source tree (so it will get fixed in their next release as well, but a -r3 release with the above patch and a GLSA would prevent others from letting their disk world readable)
FWIW, I agree with Julien, and I've submitted a request for a CVE identifier: http://www.openwall.com/lists/oss-security/2008/03/10/4
(In reply to comment #5) > I agree this is a configuration error, but the lighty team accepted this one as > a bug and fixed it in their source tree Well, it's a non-practical default value which was changed. It certainly is a bug (or unexpected feature) which makes it easy to create a security problem (by not creating a proper configuration), but it is not a security problem in itself. > (so it will get fixed in their next > release as well, but a -r3 release with the above patch and a GLSA would > prevent others from letting their disk world readable) Just btw, 1.4.19 is supposed to be released today.
The "weird" behaviour is documented in userdir.txt: Quote from http://trac.lighttpd.net/trac/browser/branches/lighttpd-1.4.x/doc/userdir.txt?rev=1371 userdir.path usually it should be set to "public_html" to take ~/public_html/ as the document root Default: empty (document root is the home directory)
(In reply to comment #8) > The "weird" behaviour is documented in userdir.txt: it will likely be updated according to the new behaviour.
(In reply to comment #9) > (In reply to comment #8) > > The "weird" behaviour is documented in userdir.txt: > it will likely be updated according to the new behaviour. That was not my point. I rather wanted to say that the behaviour was documented. Don't get me wrong, I'm all for getting the upstream patch into Gentoo, the security impact is just "borderline" for me.
Upstream also considers this to be a vulnerability, so I'd go with them. Assigning C3 status, www-servers, please bump.
-r3 is in the tree. this useflag combo should yield no failing tests (thanks to pva): USE="bzip2 fam fastcgi gdbm ipv6 ldap memcache pcre php rrdtool ssl test webdav xattr -doc -lua -minimal -mysql"
http://www.openwall.com/lists/oss-security/2008/03/10/5 assigns CVE-2008-1270 to this issue.
Arches, please test and mark stable: =www-servers/lighttpd-1.4.18-r3 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 release sh sparc x86"
Stable for HPPA.
www-servers/lighttpd-1.4.18-r3 USE="bzip2 fastcgi gdbm ipv6 pcre ssl test -doc -fam -ldap -lua -memcache -minimal -mysql -php -rrdtool -webdav -xattr" compiles and run fine here. # emerge --info Portage 2.1.4.4 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.5-r0, 2.6.24-zen3-1337 i686) ================================================================= System uname: 2.6.24-zen3-1337 i686 unknown Timestamp of tree: Tue, 11 Mar 2008 07:30:01 +0000 app-shells/bash: 3.2_p17-r1 dev-lang/python: 2.4.4-r9 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /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/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="collision-protect distlocks metadata-transfer parallel-fetch prelink sandbox sfperms strict test unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.prz.rzeszow.pl ftp://pandemonium.tiscali.de/pub/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo" LANG="pl_PL@euro.UTF-8" LC_ALL="pl_PL.UTF-8" LINGUAS="pl" 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="/usr/portage/distfiles/porttmp/" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl berkdb cli cracklib crypt cups dri fortran gdbm gpm gtk gtk2 iconv ipv6 isdnlog midi mudflap ncurses nls nptl nptlonly openmp pam pcre perl pppd python qt3 qt4 readline reflection session spl ssl tcpd unicode wxwindows x86 xorg zlib" ALSA_CARDS="emu10k1" 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_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="pl" USERLAND="GNU" VIDEO_CARDS="vesa nv nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
ppc64 stable
(In reply to comment #16) > www-servers/lighttpd-1.4.18-r3 USE="bzip2 fastcgi gdbm ipv6 pcre ssl test -doc > -fam -ldap -lua -memcache -minimal -mysql -php -rrdtool -webdav -xattr" > compiles and run fine here php support works good.
x86 stable, thanks Michal.
alpha/ia64/sparc stable
amd64 stable
you can holf off if you like until 213164 is in CVS.
This is a vote. I vote YES.
oh wait, ppc is not stable. somehow, I expected the other bug to enter [stable] faster.
(In reply to comment #24) > oh wait, ppc is not stable. somehow, I expected the other bug to enter [stable] > faster. > ... and now ppc is also stable.
vote, see above for mine
Voting YES and filing request.
GLSA 200804-08
