half-OT: heartbleed CVE-2014-0160
Hi i know that this is more or less off-topic but i doubt there are better sources to ask then the httpd-developers after update openssl and re-new all certificates one question remains: in case of httpd-prefork would a attacker only have been able to compromise the private key and data of his worker-process or as well access the memory of other workers? in that case also all passwords of any website should be treated as compromised which is the big question now the dovecot-developer says if dovecot is running in high-security mode with single processes the setup has been safe except the private key, but in case of dovceot there is also a chroot involved for the login-workers signature.asc Description: OpenPGP digital signature
Re: half-OT: heartbleed CVE-2014-0160
On 09 Apr 2014, at 1:48 PM, Reindl Harald h.rei...@thelounge.net wrote: after update openssl and re-new all certificates one question remains: in case of httpd-prefork would a attacker only have been able to compromise the private key and data of his worker-process or as well access the memory of other workers? In the case of prefork this wouldn't be true, no - they would only be able to compromise the memory of that process only. They may be able to access username/passwords from previous requests if they were still visible. In the case of the worker and event mpms, the memory of other workers could be compromised, yes. Regards, Graham --
Re: half-OT: heartbleed CVE-2014-0160
Am 09.04.2014 13:53, schrieb Graham Leggett: On 09 Apr 2014, at 1:48 PM, Reindl Harald h.rei...@thelounge.net wrote: after update openssl and re-new all certificates one question remains: in case of httpd-prefork would a attacker only have been able to compromise the private key and data of his worker-process or as well access the memory of other workers? In the case of prefork this wouldn't be true, no - they would only be able to compromise the memory of that process only. They may be able to access username/passwords from previous requests if they were still visible. In the case of the worker and event mpms, the memory of other workers could be compromised, yes thanks a lot - this makes my sleep so much better and i am happy to use httpd-prefork everywhere with all it's disadvantages in context of scalability signature.asc Description: OpenPGP digital signature
Re: half-OT: heartbleed CVE-2014-0160
after update openssl and re-new all certificates one question remains: in case of httpd-prefork would a attacker only have been able to compromise the private key and data of his worker-process or as well access the memory of other workers? The address space boundary of the process is the limit, so no access to other processes' memory. Multi-threaded workers are in a pretty bad shape with this assertion, unfortunately: credentials, cookies, symmetric keys. in that case also all passwords of any website should be treated as compromised which is the big question now It is answered by the idea that an attacker can chose _when_ to execute the exploit. Meaning this can happen after some creds have been dealt with. the dovecot-developer says if dovecot is running in high-security mode with single processes the setup has been safe except the private key, but in case of dovceot there is also a chroot involved for the login-workers It depends on the authentication scheme. Depending on the auth driver (driver=passwd-file...), dovecot reads file chunks onto the heap, adds entries to a hash table and closes the file again. Crums may be left there. There have been some zero-before-free changes in mozilla-nss recently. It may be time to have object reuse issues in mind for both core and at least the auth* modules. Roman.
Re: half-OT: heartbleed CVE-2014-0160
On 09 Apr 2014, at 2:14 PM, Roman Drahtmueller dr...@suse.de wrote: There have been some zero-before-free changes in mozilla-nss recently. It may be time to have object reuse issues in mind for both core and at least the auth* modules. The following function was added to apr-util to do that: /** * @brief Register a cleanup to zero out the buffer provided * when the pool is cleaned up. * * @param pool - pool to register the cleanup * @param buffer - buffer to zero out * @param size - size of the buffer to zero out */ APU_DECLARE(apr_status_t) apr_crypto_clear(apr_pool_t *pool, void *buffer, apr_size_t size); Regards, Graham --
Re: half-OT: heartbleed CVE-2014-0160
Am 09.04.2014 14:19, schrieb Graham Leggett: On 09 Apr 2014, at 2:14 PM, Roman Drahtmueller dr...@suse.de wrote: There have been some zero-before-free changes in mozilla-nss recently. It may be time to have object reuse issues in mind for both core and at least the auth* modules. The following function was added to apr-util to do that: /** * @brief Register a cleanup to zero out the buffer provided * when the pool is cleaned up. * * @param pool - pool to register the cleanup * @param buffer - buffer to zero out * @param size - size of the buffer to zero out */ APU_DECLARE(apr_status_t) apr_crypto_clear(apr_pool_t *pool, void *buffer, apr_size_t size); sounds good - thank you! signature.asc Description: OpenPGP digital signature
Re: half-OT: heartbleed CVE-2014-0160
On Wed, Apr 9, 2014 at 5:48 AM, Reindl Harald h.rei...@thelounge.net wrote: after update openssl and re-new all certificates one question remains: in case of httpd-prefork would a attacker only have been able to compromise the private key and data of his worker-process or as well access the memory of other workers? Doesn't seem very helpful in practice. The different processes are handling similar requests and an attacker would just run a number of handshakes to hit arbitrary processes.
Re: half-OT: heartbleed CVE-2014-0160
Combined with typical ssl session shmcb ... That single process still has session keys of other prefork processes, as well as the common ssl session ticket key and ssl cert keys. In practice the benefits of prefork are somewhat limited to casual attacks.
Re: half-OT: heartbleed CVE-2014-0160
Am 09.04.2014 17:41, schrieb William A. Rowe Jr.: Combined with typical ssl session shmcb ... That single process still has session keys of other prefork processes, as well as the common ssl session ticket key and ssl cert keys. In practice the benefits of prefork are somewhat limited to casual attacks. that's clear and anything related to SSL/TLS (certificates, keys) needs to be changed, the original question was about user-payload like passwords submitted via POST on the neighbour worker signature.asc Description: OpenPGP digital signature
Re: [PATCH 55467] - Updates to mod_ssl to support TLS hello extensions and TLS supplemental data
On Fri, Apr 4, 2014 at 7:48 PM, Jeff Trawick traw...@gmail.com wrote:
On Tue, Feb 18, 2014 at 3:50 PM, Scott Deboy sde...@secondstryke.comwrote:
Hi folks,
I was wondering if someone would be willing/interested in reviewing the
patch I've attached to issue 55467.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55467
The patch adds hooks to mod_ssl which give third-party modules the
ability to send and receive custom TLS hello extensions TLS supplemental
data. It also gives third-party modules the ability to trigger
renegotiation. It leverages APIs recently added to OpenSSL master and
1.0.2 stable branches.
Any feedback is appreciated!
Any thoughts out there on passing SSL* to the hook as void* as in the
patch? I've been experimenting with some hooks to enable Certificate
Transparency in a module, and it seemed feasible to me to let mod_ssl.h own
the job of getting the right headers included in order to specify the right
OpenSSL datatype on the API. Is that asking for trouble?
If building with OpenSSL 1.0.2, the affected optional hooks shouldn't be
available.
I anticipate syncing my CT code with the pieces
for SSL_CTX_set_custom_cli_ext()/SSL_CTX_set_custom_srv_ext() and
committing the relevant parts of your patch (not that the rest is much
different). Hopefully some genuine mod_ssl developers will render an
opinion on placement and any other details.
I started really looking at the TLS extension APIs today... Here are
some notes, hopefully based on a proper understanding of the code :) :
The optional functions can only be called at startup -- not thread-safe, no
impact on connection anyway. I guess this would be handled in API
documentation.
SSL_CTX_set_custom_cli_ext() and SSL_CTX_set_custom_srv_ext() fail if a
callback is already registered for the extension type or if a memory
allocation error occurs. As long as any modules that need to participate
use your APIs, the duplicate registration is handled. However, the memory
allocation error (or any other future error) is not handled.
In the optional function the module passes userdata (userdata which must be
known at initialization, which severely limits its usefulness). During the
handshake every module that handles any TLS extension via this API will be
called, and all but one must ignore the call if it isn't the extension type
they registered. The hook only gets the init-time value passed in, not the
conn_rec (from which the server_rec and all sorts of context-specific
configuration could be found).
I think some changes are appropriate:
a) the module code that actually handles the TLS extension (receiving or
generating) must get the conn_rec (which is easy since mod_ssl retrieves
the conn_rec in the call from OpenSSL. Given the conn_rec, it doesn't seem
important that the module call also receives its init-time userdata, but it
doesn't hurt anything.
b) since only one module can register to handle a particular TLS extension,
there is no need for mod_ssl to run a hook (which could be accidentally
subverted by some other module failing a call for an extension that it
doesn't handle); instead, the init-time registration of a module's interest
in a TLS extension should provide a callback function; so OpenSSL call's
mod_ssl's callback which retrieves the conn_rec and looks up the module
callback function by TLS extension id
Does that make sense so far?
Another concern is that a module may not actually care about extensions
depending on vhost-specific configuration and/or mode. The server-side
callbacks are simply ignored if running in a proxy, and similar for the
client-side callbacks. As long as a module can get to its configuration
(via conn_rec presumably) in the other cases it can filter out calls that
it shouldn't do anything for.
--/--
So why not let the module handle all of this itself, without mod_ssl going
to the trouble of keeping track stuff that OpenSSL already handles? For my
initial C-T implementation (
https://github.com/trawick/ct-httpd/blob/master/src/proto1/) I added a hook
which the ssl_ct module implements as follows:
static int ssl_ct_ssl_init_ctx(server_rec *s, apr_pool_t *p, int is_proxy,
SSL_CTX *ssl_ctx)
{
ct_callback_info *cbi = apr_pcalloc(p, sizeof *cbi);
ct_server_config *sconf = ap_get_module_config(s-module_config,
ssl_ct_module);
cbi-s = s;
if (is_proxy sconf-proxy_awareness != PROXY_OBLIVIOUS) {
/* _cli_ = client */
if (!SSL_CTX_set_custom_cli_ext(ssl_ctx, CT_EXTENSION_TYPE,
client_extension_callback_1,
client_extension_callback_2, cbi)) {
/* error, abort startup */
}
}
else if configured to do stuff in server mode {
}
/* do other stuff unrelated to TLS extensions */
return OK;
}
mod_ssl calls this in ssl_init_ctx() after all of its existing
configuration.
Re: svn commit: r1585438 - /httpd/httpd/branches/2.4.x/STATUS
Hi, this is already in the proposal list, first one at the top, just waiting for a last vote to be accepted. CJ Le 07/04/2014 11:24, yla...@apache.org a écrit : Author: ylavic Date: Mon Apr 7 09:24:05 2014 New Revision: 1585438 URL: http://svn.apache.org/r1585438 Log: Propose mod_auth_form optional functions load changes. Modified: httpd/httpd/branches/2.4.x/STATUS Modified: httpd/httpd/branches/2.4.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1585438r1=1585437r2=1585438view=diff == --- httpd/httpd/branches/2.4.x/STATUS (original) +++ httpd/httpd/branches/2.4.x/STATUS Mon Apr 7 09:24:05 2014 @@ -251,6 +251,13 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: The patch includes generated doc changes in order to carry eol-style. +1: trawick + * mod_auth_form: Make sure the optional functions are loaded even when +the AuthFormProvider isn't specified. PR 56351. + Submitted/Commited by: minfrin + trunk patch: http://svn.apache.org/r1531672 + 2.4.x patch: trunk works (modulo CHANGES) + +1: ylavic + OTHER PROPOSALS * A list of further possible backports can be found at:
Re: [PATCH 55467] - Updates to mod_ssl to support TLS hello extensions and TLS supplemental data
On Wed, Apr 9, 2014 at 10:24 AM, Jeff Trawick traw...@gmail.com wrote:
On Fri, Apr 4, 2014 at 7:48 PM, Jeff Trawick traw...@gmail.com wrote:
On Tue, Feb 18, 2014 at 3:50 PM, Scott Deboy sde...@secondstryke.comwrote:
Hi folks,
I was wondering if someone would be willing/interested in reviewing the
patch I've attached to issue 55467.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55467
The patch adds hooks to mod_ssl which give third-party modules the
ability to send and receive custom TLS hello extensions TLS supplemental
data. It also gives third-party modules the ability to trigger
renegotiation. It leverages APIs recently added to OpenSSL master and
1.0.2 stable branches.
Any feedback is appreciated!
Any thoughts out there on passing SSL* to the hook as void* as in the
patch? I've been experimenting with some hooks to enable Certificate
Transparency in a module, and it seemed feasible to me to let mod_ssl.h own
the job of getting the right headers included in order to specify the right
OpenSSL datatype on the API. Is that asking for trouble?
If building with OpenSSL 1.0.2, the affected optional hooks shouldn't
be available.
I anticipate syncing my CT code with the pieces
for SSL_CTX_set_custom_cli_ext()/SSL_CTX_set_custom_srv_ext() and
committing the relevant parts of your patch (not that the rest is much
different). Hopefully some genuine mod_ssl developers will render an
opinion on placement and any other details.
I started really looking at the TLS extension APIs today... Here are
some notes, hopefully based on a proper understanding of the code :) :
The optional functions can only be called at startup -- not thread-safe,
no impact on connection anyway. I guess this would be handled in API
documentation.
SSL_CTX_set_custom_cli_ext() and SSL_CTX_set_custom_srv_ext() fail if a
callback is already registered for the extension type or if a memory
allocation error occurs. As long as any modules that need to participate
use your APIs, the duplicate registration is handled. However, the memory
allocation error (or any other future error) is not handled.
In the optional function the module passes userdata (userdata which must
be known at initialization, which severely limits its usefulness). During
the handshake every module that handles any TLS extension via this API will
be called, and all but one must ignore the call if it isn't the extension
type they registered. The hook only gets the init-time value passed in,
not the conn_rec (from which the server_rec and all sorts of
context-specific configuration could be found).
I think some changes are appropriate:
a) the module code that actually handles the TLS extension (receiving or
generating) must get the conn_rec (which is easy since mod_ssl retrieves
the conn_rec in the call from OpenSSL. Given the conn_rec, it doesn't seem
important that the module call also receives its init-time userdata, but it
doesn't hurt anything.
b) since only one module can register to handle a particular TLS
extension, there is no need for mod_ssl to run a hook (which could be
accidentally subverted by some other module failing a call for an extension
that it doesn't handle); instead, the init-time registration of a module's
interest in a TLS extension should provide a callback function; so OpenSSL
call's mod_ssl's callback which retrieves the conn_rec and looks up the
module callback function by TLS extension id
Does that make sense so far?
Another concern is that a module may not actually care about extensions
depending on vhost-specific configuration and/or mode. The server-side
callbacks are simply ignored if running in a proxy, and similar for the
client-side callbacks. As long as a module can get to its configuration
(via conn_rec presumably) in the other cases it can filter out calls that
it shouldn't do anything for.
--/--
So why not let the module handle all of this itself, without mod_ssl going
to the trouble of keeping track stuff that OpenSSL already handles? For my
initial C-T implementation (
https://github.com/trawick/ct-httpd/blob/master/src/proto1/) I added a
hook which the ssl_ct module implements as follows:
static int ssl_ct_ssl_init_ctx(server_rec *s, apr_pool_t *p, int is_proxy,
SSL_CTX *ssl_ctx)
{
ct_callback_info *cbi = apr_pcalloc(p, sizeof *cbi);
ct_server_config *sconf = ap_get_module_config(s-module_config,
ssl_ct_module);
cbi-s = s;
if (is_proxy sconf-proxy_awareness != PROXY_OBLIVIOUS) {
/* _cli_ = client */
if (!SSL_CTX_set_custom_cli_ext(ssl_ctx, CT_EXTENSION_TYPE,
client_extension_callback_1,
client_extension_callback_2, cbi))
{
/* error, abort startup */
}
}
else if configured to do stuff in server mode {
}
/* do
Re: half-OT: heartbleed CVE-2014-0160
On 09.04.2014 18:05, Reindl Harald wrote: Am 09.04.2014 17:41, schrieb William A. Rowe Jr.: Combined with typical ssl session shmcb ... That single process still has session keys of other prefork processes, as well as the common ssl session ticket key and ssl cert keys. In practice the benefits of prefork are somewhat limited to casual attacks. that's clear and anything related to SSL/TLS (certificates, keys) needs to be changed, the original question was about user-payload like passwords submitted via POST on the neighbour worker But how do you know it is only the neighbour worker? If the memory hasn't been cleared, the next connection from the attacker could get handled by the previous neighbour and confidential data might still sit in that processes memory readable by the attacker. What I didn't check until now, is whether one can describe the places/addresses in memory that are readable by an attacker (any address or only 64KB around an address at some fixed position in some request or connection handling struct) and whether we could for some platforms then describe the real exposure. Some data might always be to far away (very different address). Not sure whether that's feasible or the answer is simply any address. Regards, Rainer
Re: svn commit: r1585902 - in /httpd/httpd/branches/2.4.x/docs/manual/mod: mod_ssl.html.en mod_ssl.xml mod_ssl.xml.meta
On Wed, Apr 9, 2014 at 2:24 AM, kbr...@apache.org wrote: Author: kbrand Date: Wed Apr 9 08:24:25 2014 New Revision: 1585902 URL: http://svn.apache.org/r1585902 Log: Update SSLPassPhraseDialog directive docs to correctly describe the current behavior for exec-type programs in 2.4.x, at least. The new argument structure is a consequence of r1573360 (backport to 2.4.8 [unreleased]). Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.html.en httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.xml httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.xml.meta Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.html.en URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.html.en?rev=1585902r1=1585901r2=1585902view=diff == --- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.html.en (original) +++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.html.en Wed Apr 9 08:24:25 2014 @@ -1258,11 +1258,16 @@ query can be done in two ways which can licodeexec:/path/to/program/code p Here an external program is configured which is called at startup for each -encrypted Private Key file. It is called with two arguments (the first is +encrypted Private Key file. +For versions up to 2.4.7, it is called with two arguments (the first is of the form ``codeservername:portnumber/code'', the second is either ``codeRSA/code'', ``codeDSA/code'', or ``codeECC/code''), which indicate for which server and algorithm it has to print the corresponding -Pass Phrase to codestdout/code. The intent is that this external +Pass Phrase to codestdout/code. +Starting with version 2.4.9, it is called with one argument, a string of the +form ``codeservername:portnumber:index/code'' (with codeindex/code +being a zero-based sequence number), which indicate the server, TCP port +and certificate number. The intent is that this external program first runs security checks to make sure that the system is not compromised by an attacker, and only when these checks were passed successfully it provides the Pass Phrase./p IMO this needs to be reworked to restore compatibility for 2.x up through 2.4.7, with the new interface used if some new keyword is added on the directive. Yeah, some people who reworked their scripts will have to add that new keyboard, but this will unblock others (vendors, distros, individuals) from upgrading without surprise. Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.xml URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.xml?rev=1585902r1=1585901r2=1585902view=diff == --- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.xml (original) +++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.xml Wed Apr 9 08:24:25 2014 @@ -295,11 +295,16 @@ query can be done in two ways which can licodeexec:/path/to/program/code p Here an external program is configured which is called at startup for each -encrypted Private Key file. It is called with two arguments (the first is +encrypted Private Key file. +For versions up to 2.4.7, it is called with two arguments (the first is of the form ``codeservername:portnumber/code'', the second is either ``codeRSA/code'', ``codeDSA/code'', or ``codeECC/code''), which indicate for which server and algorithm it has to print the corresponding -Pass Phrase to codestdout/code. The intent is that this external +Pass Phrase to codestdout/code. +Starting with version 2.4.9, it is called with one argument, a string of the +form ``codeservername:portnumber:index/code'' (with codeindex/code +being a zero-based sequence number), which indicate the server, TCP port +and certificate number. The intent is that this external program first runs security checks to make sure that the system is not compromised by an attacker, and only when these checks were passed successfully it provides the Pass Phrase./p Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.xml.meta URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.xml.meta?rev=1585902r1=1585901r2=1585902view=diff == --- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.xml.meta (original) +++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_ssl.xml.meta Wed Apr 9 08:24:25 2014 @@ -8,6 +8,6 @@ variants varianten/variant -variant outdated=yesfr/variant +variantfr/variant /variants /metafile -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: svn commit: r1585438 - /httpd/httpd/branches/2.4.x/STATUS
Thanks, promoted in r1586125. On Wed, Apr 9, 2014 at 7:15 PM, Christophe JAILLET christophe.jail...@wanadoo.fr wrote: Hi, this is already in the proposal list, first one at the top, just waiting for a last vote to be accepted. CJ Le 07/04/2014 11:24, yla...@apache.org a écrit : Author: ylavic Date: Mon Apr 7 09:24:05 2014 New Revision: 1585438 URL: http://svn.apache.org/r1585438 Log: Propose mod_auth_form optional functions load changes. Modified: httpd/httpd/branches/2.4.x/STATUS Modified: httpd/httpd/branches/2.4.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1585438r1=1585437r2=1585438view=diff == --- httpd/httpd/branches/2.4.x/STATUS (original) +++ httpd/httpd/branches/2.4.x/STATUS Mon Apr 7 09:24:05 2014 @@ -251,6 +251,13 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: The patch includes generated doc changes in order to carry eol-style. +1: trawick + * mod_auth_form: Make sure the optional functions are loaded even when +the AuthFormProvider isn't specified. PR 56351. + Submitted/Commited by: minfrin + trunk patch: http://svn.apache.org/r1531672 + 2.4.x patch: trunk works (modulo CHANGES) + +1: ylavic + OTHER PROPOSALS * A list of further possible backports can be found at:
Re: half-OT: heartbleed CVE-2014-0160
Am 09.04.2014 21:42, schrieb Rainer Jung: On 09.04.2014 18:05, Reindl Harald wrote: Am 09.04.2014 17:41, schrieb William A. Rowe Jr.: Combined with typical ssl session shmcb ... That single process still has session keys of other prefork processes, as well as the common ssl session ticket key and ssl cert keys. In practice the benefits of prefork are somewhat limited to casual attacks. that's clear and anything related to SSL/TLS (certificates, keys) needs to be changed, the original question was about user-payload like passwords submitted via POST on the neighbour worker But how do you know it is only the neighbour worker? not the - any neighbour worker i am still not 100% sure that in case of httpd-worker only certs and keys are compromised while at the same time i don't want to spread panic around me If the memory hasn't been cleared, the next connection from the attacker could get handled by the previous neighbour and confidential data might still sit in that processes memory readable by the attacker. that sounds bad - i had the impression that physical memory and memory assigned to a process from previous requests is somehow different - now it sounds like a nightmare What I didn't check until now, is whether one can describe the places/addresses in memory that are readable by an attacker (any address or only 64KB around an address at some fixed position in some request or connection handling struct) and whether we could for some platforms then describe the real exposure. Some data might always be to far away (very different address). Not sure whether that's feasible or the answer is simply any address so if i understand that correctly better be safe than sorry it would be a good adivse to inform all users that it is unlikely but possibly anyways a good idea to recommend change *any* passwords used in the history independent if multi-threaded or mpm-woker was used? until know i was more or less convinced that in case of mpm-worker and changed all certs / private keys yesterday the problem is isolated - well, that issue is terrible at all :-( however, thanks for feedback, i think we should activly recommend to change *any* credentials used in the past to be sure and prevent why nobody told me from users / customers in the future signature.asc Description: OpenPGP digital signature
Re: mod_cache thundering herd bug
r1023398 for 2.2: http://people.apache.org/~covener/patches/httpd-2.2.x-thunder.diff The remove_url() prevents other threads from serving a stale cached file during refresh of a slow response, but it's unnecessary to have a separate path because the refresh has to deal with 200s already. When the remove_url was added, there as no thundering herd lock / no ability to serve stale content while one guy was reloading. On Tue, Apr 8, 2014 at 2:11 PM, Jim Riggs apache-li...@riggs.me wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=50317 While we are at ApacheCon, I would love to address this nasty bug with someone familiar with 2.2's mod_cache. Our sites were brought down a few times last year before we finally tracked it down to being this particular bug. I am using a crude backport of the 2.3 patch (r1023398) in 2.2. It works, but I don't know if it is correct. Can someone look at this one with me? We really need to get this fixed in 2.2, because there is NO thundering herd protection at all as things stand right now. - Jim -- Eric Covener cove...@gmail.com
Re: half-OT: heartbleed CVE-2014-0160
On 09.04.2014 21:42, Rainer Jung wrote: On 09.04.2014 18:05, Reindl Harald wrote: Am 09.04.2014 17:41, schrieb William A. Rowe Jr.: Combined with typical ssl session shmcb ... That single process still has session keys of other prefork processes, as well as the common ssl session ticket key and ssl cert keys. In practice the benefits of prefork are somewhat limited to casual attacks. that's clear and anything related to SSL/TLS (certificates, keys) needs to be changed, the original question was about user-payload like passwords submitted via POST on the neighbour worker But how do you know it is only the neighbour worker? If the memory hasn't been cleared, the next connection from the attacker could get handled by the previous neighbour and confidential data might still sit in that processes memory readable by the attacker. What I didn't check until now, is whether one can describe the places/addresses in memory that are readable by an attacker (any address or only 64KB around an address at some fixed position in some request or connection handling struct) and whether we could for some platforms then describe the real exposure. Some data might always be to far away (very different address). Not sure whether that's feasible or the answer is simply any address. I see: this is actually a question concerning OpenSSL and its memory management. Exposed is memory starting at the received heartbeat request SSL packet structure living in OpenSSL. That is allocated by OpenSSL_malloc as well as most other OpenSSL memory. So it won't be easy to find valid assertions about what type of data should be safe. What *might* be, is that data loaded into memory by Apache itself and not passed to or from OpenSSL would typically not be accessible, e.g. Apache configuration information, scoreboard, request or response data from requests being handled by the same instance but not via HTTPS. For this to be true, APR pool allocated memory needs to be at least 64KB in address space away from any OPENSSL_malloc'ed memory. Regards, Rainer
Re: mod_cache thundering herd bug
On 9 Apr 2014, at 14:46, Eric Covener cove...@gmail.com wrote: r1023398 for 2.2: http://people.apache.org/~covener/patches/httpd-2.2.x-thunder.diff The remove_url() prevents other threads from serving a stale cached file during refresh of a slow response, but it's unnecessary to have a separate path because the refresh has to deal with 200s already. When the remove_url was added, there as no thundering herd lock / no ability to serve stale content while one guy was reloading. covener, mrumph, and I looked at this today at ApacheCon. I updated the bug with some comments and attached this patch. https://issues.apache.org/bugzilla/show_bug.cgi?id=50317
