Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-Id: <5.1.0.14.2.20021101155513.0315d7b0@pop3.rowe-clan.net>
Date: Fri, 01 Nov 2002 16:12:19 -0600
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@apache.org>
Subject: Re: workaround for encoded slashes (%2f)
Cc: dev@httpd.apache.org,dev@httpd.apache.org
In-Reply-To: <5.1.0.14.2.20021101125959.02c0d5f0@pop3.rowe-clan.net>
References: <3DC2C117.C5189C11@Golux.Com>
 <83100D46-EC49-11D6-B519-000393753936@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 01:02 PM 11/1/2002, William A. Rowe, Jr. wrote:
>At 11:59 AM 11/1/2002, Rodent of Unusual Size wrote:
>>"Roy T. Fielding" wrote:
>>> 
>>> Your patch will simply let the %2F through, but then a later section
>>> of code will translate them to / and we've opened a security hole
>>> in the main server.  I'd rather move the rejection code to the
>>> place where a decision has to be made (like the directory walk),
>>> but I have no time to do it myself.  I think it is reasonable to
>>> allow %2F under some circumstances, but only in content handlers
>>> and only as part of path-info and not within the real directory
>>> structure.
>>
>>is this a veto?  because i'd like to understand how this
>>'opens a security hole' available to client-side exploitation
>>without server-side deficiencies (such as a poorly-coded cgi
>>script).  if there is none, i don't see why this cannot go
>>in as a starting point.
>
>Yes, it's a veto to introduce a security hole as a 'starting point' that
>someone might get around to cleaning up later.

And contrawise, might not be cleaned up till it's reported to bugtraq.
I'm suggesting that in the interest of security, we be absolutely
cautious before allowing admins to open themselves to such a
can of worms.

Perhaps this is not a technical issue.  You argue that the behavior
of the server is not a technical issue, only code has technical veto
merit.  I respectfully disagree, and feel that the code's behavior is
a technical issue, and we won't come eye to eye on this.

But my statement did come across antagonistic, and I apologize.
I should have said that "because of the potential for issues, I object
to this code on the grounds of secuirty, and as a matter of courtesy 
to third party module authors.  Can this please wait for 2.1-dev so 
everyone in the wider community (including our bugtraqers) have 
a chance to look at the impact of this change?"

>If you want to do something this radical, you are going to need to
>float it into 2.1-dev.  Then we can at least insist that 2.2 module
>authors do the 'right thing' for security, whatever that is.

This was perhaps badly worded.  We disagree on the merits of an
API/server behavior change as a "technical" issue.

However, I'm not against (veto or otherwise) introducing this to 2.1-dev
so that module authors and we can thoroughly tear this code apart
and be 99.98% certain that no vulnerabilities are introduced.

>Anyone looking at unparsed_uri is subject to falling into this hole.
>That would be a good place to start looking for newly introduced
>vulnerabilities with your patch.

I apologize for the offense I caused.  This is a very serious matter that
we are looking at through different glasses (or monocles).  Please 
consider the advantages of putting forward this patch to the very first
2.1.0-beta release so all module authors begin looking at the impact
from day one of 2.2 module development.

Bill