Bug 10775

This is probably the same bug as reported to RedHat in:

   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=68125

In which case, PATH_TRANSLATED and SCRIPT_NAME are corrupted as well as PATH_INFO.

 The reference provided by John Ellson does appear to be
the same bug.

The proximate cause problem is in the function ap_find_path_info
in server/util_script.c.  It assumes that the tails
of the uri and the path_info arguments will match exactly.
But in the example case, the uri argument is '/cgi-bin/env/http://bluh'
and the path_info argument is '/http:/bluh' -- note that the other slash
before the 'bluh' is missing.  Apparently the path_info argument
(which comes directly from the request structure) has been either
garbled or inappropriately normalized.  I don't know yet where this
garbling occurs.

The normalized value is assigned to r->path_info
during the call to ap_directory_walk.  ap_directory_walk contains the following
comment:

    /* XXX Notice that this forces path_info to be canonical.  That might
     * not be desired by all apps. ...

It would appear that any application that depends on the PATH_INFO from a uri
such as 'http://www.plover.com/cgi-bin/myprogram/http://some.other.url/' 
falls into the category of "an app that does not desire this behavior."

But there is still a bug, because ap_find_path_info assumes that the
tails of the r->path_info and r->uri will match, and they don't,
because the path_info was canonicalized in ap_directory_walk, but the
r->uri was not canonicalized.  

The ap_directory_walk comment cited above continues:

	...  However, some of those same apps likely
     * have significant security holes.
     */

I believe this is referring to apps that might be invoked as
http://perl.plover.com/cgi-bin/myapp/../../../../../../../../../etc/passwd.
Canonicalizing this path may well save 'myapp' from a severe security
problem.  However, compressing repeated slashes from the path_info
does not appear to have any analogous security benefit.

*** Bug 13783 has been marked as a duplicate of this bug. ***

2.0.46 as well as HEAD still have this problem.

*** Bug 20047 has been marked as a duplicate of this bug. ***

Created attachment 13169 [details]
fix for SCRIPT_NAME, skips multiple-slashes in URI while matching against PATH_INFO (note: this doesn't fix PATH_INFO)

patch has only been tested against 2.1-HEAD, but should apply to 2.0-HEAD as well
to fix the issue with PATH_INFO would require a bunch of more work (like
including the functionality of apr_filepath_merge into ap_directory_walk)

Debian's apache2_2.0.52-2 has this problem as described. It can also be triggered
by "%2f"s appearing after the script name with "AllowEncodedSlashes on", if the
encoded slash abuts either unencoded slash or another %2f.

according to some CGI spec I recently found the somehow garbled PATH_INFO is 
legal so the proposed patch should indeed fix the bug  

Patch Seems reasonable to me... Comments from the Crowd?

Committed patch to HEAD. 

Note that the PATH_INFO issue must still be fixed here.  Bug #20047 is about
PATH_INFO, but it has been marked as a duplicate of this one.  Thus, either we
fix it here, or we open a new bug report for it.

I do not believe that a PATH_INFO of "foo//bar" should be equivalent to
"foo/bar".  Many existing applications certainly do not think so.

Hello, I am the author of the Perl CGI module and just ran into this bug 
myself. For those who are interested, I have created a workaround for the bug 
in CGI.pm version 3.11; it will return correct values for script_name(), 
path_info() and url() for versions of Apache both with and without this bug. 
However, it will not correct the situation described below in which ScriptAlias 
is used to pass additional path information to the CGI script in such a way 
that the info does not appear in REQUEST_URI. 
 
 

Committed to HEAD two years ago, and I can't reproduce the problem.  Assuming fixed.