Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of symlinks #27

Open
dh-benrod5 opened this issue Feb 11, 2014 · 4 comments
Open

Handling of symlinks #27

dh-benrod5 opened this issue Feb 11, 2014 · 4 comments

Comments

@dh-benrod5
Copy link

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.

@dekimsey
Copy link

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.

@Pawel-Panek
Copy link

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?

@mkrsn
Copy link

mkrsn commented Jan 24, 2017

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)

@Pawel-Panek
Copy link

@mkrsn you're actually wrong mein Freund. Here is the last reply from project owner: #40 (comment), dated Sep 26, 2016. Not so dead perhaps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants