httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Drost" <chris.dros...@gmail.com>
Subject Re: v. 2.2 Documentation errors? (in mod/core.html#options and misc/security_tips.html#protectserverfiles)
Date Sat, 13 Dec 2008 00:44:06 GMT
>
> 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


Mime
View raw message