php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22213 Apache mod_ssl + PHP + cURL SSL segfault
Submitted: 2003-02-13 15:56 UTC Modified: 2003-08-20 23:59 UTC
Votes:4
Avg. Score:4.2 ± 0.8
Reproduced:3 of 3 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (33.3%)
From: alan at pair dot com Assigned:
Status: No Feedback Package: cURL related
PHP Version: 4CVS-2003-08-15 (stable) OS: FreeBSD 4.6-STABLE
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: alan at pair dot com
New email:
PHP Version: OS:

 

 [2003-02-13 15:56 UTC] alan at pair dot com
I've reproduced this bug with PHP versions 4.2.2, and the STABLE PHP dated Feb 13, 2003. 

FreeBSD 4.6-stable
PHP 4.2.2 --with-curl
curl --with-ssl, versions 7.9.8 and 7.10.3
Apache 1.3.27 mod_ssl
OpenSSL 0.9.7, and a variety of flavors of 0.9.6.

To reproduce the bug:
* start apache
* send a HUP signal to apache's parent process (to restart it)

The server needn't serve any pages (php or otherwise) before the HUP is sent.  Apache crashes, I believe while trying to reinitialize the mod_ssl module.

Running the same version of everything, but curl compiled --without-ssl
makes it work correctly: the apache parent kills off its children and spawns new ones without the parent segfaulting.

It seems to be dying inside SSL_CTX_ctrl (via SSL_CTX_set_options) when called from apache's ssl_init_ConfigureServer, at this line:

SSL_CTX_set_options(ctx, SSL_OP_ALL);

Unfortunately, by the time it segfaults, the stack has been corrupted, and it gets really difficult to debug.

Alan



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-02-13 16:17 UTC] iliaa@php.net
This bug could be related to bug #22112.
 [2003-02-13 19:22 UTC] sniper@php.net
And the full configure line used to configure php was..?

 [2003-02-14 08:33 UTC] alan at pair dot com
The configure command:

./configure --with-apache=/usr/pair/sw/apachessl_1.3.27 --with-config-file-path=/usr/local/etc --enable-magic-quotes --enable-bcmath --without-cdb --with-zlib-dir=/usr/local --with-gd --without-ttf --without-msql --with-mysql=/usr/local --with-iodbc --with-pdflib --enable-inline-optimization --disable-memory-limit --with-db --without-gdbm --with-ndbm --without-db2 --without-dbm --with-gettext --without-readline --with-recode --with-openssl=/usr/local/ssl --with-mcrypt --without-db3 --enable-dba --with-curl=/usr/local/lib --with-png-dir=/usr/local/lib

Compiling without "--with-curl" fixes the bug.  Compiling curl "--without-ssl" also does the trick.
 [2003-02-14 08:41 UTC] alan at pair dot com
Regarding notes/issues raised on bug #22112:
I made sure that apache is linking against only one copy of libssl and libcrypto.  

We have a global ErrorLog directive in the httpd.conf we're testing with, but no VirtualHost blocks at all: it's a base conf file, and the server doesn't even need to serve any pages for this to be a problem for us.

Our httpd.conf conditionally turns on SSL only when the "-DSSL" flag is present.  When apache is run without that flag, it works without any problems.  It crashes only when SSL is running.

("SSLEngine on" only happens with -DSSL)

Thanks.
 [2003-02-14 17:16 UTC] daniel at haxx dot se
How about providing a stack trace or something that shows us what was going on when it crashed?

For information, libcurl calls only two functions to initialize the OpenSSL library:

SSL_load_error_strings();
SSLeay_add_ssl_algorithms(); (a define for SSL_library_init)

(The rest is done when some action is called for, and this report says that isn't required for this problem to occur.)

I honestly can't see how this can be wrong from a libcurl point of view.
 [2003-02-18 08:54 UTC] alan at pair dot com
Here's a stack dump when it segfaults:

Program received signal SIGSEGV, Segmentation fault.
0x81df50c in SSL_CTX_ctrl ()
(gdb) bt
#0  0x81df50c in SSL_CTX_ctrl ()
#1  0x81793f4 in ssl_init_Module (s=0x830b038, p=0x830b010)
#2  0x8179741 in ssl_init_Module (s=0x830b038, p=0x830b010)
    at ssl_engine_init.c:304
#3  0x8195dd0 in ap_init_modules (p=0x830b010, s=0x830b038)
    at http_config.c:1703
#4  0x81a059e in standalone_main (argc=5, argv=0xbfbffa54) at http_main.c:5172
#5  0x81a0ec0 in main (argc=5, argv=0xbfbffa54) at http_main.c:5566
#6  0x807f72d in _start ()
(gdb) 

However, as I mentioned before, that's not completely accurate.  Stepping through the code, here's a bit more detail as to where it's crashing:

(gdb)n
585             ctx = SSL_CTX_new(SSLv23_server_method()); /* be more flexible */
(gdb) bt
#0  ssl_init_ConfigureServer (s=0x830b038, p=0x830b010, sc=0x830b3e0)
    at ssl_engine_init.c:585
#1  0x8179741 in ssl_init_Module (s=0x830b038, p=0x830b010)
    at ssl_engine_init.c:304
#2  0x8195dd0 in ap_init_modules (p=0x830b010, s=0x830b038)
    at http_config.c:1703
#3  0x81a059e in standalone_main (argc=5, argv=0xbfbffa54) at http_main.c:5172
#4  0x81a0ec0 in main (argc=5, argv=0xbfbffa54) at http_main.c:5566
#5  0x807f72d in _start ()
(gdb) n
586         SSL_CTX_set_options(ctx, SSL_OP_ALL);
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0x81df50c in SSL_CTX_ctrl ()
(gdb) bt
#0  0x81df50c in SSL_CTX_ctrl ()
#1  0x81793f4 in ssl_init_Module (s=0x830b038, p=0x830b010)
#2  0x8179741 in ssl_init_Module (s=0x830b038, p=0x830b010)
    at ssl_engine_init.c:304
#3  0x8195dd0 in ap_init_modules (p=0x830b010, s=0x830b038)
    at http_config.c:1703
#4  0x81a059e in standalone_main (argc=5, argv=0xbfbffa54) at http_main.c:5172
#5  0x81a0ec0 in main (argc=5, argv=0xbfbffa54) at http_main.c:5566
#6  0x807f72d in _start ()
(gdb) 


This particular version is compiled with PHP 4.3.0, Apache 1.3.27, mod_ssl 2.8.12, and curl 7.10.3.  But I've been able to reproduce it with different versions of curl and PHP.

If I run the same compiled executable without SSL turned on, it does not segfault when it receives HUP.
If I compile curl --without-ssl, and compile php against this version of curl, apache does not segfault when it receives SIGHUP even when modssl is turned on.
If I compile PHP without curl, apache does not segfault when it receives SIGHUP.

I don't know that it's curl's fault.  I just know that the problem goes away when PHP isn't using curl, or when curl isn't using SSL.

Thanks,
Alan
 [2003-02-18 12:02 UTC] sniper@php.net
Is mod_ssl compiled as DSO? Or static module?

I have both PHP and mod_ssl as DSOs and I can not
reproduce this..

 [2003-02-18 12:43 UTC] alan at pair dot com
It looks like both mod_php and mod_ssl are being compiled in statically, along with a static core.

I'm going to try doing this DSO and see if it helps; but that may not be an option for us depending on why things were compiled statically in the first place.  Thanks.
 [2003-02-18 13:10 UTC] alan at pair dot com
Building apache with mod_so, SHARED_CORE=yes, and mod_ssl as a SharedModule prevents this bug from showing its head.  However, we're still interested in getting this working in the statically compiled version, so if you can reproduce it in that environment, we'd appreciate any insight on what's causing it there.  Thanks!

Alan
 [2003-07-24 13:59 UTC] php at dpk dot net
I'm using static modules here. The setup worked fine on one server, but not on the other. The primary difference - the borken one did the 'ClearModuleList' and then 'AddModule' for every module, while the other did not.

Getting rid of the ClearModuleList and AddModule directives fixed it. I suspect it was a problem in the order in which the modules were loaded.
 [2003-08-15 08:26 UTC] sniper@php.net
Could you try this:

1. rm -rf ext/openssl
2. ./cvsclean && ./buildconf (hopefully you have the right tools to rebuild the configure :)
3. do the normal installation of PHP as static apache module

 [2003-08-20 23:59 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2006-05-15 09:47 UTC] michael at gamepoint dot net
Hello,

I had a problem with this setup as well.
All installed with FreeBSD ports.
Configure command:
'./configure' '--enable-versioning' '--enable-memory-limit' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--with-regex=php' '--with-apxs=/usr/local/sbin/apxs' '--prefix=/usr/local' 'i386-portbld-freebsd4.11' 

mod_ssl and cURL loaded as a module by /usr/local/etc/php/extensions.ini.
In extensions.ini, cURL was loaded *before* mod_openssl was loaded.

When I changed this to mod_openssl loaded before cURL, it worked.

This solved the problem for me.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Thu Jun 04 12:01:25 2020 UTC