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)
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 =
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
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
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
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
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
-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
-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.
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
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
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
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
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
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?
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
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.
17 matches
Mail list logo