You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Randy Terbush <ra...@zyzzyva.com> on 1997/01/16 03:01:15 UTC
Re: http_access.c modification for 1.1.3 (fwd)
------- Blind-Carbon-Copy
To: jns@cisco.com, domatthe@cisco.com
Subject: Re: http_access.c modification for 1.1.3 (fwd)
In-reply-to: robh's message of Thu, 16 Jan 1997 00:58:18 +0000.
<Pi...@ponty.imdb.com>
X-uri: http://www.zyzzyva.com/
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 15 Jan 1997 20:01:15 -0600
From: Randy Terbush <ra...@sierra>
I believe that the is_scriptaliased() check would require the
CGI to reside in a ScriptAliased directory. Not desireable in
my opinion since we don't use this directive in any of our
installations.
We were forced to move rather quickly to address this problem.
In our quick scan of available systems, we found no OS that
did not support both of these conditions. We are still debating
the ultimate solution for 1.2.
Regarding the correct return codes, perhaps one of the protocol
experts in the group can comment.
Thanks for using Apache.
> not acked
>
> ---------- Forwarded message ----------
> Date: Wed, 15 Jan 1997 14:03:41 -0800
> From: John Stewart <jn...@cisco.com>
> To: apache-bugs@apache.org
> Cc: domatthe@cisco.com
> Subject: http_access.c modification for 1.1.3
>
>
> Doug Matthews and I submitted a bug against 1.1.2 regarding cgi-bin
> programs, which you fixed in 1.1.3, but we still view the fix as an
> issue.
>
> Our patch to the 1.1.3 code base follows. We've made some
> assumptions, which if are wrong, we'd appreciate knowing.
>
> First, the circumstances where the stat fails with an error code which
> isn't understood, on a machine which doesn't have ENOENT and or
> ENOTDIR, should still be processed through the CGI is_scriptaliased to
> determine whether or not it is a valid script -- since CGI's are the
> situation where the tests break down.
>
> Second, given that CGI's were the scenario where 1.1.2 broke down, the
> 1.1.3 patches should be checking against not only ENOTDIR but also
> is_scriptaliased. Witness the issue when the URL
> http://www/index.html/access is triggered.
>
> In this circumstance, with ENOTDIR enabled in the OS, the path is
> invalid, but then the path is *still* parsed to get the baseline for
> presentation. At the time it is determined the file isn't found, the
> return code is NOT_FOUND and the error handler directive for 404, if
> defined, takes over.
>
> Problem is, you are *still* parsing the URL, which if nothing else is
> inefficient. Instead, we're suggesting that if ENOTDIR is determined
> *and* it is a script (which to our knowledge is the only circumstance
> where this happens to be valid) then continue parsing.
>
> And if not, here is another change, return NOT_FOUND instead of
> FORBIDDEN. We noticed that the 404 error handler -- which according
> to the definitions of NOT_FOUND -- should have been triggered and
> wasn't.
>
> Maybe we're in left field, who knows -- well, you guys know. Tell us.
>
> thx -- John
>
>
> ------=------=------=------=------=------=------=------=------=------
>
> *** http_request.c 1997/01/15 21:37:03 1.1
> --- http_request.c 1997/01/15 21:42:28
> ***************
> *** 179,191 ****
> *cp = '\0';
> return OK;
> }
> ! #if defined(ENOENT) && defined(ENOTDIR)
> ! else if (errno == ENOENT || errno == ENOTDIR) {
> #else
> #error Your system apparently does not define ENOENT || ENOTDIR.
> #error Removal of these lines opens a security hole if protecting
> #error from directory indexes with DirectoryIndex.
> ! else {
> #endif
> last_cp = cp;
>
> --- 179,192 ----
> *cp = '\0';
> return OK;
> }
> ! #if defined(ENOENT)
> ! else if (errno == ENOENT ||
> ! (errno == ENOTDIR && is_scriptaliased(r))) {
> #else
> #error Your system apparently does not define ENOENT || ENOTDIR.
> #error Removal of these lines opens a security hole if protecting
> #error from directory indexes with DirectoryIndex.
> ! else if (is_scriptaliased(r)) {
> #endif
> last_cp = cp;
>
> ***************
> *** 195,206 ****
> while (cp > path && cp[-1] == '/')
> --cp;
> }
> - #if defined(ENOENT) && defined(ENOTDIR)
> else {
> log_printf(r->server, "access to %s failed for client; unable to determine if index file exists (stat() returned unexpected error[%d])", r->filename, errno);
> ! return FORBIDDEN;
> }
> - #endif
> }
>
> return OK;
> --- 196,205 ----
> while (cp > path && cp[-1] == '/')
> --cp;
> }
> else {
> log_printf(r->server, "access to %s failed for client; unable to determine if index file exists (stat() returned unexpected error[%d])", r->filename, errno);
> ! return NOT_FOUND;
> }
> }
>
> return OK;
>
>
------- End of Blind-Carbon-Copy
Re: http_access.c modification for 1.1.3 (fwd)
Posted by Marc Slemko <ma...@znep.com>.
On Wed, 15 Jan 1997, Randy Terbush wrote:
> ------- Blind-Carbon-Copy
>
> To: jns@cisco.com, domatthe@cisco.com
> Subject: Re: http_access.c modification for 1.1.3 (fwd)
> In-reply-to: robh's message of Thu, 16 Jan 1997 00:58:18 +0000.
> <Pi...@ponty.imdb.com>
> X-uri: http://www.zyzzyva.com/
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Date: Wed, 15 Jan 1997 20:01:15 -0600
> From: Randy Terbush <ra...@sierra>
>
>
> I believe that the is_scriptaliased() check would require the
> CGI to reside in a ScriptAliased directory. Not desireable in
> my opinion since we don't use this directive in any of our
> installations.
I'm sure you could replace what they are saying with a check to see if it
is a CGI of any sort. I agree with some of what they are saying; more
comments below.
> We were forced to move rather quickly to address this problem.
> In our quick scan of available systems, we found no OS that
> did not support both of these conditions. We are still debating
> the ultimate solution for 1.2.
>
> Regarding the correct return codes, perhaps one of the protocol
> experts in the group can comment.
>
> Thanks for using Apache.
>
> > not acked
> >
> > ---------- Forwarded message ----------
> > Date: Wed, 15 Jan 1997 14:03:41 -0800
> > From: John Stewart <jn...@cisco.com>
> > To: apache-bugs@apache.org
> > Cc: domatthe@cisco.com
> > Subject: http_access.c modification for 1.1.3
> >
> >
> > Doug Matthews and I submitted a bug against 1.1.2 regarding cgi-bin
> > programs, which you fixed in 1.1.3, but we still view the fix as an
> > issue.
> >
> > Our patch to the 1.1.3 code base follows. We've made some
> > assumptions, which if are wrong, we'd appreciate knowing.
> >
> > First, the circumstances where the stat fails with an error code which
> > isn't understood, on a machine which doesn't have ENOENT and or
> > ENOTDIR, should still be processed through the CGI is_scriptaliased to
> > determine whether or not it is a valid script -- since CGI's are the
> > situation where the tests break down.
I think there is something wrong in this bit if ENOENT and/or ENOTDIR
aren't defined, but don't have the time to sort through it now.
> >
> > Second, given that CGI's were the scenario where 1.1.2 broke down, the
> > 1.1.3 patches should be checking against not only ENOTDIR but also
> > is_scriptaliased. Witness the issue when the URL
> > http://www/index.html/access is triggered.
> >
> > In this circumstance, with ENOTDIR enabled in the OS, the path is
> > invalid, but then the path is *still* parsed to get the baseline for
> > presentation. At the time it is determined the file isn't found, the
> > return code is NOT_FOUND and the error handler directive for 404, if
> > defined, takes over.
> >
> > Problem is, you are *still* parsing the URL, which if nothing else is
> > inefficient. Instead, we're suggesting that if ENOTDIR is determined
> > *and* it is a script (which to our knowledge is the only circumstance
> > where this happens to be valid) then continue parsing.
Possibly worthwhile considering, but as Randy said you need a more complex
check than that to see if it is a CGI. Complexity bad.
Part of this is the basic design of the index module too; "we have no idea
what this is, but hey let's try seeing if it is a file".
> >
> > And if not, here is another change, return NOT_FOUND instead of
> > FORBIDDEN. We noticed that the 404 error handler -- which according
> > to the definitions of NOT_FOUND -- should have been triggered and
> > wasn't.
We do not know that it is not found. We know that we will not let you
access that path because it isn't secure, so it is forbidden. RFC 2068
says:
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe the
reason for the refusal in the entity. This status code is commonly
used when the server does not wish to reveal exactly why the request
has been refused, or when no other response is applicable.
I think that applies to this case. We don't want to reveal exactly why
the request was refused because, to some degree, we don't know exactly
why.
That said, it is also an argument for a 404.
10.4.5 404 Not Found
The server has not found anything matching the Request-URI. No
indication is given of whether the condition is temporary or
permanent.
It is true that we can't find anything matching the request; it may be
there but we aren't willing to look further because of possible risks. On
top of that, it returns any nice 404 handler you have. I still don't like
saying not found just because it isn't your typical not found, but the
issue should be considered.
> >
> > Maybe we're in left field, who knows -- well, you guys know. Tell us.
> >
> > thx -- John
> >
> >
> > ------=------=------=------=------=------=------=------=------=------
> >
> > *** http_request.c 1997/01/15 21:37:03 1.1
> > --- http_request.c 1997/01/15 21:42:28
> > ***************
> > *** 179,191 ****
> > *cp = '\0';
> > return OK;
> > }
> > ! #if defined(ENOENT) && defined(ENOTDIR)
> > ! else if (errno == ENOENT || errno == ENOTDIR) {
> > #else
> > #error Your system apparently does not define ENOENT || ENOTDIR.
> > #error Removal of these lines opens a security hole if protecting
> > #error from directory indexes with DirectoryIndex.
> > ! else {
> > #endif
> > last_cp = cp;
> >
> > --- 179,192 ----
> > *cp = '\0';
> > return OK;
> > }
> > ! #if defined(ENOENT)
> > ! else if (errno == ENOENT ||
> > ! (errno == ENOTDIR && is_scriptaliased(r))) {
> > #else
> > #error Your system apparently does not define ENOENT || ENOTDIR.
> > #error Removal of these lines opens a security hole if protecting
> > #error from directory indexes with DirectoryIndex.
> > ! else if (is_scriptaliased(r)) {
> > #endif
> > last_cp = cp;
> >
> > ***************
> > *** 195,206 ****
> > while (cp > path && cp[-1] == '/')
> > --cp;
> > }
> > - #if defined(ENOENT) && defined(ENOTDIR)
> > else {
> > log_printf(r->server, "access to %s failed for client; unable to determine if index file exists (stat() returned unexpected error[%d])", r->filename, errno);
> > ! return FORBIDDEN;
> > }
> > - #endif
> > }
> >
> > return OK;
> > --- 196,205 ----
> > while (cp > path && cp[-1] == '/')
> > --cp;
> > }
> > else {
> > log_printf(r->server, "access to %s failed for client; unable to determine if index file exists (stat() returned unexpected error[%d])", r->filename, errno);
> > ! return NOT_FOUND;
> > }
> > }
> >
> > return OK;
> >
> >
>
>
>
>
> ------- End of Blind-Carbon-Copy
>