> On 6 Mar 2023, at 13:32, Ruediger Pluem wrote:
>
>
>
> On 3/6/23 12:35 PM, Dirk-Willem van Gulik wrote:
>> I was cleaning up some of our private code - and came across the patch below
>> - exposing the SHARED_CHIPHERs.
>>
>> We scratch this itch in
I was cleaning up some of our private code - and came across the patch below -
exposing the SHARED_CHIPHERs.
We scratch this itch in a few places to help force (or prevent) the forcing of
a protocol upgrade from application land.
No idea how common that is - any reason not to submit this as a s
In some code
(https://source.redwax.eu/svn/redwax/rs/mod_cms_verify/trunk/mod_cms_verify.c)
I have in input filter (that checks a PKCS#7 signature before passing the
payload on to a proxy/cgi-script, etc).
I am testing this with:
echo "field1=foo&field2=bar” |\
openssl
On 14 Jul 2021, at 23:47, Yann Ylavic wrote:
> On Wed, Jul 14, 2021 at 3:42 PM Yann Ylavic wrote:
>>
>> On Tue, Jul 13, 2021 at 4:16 PM Stefan Eissing
>> wrote:
>>>
>>> In Yann's v3 of the patch, it triggers only when I stop the server while
>>> the test case is ongoing,
>>
>> OK thanks, I
Thank you so much for finding is!
This one has been plaguing us for quite a bit - and we where totally looking in
the wrong place.
Dw.
> On 22 Mar 2020, at 13:12, gbec...@apache.org wrote:
>
> Author: gbechis
> Date: Sun Mar 22 12:12:21 2020
> New Revision: 1875516
>
> URL: http://svn.apache
Jim,
On 21 Feb 2020, at 13:20, Jim Jagielski wrote:
> Wow. Was Netcraft actually somewhat kind to Apache httpd? They actually
> admitted some areas where httpd is doing better, and still does better,
> market-share wise, than nginx.
They are very kind (and professional) people. And the pub i
On 19 Apr 2018, at 12:09, Graham Leggett wrote:
> On 18 Apr 2018, at 10:46 PM, Mark Blackman wrote:
>
>> Is most popular the right thing to aim for? I would advise continuing to
>> trade on Apache’s current strengths (versatility and documentation for me
>> and relative stability) and let the
> On 7 Feb 2018, at 16:24, Graham Leggett wrote:
>
> On 07 Feb 2018, at 5:18 PM, Graham Leggett wrote:
>
>> Looking back through the archives, looks like that backport was already
>> accepted:
>>
>> http://svn.apache.org/viewvc?view=revision&revision=1634520
>
> Hmmm… it’s actually only sol
> On 2 Feb 2018, at 15:44, Stefan Eissing wrote:
>
>
>
>> Am 02.02.2018 um 15:42 schrieb Yann Ylavic :
>>
>> On Fri, Feb 2, 2018 at 3:25 PM, Plüm, Rüdiger, Vodafone Group
>> wrote:>
>>>
-Ursprüngliche Nachricht- Von: Jim Jagielski
[mailto:j...@jagunet.com] Gesendet: Freita
> On 3 May 2017, at 15:14, Issac Goldstand wrote:
>
> On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote:
>>
>>> On 3 May 2017, at 14:53, Issac Goldstand >> <mailto:mar...@beamartyr.net>> wrote:
>>>
>>> On 5/3/2017 12:46 PM, Dirk-Wi
> On 3 May 2017, at 14:53, Issac Goldstand wrote:
>
> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
>> On 3 May 2017, at 10:03, Issac Goldstand wrote:
>>>
>>> +1 on the idea
>>>
>>> So far I'm -0 about all of the proposed impl
> On 3 May 2017, at 14:09, Graham Leggett wrote:
>
> On 03 May 2017, at 2:01 PM, Stefan Eissing
> wrote:
>
>> We seem to all agree that a definition in code alone will not be good
>> enough. People need to be able to see what is actually in effect.
>
> I think we’re overthinking this.
>
>
On 3 May 2017, at 10:03, Issac Goldstand wrote:
>
> +1 on the idea
>
> So far I'm -0 about all of the proposed implementations for 2 reasons:
>
> 1) Mr and Mrs normal (whom are our primary customers in the original
> proposal) usually download Apache from their distro or some other
> binary. T
On 24 Feb 2017, at 18:52, Jim Jagielski wrote:
>
> I think we should start, in addition to "signing" w/ md5 and sha-1,
> using sha-256 as well.
>
> Sound OK?
That seems to match the advice of NIST, E-CRYPT and the BSI on
https://www.nrc.nl/nieuws/2017/02/24/zelfrijdende-auto-google-ub
> On 20 Jan 2017, at 21:13, William A Rowe Jr wrote:
>
> On Fri, Jan 20, 2017 at 1:49 PM, William A Rowe Jr
> wrote:
>> On Fri, Jan 20, 2017 at 1:21 PM, Dirk-Willem van Gulik
>> wrote:
>>> RFC 7231 has retired Content-MD5.
>>>
>>> Fai
On 20 Jan 2017, at 20:49, William A Rowe Jr wrote:
>
> Note that https://www.rfc-editor.org/rfc/rfc7616.txt still provides
> for MD5 hashed
> digest auth keys. So removing this altogether will break mod_auth_digest in a
> manner that breaks existing user auth.
>
>
> Note that https://www.rfc-e
> On 20 Jan 2017, at 20:49, William A Rowe Jr wrote:
>
> On Fri, Jan 20, 2017 at 1:21 PM, Dirk-Willem van Gulik
> wrote:
>> RFC 7231 has retired Content-MD5.
>>
>> Fair game to remove it from -trunk - or make it squeek 'debrecated' at WARN
>> o
RFC 7231 has retired Content-MD5.
Fair game to remove it from -trunk - or make it squeek 'debrecated' at WARN or
INFO and retire it at the next minor release ?
Dw.
> On 14 Jan 2017, at 22:31, William A Rowe Jr wrote:
>
> On Sat, Jan 14, 2017 at 12:15 PM, Dirk-Willem van Gulik
> wrote:
>>
>> On 14 Jan 2017, at 19:05, William A Rowe Jr wrote:
>>
>> Any mod_letsencrypt can provision the certs but needs to do so
&
> On 14 Jan 2017, at 20:05, Stefan Sperling wrote:
>
> On Sat, Jan 14, 2017 at 07:15:29PM +0100, Dirk-Willem van Gulik wrote:
>> In fact - that may be a nice feature - an, essential, empheral port.
>
> Would that work for web servers behind firewalls?
No; would not exp
> On 14 Jan 2017, at 19:05, William A Rowe Jr wrote:
>
> On Sat, Jan 14, 2017 at 10:22 AM, Eric Covener wrote:
>> On Sat, Jan 14, 2017 at 11:19 AM, Eric Covener wrote:
>>>
>>> I think if a feature/directive will turn on something that will write
>>> to configured keystores, it really shouldn'
(reshuffled top post)
On 14 Jan 2017, at 16:07, Rich Bowen wrote:
> On Jan 10, 2017 12:15 PM, "Jacob Champion" <mailto:champio...@gmail.com>> wrote:
> On 01/10/2017 08:35 AM, Dirk-Willem van Gulik wrote:
> Before I send someone into the woods - did anyone consider/do
Before I send someone into the woods - did anyone consider/do a quick
‘mod_lets_encrypt’ (with or without a persistent store) — that requires
virtually no configuration ?
Or is the web world still thinking unix with clear small concise scripts that
do one thing well ?
Dw
On 22 Jul 2016, at 18:59, Steffen wrote:
>
> See https://joinup.ec.europa.eu/node/153614
I think I’ve gotten the right people at the EC to know that d Eric Covener
(cove...@apache.org) as the Chair of HTTPD is the right starting place should
they want a proper conversation.
Dw (who once upon
That is my reading as well - +1.
> On 30 Jun 2016, at 18:38, Jim Jagielski wrote:
>
> +1
>
>> On Jun 30, 2016, at 11:38 AM, Stefan Eissing
>> wrote:
>>
>> We now set exactly the same callback right before in line 709. If we had
>> more than one callback, we would not have to specify NULL, b
Was looking into a report that something could get a lift on websocket with a
specific AltSubject trickery; but got into jak shaving - where I cannot work
out why SSLProxyCheckPeerCN et.al. get ignored. The most trivial config I could
find to reproduce is:
Listen 123.123.123.123:4321
> On 19 Nov 2015, at 10:07, Ewald Dieterich wrote:
>
> This is from mod_session_crypto.c, decrypt_string():
>
>/* strip base64 from the string */
>decoded = apr_palloc(r->pool, apr_base64_decode_len(in));
>decodedlen = apr_base64_decode(decoded, in);
>decoded[decodedlen] = '\0';
>>> On 28 May 2015, at 17:03, William A Rowe Jr >> <mailto:wr...@rowe-clan.net>> wrote:
….
>>> > > On 26 May 2015, at 17:22, Dirk-Willem van Gulik >> > > <mailto:di...@webweaving.org>> wrote:
>>> > ..
>>> > >
> On 28 May 2015, at 17:24, Dirk-Willem van Gulik wrote:
>
>
>> On 28 May 2015, at 17:03, William A Rowe Jr > <mailto:wr...@rowe-clan.net>> wrote:
>>
>>
>> On May 26, 2015 10:31 AM, "Dirk-Willem van Gulik" > <mailto:di...@webw
> On 28 May 2015, at 17:03, William A Rowe Jr wrote:
>
>
> On May 26, 2015 10:31 AM, "Dirk-Willem van Gulik" <mailto:di...@webweaving.org>> wrote:
> >
> >
> > > On 26 May 2015, at 17:22, Dirk-Willem van Gulik > > <mailto:di...
> On 28 May 2015, at 16:25, Jim Jagielski wrote:
>
> One thing I've been thinking about, and there might even be some hooks
> in trunk for it, is the idea of slave connections (or sub-connections)
> which kind of *is* a pseudo connection. So one could create a connection
> and then a sub/slave c
> On 26 May 2015, at 17:22, Dirk-Willem van Gulik wrote:
..
> So I think that what is needed are two (or three) functions
...
> - A string comparison function; where at least one string is is under
> control of the attacker.
Now the issue here is that length is every easily re
Folks,
Did a scan through a fair bit of our code. mod_digest is not the only place;
e.g. in basic auth; we are also
not as careful in all cases as we could be.
So I think that what is needed are two (or three) functions
- A fairly mundane (binary) timing safe compare that compares two fi
Very quick and dirty list of the most obvious places where we compare stuff.
Currently trying to find some time to figure out if these are all vulnerable;
or if it is just the two outer ones.
Dw.
Index: modules/aaa/mod_auth_digest.c
==
Folks,
security@ got a notification of a potential side channel attack. The original
message is below (sans details on the poster who wants to remain private).
In short - we’re comparing the digest in mod-auth-digest in a manner that may
reveal how much is actually correct; leading potentially
> I still develop in what a lot of folks would consider a fairly "primitive"
> environment (vi) that doesn't do anything for style checking things like line
> width/spacing before and after control statements/indentation/variable
> declaration/etc. I know of the indent tool available on most un
On 21 Apr 2015, at 15:55, Jim Jagielski wrote:
> For comment: What do people think about adding the capability that
> when httpd is started, it tries to access http://httpd.apache.org/doap.rdf
> to check its version number with the latest one referred to in that
> file and, if a newer one exists,
> On 06 Nov 2014, at 14:14, Andreas B. wrote:
>
> Am 06.11.2014 um 08:34 schrieb Dirk-Willem van Gulik:
>>> On 06 Nov 2014, at 07:05, Kaspar Brand
>>> <mailto:httpd-dev.2...@velox.ch> wrote:
>>>
>>>> 11.3.1 Certificate exact mat
> On 06 Nov 2014, at 07:05, Kaspar Brand wrote:
>
>> 11.3.1 Certificate exact match
>> …
>> CertificateExactAssertion ::= SEQUENCE {
>> serialNumber CertificateSerialNumber,
>> issuerName }
...
> (i.e., we are again back at the point that uniqueness of an X.509
> certificate
> Date: 13 Oct 2014 12:03:26 CEST
> From: Dirk-Willem van Gulik
> To: di...@webweaving.org
> Subject: CVE-2014-3671: DNS Reverse Lookup as a vector for the Bash
> vulnerability (CVE-2014-6271 et.al.)
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> On 29 Aug 2014, at 21:05, Jim Jagielski wrote:
>
> FWIW, this is reported in
>
>https://issues.apache.org/bugzilla/show_bug.cgi?id=53218
>
> I was thinking of a dual-approach: Increase PROXY_WORKER_MAX_NAME_SIZE
> and making the truncation of the worker name (s->name) non-fatal
> (but lo
Op 19 mei 2014, om 15:04 heeft Dirk-Willem van Gulik het
volgende geschreven:
> Op 17 mei 2014, om 14:15 heeft Dr Stephen Henson
> het volgende geschreven:
>> On 14/05/2014 10:23, Dirk-Willem van Gulik wrote:
>>> Now I must be getting rusty - we ha
Op 17 mei 2014, om 14:15 heeft Dr Stephen Henson
het volgende geschreven:
> On 14/05/2014 10:23, Dirk-Willem van Gulik wrote:
>> Now I must be getting rusty - we have in the config file
>>
>> SSLCipherSuite -ALL:ECDHE-RSA-AES256-SHA
>> SSLProtocol -ALL +TLSv1.1 +TLS
oes this ring a bell?
Dw.
> Von: Dirk-Willem van Gulik [mailto:di...@webweaving.org]
> Gesendet: Mittwoch, 14. Mai 2014 11:23
> An: dev@httpd.apache.org
> Betreff: Odd - SSLCipherSuite
>
> Now I must be getting rusty - we have in the config file
>
> SSLCipherSuit
Now I must be getting rusty - we have in the config file
SSLCipherSuite -ALL:ECDHE-RSA-AES256-SHA
SSLProtocol -ALL +TLSv1.1 +TLSv1.2 +SSLv3
with the first resolving nicely with
openssl ciphers -ALL:ECDHE-RSA-AES256-SHA
to just
ECDHE-RSA-AES256-SHA
So my assumpt
Op 21 jul. 2013, om 20:58 heeft Graham Leggett het volgende
geschreven:
> On 17 Jul 2013, at 4:44 PM, Eric Covener wrote:
>
>> All of the client-cert-as-basic-auth-substitute mechanisms we have
>> require you to check the dummy password with a "real"
>> authbasicprovider.
That is not quite t
Op 12 aug. 2013, om 01:35 heeft Eric Covener het volgende
geschreven:
>
> > What do you think of including a header? Is there a way to find out
> > from the encrypted traffic where the header ends and where the body
> > starts?
>
> For a typical request they are in separate SSL records and so
Op 10 aug. 2013, om 21:35 heeft Reindl Harald het
volgende geschreven:
>
> IMHO that is all the wrong train
>
> "victim's browser to visit the targeted website thousands of times"
> for me says clearly that a proper server with rate-controls based
> on iptable sor a firewall in front of the ma
On 10 Aug 2013, at 18:14, "Steinar H. Gunderson" wrote:
> On Sat, Aug 10, 2013 at 06:11:09PM +0200, Dirk-Willem van Gulik wrote:
>> I'd keep in mind that compression is simply an amplifier for this type of
>> attack. It makes the approach more effective. But it
On 10 Aug 2013, at 00:37, Eric Covener wrote:
> On Fri, Aug 9, 2013 at 5:24 PM, Steinar H. Gunderson
> wrote:
>> On Tue, Aug 06, 2013 at 01:32:00PM -0400, Eric Covener wrote:
>>> Another option in this neighborhood is small/varying deflate blocks.
>>> But that probably limits the usefulness of
On 11 May 2013, at 20:26, Reindl Harald wrote:
> after the connection is established and in case of connect
> you have already passed the TCP transmissions and kernel
> settings like
>
> net.ipv4.tcp_fin_timeout = 5
> net.ipv4.tcp_retries1 = 5
> net.ipv4.tcp_syn_retries = 5
> net.ipv4.tcp_synac
On 3 mei 2013, at 10:55, Marian Marinov wrote:
>
> If Apache by default delays 404s, this may have some effect in the first
> month or two after the release of this change. But then the the botnet
> writers will learn and update their software.
> I do believe that these guys are monitoring mai
I think we're mixing three issues
1) Prevent Starvation.
protecting a server from server side/machine starvation (i.e. running
out of file descriptors, sockets, mbuf's, whatever).
So here you are in the domain where there is no argument in terms of
protocol violation/bad c
On 1 mei 2013, at 13:31, Graham Leggett wrote:
>
> The evidence was just explained - a bot that does not get an answer quick
> enough gives up and looks elsewhere.
> The key words are "looks elsewhere".
For what it is worth - I've been experimenting with this (up till about 6
months ago) on a
On 8 Nov 2011, at 23:03, Daniel Ruggeri wrote:
> On 11/8/2011 3:10 PM, Stefan Fritsch wrote:
> > * mod_ssl's proxy support only allows one proxy client certificate per
> > frontend virtual host. Lift this restriction.
> > jim sez: Why a blocker?, pgollucci +1 jim
> > wrowe asks: wha
On 1 Sep 2011, at 13:33, Jim Jagielski wrote:
>
> On Sep 1, 2011, at 6:31 AM, Plüm, Rüdiger, VF-Group wrote:
>> I already fixed that in trunk.
>> I think this regression justifies another release for 2.2.x. But IMHO we
>> should wait at least until
>> mid next week to see if other regressions c
On 1 Sep 2011, at 12:06, Ben Laurie wrote:
> On Wed, Aug 31, 2011 at 9:03 PM, Dirk-WIllem van Gulik
> wrote:
>> Suggestion for
>>
>>http://people.apache.org/~dirkx/CVE-2011-3192.txt
>
> You probably mean "deprecated" not "desecrated&quo
Folks,
See below - for the 1.3 discussion - that suggest we should take it a notch
down:
On 31 Aug 2011, at 22:35, Munechika Sumikawa wrote:
We're currently discussing this - and will propably adjust the
announcement a bit. It is vulnerable in that it can suddenly take a
lot more
On 31 Aug 2011, at 21:07, Dirk-WIllem van Gulik wrote:
>> http://people.apache.org/~dirkx/CVE-2011-3192.txt
Off to bed now. If there is consensus we are 'done' then a vote on either of
these options would be of use
1 as above
2 as above but with complete rev
On 31 Aug 2011, at 21:03, Dirk-WIllem van Gulik wrote:
> Suggestion for
>
> http://people.apache.org/~dirkx/CVE-2011-3192.txt
>
> to be sent to announce and the usual security places.
>
> ->Comments on weaken/strenghten 1.3 text
>
> Happy to
Suggestion for
http://people.apache.org/~dirkx/CVE-2011-3192.txt
to be sent to announce and the usual security places.
-> Comments on weaken/strenghten 1.3 text
Happy to completely recant that it was vulnerable. Or happy to keep a
bit of a warning in there.
-> Lots o
On 26 Aug 2011, at 18:05, William A. Rowe Jr. wrote:
> On 8/26/2011 11:41 AM, Eric Covener wrote:
>> Should we bump the "5"'s in the draft advisory and/or code to a more
>> liberal #? At the very least for the 2.0 rewrite solution that will
>> return forbidden instead of full content?
>
> Can w
On 31 Aug 2011, at 18:20, William A. Rowe Jr. wrote:
> Note some additional improvements for a 'final' update 3 advisory…
Ack! Draft coming in half an hour or so,
Dw.
Folks,
How do we wrap this up in what remains of the (US) day ?
I can have ready a final draft or a 'more mitigation' draft - of the stay
tuned type.
Since Advisory update-2 I gotten about 5 emails with helpful (but small)
improvements for what we have; 3 with some detailed feedback - and a
On 28 Aug 2011, at 18:12, rpl...@apache.org wrote:
> URL: http://svn.apache.org/viewvc?rev=1162560&view=rev
> Log:
> * Silence compiler warning
> +apr_off_t pofft = 0;
This may have been more than that - it fixes my testcase on FreeBSD with all
optimizing set to max (OSX and Ubuntu where
On 26 aug. 2011, at 18:35, Guenter Knauf wrote:
> Hi Dirk,
> Am 26.08.2011 12:44, schrieb Dirk-Willem van Gulik:
>> 4) Deploy a Range header count module as a temporary stopgap measure:
>>
>>http://people.apache.org/~dirkx/mod_rangecnt.c
> you have a c
From the Full Disclosure list. Does anyone have time to confirm this
improvement.
On 26 Aug 2011, at 12:09, Carlos Alberto Lopez Perez wrote:
> RewriteEngine on
> RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC,OR]
> RewriteCond %{HTTP:request-range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$
On 26 aug. 2011, at 10:47, Dirk-Willem van Gulik wrote:
> Folks - as we're not quit there yet - I want to do sent out an updated
> advisory at 11:00 UTC. We have enough new information and extra mitigations.
> Will post the draft(s) to security@ this time.
Apologies fo
Folks - as we're not quit there yet - I want to do sent out an updated advisory
at 11:00 UTC. We have enough new information and extra mitigations. Will post
the draft(s) to security@ this time.
Secondly - I got below updates to the regex-es; to optimise the pcre
expressions and remove the exha
your take ?
Thanks,
Dw.
--
Dirk-Willem van Gulik.
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 rej
On 25 Aug 2011, at 17:45, Greg Ames wrote:
> On Thu, Aug 25, 2011 at 10:25 AM, Jim Jagielski 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
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 nee
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,
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 lat
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: "Dirk-Willem van Gulik"
> Newsgroups: gmane.comp.apache.devel
> To: ;
> Sent: Wednesday, August 24, 2011 5:34 PM
> Subject: Final draft / CVE-2011-3192
>
>
> Thanks for all the help. All fixes included. Below will go out to
On 24 Aug 2011, at 21:39, Greg Ames wrote:
> On Wed, Aug 24, 2011 at 3:19 PM, Jim Jagielski wrote:
>
> >
> > If we only merge adjacent ascending ranges, then it seems like an attacker
> > could just craft a header where the ranges jump around and dodge our fix.
> >
>
> I think no matter what,
That is fine - we can do another update tomorrow, say noon zulu - if we expect
that we do not have a proper patch and/or a 2.0.65 / 2.2.20 in the day
following.
Weird though - my 2.0.61 and 64 does seem fine. So probably very early 2.0
series.
Dw
On 24 Aug 2011, at 20:40, Eric Covener wrote:
On 24 Aug 2011, at 16:35, Tim Bannister wrote:
> On Tue, Aug 23, 2011, Roy T. Fielding wrote:
>> And the spec says ...
>>
>> When a client requests multiple ranges in one request, the
>> server SHOULD return them in the order that they appeared in the
>> request.
>>
>> My suggestion is to
Thanks for all the help. All fixes included. Below will go out to announce at
the top of the hour - unless I see a veto.
Dw.
Title:CVE-2011-3192: Range header DoS vulnerability Apache HTTPD 1.3/2.x
Apache HTTPD Security ADVISORY
Date: 20110824 1600Z
Product: Apache HTTPD W
Various suggest on-list and off-list fixes applied. Thanks all.
A few more +1's would be nice :)
Dw.
Title:CVE-2011-3192: Range header DoS vulnerability Apache HTTPD 1.3/2.x
Apache HTTPD Security ADVISORY
Date: 20110824 1600Z
Product: Apache HTTPD Web Server
Versions: Apa
On 24 Aug 2011, at 15:34, Guenter Knauf wrote:
> can you please apply:
> --- mod_rangecnt.c.orig Wed Aug 24 16:25:34 2011
> +++ mod_rangecnt.cWed Aug 24 15:26:48 2011
Done.
> which I need on NetWare in order to get ap_hook_post_read_request() proto;
>
> and maybe we should also add l
Folks,
Can I have a few +1's on below - or feedback on what we'd like to have changed ?
* Would like to get this out in an hour or so ?
* FIne with the 48 hours commitment of an update ?
Dw.
Title:CVE-2011-3192: Range header DoS vulnerability Apache HTTPD 1.3/2.x
Date: 20
On 24 Aug 2011, at 14:07, Dirk-WIllem van Gulik wrote:
* Folks - do we also need to add Request-Range ?
* Updated with Rudigers comments., Eric, Florians, Marks.
* Consensus that the deflate stuff needs to go out reflected.
* More Comments please. Esp. on the quality
On 24 Aug 2011, at 14:01, Plüm, Rüdiger, VF-Group wrote:
> Have you tried if the same happens with mod_deflate, but with one of the
> the proposed mitigations in place?
As soon as I reject/block on the range header - all is fine again.
> As said my guess is that this might be an issue with mod_
* Folks - do we also need to add Request-Range ?
* Updated with Rudigers comments., Eric, Florians
* Consensus that the deflate stuff needs to go out reflected.
* More Comments please. Esp. on the quality and realisticness of the
mitigtions.
* Is this the right li
On 24 Aug 2011, at 13:43, Florian Weimer wrote:
> * Dirk-WIllem van Gulik:
>
>> Hmm - when I remove mod_deflate (i.e. explicitly as it is the default
>> in all our installs) and test on a / entry which is a static file
>> which is large (100k)* - then I cannot get
On 24 Aug 2011, at 13:22, Florian Weimer wrote:
> * Plüm, Rüdiger, VF-Group:
>
>> As said this has *nothing* to do with mod_deflate. This was IMHO just
>> a guess by the original author of the tool.
>
> This matches my testing, too. I see a significant peak in RAM usage on
> a server where "ap
* Updated with Rudigers comments.
* Do we have consensus that the deflate stuff needs to go out - is not
relevant ?
* More Comments please. Esp. on the quality and realisticness of the
mitigtions.
Thanks,
Title: CVE-2011-3192: Range header DoS vulnerability in Apache
On 24 Aug 2011, at 12:57, Plüm, Rüdiger, VF-Group wrote:
>> -> Where possible - disable mod_deflate
>>
>> => we sure this covers all cases - or this is a good stopgap ?
>
> As said this has *nothing* to do with mod_deflate. This was IMHO just
> a guess by the original author of the
Comments please. Esp. on the quality and realisticness of the mitigtions.
Title: CVE-2011-3192: Range header DoS vulnerability in Apache 1.3 and
Apache 2
Date: 20110824 1600Z
# Last Updated: 20110824 1600Z
Product: Apache Web Server
Versions: Apache 1.3 all versions, Apache 2 all
The new Range: header has been given the CVE of
CVE-2011-3192
Please use that in subjects, commits and what not.
Thanks,
Dw.
On 24 Aug 2011, at 09:28, Dirk-Willem van Gulik wrote:
> Folks,
>
> Have we done (or who is doing a CVE) on this ? So we get immediate 'fixes&
Folks,
This issue is now active in the wild. So some unified/simple comms is needed.
What is the wisdom on mitigation advise/briefing until a proper fix it out - in
order of ease:
-> Where possible - disable mod_deflate
=> we sure this covers all cases - or this is a good
Folks,
Have we done (or who is doing a CVE) on this ? So we get immediate 'fixes' out
like a tiny patch to count the comma's, a caveated LimitRequestFieldSize 100 or
a clever Regex on %{HTTP_Range}.
Or am I totally asleep and missed the CVE (as my google foo only nets me
CVE-2005-2728 right no
Can anyone remember why SSLRenegBufferSize is set at 128k (131072 bytes)
currently by default ?
And if that is just an accidental default - or if deep thought has gone into it
?
And what are the specific things which are likely to break if it is set
significantly smaller* ?
Thanks,
Dw.
*:
Reudiger,
Why is:
https://issues.apache.org/bugzilla/show_bug.cgi?id=30865
still open ? You are not sure it was fixed ? Or we just forgot about it ?
Thanks,
Dw.
On 1 Feb 2011, at 22:17, Jorge Schrauwen wrote:
> Any httpd people coming to FOSDEM in Brussels, Belgium this weekend?
+1 for me.
Dw
On 10 Nov 2010, at 14:42, Dan Poirier wrote:
> If multiple response statuses would be valid for a request (e.g. 403,
> 413), is there any standard on how to pick one? I looked through RFC
> 2616 but didn't see anything. Or is it just an implementation detail?
This was subject of a fair bit of
On 4 Nov 2010, at 21:26, Brian J. France wrote:
> With the current patch, see link below, it changes the syntax to ErrorLog to
> this:
>
> ErrorLog file-path|syslog[:facility] [rotating[:]]
Nice!
> There is one security issue that people may have a problem with in that the
> directory path
1 - 100 of 389 matches
Mail list logo
