#25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

2004-02-02 Thread david at bizeweb dot com
 ID:   25753
 Comment by:   david at bizeweb dot com
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Apache related
 Operating System: *
 PHP Version:  4CVS, 5CVS
 New Comment:

I found out that to use the CVS that you'll need to use .buildconf
first.  I had not done that.  I have installed the cvs php properly now
(I hope) and can not repeat the error.  Sorry if I got anyone looking
for something that wasn't there.


Previous Comments:


[2004-02-02 08:25:48] david at bizeweb dot com

I a related problem to an apache list, and someone directed me to here.
 I thought timing was so perfect and that the problem was fixed. 
However, I think this bug still exists.  Unless I need to install a
specific CVS version. I have php4-STABLE-200402012230 installed on a
RH9 with apache2.0.44 with a php config of 
CFLAGS="-I/usr/kerberos/include -DSECURITY_HOLE_PASS_AUTHORIZATION"
./configure --with-apxs2=/usr/local/apache/bin/apxs --with-gettext
--with-imap=/dl/imap-2001a --with-kerberos --with-glibcc --with-xml
--with-mysql.

I've isolated my server and in my httpd.conf have set the following for
easy testing.
StartServers 1
MinSpareServers  1
MaxSpareServers 2


ServerName foo.com



php_admin_flag engine off
ServerName foo2.com

I can keep going to foo.com without any problems as soon as I goto
foo2.com, then foo.com will attempt to dl the php files.
I'm new to this field, but if I can help just ask.



[2004-01-28 12:40:04] [EMAIL PROTECTED]

This only happens on text/html files with the executable bit set.  If
the +x bit is set, we load the current ini settings and if php's
xbithack option is not set we decline the request but forget to reset
the ini settings potentially leaking them to the next request.  This is
now fixed in CVS and will be in the next release of both PHP4 and PHP5.



[2004-01-28 00:47:04] rover at tob dot ru

We examine source files more carefull and remake a patch:

diff -udr php-4.3.3/sapi/apache/mod_php4.c
php-4.3.3.patched/sapi/apache/mod_php4.c
--- php-4.3.3/sapi/apache/mod_php4.c2003-06-03 11:41:49.0
+0600
+++ php-4.3.3.patched/sapi/apache/mod_php4.c2004-01-28
10:48:27.0 +0500
@@ -830,6 +830,9 @@
}
if(!AP(xbithack)) {
r->allowed |= (1 << METHODS) - 1;
+   zend_try {
+   zend_ini_deactivate(TSRMLS_C);
+   } zend_end_try();
return DECLINED;
}
return send_parsed_php(r);



[2004-01-27 13:36:14] rover at tob dot ru

It seems we have found a bug in mod_php4.c. We can 100% reproduce this
error. How to reproduce (our case):
in httpd.conf we have:

# to enable only one instance of apache process
StartServers 1
MaxClients 1
#

php_value engine off


in php.ini:
Engine = On,
we enable php-scripts at all site, but disable in /info.

Let's begin:
#/usr/sbin/apache.dbg -f /etc/apache/httpd.conf
#gbd /usr/sbin/apache.gdb pid_of_child (attach to child, what serve
requests)
(gdb)p php_apache_info.engine
 =1! php-engine ENABLED
(gdb)watch php_apache_info.engine  ! VERY IMPORTANT
(gdb)break send_php! bug in this func.
(gdb)c

1) Request a usual file from http://our.site/info/index.html:
Because we define 'php_value off' for this directory - at line 829 in
function php_xbithack_handler(remember - we process text/html) we call
zend_hash_apply((HashTable *) per_dir_conf, (apply_func_t)
php_apache_alter_ini_entries TSRMLS_CC);
and change our 'engine' value to 0.
backtrace for this call (don't look at line number - they shifted
because i insert debug lines in source files):
Hardware watchpoint 1: php_apache_info.engine
Old value = 1
New value = 0
#0  OnUpdateInt (entry=0x80dc778, new_value=0x80d3cc4 "off",
new_value_length=3, mh_arg1=0x0, mh_arg2=0x4057f92c,
mh_arg3=0x0, stage=4) at
/usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
#1  0x4051110a in zend_alter_ini_entry (name=0x80de170 "engine",
name_length=7, new_value=0x80de180 "off",
new_value_length=3, modify_type=2, stage=4) at
/usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:212
#2  0x40519fc6 in php_apache_alter_ini_entries
(per_dir_entry=0x812c598)
at
/usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:511
#3  0x4050b8f9 in zend_hash_apply (ht=0x809fc98, apply_func=0x40519f40
)
at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_hash.c:698
#4  0x4051ad1b in php_xbithack_handler (r=0x81367ec)
at
/usr/local/src/apache2+php4/php4-4.3.3/sapi/apache

#25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

2004-02-02 Thread david at bizeweb dot com
 ID:   25753
 Comment by:   david at bizeweb dot com
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Apache related
 Operating System: *
 PHP Version:  4CVS, 5CVS
 New Comment:

I a related problem to an apache list, and someone directed me to here.
 I thought timing was so perfect and that the problem was fixed. 
However, I think this bug still exists.  Unless I need to install a
specific CVS version. I have php4-STABLE-200402012230 installed on a
RH9 with apache2.0.44 with a php config of 
CFLAGS="-I/usr/kerberos/include -DSECURITY_HOLE_PASS_AUTHORIZATION"
./configure --with-apxs2=/usr/local/apache/bin/apxs --with-gettext
--with-imap=/dl/imap-2001a --with-kerberos --with-glibcc --with-xml
--with-mysql.

I've isolated my server and in my httpd.conf have set the following for
easy testing.
StartServers 1
MinSpareServers  1
MaxSpareServers 2


ServerName foo.com



php_admin_flag engine off
ServerName foo2.com

I can keep going to foo.com without any problems as soon as I goto
foo2.com, then foo.com will attempt to dl the php files.
I'm new to this field, but if I can help just ask.


Previous Comments:


[2004-01-28 12:40:04] [EMAIL PROTECTED]

This only happens on text/html files with the executable bit set.  If
the +x bit is set, we load the current ini settings and if php's
xbithack option is not set we decline the request but forget to reset
the ini settings potentially leaking them to the next request.  This is
now fixed in CVS and will be in the next release of both PHP4 and PHP5.



[2004-01-28 00:47:04] rover at tob dot ru

We examine source files more carefull and remake a patch:

diff -udr php-4.3.3/sapi/apache/mod_php4.c
php-4.3.3.patched/sapi/apache/mod_php4.c
--- php-4.3.3/sapi/apache/mod_php4.c2003-06-03 11:41:49.0
+0600
+++ php-4.3.3.patched/sapi/apache/mod_php4.c2004-01-28
10:48:27.0 +0500
@@ -830,6 +830,9 @@
}
if(!AP(xbithack)) {
r->allowed |= (1 << METHODS) - 1;
+   zend_try {
+   zend_ini_deactivate(TSRMLS_C);
+   } zend_end_try();
return DECLINED;
}
return send_parsed_php(r);



[2004-01-27 13:36:14] rover at tob dot ru

It seems we have found a bug in mod_php4.c. We can 100% reproduce this
error. How to reproduce (our case):
in httpd.conf we have:

# to enable only one instance of apache process
StartServers 1
MaxClients 1
#

php_value engine off


in php.ini:
Engine = On,
we enable php-scripts at all site, but disable in /info.

Let's begin:
#/usr/sbin/apache.dbg -f /etc/apache/httpd.conf
#gbd /usr/sbin/apache.gdb pid_of_child (attach to child, what serve
requests)
(gdb)p php_apache_info.engine
 =1! php-engine ENABLED
(gdb)watch php_apache_info.engine  ! VERY IMPORTANT
(gdb)break send_php! bug in this func.
(gdb)c

1) Request a usual file from http://our.site/info/index.html:
Because we define 'php_value off' for this directory - at line 829 in
function php_xbithack_handler(remember - we process text/html) we call
zend_hash_apply((HashTable *) per_dir_conf, (apply_func_t)
php_apache_alter_ini_entries TSRMLS_CC);
and change our 'engine' value to 0.
backtrace for this call (don't look at line number - they shifted
because i insert debug lines in source files):
Hardware watchpoint 1: php_apache_info.engine
Old value = 1
New value = 0
#0  OnUpdateInt (entry=0x80dc778, new_value=0x80d3cc4 "off",
new_value_length=3, mh_arg1=0x0, mh_arg2=0x4057f92c,
mh_arg3=0x0, stage=4) at
/usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
#1  0x4051110a in zend_alter_ini_entry (name=0x80de170 "engine",
name_length=7, new_value=0x80de180 "off",
new_value_length=3, modify_type=2, stage=4) at
/usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:212
#2  0x40519fc6 in php_apache_alter_ini_entries
(per_dir_entry=0x812c598)
at
/usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:511
#3  0x4050b8f9 in zend_hash_apply (ht=0x809fc98, apply_func=0x40519f40
)
at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_hash.c:698
#4  0x4051ad1b in php_xbithack_handler (r=0x81367ec)
at
/usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:850
#5  0x080551c3 in ap_invoke_handler (r=0x81367ec) at http_config.c:518
#6  0x08067e28 in process_request_internal (r=0x81367ec) at
http_request.c:1332
#7  0x08067fd4 in ap_process_request (r=0x81367ec) at
http_request.c:1348
#8  0x08060644 in child_main (child_num_arg=0) at http_main.c:4719
#9  0x080607f7 in make_child (s=0x0, slot=0, now=0) at
http_main.c:4898
#10 0x08060920