Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Apache: Dev

2.0.x

 

 

Apache dev RSS feed   Index | Next | Previous | View Threaded


marcin.zawadzki at globalvanet

Jul 12, 2006, 12:48 PM

Post #1 of 15 (4215 views)
Permalink
2.0.x

In version 2.0.x (latest), is very important bug security.

When option followsymlinks and symlinksifownermatrch are disabled, there
is another way to use symlinks on linux. There is:

I created directory in document root (documentroot=/home/apachedata/htdocs):

mkdir directory1

then i create a symlinks, wchich names is the name of file in Directory
index (for example index.html)

ln -s /etc/passwd index.html

Then in browser i put:

http://hostname/directory1

and i see the passwd file i browser.
If i put http://hostname/directory1/index.html then this security
problem is not exist.
Please reapir this error(bug), and email me when it is repaired.

Sorry for my English.

--
Marcin Zawadzki, http://ftims.pl/~marcin/
GPG: 4096D/81DFA928 6C5C F525 8CAA 2A20 B878 C248 08FE 060C 81DF A928


nick at webthing

Jul 12, 2006, 3:43 PM

Post #2 of 15 (4138 views)
Permalink
Re: 2.0.x [In reply to]

I had in mind to fix this tonight. But it's too complex to get right
late at night after a long day and a couple of glasses of wine.

A look at it suggests we have a bug in ap_directory_walk
affecting all versions. The "cached dir walk" optimisation at
lines 555-583 (Trunk) is losing the symlink check.

The quickest fix would be to scrap the optimisation altogether.
Otherwise, we need to run the extra checks at lines ~942-1014
at that point.

All of this is unfortunately in a single function. Any better fix
is going to be thoroughly ugly, unless it changes that.

Anyone else looked at it, please let me know if your diagnosis
agrees with mine, and if you can see a less ugly fix!

--
Nick Kew


marcin.zawadzki at globalvanet

Jul 13, 2006, 1:17 AM

Post #3 of 15 (4136 views)
Permalink
Re: 2.0.x [In reply to]

when you repair this problem, in which version?

Marcin Zawadzki, http://ftims.pl/~marcin/
GPG: 4096D/81DFA928 6C5C F525 8CAA 2A20 B878 C248 08FE 060C 81DF A928



Nick Kew napisał(a):
> I had in mind to fix this tonight. But it's too complex to get right
> late at night after a long day and a couple of glasses of wine.
>
> A look at it suggests we have a bug in ap_directory_walk
> affecting all versions. The "cached dir walk" optimisation at
> lines 555-583 (Trunk) is losing the symlink check.
>
> The quickest fix would be to scrap the optimisation altogether.
> Otherwise, we need to run the extra checks at lines ~942-1014
> at that point.
>
> All of this is unfortunately in a single function. Any better fix
> is going to be thoroughly ugly, unless it changes that.
>
> Anyone else looked at it, please let me know if your diagnosis
> agrees with mine, and if you can see a less ugly fix!
>
>


wrowe at rowe-clan

Jul 13, 2006, 4:46 PM

Post #4 of 15 (4129 views)
Permalink
Re: 2.0.x [In reply to]

Nick Kew wrote:
> I had in mind to fix this tonight. But it's too complex to get right
> late at night after a long day and a couple of glasses of wine.
>
> A look at it suggests we have a bug in ap_directory_walk
> affecting all versions. The "cached dir walk" optimisation at
> lines 555-583 (Trunk) is losing the symlink check.
>
> The quickest fix would be to scrap the optimisation altogether.
> Otherwise, we need to run the extra checks at lines ~942-1014
> at that point.

Scrapping the optimization is a red herring.

The optimization logic -should- be noting where the original pass varies
from the current pass through merging, and then taking a left turn to then
construct fresh merges of previously-unmerged sections.

I suspect there 1) might be an overly agressive shortcut out of the merge
checking, and 2) that r->filename might not be updated early enough by
mod_dir to catch index.html. If r->filename is still /foo/bar/ and not
/foo/bar/index.html then the entire dir_walk assumption is a red herring.

I am spending cycles tonight looking at this, and am likely to add some
diagnostics that add some insight to what dir_walk actually walks and even
what it merges, for the benefit of users diagnosing their config.

Bill


wrowe at rowe-clan

Jul 13, 2006, 4:48 PM

Post #5 of 15 (4146 views)
Permalink
Re: 2.0.x [In reply to]

Marcin Zawadzki/GlobalVanet.com wrote:
> when you repair this problem, in which version?

Marcin, if you continued this dialog on security [at] apach where you
originally reported it, the dev team would be quite a bit more likely
to engage in constructive dialog. I have no issue with discrete vuln
reporting practices, nor the scream from the rooftops vuln reporting
theory. But I'm totally puzzled why you would want it both ways.


nick at webthing

Jul 13, 2006, 7:09 PM

Post #6 of 15 (4121 views)
Permalink
Re: 2.0.x [In reply to]

On Friday 14 July 2006 00:46, William A. Rowe, Jr. wrote:

OK, I have a fix that appears to work. Mostly.
Well, it fixes the problem reported. This was working with
2.2.2, and I attach a patch against that.

> Nick Kew wrote:
> > I had in mind to fix this tonight. But it's too complex to get right
> > late at night after a long day and a couple of glasses of wine.
> >
> > A look at it suggests we have a bug in ap_directory_walk
> > affecting all versions. The "cached dir walk" optimisation at
> > lines 555-583 (Trunk) is losing the symlink check.

FWIW, that was the directory_walk called from ap_internal_fast_redirect
in fixup_dir. Not the one from ap_sub_req_lookup_uri.
> >
> > The quickest fix would be to scrap the optimisation altogether.
> > Otherwise, we need to run the extra checks at lines ~942-1014
> > at that point.
>
> Scrapping the optimization is a red herring.

Possibly.

> The optimization logic -should- be noting where the original pass varies
> from the current pass through merging, and then taking a left turn to then
> construct fresh merges of previously-unmerged sections.
>
> I suspect there 1) might be an overly agressive shortcut out of the merge
> checking, and 2) that r->filename might not be updated early enough by
> mod_dir to catch index.html. If r->filename is still /foo/bar/ and not
> /foo/bar/index.html then the entire dir_walk assumption is a red herring.

It is set to index.html second time through (I walked through that with gdb).
When you request index.html explicitly, the check happens in the
directory walk code (lines 942-1014), which returns FORBIDDEN.

In the problem case, first time through it's the directory, which is of course
allowed (and not a symlink). Second time round - when it is the symlink -
it has optimised out the directory walk on the necessary but not
sufficient grounds that the per-dir config is identical.

Now that's not the whole story. If I wrap index.html in a <Files> stanza,
the per-dir config is not identical, but it still misses the symlink check.
I haven't figured out the full gory details yet, but here's some more.

Directory walk called from ap_sub_req_lookup_uri is returning
index.html as a regular file, not a symlink. I tried fixing that with
a patch:

--- server/request.c.222 2006-04-22 02:53:06.000000000 +0100
+++ server/request.c 2006-07-14 01:58:48.511404250 +0100
@@ -525,7 +525,7 @@
* with APR_ENOENT, knowing that the path is good.
*/
if (!r->finfo.filetype || r->finfo.filetype == APR_LNK) {
- rv = apr_stat(&r->finfo, r->filename, APR_FINFO_MIN, r->pool);
+ rv = apr_stat(&r->finfo, r->filename, APR_FINFO_MIN|APR_FINFO_LINK,
r->pool);

/* some OSs will return APR_SUCCESS/APR_REG if we stat
* a regular file but we have '/' at the end of the name;
@@ -545,7 +545,7 @@
}
}

- if (r->finfo.filetype == APR_REG) {
+ if ((r->finfo.filetype == APR_REG) || (r->finfo.filetype == APR_LNK)) {
entry_dir = ap_make_dirstr_parent(r->pool, entry_dir);
}
else if (r->filename[strlen(r->filename) - 1] != '/') {

This works, in that it's now FORBIDDEN when it should be. However,
it screws up when symlinks are permitted: it then marks index.html
as a directory (line 1023; "thisinfo" having been set at line 937),
so when it reaches fixup_dir in the subreq, it redirects to index.html/

Now, if in addition to the above patch, I remove the optimisation at
lines 923-940, it works correctly with FollowSymLinks either on or off.
I'm not sure about SymLinksIfOwnerMatch: it appears to be ignored,
and It's too late in the wee hours to figure that out.

--
Nick Kew
Attachments: patch (1.33 KB)


rpluem at apache

Jul 19, 2006, 5:46 AM

Post #7 of 15 (4119 views)
Permalink
Re: 2.0.x [In reply to]

I have a patch that works against trunk (checked Options None, Options
FollowSymLinks, Options SymLinksifOwnerMatch). It keeps the optimization and
comes at the cost of one extra stat if we have FollowSymLinks NOT set or if
SymLinksifOwnerMatch is set and up to 3 further stats due to resolve_symlink if
it is really a symbolic link. From my current point of view this seems to be an
acceptable penalty. As I am not very familar with this code and this part of the
code seems to be critical from the performance and security perspective remote
eyes, reviews and comments are very welcome.


Index: server/request.c
===================================================================
--- server/request.c (Revision 422739)
+++ server/request.c (Arbeitskopie)
@@ -524,17 +524,50 @@
&& (!r->path_info || !*r->path_info)))
&& (cache->dir_conf_tested == sec_ent)
&& (strcmp(entry_dir, cache->cached) == 0)) {
+ int familar = 0;
+
/* Well this looks really familiar! If our end-result (per_dir_result)
* didn't change, we have absolutely nothing to do :)
* Otherwise (as is the case with most dir_merged/file_merged requests)
* we must merge our dir_conf_merged onto this new r->per_dir_config.
*/
if (r->per_dir_config == cache->per_dir_result) {
- return OK;
+ familar = 1;
}

if (r->per_dir_config == cache->dir_conf_merged) {
r->per_dir_config = cache->per_dir_result;
+ familar = 1;
+ }
+
+ if (familar) {
+ apr_finfo_t thisinfo;
+ int res;
+ allow_options_t opts;
+ core_dir_config *this_dir;
+
+ this_dir = ap_get_module_config(r->per_dir_config, &core_module);
+ opts = this_dir->opts;
+ /*
+ * If Symlinks are allowed in general we do not need the following
+ * check.
+ */
+ if (!(opts & OPT_SYM_LINKS)) {
+ apr_stat(&thisinfo, r->filename,
+ APR_FINFO_MIN | APR_FINFO_NAME | APR_FINFO_LINK,
+ r->pool);
+ if (thisinfo.filetype == APR_LNK) {
+ /* Is this a possibly acceptable symlink? */
+ if ((res = resolve_symlink(r->filename, &thisinfo,
+ opts, r->pool)) != OK) {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ "Symbolic link not allowed "
+ "or link target not accessible: %s",
+ r->filename);
+ return r->status = res;
+ }
+ }
+ }
return OK;
}



Regards

Rüdiger
Attachments: symlink_sec_patch.diff (2.20 KB)


wrowe at rowe-clan

Jul 19, 2006, 8:13 AM

Post #8 of 15 (4102 views)
Permalink
Re: 2.0.x [In reply to]

This is much closer to what I'm working with, I like your patch better in fact.

Please commit to trunk; I believe we can reoptimize the familiar case using
a different rule based on a cached canonical filename pattern. -but- this
shouldn't hold up committing this fix; if you can save two flavors which
apply clean to 2.0.58, 2.2.2, then we should make these available immediately
under /dist/httpd/patches/apply_to_2.x.x/ locations.

Working on a perl-framework validation that my collegue Sris started, and will
commit that the moment it's ready.

Bill

Ruediger Pluem wrote:
> I have a patch that works against trunk (checked Options None, Options
> FollowSymLinks, Options SymLinksifOwnerMatch). It keeps the optimization and
> comes at the cost of one extra stat if we have FollowSymLinks NOT set or if
> SymLinksifOwnerMatch is set and up to 3 further stats due to resolve_symlink if
> it is really a symbolic link. From my current point of view this seems to be an
> acceptable penalty. As I am not very familar with this code and this part of the
> code seems to be critical from the performance and security perspective remote
> eyes, reviews and comments are very welcome.
>
>
> Index: server/request.c
> ===================================================================
> --- server/request.c (Revision 422739)
> +++ server/request.c (Arbeitskopie)
> @@ -524,17 +524,50 @@
> && (!r->path_info || !*r->path_info)))
> && (cache->dir_conf_tested == sec_ent)
> && (strcmp(entry_dir, cache->cached) == 0)) {
> + int familar = 0;
> +
> /* Well this looks really familiar! If our end-result (per_dir_result)
> * didn't change, we have absolutely nothing to do :)
> * Otherwise (as is the case with most dir_merged/file_merged requests)
> * we must merge our dir_conf_merged onto this new r->per_dir_config.
> */
> if (r->per_dir_config == cache->per_dir_result) {
> - return OK;
> + familar = 1;
> }
>
> if (r->per_dir_config == cache->dir_conf_merged) {
> r->per_dir_config = cache->per_dir_result;
> + familar = 1;
> + }
> +
> + if (familar) {
> + apr_finfo_t thisinfo;
> + int res;
> + allow_options_t opts;
> + core_dir_config *this_dir;
> +
> + this_dir = ap_get_module_config(r->per_dir_config, &core_module);
> + opts = this_dir->opts;
> + /*
> + * If Symlinks are allowed in general we do not need the following
> + * check.
> + */
> + if (!(opts & OPT_SYM_LINKS)) {
> + apr_stat(&thisinfo, r->filename,
> + APR_FINFO_MIN | APR_FINFO_NAME | APR_FINFO_LINK,
> + r->pool);
> + if (thisinfo.filetype == APR_LNK) {
> + /* Is this a possibly acceptable symlink? */
> + if ((res = resolve_symlink(r->filename, &thisinfo,
> + opts, r->pool)) != OK) {
> + ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
> + "Symbolic link not allowed "
> + "or link target not accessible: %s",
> + r->filename);
> + return r->status = res;
> + }
> + }
> + }
> return OK;
> }
>
>
>
> Regards
>
> Rüdiger
>
>
> ------------------------------------------------------------------------
>
> Index: server/request.c
> ===================================================================
> --- server/request.c (Revision 422739)
> +++ server/request.c (Arbeitskopie)
> @@ -524,17 +524,50 @@
> && (!r->path_info || !*r->path_info)))
> && (cache->dir_conf_tested == sec_ent)
> && (strcmp(entry_dir, cache->cached) == 0)) {
> + int familar = 0;
> +
> /* Well this looks really familiar! If our end-result (per_dir_result)
> * didn't change, we have absolutely nothing to do :)
> * Otherwise (as is the case with most dir_merged/file_merged requests)
> * we must merge our dir_conf_merged onto this new r->per_dir_config.
> */
> if (r->per_dir_config == cache->per_dir_result) {
> - return OK;
> + familar = 1;
> }
>
> if (r->per_dir_config == cache->dir_conf_merged) {
> r->per_dir_config = cache->per_dir_result;
> + familar = 1;
> + }
> +
> + if (familar) {
> + apr_finfo_t thisinfo;
> + int res;
> + allow_options_t opts;
> + core_dir_config *this_dir;
> +
> + this_dir = ap_get_module_config(r->per_dir_config, &core_module);
> + opts = this_dir->opts;
> + /*
> + * If Symlinks are allowed in general we do not need the following
> + * check.
> + */
> + if (!(opts & OPT_SYM_LINKS)) {
> + apr_stat(&thisinfo, r->filename,
> + APR_FINFO_MIN | APR_FINFO_NAME | APR_FINFO_LINK,
> + r->pool);
> + if (thisinfo.filetype == APR_LNK) {
> + /* Is this a possibly acceptable symlink? */
> + if ((res = resolve_symlink(r->filename, &thisinfo,
> + opts, r->pool)) != OK) {
> + ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
> + "Symbolic link not allowed "
> + "or link target not accessible: %s",
> + r->filename);
> + return r->status = res;
> + }
> + }
> + }
> return OK;
> }
>


wrowe at rowe-clan

Jul 19, 2006, 8:38 AM

Post #9 of 15 (4125 views)
Permalink
Re: 2.0.x [In reply to]

Actually, does this handle the nested case (more than one level depth?)

I'm afraid it doesn't. Staying with the 'familiar' theme, it seems to
make sense to follow the entire code path, optimizing out the actual
operations by checking if (familiar).

William A. Rowe, Jr. wrote:
> This is much closer to what I'm working with, I like your patch better
> in fact.
>
> Please commit to trunk; I believe we can reoptimize the familiar case using
> a different rule based on a cached canonical filename pattern. -but- this
> shouldn't hold up committing this fix; if you can save two flavors which
> apply clean to 2.0.58, 2.2.2, then we should make these available
> immediately
> under /dist/httpd/patches/apply_to_2.x.x/ locations.
>
> Working on a perl-framework validation that my collegue Sris started,
> and will
> commit that the moment it's ready.
>
> Bill
>
> Ruediger Pluem wrote:
>> I have a patch that works against trunk (checked Options None, Options
>> FollowSymLinks, Options SymLinksifOwnerMatch). It keeps the
>> optimization and
>> comes at the cost of one extra stat if we have FollowSymLinks NOT set
>> or if
>> SymLinksifOwnerMatch is set and up to 3 further stats due to
>> resolve_symlink if
>> it is really a symbolic link. From my current point of view this seems
>> to be an
>> acceptable penalty. As I am not very familar with this code and this
>> part of the
>> code seems to be critical from the performance and security
>> perspective remote
>> eyes, reviews and comments are very welcome.
>>
>>
>> Index: server/request.c
>> ===================================================================
>> --- server/request.c (Revision 422739)
>> +++ server/request.c (Arbeitskopie)
>> @@ -524,17 +524,50 @@
>> && (!r->path_info || !*r->path_info)))
>> && (cache->dir_conf_tested == sec_ent)
>> && (strcmp(entry_dir, cache->cached) == 0)) {
>> + int familar = 0;
>> +
>> /* Well this looks really familiar! If our end-result
>> (per_dir_result)
>> * didn't change, we have absolutely nothing to do :)
>> * Otherwise (as is the case with most dir_merged/file_merged
>> requests)
>> * we must merge our dir_conf_merged onto this new
>> r->per_dir_config.
>> */
>> if (r->per_dir_config == cache->per_dir_result) {
>> - return OK;
>> + familar = 1;
>> }
>>
>> if (r->per_dir_config == cache->dir_conf_merged) {
>> r->per_dir_config = cache->per_dir_result;
>> + familar = 1;
>> + }
>> +
>> + if (familar) {
>> + apr_finfo_t thisinfo;
>> + int res;
>> + allow_options_t opts;
>> + core_dir_config *this_dir;
>> +
>> + this_dir = ap_get_module_config(r->per_dir_config,
>> &core_module);
>> + opts = this_dir->opts;
>> + /*
>> + * If Symlinks are allowed in general we do not need the
>> following
>> + * check.
>> + */
>> + if (!(opts & OPT_SYM_LINKS)) {
>> + apr_stat(&thisinfo, r->filename,
>> + APR_FINFO_MIN | APR_FINFO_NAME |
>> APR_FINFO_LINK,
>> + r->pool);
>> + if (thisinfo.filetype == APR_LNK) {
>> + /* Is this a possibly acceptable symlink? */
>> + if ((res = resolve_symlink(r->filename, &thisinfo,
>> + opts, r->pool)) != OK) {
>> + ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
>> + "Symbolic link not allowed "
>> + "or link target not accessible:
>> %s",
>> + r->filename);
>> + return r->status = res;
>> + }
>> + }
>> + }
>> return OK;
>> }
>>
>>
>>
>> Regards
>>
>> Rüdiger
>>
>>
>> ------------------------------------------------------------------------
>>
>> Index: server/request.c
>> ===================================================================
>> --- server/request.c (Revision 422739)
>> +++ server/request.c (Arbeitskopie)
>> @@ -524,17 +524,50 @@
>> && (!r->path_info || !*r->path_info)))
>> && (cache->dir_conf_tested == sec_ent)
>> && (strcmp(entry_dir, cache->cached) == 0)) {
>> + int familar = 0;
>> +
>> /* Well this looks really familiar! If our end-result
>> (per_dir_result)
>> * didn't change, we have absolutely nothing to do :)
>> * Otherwise (as is the case with most dir_merged/file_merged
>> requests)
>> * we must merge our dir_conf_merged onto this new
>> r->per_dir_config.
>> */
>> if (r->per_dir_config == cache->per_dir_result) {
>> - return OK;
>> + familar = 1;
>> }
>>
>> if (r->per_dir_config == cache->dir_conf_merged) {
>> r->per_dir_config = cache->per_dir_result;
>> + familar = 1;
>> + }
>> +
>> + if (familar) {
>> + apr_finfo_t thisinfo;
>> + int res;
>> + allow_options_t opts;
>> + core_dir_config *this_dir;
>> +
>> + this_dir = ap_get_module_config(r->per_dir_config,
>> &core_module);
>> + opts = this_dir->opts;
>> + /*
>> + * If Symlinks are allowed in general we do not need the
>> following
>> + * check.
>> + */
>> + if (!(opts & OPT_SYM_LINKS)) {
>> + apr_stat(&thisinfo, r->filename,
>> + APR_FINFO_MIN | APR_FINFO_NAME |
>> APR_FINFO_LINK,
>> + r->pool);
>> + if (thisinfo.filetype == APR_LNK) {
>> + /* Is this a possibly acceptable symlink? */
>> + if ((res = resolve_symlink(r->filename, &thisinfo,
>> + opts, r->pool)) != OK) {
>> + ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
>> + "Symbolic link not allowed "
>> + "or link target not accessible:
>> %s",
>> + r->filename);
>> + return r->status = res;
>> + }
>> + }
>> + }
>> return OK;
>> }
>>
>
>
>


rpluem at apache

Jul 19, 2006, 12:41 PM

Post #10 of 15 (4130 views)
Permalink
Re: 2.0.x [In reply to]

On 19.07.2006 17:38, William A. Rowe, Jr. wrote:
> Actually, does this handle the nested case (more than one level depth?)

Which case exactly do you have in mind?

Regards

Rüdiger


wrowe at rowe-clan

Jul 19, 2006, 1:25 PM

Post #11 of 15 (4124 views)
Permalink
Re: 2.0.x [In reply to]

Ruediger Pluem wrote:
> On 19.07.2006 17:38, William A. Rowe, Jr. wrote:
>> Actually, does this handle the nested case (more than one level depth?)
>
> Which case exactly do you have in mind?

I have to investigate which modules can cause redirects similar to mod_dir's
internal redirect, but the gist is <Directory /webcontent>, user accesses
/one/document.html, user is served /two/document.html from a redirect, where
document.html in /webcontent/two/ is our evil symlink.


rpluem at apache

Jul 19, 2006, 2:29 PM

Post #12 of 15 (4133 views)
Permalink
Re: 2.0.x [In reply to]

On 07/19/2006 10:25 PM, William A. Rowe, Jr. wrote:
> Ruediger Pluem wrote:
>
>> On 19.07.2006 17:38, William A. Rowe, Jr. wrote:
>>
>>> Actually, does this handle the nested case (more than one level depth?)
>>
>>
>> Which case exactly do you have in mind?
>
>
> I have to investigate which modules can cause redirects similar to
> mod_dir's
> internal redirect, but the gist is <Directory /webcontent>, user accesses
> /one/document.html, user is served /two/document.html from a redirect,
> where
> document.html in /webcontent/two/ is our evil symlink.

Just to be sure that we are on the same page:

euler:/usr/src/apache/apache_trunk/htdocs # ls -Rl webcontent/
webcontent/:
total 16
drwxr-xr-x 4 ruediger users 4096 Jul 19 23:04 .
drwxr-xr-x 5 ruediger users 4096 Jul 19 23:04 ..
drwxr-xr-x 2 ruediger users 4096 Jul 19 23:04 one
drwxr-xr-x 2 ruediger users 4096 Jul 19 23:05 two

webcontent/one:
total 8
drwxr-xr-x 2 ruediger users 4096 Jul 19 23:04 .
drwxr-xr-x 4 ruediger users 4096 Jul 19 23:04 ..

webcontent/two:
total 8
drwxr-xr-x 2 ruediger users 4096 Jul 19 23:05 .
drwxr-xr-x 4 ruediger users 4096 Jul 19 23:04 ..
lrwxrwxrwx 1 ruediger users 11 Jul 19 23:05 document.html -> /etc/passwd

<Directory "/usr/src/apache/apache_trunk/htdocs/webcontent">
Options SymLinksifOwnerMatch
RewriteEngine on
RewriteRule ^one/document.html$ two/document.html [L]
</Directory>


Is this the scenario you had in mind? This works correctly with the patch.

Regards

Rüdiger


sris at covalent

Jul 19, 2006, 10:05 PM

Post #13 of 15 (4123 views)
Permalink
Re: 2.0.x [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have attached a perl test script to validate this bug. This is what u
have to do..

* copy the attached tar file test_symlink.tar.gz to
./httpd-test/perl-framework/

* untar it, make and run t/TEST


*run "t/TEST -verbose t/apache/sym_link.t" to run the required test only
in verbose mode.

All test cases have to be passed with the desired apache functionality.
but due to the bug in concern, test 2 is 'not ok'.

sample output(with the bug..)

ok 1
# testing : calling url of a directory, where symlinks are not allowed
and index.html is a symbolic link.
# expected: 403
# received: 200
not ok 2
# Failed test 2 in t/apache/sym_link.t at line 14
# testing : calling the url of a symlink 'index.html' in a dir where
symlinks are not allowed
# expected: 403
# received: 403
ok 3
# testing : calling url of a directory, where symlinks are allowed and
index.html is a symbolic link.
# expected: 200
# received: 200
ok 4
# testing : calling url of a symlink 'index.html' in a dir where
symlinks are allowed.
# expected: 200
# received: 200
ok 5
FAILED test 2
Failed 1/5 tests, 80.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
- -
-
-------------------------------------------------------------------------------
t/apache/sym_link.t 5 1 20.00% 2



Regards
Sris

William A. Rowe, Jr. wrote:
> This is much closer to what I'm working with, I like your patch better
> in fact.
>
> Please commit to trunk; I believe we can reoptimize the familiar case using
> a different rule based on a cached canonical filename pattern. -but- this
> shouldn't hold up committing this fix; if you can save two flavors which
> apply clean to 2.0.58, 2.2.2, then we should make these available
> immediately
> under /dist/httpd/patches/apply_to_2.x.x/ locations.
>
> Working on a perl-framework validation that my collegue Sris started,
> and will
> commit that the moment it's ready.
>
> Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEvw78KjzBuDV8dpIRApXGAJ4g7SLC5vaiH/Xgc8D7Lst5SNjybQCfSgf5
OaMDc/8QGcnPhBc9j64KAPE=
=VzYt
-----END PGP SIGNATURE-----
Attachments: sris.vcf (0.15 KB)


sris at covalent

Jul 19, 2006, 10:08 PM

Post #14 of 15 (4121 views)
Permalink
Re: 2.0.x [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

SORRY.. attachment is here.. :)


Kanagasabai Sriskanthaverl wrote:
> I have attached a perl test script to validate this bug. This is what u
> have to do..
>
> * copy the attached tar file test_symlink.tar.gz to
> ./httpd-test/perl-framework/
>
> * untar it, make and run t/TEST
>
>
> *run "t/TEST -verbose t/apache/sym_link.t" to run the required test only
> in verbose mode.
>
> All test cases have to be passed with the desired apache functionality.
> but due to the bug in concern, test 2 is 'not ok'.
>
> sample output(with the bug..)
>
> ok 1
> # testing : calling url of a directory, where symlinks are not allowed
> and index.html is a symbolic link.
> # expected: 403
> # received: 200
> not ok 2
> # Failed test 2 in t/apache/sym_link.t at line 14
> # testing : calling the url of a symlink 'index.html' in a dir where
> symlinks are not allowed
> # expected: 403
> # received: 403
> ok 3
> # testing : calling url of a directory, where symlinks are allowed and
> index.html is a symbolic link.
> # expected: 200
> # received: 200
> ok 4
> # testing : calling url of a symlink 'index.html' in a dir where
> symlinks are allowed.
> # expected: 200
> # received: 200
> ok 5
> FAILED test 2
> Failed 1/5 tests, 80.00% okay
> Failed Test Stat Wstat Total Fail Failed List of Failed
> -
> -
> -------------------------------------------------------------------------------
> t/apache/sym_link.t 5 1 20.00% 2
>
>
>
> Regards
> Sris
>
> William A. Rowe, Jr. wrote:
>>> This is much closer to what I'm working with, I like your patch better
>>> in fact.
>>>
>>> Please commit to trunk; I believe we can reoptimize the familiar case using
>>> a different rule based on a cached canonical filename pattern. -but- this
>>> shouldn't hold up committing this fix; if you can save two flavors which
>>> apply clean to 2.0.58, 2.2.2, then we should make these available
>>> immediately
>>> under /dist/httpd/patches/apply_to_2.x.x/ locations.
>>>
>>> Working on a perl-framework validation that my collegue Sris started,
>>> and will
>>> commit that the moment it's ready.
>>>
>>> Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEvw/aKjzBuDV8dpIRAltTAJ9bjZQH5s5hoOhvEnntnwej0HYTPQCeOiLe
NI++DjiaDMfqjkKiZMPe+FI=
=vDgs
-----END PGP SIGNATURE-----
Attachments: test_symlink.tar.gz (3.90 KB)
  sris.vcf (0.15 KB)


rpluem at apache

Jul 20, 2006, 6:07 AM

Post #15 of 15 (4125 views)
Permalink
Re: 2.0.x [In reply to]

> On 07/19/2006 10:25 PM, William A. Rowe, Jr. wrote:
>>> Ruediger Pluem wrote:
>>
>>> On 19.07.2006 17:38, William A. Rowe, Jr. wrote:
>>>
>>>> Actually, does this handle the nested case (more than one level depth?)
>>>
>>>
>>> Which case exactly do you have in mind?
>>
>>
>> I have to investigate which modules can cause redirects similar to
>> mod_dir's
>> internal redirect, but the gist is <Directory /webcontent>, user accesses
>> /one/document.html, user is served /two/document.html from a redirect,
>> where
>> document.html in /webcontent/two/ is our evil symlink.
>>
>> Just to be sure that we are on the same page:

As I have not heard any further comments and the tests submitted by Kanagasabai
are passed I committed the patch to trunk (r423886). Please find attached
the flavours of this patch for 2.0.58 and 2.2.2.
Please let me know if you think that I should place them into the patches
directory for 2.0.58 / 2.2.2.


Regards

Rüdiger
Attachments: symlink_sec_patch_2.0.58.diff (2.15 KB)
  symlink_sec_patch_2.2.2.diff (2.15 KB)

Apache dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.