On Wed, Aug 24, 2011 at 23:59, Chris London ch...@kwista.com wrote:
Hey everyone,
I don't like to bother mailing lists with beginner questions so I spent
a few hours on Google looking for info and tutorials. I'm sure at least one
of you has had that experience :) Anyway, I have finished my
Hello dear community -
I need to create some kind of proxy using Apache Server.
I tried to use something like
ProxyPass /test1/test2/ http://another_server/test/test.dll but had no
success because ProxyPass require / suffix after the second URL (something
like
Do you mean, Nick, that I have submitted the question to the wrong branch?
Nick Kew-3 wrote:
On 25 Aug 2011, at 10:15, Denys wrote:
Any kind of help is greatly appreciated.
Start by reading TFM.
If you still can't understand, try a user support forum.
View this message in
On 25 Aug 2011, at 11:04, Denys wrote:
Do you mean, Nick, that I have submitted the question to the wrong branch?
branch? What's a branch? This is a mailing list for module developers!
Sorry, my reply was OTT. I just get a bit cross at some of the stuff that gets
misdirected from
On 25 Aug 2011, at 11:04, Denys wrote:
Do you mean, Nick, that I have submitted the question to the wrong branch?
branch? What's a branch? This is a mailing list for module developers!
Sorry, my reply was OTT. I just get a bit cross at some of the stuff that gets
misdirected from
On Thursday 25 August 2011, Jim Jagielski wrote:
OK then… we seem to be coalescing into some consensus here…
basically, if the client sends stuff which is brain-dead stupid,
we simply 2000 and send the whole kit-and-kaboodle.
I'd like to propose that we update the byterange filter to perform
Thanks. Added to the interim draft update.
Dw.
On 25 Aug 2011, at 06:36, Steffen wrote:
For Mitigation of Apache Range Header DoS Attack with mod_security, see
also:
http://blog.spiderlabs.com/2011/08/mitigation-of-apache-range-header-dos-attack.html
- Original Message -
On 24 Aug 2011, at 22:16, Stefan Fritsch wrote:
I have another idea: Instead of using apr_brigade_partition write a
new function ap_brigade_copy_part that leaves the original brigade
untouched. It would copy the necessary buckets to a new brigade and
then split the first and last of those
-Original Message-
From: Stefan Fritsch
Sent: Donnerstag, 25. August 2011 08:21
To: dev@httpd.apache.org
Subject: Re: DoS with mod_deflate range requests
On Thursday 25 August 2011, Jim Jagielski wrote:
OK then... we seem to be coalescing into some consensus here...
I am keeping a draft at
http://people.apache.org/~dirkx/CVE-2011-3192.txt
Changes since last are:
- version ranges more specific
- vendor information added
- backgrounder on relation to 2007 issues (see below to ensure I got this
right).
I suggest we sent this out
Tested and this does appear to both address the DoS as well as
reduce memory usage for excessive range requests…
+1 for adding this no matter what.
On Aug 24, 2011, at 7:38 PM, Stefan Fritsch wrote:
On Thursday 25 August 2011, Greg Ames wrote:
On Wed, Aug 24, 2011 at 5:16 PM, Stefan Fritsch
On Aug 25, 2011, at 2:56 AM, Plüm, Rüdiger, VF-Group wrote:
-Original Message-
From: Stefan Fritsch
Sent: Donnerstag, 25. August 2011 08:21
To: dev@httpd.apache.org
Subject: Re: DoS with mod_deflate range requests
On Thursday 25 August 2011, Jim Jagielski wrote:
OK then...
On 25 Aug 2011, at 12:40, Jim Jagielski wrote:
Tested and this does appear to both address the DoS as well as
reduce memory usage for excessive range requests…
+1 for adding this no matter what.
Yup - same here. Makes PDF serving a heck of a lot better too.
Dw.
On Aug 24, 2011, at
I have a feeling that we could push this out today…
I'm going to fold Stefan's path into trunk, and we should use
trunk (CTR) to polish up the patch as well as add whatever
other features we need. From there, backporting to 2.2/2.0
will be trivial.
On Aug 25, 2011, at 4:18 AM, Dirk-Willem van
-Original Message-
From: Stefan Fritsch
Sent: Donnerstag, 25. August 2011 01:39
To: dev@httpd.apache.org
Subject: Re: Fixing Ranges
On Thursday 25 August 2011, Greg Ames wrote:
On Wed, Aug 24, 2011 at 5:16 PM, Stefan Fritsch s...@sfritsch.de
wrote:
I have another idea:
+1
Regards
Rüdiger
-Original Message-
From: Jim Jagielski [mailto:j...@jagunet.com]
Sent: Donnerstag, 25. August 2011 14:13
To: dev@httpd.apache.org
Subject: Re: Next update on CVE-2011-3192
I have a feeling that we could push this out today...
I'm going to fold Stefan's
On Thu, 25 Aug 2011, Plüm, Rüdiger, VF-Group wrote:
I think it would be best if you could commit this PoC patch as is (or
with adjustments according to the comments above) to trunk and we polish
it up in trunk until it is fine.
Somebody else go ahead and commit it, please. I won't have time
PoC folded into trunk… Let's go ;)
On Aug 25, 2011, at 8:16 AM, Plüm, Rüdiger, VF-Group wrote:
-Original Message-
From: Stefan Fritsch
Sent: Donnerstag, 25. August 2011 01:39
To: dev@httpd.apache.org
Subject: Re: Fixing Ranges
On Thursday 25 August 2011, Greg Ames wrote:
Now that the memory utilz is being fixed, we need to determine
what sort of usage we want to allow… I'm guessing that people
are ok with http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311
as the guiding spec?
+1 for 2.3, -0 for 2.2. I guess for 2.2 we should only detect misuse (the
definition of misuse
needs to configurable) and reply with a 200 if misuse is detected.
misuse would be
- too much ranges [Let the number be configurable with a sane default e.g. 100
and a possible setting of 0 for
Hi Dirk-Willem, list.
I wasn't sure whether to mail this in, it is inconsequential; the
module is supposed to count the number of ranges, but it actually
counts the number of commas between ranges, leading to an off-by-one.
IE, a request with 6 ranges would not be rejected, where as the code
has
I'm playing around w/ ap_set_byterange() for the merging and
detection part, but that should not hold up release with the
optimized code…
I can do a 2.2.10 release with the byte range stuff once we
agree on the back port and confirm it fixes the problem...
On Thu, Aug 25, 2011 at 10:25 AM, Jim Jagielski j...@jagunet.com wrote:
Now that the memory utilz is being fixed, we need to determine
what sort of usage we want to allow… I'm guessing that people
are ok with http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311
as the guiding spec?
I'm no
On 8/25/2011 11:45 AM, Greg Ames wrote:
On Thu, Aug 25, 2011 at 10:25 AM, Jim Jagielski j...@jagunet.com
mailto:j...@jagunet.com
wrote:
Now that the memory utilz is being fixed, we need to determine
what sort of usage we want to allow… I'm guessing that people
are ok with
On 8/25/2011 11:24 AM, Jim Jagielski wrote:
I'm playing around w/ ap_set_byterange() for the merging and
detection part, but that should not hold up release with the
optimized code…
I can do a 2.2.10 release with the byte range stuff once we
agree on the back port and confirm it fixes the
I agree we don't *need* to, but we should…
And we do (now)
On Aug 25, 2011, at 12:45 PM, Greg Ames wrote:
On Thu, Aug 25, 2011 at 10:25 AM, Jim Jagielski j...@jagunet.com wrote:
Now that the memory utilz is being fixed, we need to determine
what sort of usage we want to allow… I'm guessing
On Aug 25, 2011, at 1:45 PM, William A. Rowe Jr. wrote:
On 8/25/2011 11:24 AM, Jim Jagielski wrote:
I'm playing around w/ ap_set_byterange() for the merging and
detection part, but that should not hold up release with the
optimized code…
I can do a 2.2.10 release with the byte range stuff
On 25 Aug 2011, at 15:48, Plüm, Rüdiger, VF-Group wrote:
+1 for 2.3, -0 for 2.2. I guess for 2.2 we should only detect misuse (the
definition of misuse
needs to configurable) and reply with a 200 if misuse is detected.
Ok - given the patch a good test - and actually - am not sure we need
On 25 Aug 2011, at 17:45, Greg Ames wrote:
On Thu, Aug 25, 2011 at 10:25 AM, Jim Jagielski j...@jagunet.com wrote:
Now that the memory utilz is being fixed, we need to determine
what sort of usage we want to allow… I'm guessing that people
are ok with
On 25 Aug 2011, at 15:53, Tom Evans wrote:
I wasn't sure whether to mail this in, it is inconsequential; the
module is supposed to count the number of ranges, but it actually
counts the number of commas between ranges, leading to an off-by-one.
IE, a request with 6 ranges would not be
On 25 Aug 2011, at 15:48, Plüm, Rüdiger, VF-Group wrote:
For 2.3 the last one could be 3 state:
off - Don't do anything about that
on - reply with 200 if misuse is detected.
optimize - Do sorts and merges and fill too small chunks between the ranges.
Default for 2.3 would be optimize.
I
On Aug 25, 2011, at 2:27 PM, Dirk-Willem van Gulik wrote:
On 25 Aug 2011, at 17:45, Greg Ames wrote:
On Thu, Aug 25, 2011 at 10:25 AM, Jim Jagielski j...@jagunet.com wrote:
Now that the memory utilz is being fixed, we need to determine
what sort of usage we want to allow… I'm guessing
Folks,
What is wisdom? We have an updated version at
people.apache.org/CVE-2011-3192.txt.
i'd say, let's send this of day if we expect the full patch to take another 24+
hours. As there is a need for the i proved mitigations And otherwise skip it
and go to final ASAP?
What is your take ?
For us to be able to control the number of overlaps, ranges,
etc will require an API bump to add an entry to server_rec.
Are we sure we want to do that for 2.2 or save that for trunk?
On Aug 25, 2011, at 3:12 PM, Jim Jagielski wrote:
I just need to create and connect some runtime config
On 8/25/2011 3:05 PM, Jim Jagielski wrote:
For us to be able to control the number of overlaps, ranges,
etc will require an API bump to add an entry to server_rec.
Are we sure we want to do that for 2.2 or save that for trunk?
Let's -not- overload server_rec.
First, it's per-dir... it would
On Thu, 25 Aug 2011, j...@apache.org wrote:
Author: jim
Date: Thu Aug 25 17:38:19 2011
New Revision: 1161661
URL: http://svn.apache.org/viewvc?rev=1161661view=rev
Log:
Merge in byteranges
Modified:
httpd/httpd/trunk/modules/http/byterange_filter.c
Modified:
Using stef's byterange4 test, I'm seeing:
apr_brigade_length (bb=0x7feb00a23200, read_all=1, length=0x7fff6e03e8b0) at
apr_brigade.c:201
201 if (bkt-length == (apr_size_t)(-1)) {
(gdb) where
#0 apr_brigade_length (bb=0x7feb00a23200, read_all=1, length=0x7fff6e03e8b0)
at
+1, also has the advantage of not being a quadratic
allocator the way Jim's usage of apr_pstrcat is.
From: Stefan Fritsch s...@sfritsch.de
To: dev@httpd.apache.org
Sent: Thursday, August 25, 2011 4:56 PM
Subject: Re: svn commit: r1161661 -
On Aug 25, 2011, at 4:56 PM, Stefan Fritsch wrote:
Is it really a good idea to first parse the range string (involving lots of
copying with ap_getword), then format it back into a string just to have it
parsed by parse_byterange again?
It is if we want to be able to create a correct
On Aug 25, 2011, at 5:02 PM, Joe Schaefer wrote:
+1, also has the advantage of not being a quadratic
allocator the way Jim's usage of apr_pstrcat is.
So what, exactly, will ap_set_byterange() do…? It was
my impression that it created our r-range entry...
On Aug 25, 2011, at 4:56 PM, Stefan Fritsch wrote:
Is it really a good idea to first parse the range string (involving lots of
copying with ap_getword), then format it back into a string just to have it
parsed by parse_byterange again? I would much prefer to have it parsed only
once
My criticism has to do with your implementation.
There's no point in fixing exploitable code with
a differently exploitable implementation. Just
buffer things in an internal array and merge the
string once at the end of the loop, and *not* as
you iterate over the elements of the range header.
On Aug 25, 2011, at 2:02 PM, Jim Jagielski wrote:
Using stef's byterange4 test, I'm seeing:
apr_brigade_length (bb=0x7feb00a23200, read_all=1, length=0x7fff6e03e8b0) at
apr_brigade.c:201
201 if (bkt-length == (apr_size_t)(-1)) {
apr_size_t is unsigned. That's borked.
Roy
And who said this was the final version? Not me...
My plan was to simply add elements to an array and then
apr_array_pstrcat()...
On Thu, Aug 25, 2011 at 02:14:05PM -0700, Joe Schaefer wrote:
My criticism has to do with your implementation.
There's no point in fixing exploitable code
Look Jim, as someone who has written
a HTTP parsing library with a good track
record of no published security holes,
take my criticism of what you wrote for
what it's worth. I have no idea what
your plans are, was simply agreeing with
Stefan's critique of your code.
On Thursday 25 August 2011, Roy T. Fielding wrote:
On Aug 25, 2011, at 2:02 PM, Jim Jagielski wrote:
Using stef's byterange4 test, I'm seeing:
apr_brigade_length (bb=0x7feb00a23200, read_all=1,
length=0x7fff6e03e8b0) at apr_brigade.c:201 201 if
(bkt-length ==
On Thursday 25 August 2011, Jim Jagielski wrote:
We seem to be spinning at:
AP_DEBUG_ASSERT(APR_SUCCESS == apr_brigade_length(bbout, 1,
pofft));
Cannot recreate in the real world...
I have managed to fix that one. The key to recreating is having
mod_bucketeer configured and
On Thursday 25 August 2011, Dirk-WIllem van Gulik wrote:
Folks,
What is wisdom? We have an updated version at
people.apache.org/CVE-2011-3192.txt.
i'd say, let's send this of day if we expect the full patch to take
another 24+ hours. As there is a need for the i proved mitigations
And
On Thu, Aug 25, 2011 at 5:43 PM, s...@apache.org wrote:
avoid inserting the same bucket into bbout twice, causing an endless loop
--- httpd/httpd/trunk/modules/http/byterange_filter.c (original)
+++ httpd/httpd/trunk/modules/http/byterange_filter.c Thu Aug 25 21:43:32
2011
@@ -195,8 +195,8
On Friday 26 August 2011, Greg Ames wrote:
? Isn't copy going to be a new bucket on each pass of the
while() loop? Suppose we have 3 buckets and need to split buckets
#1 and #3 to satisfy the range. We also need a copy of bucket #2
in the output brigade. I don't see where it is happening
On Thursday 25 August 2011, Jim Jagielski wrote:
Be my guest. commit and fix rp's concerns.
OK, done that. Trunk r1161791 passes all tests, including the new
byterange3.t and byterange4.t.
On Thursday 25 August 2011, Stefan Fritsch wrote:
On Thursday 25 August 2011, Dirk-WIllem van Gulik wrote:
Folks,
What is wisdom? We have an updated version at
people.apache.org/CVE-2011-3192.txt.
i'd say, let's send this of day if we expect the full patch to
take another 24+
52 matches
Mail list logo
