On Jan 18, 2012, at 8:40 AM, Daniel Ruggeri wrote: > All; > I stumbled across this yesterday and was hoping some of our more > experienced openssl developers may be able to offer suggestions on how I > can track this down. I've been testing on 2.2.21 though the code should > be the same in trunk/2.4. The patch I've applied is currently proposed > for backport in 2.2 (and works fine until using an openssl engine). > > Patch applied to 2.2.21 distribution - trunk already has this: > http://people.apache.org/~druggeri/patches/httpd-2.2-SSLProxyMachineCertificateChainFile.patch > > When the new SSLProxyMachineCertificateChainFile directive is set at the > same time SSLCryptoDevice is set, a segfault occurs during > ssl_hook_pre_config while calling SSL_load_error_strings. The backtrace > I gathered with dbx points to something deeper inside openssl, but I'm > sure I've done something to cause it.
Interesting... which version of OpenSSL? Must be 0.9.7 or 0.9.8, because err_cmp() disappeared after that. And the signature doesn't match what we're seeing in the backtrace. And which platform? Solaris? SPARC or x86_64? > t@1 (l@1) signal SEGV (no mapping at the fault address) in err_cmp at > 0xffffffff7ab05540 > 0xffffffff7ab05540: err_cmp : ld [%o0 + 4], %o3 > Current function is ssl_hook_pre_config (optimized) > 280 SSL_load_error_strings(); > (dbx) where > current thread: t@1 > [1] err_cmp(0xffffffff7ae542a8, 0xffffffff7fff9470, 0x22cd, > 0x100251f30, 0xac, 0xab), at 0xffffffff7ab05540 > [2] lh_retrieve(0x10023aa80, 0xffffffff7fff9470, 0x14064057, 0x57, > 0x10024edc8, 0xffffffff7ab05540), at 0xffffffff7ab034bc > [3] int_err_get_item(0xffffffff7fff9470, 0xffffffff7acb4528, 0x14520, > 0xffffffff7aca0008, 0x19b904, 0x14400), at 0xffffffff7ab0476c > [4] ERR_func_error_string(0x64, 0xffffffff7acbdf48, 0x14520, > 0xffffffff7acbdf48, 0xffffffff7acb4528, 0x14400), at 0xffffffff7ab053d0 > [5] ERR_load_SSL_strings(0x0, 0xffffffff77e542a8, 0xffffffff77e4f0d0, > 0x51d8, 0x105df4, 0x5000), at 0xffffffff77d492f8 > =>[6] ssl_hook_pre_config(pconf = ???, plog = ???, ptemp = ???) > (optimized), at 0xffffffff77f08f04 (line ~280) in "mod_ssl.c" > [7] ap_run_pre_config(pconf = ???, plog = ???, ptemp = ???) > (optimized), at 0x10004cfe4 (line ~85) in "config.c" > [8] main(argc = ???, argv = ???) (optimized), at 0x100031954 (line > ~709) in "main.c" > > For reference, removing one directive or the other avoids the segfault. > This seems to be brought on by the combination of the two (and possibly > the engine implementation). So the combination of directives causes some memory to be overwitten that ends up pointing outside httpd's allocated address space. Does the order of the directives matter? Which Engine if I may ask? A fix was applied to the CHIL Engine that removes a dangling cleanup function pointer which caused a segfault on startup on platforms that vary the address location in which libraries are loaded (RHEL 5 being a prime example). I don't remember off the top of my head which OpenSSL version got the fix. Can you reproduce with a non-optimized, debug/symbols enabled build of OpenSSL and Apache? With the latest versions of each? S. > Any ideas? > > -- > Daniel Ruggeri > -- scte...@apache.org http://www.temme.net/sander/ PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A View my availability: http://tungle.me/sctemme
