Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
Joshua Slive wrote: > On 8/20/06, Carsten Wiedmann <[EMAIL PROTECTED]> wrote: > >> 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 . Ding ding ding. Now with some luck light bulbs will come on. Alias / ScriptAlias have (1) function which is to point the URI space into another filesystem space. If the content is under DocumentRoot there is no reason for alias.
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
On 8/20/06, Guy Hulbert <[EMAIL PROTECTED]> wrote: On Sun, 2006-20-08 at 08:36 -0400, Joshua Slive wrote: > > 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 Not if you don't want to annoy your users ... I meant in the sense that if you were designing the config system today, you could easily omit ScriptAlias. I'm not suggesting it be removed. Joshua.
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
On Sun, 2006-20-08 at 08:36 -0400, Joshua Slive wrote: > > 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 Not if you don't want to annoy your users ... -- --gh
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
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 as a substitute for ? 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 . Joshua.
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
Joshua Slive schrieb: On 8/19/06, Carsten Wiedmann <[EMAIL PROTECTED]> wrote: [I don't agree with large chunks of what you wrote, but the crux of the matter is here:] That's ok :-) BTW: Nobody else has an opinion to this discussion? Perhaps all are in the weekend vacation. ;-) > And why are sometimes (part of) the URI is case-sensitive and > somtimes not and what happens in consequence because of this > behavior. And this behavior is the only reason why it can be (on some > systems) a problem to have the ScriptAlias inside the DirectoryRoot. That last sentence is simply not true. Search the the bugtraq archives for all the other vulnerabilities in windows web servers caused by subtleties of the filesystem. You have some examples? But see the current case. In easy words: 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. It is not the job of *Alias* to deal with that; the *Alias* directives map a URL to the filesystem. If you want to protect things in the filesystem, you have . That's ok. If I want to protect something or change the behavior how the content of a directory is processed, I should do this inside a container like . But why is there the Directive "ScriptAlias"? --> This Directive should then better be removed. Next question... From the manual: | The Alias directive allows documents to be stored in the | local filesystem other than under the DocumentRoot. Or the "httpd.conf": | # Alias: Maps web paths into filesystem paths and is used to | # access content that does not live under the DocumentRoot. Now we assume that the DocumentRoot is only a special alias. Thus we can also say: | # Alias: Maps web paths into filesystem paths and is used to | # access content that does not live under another existing Alias. --> Why is it allowed (or without a warning) to make an Alias, where the target is already accessible via another Alias? Yes, it would be nice if httpd could force the use of a canonical case on case-insensitive filesystems. It can be partially done with mod_rewrite. But that would not make it safe to use ScriptAlias in the way you want. 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). Regards, Carsten
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
Joshua Slive wrote: ScriptAlias is used to both map a URL to a directory and mark requests for that URL as pointing to CGI scripts. It should not be used for directories that are already accessible from the web because they are under the DocumentRoot, for example. Instead, you can use:SetHandler cgi-script Options ExecCGI I like the idea of this documentation addition, plus maybe an explanation about why it is recommended on the security tips page (something about the differences between URLs and paths in the configuration, and the security implications of the difference, using CGI as an example), with a reference to it in the ScriptAlias section. This is important to me because after reading this thread, I've realized I never thought about these particular security hazards of referencing something by their or Alias (which is always case sensitive and has different ways of referencing the same characters), vs by their or (which is case insensitive on some operating systems, and normalizes all those character differences before trying to match). And now I need to go do an audit of my web servers to make sure... Dave
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
On 8/19/06, Carsten Wiedmann <[EMAIL PROTECTED]> wrote: [I don't agree with large chunks of what you wrote, but the crux of the matter is here:] And why are sometimes (part of) the URI is case-sensitive and somtimes not and what happens in consequence because of this behavior. And this behavior is the only reason why it can be (on some systems) a problem to have the ScriptAlias inside the DirectoryRoot. That last sentence is simply not true. Search the the bugtraq archives for all the other vulnerabilities in windows web servers caused by subtleties of the filesystem. It is not the job of *Alias* to deal with that; the *Alias* directives map a URL to the filesystem. If you want to protect things in the filesystem, you have . Yes, it would be nice if httpd could force the use of a canonical case on case-insensitive filesystems. It can be partially done with mod_rewrite. But that would not make it safe to use ScriptAlias in the way you want. Joshua.
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
Joshua Slive schrieb: On 8/19/06, Carsten Wiedmann <[EMAIL PROTECTED]> wrote: > Why is it really bad to have a ScriptAlias inside the DocumentRoot? It's > only another file system location. And it's only one line in the > config file instead of four. You have only a problem because of the > "unexpected" > behavior of httpd with case-insensitive/case-preserved file systems > ;-) And on Windows, the simplest way to make a consistent behavior > with URI's is to have a alias match case-insensitive. You seemed to miss the second part of my message, where I pointed out that there are multiple ways to "skip around" aliases if they point to directories that are otherwise accessible from the filesystem. For example, a request for //cgi-bin/file.cgi might work (I haven't tested it) The abs_path part of a HTTP URI can't start with a "//". or using one of the other "funny" characteristics of the windows filesystem that make multiple URLs point to the same filesystem location. Thus I can say, the source code is too simple... ;-) It's not the problem of Windows (OS X, ...) that httpd don't compare the real case of a file with the case of the resource given in a HTTP request. BTW: With symlinks we have a similar "funny" thing on *nix, to point multiple URIs to the same filesystem location. That is why if you want to restrict access to a filesystem location, you need to use , which knows about all these funny things. Don't forget, we are not talking about: ... ScriptAlias /cgi-bin/ c:/apache2/htdocs/cgi-bin/ vs. ... ScriptAlias /cgi-bin/ //server/share/htdocs/cgi-bin/ (different filesystem/network paths for Directory and ScriptAlias target. OK, they can point to the same resource, but that's another problem.) We are talking about: ... ScriptAlias /cgi-bin/ c:/apache2/htdocs/cgi-bin/ and http://example.com/cgi-bin/foo.cgi vs. http://example.com/CGI-BIN/foo.cgi And why are sometimes (part of) the URI is case-sensitive and somtimes not and what happens in consequence because of this behavior. And this behavior is the only reason why it can be (on some systems) a problem to have the ScriptAlias inside the DirectoryRoot. Unfortunately there is for the moment no setting in the configuration, in order to achieve with such a system a real RFC conformal behavior (e.g.like "lower_case_table_names" in MySQL). But you can achieve a consistent behavior. Regards, Carsten
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
On 8/19/06, Carsten Wiedmann <[EMAIL PROTECTED]> wrote: Why is it really bad to have a ScriptAlias inside the DocumentRoot? It's only another file system location. And it's only one line in the config file instead of four. You have only a problem because of the "unexpected" behavior of httpd with case-insensitive/case-preserved file systems ;-) And on Windows, the simplest way to make a consistent behavior with URI's is to have a alias match case-insensitive. You seemed to miss the second part of my message, where I pointed out that there are multiple ways to "skip around" aliases if they point to directories that are otherwise accessible from the filesystem. For example, a request for //cgi-bin/file.cgi might work (I haven't tested it) or using one of the other "funny" characteristics of the windows filesystem that make multiple URLs point to the same filesystem location. That is why if you want to restrict access to a filesystem location, you need to use , which knows about all these funny things. Joshua.
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
Joshua Slive schrieb: On 8/18/06, Carsten Wiedmann <[EMAIL PROTECTED]> wrote: > > I don't complete agree with you... IMHO the basic "problem" is: > The "URL-path" in ScriptAlias (like in Alias and Location) is > compared case sensitive first, also on Windows. The "normal" URI to > path translation (directory-path) not on Windows. That should be > better explained in the manual. Yes, it should be explained that *Alias* are case-sensitive in their first argument. Ok. But your diagnosis is not quite correct. URLs are always case sensitive in httpd (and in the HTTP RFC). That's a good point (IMHO they SHOULD, not MUST). But see below... The fact that multiple different URLs happen to map to the same filesystem location is an artificat of the filesystem, not of the path translation code. httpd does handle case-insensitivity correctly in its filesystem code (such as the block). Now an other point of view ;-) Ok, we can see, that httpd makes exactly what the source code says. URI comparison is made case-sensitive. And the last step, mapping the URI to a file system location, depends on the file system. (And we know: URI's are not file system locations, only resources...) But what happens in real life (all steps together)? On *nix: - with a directory "$DOCUMENT_ROOT/foo", the URI /FOO is not the same as /foo - with an alias /foo for a directory "foo" inside DocumentRoot, the URI /FOO is not the same as /foo - with an alias /bar for a directory "bar" outside DocumentRoot, the URI /BAR is not the same as /bar - with an alias /bar for a directory "bar" and a subdir "sub" outside DocumentRoot, the URI /bar/SUB is not the same as /bar/sub Now the same for e.g. Windows: - with a directory "$DOCUMENT_ROOT/foo", the URI /FOO is the same as /foo - with an alias /foo for a directory "foo" inside DocumentRoot, the URI /FOO is the same as /foo, but sometimes with a different behavior - with an alias /bar for a directory "bar" outside DocumentRoot, the URI /BAR is not the same as /bar - with an alias /bar for a directory "bar" and a subdir "sub" outside DocumentRoot, the URI /bar/SUB is the same as /bar/sub (that's really interesting: only parts of the abs_path are case-sensitive) And you think, that's a consistent behavior and according to the RFC 2616 (3.2.3)? Don't forget. That's not really a problem of the file system. Because NTFS for example is not only case-insensitive, it's also case-preserving. Thus httpd should know the real case. You remember this little sentence in the RFC 2616 (15.2)? | If an HTTP server translates HTTP URIs directly into file system calls, | the server MUST take special care not to serve files | that were not intended to be delivered to HTTP clients. > > On 8/18/06, Mark J Cox <[EMAIL PROTECTED]> wrote: > > > I think the right response here is to make it more explicit in the > > > documentation that putting a ScriptAlias cgi-bin inside document > > > root is bad. > > > > Yes, this is a relatively common configuration error. > > ... > > Instead, you can use: > > > > > >SetHandler cgi-script > >Options ExecCGI > > > > Why is it really bad to have a ScriptAlias inside the DocumentRoot? It's only another file system location. And it's only one line in the config file instead of four. You have only a problem because of the "unexpected" behavior of httpd with case-insensitive/case-preserved file systems ;-) And on Windows, the simplest way to make a consistent behavior with URI's is to have a alias match case-insensitive. BTW: That's not only a problem with Windows. Don't forget the default file system of OS X. HFS+ is also case-insensitive. Regards, Carsten
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
On 8/18/06, Carsten Wiedmann <[EMAIL PROTECTED]> wrote: Joshua Slive schrieb: > On 8/18/06, Mark J Cox <[EMAIL PROTECTED]> wrote: > > I think the right response here is to make it more explicit in the > > documentation that putting a ScriptAlias cgi-bin inside document root is > > bad. > > Yes, this is a relatively common configuration error. Although this > does not make it a bug, it does point out that our documentation could > be clearer. Unfortunately, the basic problem is that people see the > ScriptAlias in the default config file and assume that is the only way > to activate cgi scripts, so regardless of what we put in the docs, it > won't help that much. I don't complete agree with you... IMHO the basic "problem" is: The "URL-path" in ScriptAlias (like in Alias and Location) is compared case sensitive first, also on Windows. The "normal" URI to path translation (directory-path) not on Windows. That should be better explained in the manual. Yes, it should be explained that *Alias* are case-sensitive in their first argument. But your diagnosis is not quite correct. URLs are always case sensitive in httpd (and in the HTTP RFC). The fact that multiple different URLs happen to map to the same filesystem location is an artificat of the filesystem, not of the path translation code. httpd does handle case-insensitivity correctly in its filesystem code (such as the block). BTW: ScriptAlias is not complete the same as an "Options ExecCGI". On Windows you can use something like that to avoid the problem: ScriptAliasMatch "(?i)^/cgi-bin(.*)" "/apache/cgi-bin$1" I don't know why you say that Options/SetHandler isn't the same as ScriptAlias. They are identical in all important respects, as far as I know. Your suggestion is not a good one for this problem, because there are other ways to dodge around that regex on many filesystems (multiple slashes, special characters, etc). Those are all handled properly by . (Your suggestion is fine for the general question "How do I make the cgi-bin alias case-insensitive?" but it is not a safe way to use ScriptAlias to put the cgi-bin inside the DocumentRoot.) Joshua.
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
Joshua Slive schrieb: On 8/18/06, Mark J Cox <[EMAIL PROTECTED]> wrote: > I think the right response here is to make it more explicit in the > documentation that putting a ScriptAlias cgi-bin inside document root is > bad. Yes, this is a relatively common configuration error. Although this does not make it a bug, it does point out that our documentation could be clearer. Unfortunately, the basic problem is that people see the ScriptAlias in the default config file and assume that is the only way to activate cgi scripts, so regardless of what we put in the docs, it won't help that much. I don't complete agree with you... IMHO the basic "problem" is: The "URL-path" in ScriptAlias (like in Alias and Location) is compared case sensitive first, also on Windows. The "normal" URI to path translation (directory-path) not on Windows. That should be better explained in the manual. BTW: ScriptAlias is not complete the same as an "Options ExecCGI". On Windows you can use something like that to avoid the problem: ScriptAliasMatch "(?i)^/cgi-bin(.*)" "/apache/cgi-bin$1" Regards, Carsten
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
On 8/18/06, Mark J Cox <[EMAIL PROTECTED]> wrote: See http://marc.theaimsgroup.com/?l=bugtraq&m=115527423727441&w=2 which basically reports "if you put cgi-bin under docroot then you can view cgi scripts on OS which have case insensitive filesystems" Joe replied: http://marc.theaimsgroup.com/?l=bugtraq&m=115574424402976&w=2 and I submitted that as an "DISPUTED" to CVE But the original reporter disagrees: http://marc.theaimsgroup.com/?l=bugtraq&m=115583509231594&w=2 I think the right response here is to make it more explicit in the documentation that putting a ScriptAlias cgi-bin inside document root is bad. Yes, this is a relatively common configuration error. Although this does not make it a bug, it does point out that our documentation could be clearer. Unfortunately, the basic problem is that people see the ScriptAlias in the default config file and assume that is the only way to activate cgi scripts, so regardless of what we put in the docs, it won't help that much. Something like the following should probably be added to the docs for ScriptAlias (and perhaps in the CGI tutorial): ScriptAlias is used to both map a URL to a directory and mark requests for that URL as pointing to CGI scripts. It should not be used for directories that are already accessible from the web because they are under the DocumentRoot, for example. Instead, you can use:SetHandler cgi-script Options ExecCGI Joshua.
CGI Script Source Code Disclosure Vulnerability in Apache for Windows
See http://marc.theaimsgroup.com/?l=bugtraq&m=115527423727441&w=2 which basically reports "if you put cgi-bin under docroot then you can view cgi scripts on OS which have case insensitive filesystems" Joe replied: http://marc.theaimsgroup.com/?l=bugtraq&m=115574424402976&w=2 and I submitted that as an "DISPUTED" to CVE But the original reporter disagrees: http://marc.theaimsgroup.com/?l=bugtraq&m=115583509231594&w=2 I think the right response here is to make it more explicit in the documentation that putting a ScriptAlias cgi-bin inside document root is bad. Mark -- Mark J Cox | www.awe.com/mark