Hello, Just test : Into php.ini put safe_mode = On Then into a VirtualHost put : php_admin_value session.save_path /var/www/somewherehowexist Apache2 SIG 11. Regards.
Hello, A nice DOS : create a .htaccess -> php_value session.save_path /var/www/somewherehowexist Apache SIG 11 A nice security problem. Please gentoo-security close the bug to public. Regards.
Adding individual members rather than alias
Same for php-bugs alias...
Setting component to Auditing until a confirmation is made.
I can confirm the segfault - now recompiling apr, apr-util, apache, and mod_php with debugging symbols so we can pin this down.
Source : http://www.gentoo.org/doc/en/bugzilla-howto.xml#doc_chap2 Adding -ggdb3 into /etc/make.conf CFLAGS emerge gdb Adding debug to /etc/portage/package.use to dev-php/mod_php-4.4.0-r3 and net-www/apache-2.0.54-r31 emerge -pv : Calculating dependencies ...done! [ebuild R ] net-www/apache-2.0.54-r31 +apache2 +debug* -doc -ldap -mpm-leader -mpm-peruser -mpm-prefork -mpm-threadpool -mpm-worker -no-suexec (-selinux) +ssl -static-modules +threads [ebuild R ] dev-php/mod_php-4.4.0-r3 -X +apache2 +berkdb +crypt -curl* +debug* -doc -fdftk -firebird -flash -freetds +gd -gd-external +gdbm -gmp -hardenedphp -imap -informix -ipv6* -java* +jpeg -kerberos -ldap -mcal +memlimit -mssql +mysql +nls -oci8 -odbc +pam +png -postgres -snmp* +spell +ssl +tiff +truetype +xml2 -yaz FEATURES="nostrip" emerge apr apr-util apache mod_php Into php.ini : safe_mode = On Into virtualhost off apache : php_admin_value session.save_path /var/www/vhosts/somewhereexisting gdb --args /usr/sbin/apache2 -D PHP4 -D JK -d /usr/lib/apache2 -f /etc/apache2/httpd.conf -E /var/log/apache2/startuperror.log -k start europe apache2-php4 # gdb --args /usr/sbin/apache2 -D PHP4 -D JK -d /usr/lib/apache2 -f /etc/apache2/httpd.conf -E /var/log/apache2/startuperror.log -k start GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/sbin/apache2 -D PHP4 -D JK -d /usr/lib/apache2 -f /etc/apache2/httpd.conf -E /var/log/apache2/startuperror.log -k start warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 8817)] Program exited normally. If I access the virtual host containing the php_admin_value : into /var/log/apache2/error_log [Fri Sep 30 10:26:22 2005] [notice] child pid 12644 exit signal Trace/breakpoint trap (5) Yet with : set follow-fork-mode child (gdb) set follow-fork-mode child (gdb) run Starting program: /usr/sbin/apache2 -D PHP4 -D JK -d /usr/lib/apache2 -f /etc/apache2/httpd.conf -E /var/log/apache2/startuperror.log -k start warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 15510)] Program exited normally. Still in log : [Fri Sep 30 10:33:11 2005] [notice] child pid 17743 exit signal Trace/breakpoint trap (5) So they are no way to see debuggin info with gdb Regards
ahh, but there is, you just have to read the docs... man apache2 shows us that running with -X will keep it from forking. Here is a better backtrace: vericgar@phoenix ~ $ sudo gdb /usr/sbin/apache2 GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) set args -D DEFAULT_VHOST -D USERDIR -D PHP4 -X (gdb) run Starting program: /usr/sbin/apache2 -D DEFAULT_VHOST -D USERDIR -D PHP4 -X [Thread debugging using libthread_db enabled] [New Thread -1212466336 (LWP 2592)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1212466336 (LWP 2592)] 0xb7893f1e in ?? () from /usr/lib/apache2/modules/libphp4.so (gdb) bt #0 0xb7893f1e in ?? () from /usr/lib/apache2/modules/libphp4.so #1 0xb78503c6 in ?? () from /usr/lib/apache2/modules/libphp4.so #2 0xb77e476b in ?? () from /usr/lib/apache2/modules/libphp4.so #3 0xb784c7af in ?? () from /usr/lib/apache2/modules/libphp4.so #4 0xb784ca85 in ?? () from /usr/lib/apache2/modules/libphp4.so #5 0xb779d394 in ?? () from /usr/lib/apache2/modules/libphp4.so #6 0xb7889a0a in ?? () from /usr/lib/apache2/modules/libphp4.so #7 0xb789500d in ?? () from /usr/lib/apache2/modules/libphp4.so #8 0xb7894463 in ?? () from /usr/lib/apache2/modules/libphp4.so #9 0x08068e03 in ap_invoke_handler (r=0x826bca0) at config.c:152 #10 0x0806622b in ap_process_request (r=0x826bca0) at http_request.c:249 #11 0x08060fc8 in ap_process_http_connection (c=0x8265b20) at http_core.c:251 #12 0x08074125 in ap_process_connection (c=0x8265b20, csd=0x8265a68) at connection.c:43 #13 0x080688d6 in child_main (child_num_arg=-1215742192) at prefork.c:610 #14 0x08067d0d in make_child (s=0xbfffd70c, slot=0) at prefork.c:650 #15 0x08067754 in ap_mpm_run (_pconf=0x0, plog=0x80cf150, s=0x5) at prefork.c:722 #16 0x0806edff in main (argc=8, argv=0xbffffd64) at main.c:618 However, I can't seem to get debugging symbols for mod_php, which is where we need them. Anyone with more skill in debugging mod_php have ideas?
Hello, I have also test with CoreDumpDirectory /tmp into httpd.conf No way to have the core for this error's. Regards.
Public by way of bug 98871
*** Bug 98871 has been marked as a duplicate of this bug. ***
Romang: on bug 98871 the suggestion of USE=gd-external was made to solve the problem, does it solve it for you ? This could help in narrowing the problem, and provide a temporary workaround.
Hmmm I've just made a backtrace with GDB of this: php_apache_sapi_ub_write (str=0x0, str_length=102, tsrm_ls=0x811eca8) at /portcomp/portage/php-4.4.0-r1/work/php-4.4.0/sapi/apache2handler/sapi_apache2.c:74 74 /portcomp/portage/php-4.4.0-r1/work/php-4.4.0/sapi/apache2handler/sapi_apache2.c: No such file or directory. in /portcomp/portage/php-4.4.0-r1/work/php-4.4.0/sapi/apache2handler/sapi_apache2.c (gdb) bt #0 php_apache_sapi_ub_write (str=0x0, str_length=102, tsrm_ls=0x811eca8) at /portcomp/portage/php-4.4.0-r1/work/php-4.4.0/sapi/apache2handler/sapi_apache2.c:74 #1 0x406d4e96 in php_ub_body_write_no_header (str=0x0, str_length=0, tsrm_ls=0x811eca8) at /portcomp/portage/php-4.4.0-r1/work/php-4.4.0/main/output.c:689 #2 0x406d304b in php_body_write (str=0x0, str_length=0, tsrm_ls=0x811eca8) at /portcomp/portage/php-4.4.0-r1/work/php-4.4.0/main/output.c:121 #3 0x406b6e8e in php_printf (format=0x0) at /portcomp/portage/php-4.4.0-r1/work/php-4.4.0/main/main.c:430 #4 0x406b7b2f in php_error_cb (type=2, error_filename=0x4073c46b "Unknown", error_lineno=0, format=0x0, args=0x4075cf78 "") at /portcomp/portage/php-4.4.0-r1/work/php-4.4.0/main/main.c:665 #5 0x40700875 in zend_error (type=2, format=0x40746dfd "%s(%s): %s") at /portcomp/portage/php-4.4.0-r1/work/php-4.4.0/Zend/zend.c:789 #6 0x406b74c2 in php_verror (docref=0x4073c46b "Unknown", params=0x4075cf78 "", type=2, format=0x0, args=0x0, tsrm_ls=0x811eca8) at /portcomp/portage/php-4.4.0-r1/work/php-4.4.0/main/main.c:522 #7 0x406b75f8 in php_error_docref0 (docref=0x0, tsrm_ls=0x0, type=0, format=0x0) at /portcomp/portage/php-4.4.0-r1/work/php-4.4.0/main/main.c:551 #8 0x406bebd4 in php_checkuid_ex (filename=0x4df98e60 "/foo/bar", fopen_mode=0x4df98e64 "/bar", mode=3, flags=0) at /portcomp/portage/php-4.4.0-r1/work/php-4.4.0/main/safe_mode.c:144 #9 0x406bed56 in php_checkuid (filename=0x0, fopen_mode=0x0, mode=0) at /portcomp/portage/php-4.4.0-r1/work/php-4.4.0/main/safe_mode.c:191 #10 0x40609d9f in OnUpdateSaveDir (entry=0x82a31d0, new_value=0x82abc88 "/foo/bar", new_value_length=0, mh_arg1=0x0, mh_arg2=0x407c2fa8, mh_arg3=0x0, stage=16, tsrm_ls=0x811eca8) at /portcomp/portage/php-4.4.0-r1/work/php-4.4.0/ext/session/session.c:123 #11 0x407111f6 in zend_alter_ini_entry (name=0x82abc88 "/foo/bar", name_length=0, new_value=0x816f188 "/foo/bar", new_value_length=8, modify_type=0, stage=0) at /portcomp/portage/php-4.4.0-r1/work/php-4.4.0/Zend/zend_ini.c:238 #12 0x40720a88 in apply_config () at /portcomp/portage/php-4.4.0-r1/work/php-4.4.0/sapi/apache2handler/apache_config.c:167 #13 0x4071f8e5 in php_handler (r=0x82a4658) at /portcomp/portage/php-4.4.0-r1/work/php-4.4.0/sapi/apache2handler/sapi_apache2.c:457 #14 0x0806d8f5 in ap_run_handler (r=0x82a4658) at config.c:152 #15 0x0806e34a in ap_invoke_handler (r=0x82a4658) at config.c:364 #16 0x080671c9 in ap_process_request (r=0x82a4658) at http_request.c:249 #17 0x080613f9 in ap_process_http_connection (c=0x825fe78) at http_core.c:251 #18 0x0807b4e5 in ap_run_process_connection (c=0x825fe78) at connection.c:43 #19 0x0807b9b1 in ap_process_connection (c=0x825fe78, csd=0x825fd88) at connection.c:176 #20 0x08068cab in process_socket (p=0x825fd50, sock=0x825fd88, my_child_num=136757056, my_thread_num=135392424, bucket_alloc=0x8263dd0) at worker.c:521 #21 0x0806969a in worker_thread (thd=0x819bac0, dummy=0x0) at worker.c:835 #22 0x403042a3 in dummy_worker (opaque=0x0) at thread.c:105 #23 0x4038cc8b in start_thread () from /lib/libpthread.so.0 #24 0x4045692e in clone () from /lib/libc.so.6 It seems this may be partially related with another bug I remember, where the PHP binary strangely has the paths of the sandbox build env hardcoded in it and this causes strange failures, it seems time to investigate this further. Btw to debug mod_php, just emerge dev-lang/php with USE="apache2 debug", add "nostrip" to FEATURES and "-g -ggdb3" to C(XX)FLAGS, it should work. Best regards, CHTEKK.
Ok it seems the problem is not the wrong paths, also compiling PHP normally (non sandbox, non using Portage) some paths are still hardcoded. Indeed I searched a little and bugs.php.net had the answer, it seems there was a bug in the apache2handler SAPI, sapi_apache2.c file, that made this segfault here possible, the bug now is fixed upstream and 5.1.0 final, 4.4.1 final and the next 5.0.X release will have the patch, that means we have to backport it for 4.3.11, 4.4.0, 5.0.4 and 5.0.5 here on Gentoo, wich I did: http://svn.gnqs.org/projects/gentoo-php-overlay/changeset/276 With this patch applied the problem did go away with PHP 4.4.0, please use the overlays PHP ebuilds and test and report if the patch fixes this also for you. Best regards, CHTEKK.
(In reply to comment #13) > With this patch applied the problem did go away with PHP 4.4.0, please use the > overlays PHP ebuilds and test and report if the patch fixes this also for you. OK, works here as well... thanks!
Hello, OK I release a small email on different mailing-list to explain the bug and how to exploit it with .htaccess file. Regards.
CHTEKK: Any ETA for pushing th fix to Portage ?
(In reply to comment #16) > CHTEKK: Any ETA for pushing th fix to Portage ? Nope, as I don't have CVS access yet to update the old-style PHP ebuilds. For new style I'll also need some more time to finish a mod I wanted to introduce with -r2 releases of dev-lang/php and maybe include another fix. I should be finished on my part (PHP Overlay) by this evening, then I only need CVS access wich should happen today or tomorrow and I can update them. Best regards, CHTEKK.
Fixed in CVS with the latest revisions of all PHP packages. For new-style PHP: dev-lang/php-4.3.11-r3 dev-lang/php-4.4.0-r3 dev-lang/php-4.4.1 dev-lang/php-5.0.4-r3 dev-lang/php-5.0.5-r3 For old-style PHP: dev-php/php-4.3.11-r3 dev-php/php-4.4.0-r3 dev-php/php-cgi-4.3.11-r4 dev-php/php-cgi-4.4.0-r4 dev-php/mod_php-4.3.11-r3 (old-style Apache config layout) dev-php/mod_php-4.4.0-r6 (old-style Apache config layout) dev-php/mod_php-4.4.0-r7 (new-style Apache config layout) Only old-style PHP needs to be stabled by the arch-teams, dev-lang/php does not need any particular keywording (though testing and adding to ~ARCH by the arch-teams who didn't already do it or anyway test the new revisions and dev-lang/php-4.4.1 is appreciated!). Best regards, CHTEKK.
stable handling on bug 111032
GLSA 200511-08
