CVE-2011-3368 not fully fixed?

2011-10-25 Thread Marcus Meissner
Hi, I probably have overlooked something, but while QAing our Apache (2.2.12 based) updates it seems CVE-2011-3368 is not fully fixed by the patch referenced. With the RewriteRule within the VirtualHost *:80 section, RewriteEngine on RewriteRule (.*)\.(ico|jpg|gif|png)

RE: CVE-2011-3368 not fully fixed?

2011-10-25 Thread Plüm, Rüdiger, VF-Group
Can you please check if the following patch fixes this issue? Index: protocol.c === --- protocol.c (revision 1181036) +++ protocol.c (working copy) @@ -672,6 +672,7 @@ r-hostname = NULL; r-status =

Re: RFE: Control of HTTP cache control headers within mod_rewrite rules

2011-10-25 Thread Noah Robin
I ran some tests on this and the following modified version will work: Header always set Cache-Control max-age=%{CACHE_LIFETIME}e env=CACHE_LIFETIME RewriteRule /example http://www.example.com/ [E=CACHE_LIFETIME:604800] ..however, this still leaves an open question in my mind: How to solve for

Re: CVE-2011-3368 not fully fixed?

2011-10-25 Thread Marcus Meissner
Hi Rüdiger, I ported your patch to our 2.2.12 codebase (attached) and my testcase now correctly reports a 400 from the testserver when doing GET @www.suse.de/foo.png as request. Ciao, Marcus On Tue, Oct 25, 2011 at 02:49:08PM +0200, Plüm, Rüdiger, VF-Group wrote: Can you please check if the

RE: CVE-2011-3368 not fully fixed?

2011-10-25 Thread Plüm, Rüdiger, VF-Group
Thanks for testing. Applied to trunk as r1188745. Regards Rüdiger -Original Message- From: Marcus Meissner [mailto:meiss...@suse.de] Sent: Dienstag, 25. Oktober 2011 17:48 To: dev@httpd.apache.org Subject: Re: CVE-2011-3368 not fully fixed? Hi Rüdiger, I ported your patch

RE: CVE-2011-3368 not fully fixed?

2011-10-25 Thread Plüm, Rüdiger, VF-Group
I did some further analysis. While the patch for trunk is still fine as it shortens the path for bailing out the behaviour was already correct with trunk and 2.2.21. So the HTTP/0.9 behaviour you see does NOT happen with 2.2.x = 2.2.18 (plus patch) and trunk. You are affected by an old logic that

Re: CVE-2011-3368 not fully fixed?

2011-10-25 Thread William A. Rowe Jr.
On 10/25/2011 11:21 AM, Plüm, Rüdiger, VF-Group wrote: I did some further analysis. While the patch for trunk is still fine as it shortens the path for bailing out the behaviour was already correct with trunk and 2.2.21. So the HTTP/0.9 behaviour you see does NOT happen with 2.2.x = 2.2.18

RE: CVE-2011-3368 not fully fixed?

2011-10-25 Thread Plüm, Rüdiger, VF-Group
-Original Message- From: William A. Rowe Jr. [mailto:wr...@rowe-clan.net] Sent: Dienstag, 25. Oktober 2011 18:44 To: dev@httpd.apache.org Subject: Re: CVE-2011-3368 not fully fixed? On 10/25/2011 11:21 AM, Plüm, Rüdiger, VF-Group wrote: I did some further analysis. While the

RE: CVE-2011-3368 not fully fixed?

2011-10-25 Thread Plüm, Rüdiger, VF-Group
-Original Message- From: Plüm, Rüdiger, VF-Group [mailto:ruediger.pl...@vodafone.com] Sent: Dienstag, 25. Oktober 2011 18:48 To: dev@httpd.apache.org Subject: RE: CVE-2011-3368 not fully fixed? -Original Message- From: William A. Rowe Jr.

Re: svn commit: r1186545 - /httpd/httpd/trunk/server/mpm/simple/simple_io.c

2011-10-25 Thread Jim Jagielski
These types of things exist for a reason. Please don't remove them… On Oct 19, 2011, at 6:40 PM, s...@apache.org wrote: Author: sf Date: Wed Oct 19 22:40:06 2011 New Revision: 1186545 URL: http://svn.apache.org/viewvc?rev=1186545view=rev Log: Comment out some incomplete code that does

Re: Really big regex results from ap_pregsub

2011-10-25 Thread Jim Jagielski
On Oct 18, 2011, at 5:59 PM, Stefan Fritsch wrote: On Tue, 18 Oct 2011, Greg Ames wrote: On Fri, Oct 14, 2011 at 2:34 PM, Stefan Fritsch s...@sfritsch.de wrote: Btw, isn't the nmatch the number of () pairs in the regex? If so, then enforcing the AP_MAX_REG_MATCH limit could introduce

Re: Really big regex results from ap_pregsub

2011-10-25 Thread William A. Rowe Jr.
On 10/25/2011 12:04 PM, Jim Jagielski wrote: On Oct 18, 2011, at 5:59 PM, Stefan Fritsch wrote: On Tue, 18 Oct 2011, Greg Ames wrote: On Fri, Oct 14, 2011 at 2:34 PM, Stefan Fritsch s...@sfritsch.de wrote: Btw, isn't the nmatch the number of () pairs in the regex? If so, then enforcing

Re: Really big regex results from ap_pregsub

2011-10-25 Thread Jim Jagielski
On Oct 25, 2011, at 1:23 PM, William A. Rowe Jr. wrote: Well there often a legitimate call to substituting /$1/$2/$3/$1$2$3 (think of the way we break down mod_cache_disk file trees, or how some /homes/ are organized). So as a substitution counter, AP_MAX_REG_///MATCH/// is not the right

Re: svn commit: r1186545 - /httpd/httpd/trunk/server/mpm/simple/simple_io.c

2011-10-25 Thread William A. Rowe Jr.
On 10/25/2011 12:00 PM, Jim Jagielski wrote: These types of things exist for a reason. Please don't remove them… Nobody left a comment to explain why it was left dangling, and it does nothing. +1 - remove it. http://badprogrammer.infogami.com/ ... c.f. Collyer Brothers syndrome

Re: Really big regex results from ap_pregsub

2011-10-25 Thread William A. Rowe Jr.
On 10/25/2011 12:34 PM, Jim Jagielski wrote: iirc, nmatch simply prevented things like $11, $12, $99, etc... But these are never parsed, right? Only $1 - $9? Is there a use case to redux this below 10?

Re: Really big regex results from ap_pregsub

2011-10-25 Thread William A. Rowe Jr.
On 10/25/2011 12:41 PM, William A. Rowe Jr. wrote: On 10/25/2011 12:34 PM, Jim Jagielski wrote: iirc, nmatch simply prevented things like $11, $12, $99, etc... But these are never parsed, right? Only $1 - $9? Is there a use case to redux this below 10? I also understood that grouping

Re: svn commit: r1186545 - /httpd/httpd/trunk/server/mpm/simple/simple_io.c

2011-10-25 Thread William A. Rowe Jr.
On 10/25/2011 12:39 PM, William A. Rowe Jr. wrote: On 10/25/2011 12:00 PM, Jim Jagielski wrote: These types of things exist for a reason. Please don't remove them… Nobody left a comment to explain why it was left dangling, and it does nothing. +1 - remove it.