httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Drost" <>
Subject v. 2.2 Documentation errors? (in mod/core.html#options and misc/security_tips.html#protectserverfiles)
Date Thu, 11 Dec 2008 23:23:08 GMT
I'm not entirely sure about this, but I believe that there are two
errors in the documentation. Let me clarify before I begin, though I
think it probably goes without saying, that my relative URLs are
relative to . There's probably some
internal docs structure that I don't yet know about.

The more severe error occurs on
misc/security_tips.html#protectserverfiles, where it is claimed that
if you make a universal "Deny from all" directive for the root
directory /, you will stop a malicious user from creating a symlink to
the root directory, and thus revealing all of your readable files to
the entire world. Of course, malicious users can reveal your files
anyway if they have read access to /, by copying the files to a a
web-accessible directory. But that's beside the point.

This is false, as far as I can tell -- if you allow FollowSymLinks,
then the malicious user doesn't care about the <Directory />
conditional. (Per mod/core.html#options :: "Even though the server
follows the symlink it does not change the pathname used to match
against <Directory> sections.")

A less severe error seems to occur afterwards, on
mod/core.html#options :: "Omitting this option should not be
considered a security restriction, since symlink testing is subject to
race conditions that make it circumventable."

I'm guessing that the race condition goes something like this: Mallory
crafts a symlink file named attack, then tries to access
innocent.html. The server tests innocent.html and says "symlink free"
and then makes a call to display it. After the symlink test, but
before the display call, Mallory renames attack to innocent.html,
overwriting the file that's already there. If Mallory is swift enough,
he gets the directory listing anyways. I'm guessing, here. I don't
know what the original author meant, but this is the only way I see
where a race condition could make a symlink look like a normal file.

I would say that the attack is much more restricted if it has to
follow that particular form. (Yes, to some extent this is a
word-choice nitpick. Maybe just say that it´s not an "absolute"
security restriction.)

After all, the FollowSymLinks attack allows any user to show anybody
on the web the contents of your root folder with zero effort, and
opens itself up to accidental abuses. The race condition attack looks
relatively difficult and resource-intensive, and would probably
require, to be practical, access to execute an arbitrary file; it
reveals information only to Mallory. (Though, again, he can presumably
then copy the files to a web-accessible directory.)  In fact, if we
assume that an executable file is required to really get the timings
right, then Mallory might be stopped if he can't run the chmod command
to make the file executable in the first place. And if we don't allow
Apache to listen on (is that possible?) then Mallory might
have to route his requests through the Internet, making it very
difficult to get the race condition timing just right.

Like I said, I don't know the exact details of how easy the attack is.
I don't even know if the directory listings threat in
misc/security_tips.html#protectserverfiles is, in fact, noteworthy and
deserving of being on that page at all. But if it does constitute a
valid security threat, then our only advice against it should be
something like, "Don't use FollowSymLinks unless absolutely necessary,
and make sure your AllowOverrides don't let the user turn on
FollowSymLinks. Use SymLinksIfUserMatch instead. This isn't 100%
protection -- for 100% protection, disable Apache's read access to all
non-essential files, or use mod_chroot and deal with the consequences.
Sorry we can't do better, but symlinks are hard to secure."

Well, it should probably be written much more eloquently than that.
But that should be the essence.

--Chris Drost

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message