On 8/20/06, Carsten Wiedmann <[EMAIL PROTECTED]> wrote:
You have some examples?
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0017
A HTTP server must process the abs_path from an URI in a case-sensitive manner. Thus with a case-sensitive filesystem it's enough to build a canonical / normalized path and ask the system: You have this file?. With a case-insensitive/preserving filesystem you must also compare the realpath of a file with the canonical / normalized path from the request. That's really basic understanding. And it's not new that some systems, like Windows, have a case-insensitive filesystem or other differences to a "normal" *nix filesystem. A software must respect this.
And httpd absolutely does do this. *Alias* does not do it, because it is not their job. They are *not* designed to protect content, they simply map a *url* to the filesystem.
But why is there the Directive "ScriptAlias"? --> This Directive should then better be removed.
It could easily be removed. It is a convenience directive for the special case where you *both* want to map a URL, and mark the matching requests as being for cgi scripts. As I have pointed out, it should only be used when you want to do both of those things. It is really silly to be arguing over the security implications of using a directive in a way that is obviously counter to its intentions. Should I be able to use Redirect as a substitute for Deny? Should I be able to use <Location> as a substitute for <Directory>? Not every directive is safe to use for every possible purpose.
--> Why is it allowed (or without a warning) to make an Alias, where the target is already accessible via another Alias?
The problem is not using an alias for an already accessible area. The problem is using an alias to protect content (in this case, the source code of cgi scripts).
Ok. Then we can say: For some other reasons, it's not safe to make a ScriptAlias inside DirectoryRoot on *nix (it only looks as if it's safe).
Yes, this is true. *Alias* do not do the canonicalization necessary to assure they can't be bypassed. That applies to any filesystem. The docs do make it clear in other places that the only safe way to protect content in the filesystem is using <Directory>. Joshua.
