Mailing List Archive

This does look bad... I'm working on a fix. Sigh...

rst

The bug here seems to be that the Alias command and its (effective) variants
can be foxed by giving them URIs with doubled slashes, which then fail to
match. In particular, if the target directory of a ScriptAlias command is
actually, say, the cgi-bin subdirectory of DocumentRoot, this can be used
to disable the effects of ScriptAlias. Here is a patch against *0.8.16*
which appears to cure the problem:

*** mod_alias.c~ Fri Oct 27 18:03:13 1995
--- mod_alias.c Thu Nov 2 12:05:53 1995
***************
*** 134,139 ****
--- 134,173 ----
{ NULL }
};

+ int alias_matches (char *uri, char *alias_fakename)
+ {
+ char *end_fakename = alias_fakename + strlen (alias_fakename);
+ char *aliasp = alias_fakename, *urip = uri;
+
+ while (aliasp < end_fakename) {
+ if (*aliasp == '/') {
+ /* any number of '/' in the alias matches any number in
+ * the supplied URI, but there must be at least one...
+ */
+ if (*urip != '/') return 0;
+
+ while (*aliasp == '/') ++ aliasp;
+ while (*urip == '/') ++ urip;
+ }
+ else {
+ /* Other characters are compared literally */
+ if (*urip++ != *aliasp++) return 0;
+ }
+ }
+
+ /* Check last alias path component matched all the way */
+
+ if (aliasp[-1] != '/' && *urip != '\0' && *urip != '/')
+ return 0;
+
+ /* Return number of characters from URI which matched (may be
+ * greater than length of alias, since we may have matched
+ * doubled slashes)
+ */
+
+ return urip - uri;
+ }
+
char *try_alias_list (request_rec *r, array_header *aliases, int doesc)
{
alias_entry *entries = (alias_entry *)aliases->elts;
***************
*** 141,158 ****

for (i = 0; i < aliases->nelts; ++i) {
alias_entry *p = &entries[i];
! int l = strlen(p->fake);

! if(!strncmp(r->uri, p->fake, l)
! && (p->fake[l-1] == '/' || l == strlen(r->uri) || r->uri[l] == '/'))
! {
if (p->forced_type)
table_set (r->notes, "alias-forced-type", p->forced_type);

! if (doesc)
! {
char *escurl;
! /* would like to use os_escape_path here, but can't */
escurl = escape_uri(r->pool, r->uri + l);
return pstrcat(r->pool, p->real, escurl, NULL);
} else
--- 175,189 ----

for (i = 0; i < aliases->nelts; ++i) {
alias_entry *p = &entries[i];
! int l = alias_matches (r->uri, p->fake);

! if (l > 0) {
if (p->forced_type)
table_set (r->notes, "alias-forced-type", p->forced_type);

! if (doesc) {
char *escurl;
! /* would like to use os_escape_path here, but can't */
escurl = escape_uri(r->pool, r->uri + l);
return pstrcat(r->pool, p->real, escurl, NULL);
} else

[really quite extraordinarily deep voodoo code snipped]

Well, I *tried* to make the comments clear enough...

A long long time
ago someone mentioned that there was a bug involving problems with
slashes which caused script source to be displayed instead of executing
the script itself. Does anyone recall the precise nature of *that*
problem. Did people just fuss until they got bored but didn't get
round to fixing the snafu? Wups. ;{

I do recall a superficially similar bug --- it involved a single trailing
slash appended to the *ends* of URIs of scripts which were *not* in
ScriptAliased directories. That was fixed both in early Apache builds
(as part of my cleanups anticipating the content negotation code), and
independantly in the late NCSA 1.4 betas preceding their final ship.

This is a different problem...

rst

On Thu, 2 Nov 1995, Andrew Wilson wrote:
> > >URL exhibiting problem: http://www.apache.org//cgi-bin/access_count
>
> Mmm, well this seems to work, ie you get binary. I can't find any other
> scripts that do the same thing though. eg:
>
> http://www.apache.org//cgi-bin/test-cgi
>
> doesn't misbehave in any way. What's so special about access_count?

WHOA. Hold the horses. First:

I have

ScriptAlias /cgi-bin /usr/local/www.tools/cgi-bin

in the srm.conf file for hyperreal's web server, which means it applies
to www.apache.org as well. In that directory I have, for example,
"printenv", so

http://www.apacge.org/cgi-bin/printenv

works as expected.

Second: There is a /cgi-bin directory off the docroot for
www.apache.org, with Randy's name on it. it's used in a couple pages
being inlined like so:

<!--#exec cmd="/export/pub/apache/cgi-bin/access_count"-->

What's the result of having a cgi-bin directory off the docroot, even
though "cgi-bin" is a scriptalias somewhere else? The answer is that
while URL's like

http://www.apache.org/cgi-bin/blah

look for

/usr/local/www.tools/cgi-bin/blah

the URL

http://www.apache.org//cgi-bin/blah

looks for the *file*

/export/pub/apache/cgi-bin/access_count

Nothing says that file should be executed. I believe the original bug
poster may have been confused as to the purpose of the cgi-bin directory,
as indeed I would be, which he possibly saw by looking at
ftp://hyperreal.com/apache/.




Conclusion: the only "bug" is that Scriptalias doesn't match *pattern*,
just pattern*.

Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

At 04:29 PM 11/2/95 -0500, you wrote:
> [really quite extraordinarily deep voodoo code snipped]
>
>Well, I *tried* to make the comments clear enough...
>
> A long long time
> ago someone mentioned that there was a bug involving problems with
> slashes which caused script source to be displayed instead of executing
> the script itself. Does anyone recall the precise nature of *that*
> problem. Did people just fuss until they got bored but didn't get
> round to fixing the snafu? Wups. ;{
>
>I do recall a superficially similar bug --- it involved a single trailing
>slash appended to the *ends* of URIs of scripts which were *not* in
>ScriptAliased directories. That was fixed both in early Apache builds
>(as part of my cleanups anticipating the content negotation code), and
>independantly in the late NCSA 1.4 betas preceding their final ship.
>
>This is a different problem...

Anyone have NCSA 1.4 or 1.5 running? Is this bug still there?

<Aram>
--
Aram W. Mirzadeh, MIS Manager, Qosina Corporation
http://www.qosina.com/~awm/, awm@qosina.com
Apache httpd server team http://www.apache.org

> ack sent... I can't seem to replicate the problem, but I thought
> I would share it with group, just in case someone else can
> replicate it.
>
> I've asked for specifications on the type of system being run on
> as well as which modules are being included.
>
>
> >X-POP3-Rcpt: awm@luers.qosina.com
> >From: craig@craigster.com
> >To: awm@qosina.com
> >Date: Wed Nov 1 17:28:44 1995
> >Subject: WWW Form Bug Report: "Security bug involving ScriptAliased
> directories" on Linux
> >
> >Submitter: craig@craigster.com
> >Operating system: Linux, version: 1.2.13
> >Extra Modules used: none
> >URL exhibiting problem: http://www.apache.org//cgi-bin/access_count
> >
> >Symptoms:
> >--
> >If someone puts an extra "/" in a URL that points to
> >an executable file in a ScriptAliased directory, the
> >SOURCE of a Perl script (or binary information for
> >compiled programs) is output as plain text.

Yuk, right. Some weird interraction of the u+x code possibly.

Or perhaps...

> >The problem occurs in both Netscape and Lynx.
> >
> >Please respond ASAP, as this is a serious security
> >issue for us and we're looking for a fix. We have
> >triple-checked our configuration files, and don't
> >see any problems on our end. The bug is even evident
> >APACHE.ORG's server.

Shit. Someone check this ASAP? I think it's a showstopper.

> >X-POP3-Rcpt: awm@luers.qosina.com
> >From: craig@craigster.com
> >To: awm@qosina.com
> >Date: Wed Nov 1 17:28:44 1995
> >Subject: WWW Form Bug Report: "Security bug involving ScriptAliased
> directories" on Linux
> >
> >Submitter: craig@craigster.com
> >Operating system: Linux, version: 1.2.13
> >Extra Modules used: none
> >URL exhibiting problem: http://www.apache.org//cgi-bin/access_count

Mmm, well this seems to work, ie you get binary. I can't find any other
scripts that do the same thing though. eg:

http://www.apache.org//cgi-bin/test-cgi

doesn't misbehave in any way. What's so special about access_count?

> >Symptoms:
> >--
> >If someone puts an extra "/" in a URL that points to
> >an executable file in a ScriptAliased directory, the
> >SOURCE of a Perl script (or binary information for
> >compiled programs) is output as plain text.
> >
> >The problem occurs in both Netscape and Lynx.
> >
> >Please respond ASAP, as this is a serious security
> >issue for us and we're looking for a fix. We have
> >triple-checked our configuration files, and don't
> >see any problems on our end. The bug is even evident
> >APACHE.ORG's server.

*yelp* a showstopper.

Ay.

> The bug here seems to be that the Alias command and its (effective) variants
> can be foxed by giving them URIs with doubled slashes, which then fail to
> match. In particular, if the target directory of a ScriptAlias command is
> actually, say, the cgi-bin subdirectory of DocumentRoot, this can be used
> to disable the effects of ScriptAlias. Here is a patch against *0.8.16*
> which appears to cure the problem:

[really quite extraordinarily deep voodoo code snipped]

Agreed. This bug also exists in 0.6.5 and NCSA 1.3R!. A long long time
ago someone mentioned that there was a bug involving problems with
slashes which caused script source to be displayed instead of executing
the script itself. Does anyone recall the precise nature of *that*
problem. Did people just fuss until they got bored but didn't get
round to fixing the snafu? Wups. ;{

Ay.

ps. this area of code is DANGEROUSLY arcane now - that is where
bugs come from.

> [really quite extraordinarily deep voodoo code snipped]
>
> Well, I *tried* to make the comments clear enough...

Yeah, but I still had to read them to understand ;)

> A long long time
> ago someone mentioned that there was a bug involving problems with
> slashes which caused script source to be displayed instead of executing
> the script itself. Does anyone recall the precise nature of *that*
> problem. Did people just fuss until they got bored but didn't get
> round to fixing the snafu? Wups. ;{
>
> I do recall a superficially similar bug --- it involved a single trailing
> slash appended to the *ends* of URIs of scripts which were *not* in
> ScriptAliased directories. That was fixed both in early Apache builds
> (as part of my cleanups anticipating the content negotation code), and
> independantly in the late NCSA 1.4 betas preceding their final ship.
>
> This is a different problem...

As I thought.

> rst

Ay.

I have 0.8.16 (from rst) running on our main server (www.ics.uci.edu).
No problems, and I was unable to duplicate any security problem
with double-slashes in cgi-bin requests.

.....Roy

Conclusion: the only "bug" is that Scriptalias doesn't match *pattern*,
just pattern*.

Actually, the mismatch conditions are a little more specific, but that's
a fair summary... it also suggests the two workarounds I've thought of,
which are:

1) to set Options ExecCGI and DefaultType application/x-httpd-cgi in the
directory (either via <Directory> or .htaccess)

2) Just move the cgi-bin directory out of DocumentRoot.

rst