You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <ad...@rowe-clan.net> on 2001/06/14 06:08:55 UTC
Re: general/7865: %2F in PATH_INFO
From: "Robin Thellend" <ap...@robin.pfft.net>
Sent: Wednesday, June 13, 2001 10:20 PM
> The following reply was made to PR general/7865; it has been noted by GNATS.
>
> From: Robin Thellend <ap...@robin.pfft.net>
> To: <wr...@apache.org>
> Cc: <ap...@apache.org>, <ap...@apache.org>
> Subject: Re: general/7865: %2F in PATH_INFO
> Date: Wed, 13 Jun 2001 22:15:45 -0500 (CDT)
>
> No where in RFC 2396 does it mention that %2F is illegal in a URI. Like
> you say, %2F is a '/' that's not a path seperator.
>
> In my particular example:
>
> http://pfft.net/robin/foo.php/foo%2Fbar
>
> %2F should be passed to script 'foo.php' unaltered and it is up to the
> script the interpret the meaning of it.
>
> The security concerns should be limited to accessing the filesystem. Then
> and only then should you make sure there is no %2F in the path. However,
> in my example, the filesystem access ends at foo.php. Everything else
> after it has nothing to do with accessing a file and should be passed to
> the script.
It may actually become possible to address this in 2.0, it is far from reasonable
to consider this for 1.3. The question remains, should it be addressed?
The truly is _no_ standard for the contents of the path_info cgi variable.
That said, perhaps there is a call to do so (I have to admit, I've never noticed
another bug report about this, out of 10's of millions of sites.)
So, I'm passing on your comment to new-httpd, for consideration by the rest of
the coding community.
Yours,
Bill
> On 14 Jun 2001 wrowe@apache.org wrote:
>
> > Synopsis: %2F in PATH_INFO
> >
> > State-Changed-From-To: open-closed
> > State-Changed-By: wrowe
> > State-Changed-When: Wed Jun 13 17:38:40 PDT 2001
> > State-Changed-Why:
> > Please read this section of RFC2616 _very_ carefully.
> >
> > Characters other than those in the "reserved" and "unsafe" sets (see
> > RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
> >
> > For example, the following three URIs are equivalent:
> >
> > http://abc.com:80/~smith/home.html
> > http://ABC.com/%7Esmith/home.html
> > http://ABC.com:/%7esmith/home.html
> >
> > According to this standard, %2F is _not_ equivilant to '/'.
> > In fact, the '/' is defined a uri resource segment seperator
> > while %2F remains entirely undefined. It's a '/' that is
> > defined as 'not a path seperator'.
> >
> > That meaning is bogus to httpd, so it is disallowed.
> >
> > This behavior, for security reasons, is by design.
Re: general/7865: %2F in PATH_INFO
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
From: "Bill Stoddard" <bi...@wstoddard.com>
Sent: Thursday, June 14, 2001 9:41 AM
> I have had reports of this being a problem as well (last week in fact :-) here is Ken
> Coar's analysis:
>
> <ken>
> The analysis:
> If possible, it would be nice if this check were deferred until
> the determination of the path, path-info, and query-string was
> made, and then applied only to the path. However, I think that
> may be a significant undertaking, and may not even be possible
> in Apache 1.3. I will look into it next week, however.
> </ken>
>
> My first take is that this is a reasonable request. We'll probably look at doing a custom
> build for Apache 1.3 for our internal customer if it does not significantly risk breaking
> other parts of the server. We'll post whatever we come up with.
For 1.3? I had rewritten [hope I haven't pitched it] the directory_walk 1.3 logic. I threw
it at the security list as an example, but the number of apr-like functions required really
discouraged me from submitting the change to the list. [Of course, we found the quick-fix
for the security hole instead.] For 2.0, it might actually be a little harder, since the
patch I'm preparing parses from the start, not the tail [so we skip all the not-found stats.]
There is actually a 'set' of these reserved characters that are disallowed in encoding, not
simply %2f, that should be examined.
The simple way is to search for %2[Ff] in the get_path_info call, and backspace over the
segment (as if it were not found.) One risk, if /test/foo%2fbar is given, and /test/ is a
directory, we need to fail. And it is possible this opens security holes, not in Apache's
own core, but in CGIs or some modules.
But there is a bigger problem. %2f is neither a path seperator, nor the characters %, 2, f.
It's a unique beast. You can't later process it, since %252f is also %, 2, f. Almost needs
it's own unique character value :-) %252f might even be a legitimate workaround for Robin.
Bill
Re: general/7865: %2F in PATH_INFO
Posted by Bill Stoddard <bi...@wstoddard.com>.
I have had reports of this being a problem as well (last week in fact :-) here is Ken
Coar's analysis:
<ken>
The analysis:
Apache will accept a %2f in a URI it receives under two conditions
only: when it appears in the query string, and/or when the request
is for a proxy document. In all other cases it returns a 404.
You should find that there is no corresponding message in the error_log
file; that is because the 404 is manufactured rather than being a
translation of a filesystem ENOENT error.
This check is performed by function ap_unescape_uri() in
src/main/util.c. It has been there since the beginning of
Apache 1.2, so it is not a regression. I believe its intention
is to intercept potential 'sneak-attacks' on the URI space.
If possible, it would be nice if this check were deferred until
the determination of the path, path-info, and query-string was
made, and then applied only to the path. However, I think that
may be a significant undertaking, and may not even be possible
in Apache 1.3. I will look into it next week, however.
In the meantime, the workaround is to pass the escaped string as
part of the query-string rather than the path-info, and have
the script (or whatever is currently expecting the info to be in the
path-info) change how it parses its input.
</ken>
My first take is that this is a reasonable request. We'll probably look at doing a custom
build for Apache 1.3 for our internal customer if it does not significantly risk breaking
other parts of the server. We'll post whatever we come up with.
Bill
> From: "Robin Thellend" <ap...@robin.pfft.net>
> Sent: Wednesday, June 13, 2001 10:20 PM
>
>
> > The following reply was made to PR general/7865; it has been noted by GNATS.
> >
> > From: Robin Thellend <ap...@robin.pfft.net>
> > To: <wr...@apache.org>
> > Cc: <ap...@apache.org>, <ap...@apache.org>
> > Subject: Re: general/7865: %2F in PATH_INFO
> > Date: Wed, 13 Jun 2001 22:15:45 -0500 (CDT)
> >
> > No where in RFC 2396 does it mention that %2F is illegal in a URI. Like
> > you say, %2F is a '/' that's not a path seperator.
> >
> > In my particular example:
> >
> > http://pfft.net/robin/foo.php/foo%2Fbar
> >
> > %2F should be passed to script 'foo.php' unaltered and it is up to the
> > script the interpret the meaning of it.
> >
> > The security concerns should be limited to accessing the filesystem. Then
> > and only then should you make sure there is no %2F in the path. However,
> > in my example, the filesystem access ends at foo.php. Everything else
> > after it has nothing to do with accessing a file and should be passed to
> > the script.
>
> It may actually become possible to address this in 2.0, it is far from reasonable
> to consider this for 1.3. The question remains, should it be addressed?
>
> The truly is _no_ standard for the contents of the path_info cgi variable.
> That said, perhaps there is a call to do so (I have to admit, I've never noticed
> another bug report about this, out of 10's of millions of sites.)
>
> So, I'm passing on your comment to new-httpd, for consideration by the rest of
> the coding community.
>
> Yours,
>
> Bill
>
>
> > On 14 Jun 2001 wrowe@apache.org wrote:
> >
> > > Synopsis: %2F in PATH_INFO
> > >
> > > State-Changed-From-To: open-closed
> > > State-Changed-By: wrowe
> > > State-Changed-When: Wed Jun 13 17:38:40 PDT 2001
> > > State-Changed-Why:
> > > Please read this section of RFC2616 _very_ carefully.
> > >
> > > Characters other than those in the "reserved" and "unsafe" sets (see
> > > RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
> > >
> > > For example, the following three URIs are equivalent:
> > >
> > > http://abc.com:80/~smith/home.html
> > > http://ABC.com/%7Esmith/home.html
> > > http://ABC.com:/%7esmith/home.html
> > >
> > > According to this standard, %2F is _not_ equivilant to '/'.
> > > In fact, the '/' is defined a uri resource segment seperator
> > > while %2F remains entirely undefined. It's a '/' that is
> > > defined as 'not a path seperator'.
> > >
> > > That meaning is bogus to httpd, so it is disallowed.
> > >
> > > This behavior, for security reasons, is by design.
>
>