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.20021101125959.02c0d5f0@pop3.rowe-clan.net>
Date: Fri, 01 Nov 2002 13:02:28 -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
In-Reply-To: <3DC2C117.C5189C11@Golux.Com>
References: <83100D46-EC49-11D6-B519-000393753936@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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.

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.

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.

Bill