nmaier
Handling of symlinks
mod_xsendfile provides a means to white-list directories that it should be able to deliver file content from.
XSendFilePath
However, it doesn't filter based on the canonical path. Creating a symlink from any white-listed path allows read access to files that the web server has access to.
e.g. example.com/passwd -> /etc/passwd e.g. example.com/config.php -> /home/some-other-user/example.org/config.php
This does still respect Apache's uid/gid file permissions, but does not appear to be the intended behavior, and allows for a broader and likely unintended access to files on servers using suexec, suphp, or similar Apache modules to separate user privileges.
I have confirmed this behavior in mod_xsendfile 0.12 (as packaged by Debian) and the 1.0b1 beta release.
I have also found this to be the case. I think symlinks should be canonicalized before they are checked against the white-list. Implementing this as the default (secure by default) would break existing setups.
If you are using semantic versioning, that would be a good 2.0 behavior. An acceptable interim fix would be a XSendFileCanonicalizePath flag that user's can opt in on.
Yeah, mod_xsendfile would be more useful if the path can canonicalized. The XSendFilePath has no effect or is effectively set to / when we allow site user to bypass whitelisted paths with symlinks.
I see there is not much going on mod_xsendfile. Is this project dead?
ok, lets see what we have here...
- last "stable" Version : round about 6 years ago
- Version 1.0b1 never finished (5 years ago)
- Last commit: May 2012
- Open Issues: Last response from maintainer round about 2012
- Open Issues: including critical Security Problems - never fixed
Does this answer your Question?!
If not: yep... it's pretty dead (since a long time)
@mkrsn you're actually wrong mein Freund. Here is the last reply from project owner: https://github.com/nmaier/mod_xsendfile/pull/40#issuecomment-249627431, dated Sep 26, 2016. Not so dead perhaps.