php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #19655 Using MM session handler, Apache crashs at child death.
Submitted: 2002-09-29 06:16 UTC Modified: 2002-10-27 19:11 UTC
From: php at garnould dot com Assigned:
Status: No Feedback Package: Session related
PHP Version: 4.2.3 OS: 2.2.20
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: php at garnould dot com
New email:
PHP Version: OS:

 

 [2002-09-29 06:16 UTC] php at garnould dot com
Hi there,

I have a strange problem : when my apache childs are exiting, they crashs in a very strange way. 

--- 8< ---
./configure --prefix=/usr/local/php --with-apache=[1.2.26] --with-mysql=/usr/local/mysql --enable-memory-limit=yes --enable-debug=no --with-gettext=[path_to_gettext] --with-imap=[imap-2002.RC6] --with-xml --with-mcrypt=[2.5.3] --with-mm=[1.2.1]
--- 8< ---

First, the behaviour is the same with mm-1.1.3 ...

My PHP is using mm as sessions handler (session.save_handler = mm) but the gdb back trace is _VERY_ strange :

(gdb) bt
#0  0x80e5100 in ps_gc_files ()
#1  0x80e5286 in zm_shutdown_ps_mm ()
#2  0x81425bf in module_destructor ()
#3  0x8143ae9 in zend_hash_destroy ()
#4  0x81400bc in zend_shutdown ()
#5  0x80bfbe7 in php_module_shutdown ()
#6  0x80bfbc8 in php_module_shutdown_wrapper ()
#7  0x80bdd60 in php_xbithack_handler ()
#8  0x815f8ce in ap_run_cleanup ()
#9  0x815dfb4 in ap_clear_pool ()
#10 0x815e029 in ap_destroy_pool ()
#11 0x815df8c in ap_clear_pool ()
#12 0x815e029 in ap_destroy_pool ()
#13 0x816cac2 in ap_exists_scoreboard_image ()
#14 0x816f793 in ap_child_terminate ()
#15 0x816fc93 in main ()
#16 0x400d99cb in __libc_start_main () at hash/hash_rec.c:724

#1 is sayung that zm_shutdown_ps_mm is being called, which is normal, but #0 says that zm_shutdown_ps_mm calls ps_gc_files, and this is not normal : ps_gc_files is a "files sessions" handler and not a mm handler ... 

Any idea ?


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-09-29 06:39 UTC] php at garnould dot com
I forgot to talk about the environment : PHP 4.2.3 is compiled with Apache 1.3.26, mod_ssl 2.8.10, openssl 0.9.6g ...
I have logs relating that the Apache/mod_ssl worm (see http://www.cert.org/advisories/CA-2002-27.html) tried to infect the server ... Anyway, and according to CERT, it can only infect "<= openssl 0.9.6.d" ... But the hit of this worm could may be rewrite some parts of the memory (and addressing tables) ? This is just an idea, not the solution of my problem ...
 [2002-09-29 06:55 UTC] php at garnould dot com
More infos :
According to the symbols table (objdump), we have :
080e4d30 g     F .text  00000024              ps_gc_files
080e50d4 l     F .text  00000067              ps_mm_destroy

According to gdb, the problem is at 0x80e5100, meaning that is occurs into ps_mm_destroy ... Let say that gdb reporting is wrong ...But I still have the problem, I suppose ...
 [2002-09-29 07:03 UTC] php at garnould dot com
ps_mm_destroy() says :

/* This function is called during each module 
   shutdown, but we must not release the shared 
   memory pool, when an Apache child dies! */
   if (data->owner != getpid()) return;

Every child seems to try to free data, meaning that every child feel like data->owner == getpid()) ... How is this possible ?
 [2002-09-29 08:26 UTC] sander@php.net
Please recompile PHP with --enable-debug and provide a new backtrace.
 [2002-09-29 14:23 UTC] sniper@php.net
Is your configure line REALLY like that? I think it's just
that you haven't got MM support. Check phpinfo() output for 'Additional Modules' list. There should be 'session mm' entry if you have it.

(I can't reproduce that segfault with 4.2.3 or 4.3.0-dev)

 [2002-09-29 14:39 UTC] php at garnould dot com
Well, the braces values indicate the release version I used to compiled ... The configure script is called by a shell script rebuilding automatically everything, in order to upgrade easilly the packages when new releases are availables ... Yes, the "session mm" appears under "Additional Modules" section ... And the handler is correct (session.save_handler -> mm) ... 

It seems that this trouble only occurs when the Apache server is hit by the OpenSSL/Worm Slapper (see http://www.cert.org/advisories/CA-2002-27.html) ... My apache is build with a 0.9.6g OpenSSL so that the worm can't infect the server, but it could may be corrupt the memory ? I rebuilt Apache+mod_php with --enable-debug=yes and re-opened the https port, waiting for the trouble to reapper, creating a core file ... Right now, the problem stopped like everytime I stop and restart the httpd process. 

Strange strange strange ...
 [2002-09-29 16:45 UTC] php at garnould dot com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I feel like sure ( :-) ) that Apache/OpenSSL 0.9.6g is still
vulnerable to a Slapper worm attack ... 

I downloaded "Slapper worm like" code - available "for testing
prupose only" - from somewhere on the Internet, modified it to ensure
it will only attack my server when launched, and then launched it ...
Everything occured normally, the virus didn't infect my computer, the
same behaviour as the very first attacks. I used my httpd server and
segfaulted it by doing it ... I have gdb'ed my httpd+core, and
arrived on the same place in source code as mentioned in first first
gdb log. The
worm-like had crashed my apache. I checked logged and was the only
one to attack the computer. That means that OpenSSL 0.9.6g is not
safe right now ... I retried several times again but failed to
reproduce the crash ... That's why I "feel like sure" :-)

Anyway - and perhaps because of my parano. :) - I have closed my 443
window and wait for a better weather outside ;-)
openssl-0.9.6h.tar.gz ? :) An advice ...

My apache logs are showing tonight :
Unknown(0) : Notice - Login failed: authentication failure (errflg=1)
Unknown(0) : Notice - Login failed: authentication failure (errflg=1)
Unknown(0) : Notice - Login failed: authentication failure (errflg=1)
Unknown(0) : Notice - Too many login failures (errflg=2)

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.1

iQA/AwUBPZdy0BTEKqrwXlPeEQKg2ACeM+Lm5/S4PyhWykqbJYdVJaH2S1YAn3F8
XZBoIUmzRJ71rEgPRzoEm6/6
=fJ52
-----END PGP SIGNATURE-----
 [2002-09-29 17:33 UTC] sniper@php.net
Please, don't sign your comments..and are you 100% sure 
you're really compiling with 0.9.6g ? And that ALL your
software is linked with it?

Best way to be sure about it is to first remove all binaries
compiled with openssl and all old openssl libraries from your system and compile the latest from scratch.

 [2002-09-29 17:40 UTC] php at garnould dot com
> and are you 100% sure you're really compiling with 0.9.6g ? 

Yes, Apache+mod_ssl are linked with a just "untagzip'ed and compiled" openssl-0.9.6g ...

> And that ALL your software is linked with it?

Why would other software be linked with it ? We're only takking about a httpd process, not the whole of the system.

> Best way to be sure about it is to first remove all binaries
> compiled with openssl and all old openssl libraries from your system
> and compile the latest from scratch.

Why would I do that ? I am sure the steps I made : it is an Apache+0.9.6g (as shown in headers) and it is crashed by the worm code :(

Georges
 [2002-09-29 20:03 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

I meant all the libraries you link with PHP and apache with.
But please try the snapshot, it's more likely not related to SSL anyway and there were some fixes in CVS just today which should prevent this.

 [2002-10-01 13:14 UTC] pgp at garnould dot com
I tested the php4-200209300600 snap. I still have apache segfaulting :

#0  ps_mm_destroy (data=0x83f26a8) at /space/build/apache/php4-200209300600/ext/session/mod_mm.c:241
241                             next = sd->next;
(gdb) bt
#0  ps_mm_destroy (data=0x83f26a8) at /space/build/apache/php4-200209300600/ext/session/mod_mm.c:241
#1  0x8135606 in zm_shutdown_ps_mm (type=1, module_number=18) at /space/build/apache/php4-200209300600/ext/session/mod_mm.c:293
#2  0x81348c4 in zm_shutdown_session (type=1, module_number=18)
    at /space/build/apache/php4-200209300600/ext/session/session.c:1511
#3  0x80e880f in module_destructor (module=0x83e2518) at /space/build/apache/php4-200209300600/Zend/zend_API.c:1128
#4  0x80e9e47 in zend_hash_apply_deleter (ht=0x839d460, p=0x83e24e8) at /space/build/apache/php4-200209300600/Zend/zend_hash.c:598
#5  0x80e9f59 in zend_hash_graceful_reverse_destroy (ht=0x839d460) at /space/build/apache/php4-200209300600/Zend/zend_hash.c:664
#6  0x80e62dc in zend_shutdown () at /space/build/apache/php4-200209300600/Zend/zend.c:512
#7  0x80cae93 in php_module_shutdown () at /space/build/apache/php4-200209300600/main/main.c:1193
#8  0x80cae74 in php_module_shutdown_wrapper (sapi_globals=0x835b520) at /space/build/apache/php4-200209300600/main/main.c:1170
#9  0x80c1540 in apache_php_module_shutdown_wrapper ()
#10 0x81966ce in run_cleanups ()
#11 0x8194db4 in ap_clear_pool ()
#12 0x8194e29 in ap_destroy_pool ()
#13 0x8194d8c in ap_clear_pool ()
#14 0x8194e29 in ap_destroy_pool ()
#15 0x81a38c2 in clean_parent_exit ()
#16 0x81a6593 in standalone_main ()
#17 0x81a6a93 in main ()
 [2002-10-12 10:34 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


 [2002-10-27 19:11 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.


 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sun Nov 27 19:03:46 2022 UTC