#19655 [Com]: Using MM session handler, Apache crashs at child death.

ID: 19655 Comment by: php@garnould.com Reported By: php@garnould.com Status: Feedback Bug Type: Session related Operating System: 2.2.20 PHP Version: 4.2.3 New Comment: -----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----- Previous Comments: ------------------------------------------------------------------------ [2002-09-29 14:39:43] php@garnould.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 14:23:28] 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 08:26:12] sander@php.net Please recompile PHP with --enable-debug and provide a new backtrace. ------------------------------------------------------------------------ [2002-09-29 07:03:06] php@garnould.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 06:55:37] php@garnould.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 ... ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19655 -- Edit this bug report at http://bugs.php.net/?id=19655&edit=1