PR 53435, r101624, mod_ssl: error strings can't be loaded again once?
Hi, latest comment in PR 53435 shows that memory leak in mod_ssl which happens during graceful restarts can be caused by r101624. Since this commit is 11 years old, I wanted to ask people here, if following is still true with current OpenSSL: @@ -255,7 +255,11 @@ static apr_status_t ssl_cleanup_pre_config(void *data) #endif #endif ERR_remove_state(0); - ERR_free_strings(); + + /* Don't call ERR_free_strings here; ERR_load_*_strings only + * actually load the error strings once per process due to static + * variable abuse in OpenSSL. */ + /* * TODO: determine somewhere we can safely shove out diagnostics * (when enabled) at this late stage in the game: Last comment in PR 53435 showed that leaks disappeared after reverting this patch and it does not seem to break anything here. Regards, Jan Kaluza
Fwd: SuexecUserGroup inside Directory context
On 9/11/14 1:26 AM, Martynas Bendorius wrote: For someone who is going to review the patch, I am adding more information of why is the patch needed. Patch includes only a few minor changes to it, that would help shared web hosting to adopt FastCGI for some critical parts like global aliases. Currently it's impossible to switch user for aliases (and with the patch it's easy to do). That's needed for situations like: Alias /roundcube /var/www/html/roundcube-1.0.2/ If application is placed under /var/www/html, it has a different user set when accessing the alias from user's virtualhost, so SuexecUserGroup needs to be specified globally like: Directory /var/www/html SuexecUserGroup webapps webapps /Directory That way when accessing anydomain.com/roundcube, it would be executed under webapps user permissions. Without the patch, due to SuexecUserGroup suexec configuration in VirtualHost context for the customer (shared hosting account), it's executed under customer's permissions (and most often the client doesn't have enough of permissions to read sensitive data like MySQL passwords and so on). From my point of view it adds more security and flexibility when using PHP-FastCGI under shared hosting environment. +1 for this one, it's a pity that this patch hasn't got the attention of suexec developer. It's a must feature for shared hosting environments where the same virtualhost can handle multiple applications from different users. -- Marc
is this pattern in event safe?
is this pattern in event safe? apr_pool_clear(cs-p); ap_push_pool(worker_queue_info, cs-p); cs itself is allocated from cs-p (ptrans) Must cs-p be copied to the stack since MaxMemFree could return these bytes? (I have been chasing a rare crash in this neighborhood, but this pattern doesn't seem to actually be the culrpit) -- Eric Covener cove...@gmail.com
Re: PR 53435, r101624, mod_ssl: error strings can't be loaded again once?
On 11/11/2014 13:32, Jan Kaluža wrote: Hi, latest comment in PR 53435 shows that memory leak in mod_ssl which happens during graceful restarts can be caused by r101624. Since this commit is 11 years old, I wanted to ask people here, if following is still true with current OpenSSL: @@ -255,7 +255,11 @@ static apr_status_t ssl_cleanup_pre_config(void *data) #endif #endif ERR_remove_state(0); - ERR_free_strings(); + + /* Don't call ERR_free_strings here; ERR_load_*_strings only + * actually load the error strings once per process due to static + * variable abuse in OpenSSL. */ + /* * TODO: determine somewhere we can safely shove out diagnostics * (when enabled) at this late stage in the game: Last comment in PR 53435 showed that leaks disappeared after reverting this patch and it does not seem to break anything here. I just checked the sources and this was fixed in OpenSSL 0.9.7m just over 7 years ago... Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: [Patch] mod_ssl SSL_CLIENT_CERT_SUBJECTS - access to full client certificate chain
On 09.11.2014 14:30, Graham Leggett wrote: On 06 Nov 2014, at 8:05 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote: Is there another way to do this? Manually performing what certificateExactMatch is specifying, I would say - i.e., use the (SSL_CLIENT_M_SERIAL,SSL_CLIENT_I_DN) tuple as a unique identifier for a specific client certificate. Imagine I trust two roots, A and X, where X has been compromised. I authorize the certificate chain A-B-C to perform a specific action. What stops the root X from issuing an intermediate certificate with subject “B” and a leaf certificate with subject “C” to produce a chain that goes X-B-C, and the client provides both the intermediate cert B and leaf certificate C during the SSL handshake? In other words, if I only consider the serial number and issuer during authorization, what stops a compromised-but-still-trusted CA from issuing an intermediate cert that replaces another trusted issuer? We seem to talk about two separate issues, I think: (1) to uniquely identify a certificate and store that identity in an LDAP directory (from your 1 Nov message), and (2) that I trust both CA1 and CA2 to issue certificates, but I don’t trust CA2 not to (accidentally or purposefully) issue a certificate with the same issuer as CA1. For (2), which is about authorization, the certification path can be a suitable criterion (note that X.509 also defines a CertificationPath ASN.1 type in this context, though in a more complex/complete way than what you're proposing). For (1), however, it's not sufficient to pick the subjectDN from an end-entity certificate - even from a trusted issuing CA, you may expect multiple certificates with the same issuer (think of dual-keying e.g.). Or another case to take into account is that an end-endity certificate may have an empty subject DN (RFC 5280 section 4.1.2.6), in which case the concatenation of the subjectDNs (the proposed SSL_CLIENT_CERT_SUBJECTS string) wouldn't work at all. As pointed out by Tim Bannister meanwhile, comparing the complete certificate against a userCertificate LDAP attribute would be the most secure way to make sure that the user has indeed authenticated with the certificate you require. If mod_authnz_ldap's Require ldap-attribute could be extended to allow value definitions based on SSL_CLIENT_CERT, then you wouldn't depend on CertificateExactMatch support in the LDAP server (the PEM headers in SSL_CLIENT_CERT would have to be stripped before comparing to the LDAP attribute, perhaps an additional var like SSL_CLIENT_CERT_DER could be introduced if this makes things simpler in mod_authnz_ldap). Kaspar
Re: PR 53435, r101624, mod_ssl: error strings can't be loaded again once?
On 12.11.2014 03:28, Dr Stephen Henson wrote: I just checked the sources and this was fixed in OpenSSL 0.9.7m just over 7 years ago... For 0.9.8, it was fixed with 0.9.8e: https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=900f7a87760d1053127976480efcd71371787d6e I.e., given that for 2.4.x, we still support 0.9.8a (and for 2.2.x, even 0.9.6 something), the ERR_free_strings() call should probably be wrapped by a suitable #if (OPENSSL_VERSION_NUMBER = Kaspar
Re: PR 53435, r101624, mod_ssl: error strings can't be loaded again once?
On 11/12/2014 07:16 AM, Kaspar Brand wrote: On 12.11.2014 03:28, Dr Stephen Henson wrote: I just checked the sources and this was fixed in OpenSSL 0.9.7m just over 7 years ago... For 0.9.8, it was fixed with 0.9.8e: https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=900f7a87760d1053127976480efcd71371787d6e I.e., given that for 2.4.x, we still support 0.9.8a (and for 2.2.x, even 0.9.6 something), the ERR_free_strings() call should probably be wrapped by a suitable #if (OPENSSL_VERSION_NUMBER = Thanks for the info. I will do the patch and commit it to trunk and propose for 2.4.x. Kaspar Regards, Jan Kaluza
