Bugzilla Bug 212930

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