You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Mark J Cox <ma...@awe.com> on 2006/08/18 11:16:19 UTC
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
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
Posted by Joshua Slive <jo...@slive.ca>.
On 8/20/06, Guy Hulbert <gw...@eol.ca> 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
Posted by Guy Hulbert <gw...@eol.ca>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joshua Slive wrote:
> On 8/20/06, Carsten Wiedmann <ca...@gmx.de> 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 <Directory>.
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
Posted by Joshua Slive <jo...@slive.ca>.
On 8/20/06, Carsten Wiedmann <ca...@gmx.de> 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.
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
Posted by Carsten Wiedmann <ca...@gmx.de>.
Joshua Slive schrieb:
> On 8/19/06, Carsten Wiedmann <ca...@gmx.de> 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 <Directory>.
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 <Directory>. 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
Posted by Joshua Slive <jo...@slive.ca>.
On 8/19/06, Carsten Wiedmann <ca...@gmx.de> 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 <Directory>.
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
Posted by Carsten Wiedmann <ca...@gmx.de>.
Joshua Slive schrieb:
> On 8/19/06, Carsten Wiedmann <ca...@gmx.de> 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 <Directory>, which knows about all these
> funny things.
Don't forget, we are not talking about:
<Directory c:/apache2/htdocs> ... </Directory>
ScriptAlias /cgi-bin/ c:/apache2/htdocs/cgi-bin/
vs.
<Directory c:/apache2/htdocs> ... </Directory>
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:
<Directory c:/apache2/htdocs> ... </Directory>
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
Posted by Joshua Slive <jo...@slive.ca>.
On 8/19/06, Carsten Wiedmann <ca...@gmx.de> 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 <Directory>, which knows about all these
funny things.
Joshua.
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
Posted by Carsten Wiedmann <ca...@gmx.de>.
Joshua Slive schrieb:
> On 8/18/06, Carsten Wiedmann <ca...@gmx.de> 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 <Directory> 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 <ma...@awe.com> 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:
> > > <example>
> > > <Directory /usr/local/apache2/htdocs/cgi-dir>
> > > SetHandler cgi-script
> > > Options ExecCGI
> > > </Directory>
> > > </example>
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
Posted by Joshua Slive <jo...@slive.ca>.
On 8/18/06, Carsten Wiedmann <ca...@gmx.de> wrote:
> Joshua Slive schrieb:
>
> > On 8/18/06, Mark J Cox <ma...@awe.com> 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 <Directory> 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 <Directory>. (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
Posted by Carsten Wiedmann <ca...@gmx.de>.
Joshua Slive schrieb:
> On 8/18/06, Mark J Cox <ma...@awe.com> 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
Posted by David Burry <db...@tagnet.org>.
Joshua Slive wrote:
> <note><directive>ScriptAlias</directive> is used to
> <strong>both</strong> map a URL to a directory <strong>and</strong>
> 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 <directive
> module="core">DocumentRoot</directive>, for example. Instead, you can
> use:
> <example>
> <Directory /usr/local/apache2/htdocs/cgi-dir ><br />
> SetHandler cgi-script<br />
> Options ExecCGI<br />
> </Directory>
> </example></note>
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 <Location> or Alias (which is always case sensitive
and has different ways of referencing the same characters), vs by their
<Directory> or <File> (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
Posted by Joshua Slive <jo...@slive.ca>.
On 8/18/06, Mark J Cox <ma...@awe.com> 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):
<note><directive>ScriptAlias</directive> is used to
<strong>both</strong> map a URL to a directory <strong>and</strong>
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 <directive
module="core">DocumentRoot</directive>, for example. Instead, you can
use:
<example>
<Directory /usr/local/apache2/htdocs/cgi-dir ><br />
SetHandler cgi-script<br />
Options ExecCGI<br />
</Directory>
</example></note>
Joshua.