You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2017/04/10 21:21:37 UTC

[Bug 60947] Segfault on startup when using mod_ssl with APR-crypto

https://bz.apache.org/bugzilla/show_bug.cgi?id=60947

Paul Spangler <pa...@ni.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paul.spangler@ni.com

--- Comment #2 from Paul Spangler <pa...@ni.com> ---
This comment isn't related to the particular issue you've described with the
callback, but is related to the title of the bug. We've also seen a rare
segfault when mixing mod_ssl with APR-crypto, but in SSL_load_error_strings
(which is supposedly fixed in 1.1.0, see
https://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=2325):

1. SSL_load_error_strings sets up a static hash table in libeay containing
error strings, some of which point to memory in ssleay.
2. libapr loads apr_crypto_openssl, which bumps the refcount on libeay.
3. Server executes normally... until say the child process crashes or a
graceful restart.
4. All modules are unloaded, but APR drivers are not (i.e. apr_crypto_openssl
remains loaded).
5. During unload, ssleay gets unloaded but libeay remains loaded due to step 2.
6. Modules are loaded again.
7. ssleay may load into a different location than it was in step 1.
8. The hash table from step 1 still exists (in libeay), but now if it tries to
check one of the SSL error strings, it points to a now-invalid place in memory,
crashing.

Our research led to this (somewhat old) mailing list thread:
http://mailing.openssl.dev.narkive.com/syUDbGxq/memory-corruption-after-libssl-is-unloaded-from-memory
where one of the devs is "not sure it has ever been a feasible goal to make
OpenSSL DSO/DLLs
able to be unloaded (with the aim of subsequently loading)."

In the end, we decided it was safest to pin ssleay and libeay in memory for the
lifetime of the server via a module that preloads them and never unloads them.
That "solution" wouldn't fix this particular callback issue since it's related
to mod_ssl moving in memory, but I figured this might be worth sharing anyway.
Feel free to ignore if it's irrelevant :)

Maybe the "fix" here would also be to pin whatever the callback points to in
memory (if that would even be feasible) so it survives a mod_ssl reload?

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org