From: "Bill Stoddard" <[EMAIL PROTECTED]>
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
