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 http://httpd.apache.org/docs/2.2/ . 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 127.0.0.1 (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: [email protected] For additional commands, e-mail: [email protected]
