Rodent of Unusual Size wrote:
okey, here is the patch. i have been unable to detect any
security flaws in my testing. please apply and test this
as fixing the existing issue in a 'good enough' way until
a rework/redesign of the filesystem intertwingling is addressed.
no negative remarks, so
At 10:10 AM 1/16/2003, Rodent of Unusual Size wrote:
Rodent of Unusual Size wrote:
okey, here is the patch. i have been unable to detect any
security flaws in my testing. please apply and test this
as fixing the existing issue in a 'good enough' way until
a rework/redesign of the filesystem
William A. Rowe, Jr. wrote:
I should be able to blow some holes in the patch, but I can't do that
right now while spending so many hours vetting our coming 2.0.44
release, and I consider it more than a little gratuitous that you presume
lazy consensus on a patch that I'd vetoed in theory.
William A. Rowe, Jr. wrote:
I consider it more than a little gratuitous that you presume
lazy consensus on a patch that I'd vetoed in theory. I then agreed
oh, and by the way? i said i'd presume lazy consensus in a couple of days,
not right now. so i'm allowing plenty of time for
Rodent of Unusual Size wrote:
no negative remarks, so i'm going to assume lazy consensus in
a couple of days and commit it into all three branches.
not for 2.0.44, though.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist
From: Rodent of Unusual Size [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 16, 2003 9:05 PM
Rodent of Unusual Size wrote:
no negative remarks, so i'm going to assume lazy consensus in
a couple of days and commit it into all three branches.
not for 2.0.44, though.
To get it into
Greg Stein wrote:
Product features and changes *are* subject to majority vote, however, which
is why Ken is operating under a (lazy) consensus model.
for 2.1 only I hope... 2.0 is supposed to be R-T-C...
On Mon, Jan 13, 2003 at 06:46:19AM -0500, Rodent of Unusual Size wrote:
okey, here's anpther take on the %2f thing. as a reminder, we
currently reject any reques that includes an encoded slash in the
pat with a 404. this breaks environments which need to use %2f in
the path info. the issue
At 04:37 PM 1/13/2003, Greg Stein wrote:
On Mon, Jan 13, 2003 at 06:46:19AM -0500, Rodent of Unusual Size wrote:
okey, here's anpther take on the %2f thing. as a reminder, we
currently reject any reques that includes an encoded slash in the
pat with a 404. this breaks environments which need
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
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
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
William A. Rowe, Jr. wrote:
Yes, it's a veto to introduce a security hole as a 'starting point' that
someone might get around to cleaning up later.
demonstrate that it is a security hole in the server.
if you cannot demonstrate that this opens the server to
client-side attack, i do not regard
based on some offline discussion, i am going to table this
for now and try suitably modified versions of the %5c attack
against the patched server.
Rodent of Unusual Size wrote:
based on some offline discussion, i am going to table this
for now and try suitably modified versions of the %5c attack
against the patched server.
without a demonstrable technical justification, i still consider
it an invalid veto, but the concerns and
On Wed, Oct 30, 2002 at 06:09:04PM -0600, William A. Rowe, Jr. wrote:
At 04:43 PM 10/30/2002, Bill Stoddard wrote:
At 02:52 PM 10/30/2002, 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
William A. Rowe, Jr. wrote:
3.2.3 URI Comparison ...
*** Characters other than those in the reserved and unsafe sets (see RFC 2396
[42]) are equivalent to their % HEX HEX encoding. For example, the following
three URIs are equivalent:
http://abc.com:80/~smith/home.html
since a server version long long ago in a century far far away,
we have automatically pitched any request with a uri containing
an encoded slash (i.e., %2f). this was chosen as default behaviour
as pre-emptive defence of lame cgi scripts which might not bother
to validate their input (gasp!).
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.
At 02:52 PM 10/30/2002, 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
At 02:52 PM 10/30/2002, 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
William A. Rowe, Jr. wrote:
Because loc_walk, dir_walk and family all deal in parsed URIs, and
we have a 256 character code page, there is no way to disambiguate
the %2f from a '/'. If those families handled the unparsed URI we could
do this with no problem, because they would be able to
22 matches
Mail list logo
