You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by Christopher Drost <ch...@gmail.com> on 2008/12/12 00:23:08 UTC
v. 2.2 Documentation errors? (in mod/core.html#options and misc/security_tips.html#protectserverfiles)
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: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: v. 2.2 Documentation errors? (in mod/core.html#options and misc/security_tips.html#protectserverfiles)
Posted by Joshua Slive <jo...@slive.ca>.
On Thu, Dec 18, 2008 at 9:48 AM, Rich Bowen <rb...@rcbowen.com> wrote:
> The security tips document is hardly our most stellar accomplishment. It
> would be really handy if we could get someone of the caliber of Ivan Ristic
> or Ben Laurie to overhaul it and bring it up to the realities of this
> century. While most of what's in it is accurate, some of it is confusing,
> and as a whole it's woefully incomplete.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: v. 2.2 Documentation errors? (in mod/core.html#options and misc/security_tips.html#protectserverfiles)
Posted by Rich Bowen <rb...@rcbowen.com>.
The security tips document is hardly our most stellar accomplishment.
It would be really handy if we could get someone of the caliber of
Ivan Ristic or Ben Laurie to overhaul it and bring it up to the
realities of this century. While most of what's in it is accurate,
some of it is confusing, and as a whole it's woefully incomplete.
--
What the world needs is more geniuses with humility, there are so few
of us left.
Oscar Levant
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: v. 2.2 Documentation errors? (in mod/core.html#options and misc/security_tips.html#protectserverfiles)
Posted by Christopher Drost <ch...@gmail.com>.
On Sat, Dec 13, 2008 at 6:41 AM, Eric Covener <co...@gmail.com> wrote:
>
> It seems like the introductory text in the security tips section is
> okay, but the example chosen to illustrate the "normal URL mapping
> rules" is unfortunately chosen.(symlink) to illustrate the "default
> to no access" directory container.
>
> --
> Eric Covener
The problems in the section become worse if symlinks have nothing to
do with the behavior claimed. AFAIK, without symlinks, there is no
"normal URL mapping rule" that lets you escape DocumentRoot. Well,
there are Aliases, but those are an explicit inclusion by the
webmaster of another file into the directory structure, anyway.
Come to think of it, if symlinks have nothing to do with it, then the
introductory text is in fact flat out wrong. Apache doesn't have a
feature of default access: You have to enable access explicitly with
Alias and DocumentRoot commands.
And it seems to me that the only case in which <Directory /> Deny from
all </Directory> changes anything at all, is when someone Aliases or
DocumentRoots a folder, but then forgets to add a <Directory
myfolder>Allow from all</Directory> section. But presumably, they
wanted it to be seen, so they would have added that directive in short
order anyway.
Maybe it's a useful Security Tip that you can deny access to a file or
directory that's otherwise within your DocumentRoot, with the Deny
from all directive. I don't know. But there should never be any reason
to put a Deny from all directive on a superfolder of your
DocumentRoot. Because presumably either (a) it belongs on the
DocumentRoot directly, because you're doing Something Weird, or (b)
you'll just invalidate it later with an Allow from all directive on
your DocumentRoot.
-- Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: v. 2.2 Documentation errors? (in mod/core.html#options and misc/security_tips.html#protectserverfiles)
Posted by Eric Covener <co...@gmail.com>.
On Fri, Dec 12, 2008 at 7:44 PM, Christopher Drost
<ch...@gmail.com> wrote:
> Go ahead, try it. I did. Right now http://drostie.org/symlink/ is a
> symlink pointing to the folder /hidden, which is very far away from my
> DocumentRoot. It could (and did) point to my root directory at some
> point. And the symlink was created without sudo or root privileges by
> my normal account. The <Directory /> directive didn't stop anything.
> Because the person who wrote this Security Tip didn't read
> mod/core.html#options.
It seems like the introductory text in the security tips section is
okay, but the example chosen to illustrate the "normal URL mapping
rules" is unfortunately chosen.(symlink) to illustrate the "default
to no access" directory container.
--
Eric Covener
covener@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: v. 2.2 Documentation errors? (in mod/core.html#options and misc/security_tips.html#protectserverfiles)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Christopher Drost wrote:
>
> The error comes when misc/security_tips.html#protectserverfiles also
> claims a resolution to this problem. The resolution consists of
> sticking the directive:
>
> <Directory />
> Order Deny, Allow
> Deny from all
> </Directory>
No, I don't believe it's claiming that this is the entire solution. This
is one piece of a multi-layer puzzle. The proper solution is to not allow
Options FollowSymLinks from *any* untrusted (user modifiable) system path.
Only root-owned directories should be set to allow FollowSymLinks
(which is much faster) while the user controlled directories should not.
If the documentation is unclear, I'd agree this needs to be clarified.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: v. 2.2 Documentation errors? (in mod/core.html#options and misc/security_tips.html#protectserverfiles)
Posted by Christopher Drost <ch...@gmail.com>.
>
> You said <Directory />, which is not the document root or something
> relative to a users home directory.. It's the root of the
> filesystem.
>
Where on earth did I claim that <Directory /> was either the document
root or something relative to a users home directory?
Looking back on the original email, I was maybe a bit too brief. So
let me be completely explicit here:
I don't know whether you understand the claimed security risk on
misc/security_tips.html#protectserverfiles. But the idea is, you own a
web server which allows (presumably intentionally) multiple users to
upload files that are visible from the web. That is supposed to happen
sometimes; think of any shared web hosting plan you like. And maybe
you, as the sysadmin, can't trust those users 100%. This is the
"situation," as I will refer to it below.
So misc/security_tips.html#protectserverfiles outlines a possible
attack on the system, within this situation. The attack goes as
follows: a malicious user creates a symlink, pointed to the root
directory. This symlink is in some place publicly accessible to the
web. They (or anyone else) can then access this symlink from the web,
and can browse the root directory from their public web connection.
This happens even if they have no access to do directory listings et
cetera on the root directory, and possibly even if they are in a
chroot jail, as long as Apache has access to list and read files on
the root directory. This is the "attack", as I will refer to it below.
I am taking no issue with this; I am taking it for granted. We have
our situation, we have an attack; so, we have a problem description.
The error comes when misc/security_tips.html#protectserverfiles also
claims a resolution to this problem. The resolution consists of
sticking the directive:
<Directory />
Order Deny, Allow
Deny from all
</Directory>
...into your httpd.conf (or whatever your system is calling it) file.
This proposed resolution doesn't stop the attack within the situation.
And the reason it doesn't is that Apache doesn't look at the symlink
and say, "oh, the file that I'm matching against file/directory
sections is the root directory." It does not do that, unless
mod/core.html#Options is wrong. When Apache looks at the symlink, it
says, "oh, the file that I'm matching against file/directory sections
is this symlink." Not the root directory. This means that if that
symlink is posted in any web accessible place at all -- any of them --
then Apache will say, "oh, the symlink is accessible too. I'll just do
a directory listing of / for the entire web, then." Ergo, fail.
At best, the proposed resolution can only invalidate the attack by
invalidating the situation: "well, I'll just get rid of my multiple
users!" -- or, "my multiple users don't need any web accessible
postings at all." But that's not the situation that's vulnerable to
the attack in the first place. That's a different situation.
Go ahead, try it. I did. Right now http://drostie.org/symlink/ is a
symlink pointing to the folder /hidden, which is very far away from my
DocumentRoot. It could (and did) point to my root directory at some
point. And the symlink was created without sudo or root privileges by
my normal account. The <Directory /> directive didn't stop anything.
Because the person who wrote this Security Tip didn't read
mod/core.html#options.
That is what I am claiming. I don't know what you believed that I was
claiming, but that is my error #1 in the documentation.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: v. 2.2 Documentation errors? (in mod/core.html#options and misc/security_tips.html#protectserverfiles)
Posted by Eric Covener <co...@gmail.com>.
On Fri, Dec 12, 2008 at 5:26 AM, Christopher Drost
<ch...@gmail.com> wrote:
>>
>> How do you get out from under / with a symlink?
>>
>
> I don't understand the question. You don't "get out from under" the
> global root directory -- I'm not suggesting a break on chroot or
> something like that. You do get out from under the DocumentRoot. (You
> might even get out from a chroot applied to Mallory's account but not
> Apache's, if I understand the interplay of symlinks and chroot
> properly.)
>
> This Mallory can do as follows, if e.g. he has a site under
> mod_userdir. Mallory logs into his account and just types:
>
> ln -s / /home/mallory/public_html/root
You said <Directory />, which is not the document root or something
relative to a users home directory.. It's the root of the
filesystem.
--
Eric Covener
covener@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: v. 2.2 Documentation errors? (in mod/core.html#options and misc/security_tips.html#protectserverfiles)
Posted by Christopher Drost <ch...@gmail.com>.
>
> How do you get out from under / with a symlink?
>
I don't understand the question. You don't "get out from under" the
global root directory -- I'm not suggesting a break on chroot or
something like that. You do get out from under the DocumentRoot. (You
might even get out from a chroot applied to Mallory's account but not
Apache's, if I understand the interplay of symlinks and chroot
properly.)
This Mallory can do as follows, if e.g. he has a site under
mod_userdir. Mallory logs into his account and just types:
ln -s / /home/mallory/public_html/root
Now when Apache sees the symbolic link at
http://www.example.com/~mallory/root, it follows it to the root
directory, which it displays (if Options Indexes is also set). The
<Directory /> Deny from all directive doesn't deny access to Mallory
because presumably there is a <Directory /home/mallory/public_html>
Allow from all directive that makes Mallory's pages visible from the
internet in the first place, and even though the server follows the
symlink it does not change the pathname used to match against
<Directory> sections.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: v. 2.2 Documentation errors? (in mod/core.html#options and misc/security_tips.html#protectserverfiles)
Posted by Eric Covener <co...@gmail.com>.
On Thu, Dec 11, 2008 at 6:23 PM, Christopher Drost
<ch...@gmail.com> wrote:
>
> 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.")
How do you get out from under / with a symlink?
--
Eric Covener
covener@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: v. 2.2 Documentation errors? (in mod/core.html#options and misc/security_tips.html#protectserverfiles)
Posted by Christopher Drost <ch...@gmail.com>.
>
> I wrote the note about FollowSymLinks not being a security restriction
> based on some bug reports and a response (by Roy, if I remember
> correctly) stating that nobody should expect FollowSymLinks to be
> secure in the first place. Since the docs implied otherwise, I changed
> the docs.
>
> You are most likely correct that the race conditions are "relatively"
> hard to exploit. But the "relatively" is very difficult to quantify.
> So if you don't really know what you are doing, you shouldn't expect
> to be protected by turning off symlinks. If you know what you are
> doing, then you should understand the limits implied by the statement
> in the docs without further explanation. We aren't going to include a
> treatise on symlink race conditions in the Options docs.
>
> Yes, omitting FollowSymLinks is a perfectly valid way of preventing
> you from accidentally shooting yourself in the foot. But I don't
> consider that to be a security restriction.
>
> Joshua.
Fair enough; we differ on what we consider a "security restriction,"
and that's fine by me. But if you remember where you found them, might
we at least link to the bug reports?
--Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: v. 2.2 Documentation errors? (in mod/core.html#options and misc/security_tips.html#protectserverfiles)
Posted by Joshua Slive <jo...@slive.ca>.
On Thu, Dec 11, 2008 at 6:23 PM, Christopher Drost
<ch...@gmail.com> wrote:
> 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.
I wrote the note about FollowSymLinks not being a security restriction
based on some bug reports and a response (by Roy, if I remember
correctly) stating that nobody should expect FollowSymLinks to be
secure in the first place. Since the docs implied otherwise, I changed
the docs.
You are most likely correct that the race conditions are "relatively"
hard to exploit. But the "relatively" is very difficult to quantify.
So if you don't really know what you are doing, you shouldn't expect
to be protected by turning off symlinks. If you know what you are
doing, then you should understand the limits implied by the statement
in the docs without further explanation. We aren't going to include a
treatise on symlink race conditions in the Options docs.
Yes, omitting FollowSymLinks is a perfectly valid way of preventing
you from accidentally shooting yourself in the foot. But I don't
consider that to be a security restriction.
Joshua.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org