php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #20190 Random mem corruption: zend_get_executed_filename() mismatch
Submitted: 2002-10-31 08:55 UTC Modified: 2003-06-02 17:24 UTC
Votes:10
Avg. Score:4.8 ± 0.4
Reproduced:6 of 7 (85.7%)
Same Version:5 (83.3%)
Same OS:4 (66.7%)
From: mbr at freebsd dot org Assigned:
Status: No Feedback Package: Apache related
PHP Version: 4.3.0-dev OS: FreeBSD
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2002-10-31 08:55 UTC] mbr at freebsd dot org
I've done this change in main/fopen_wrappers.c to see what
happens:

- php_error(E_WARNING, "open_basedir restriction
-           in effect. File is in wrong directory");

+ php_error(E_WARNING, "open_basedir: File should
+           be in %s, but is in %s file (%s)",
+           pathbuf, path,   
+           zend_get_executed_filename(TSRMLS_C));

let's say pathbuf=$a, path=$b, 
zend_get_executed_filename=$c

As you see $a (which is PG(open_basedir)), should be
identical to the path without added filename of both
$b and $c.

The error is random. Sometimes $a and $c are correct,
and $b is plain wrong (from a previous request). Sometimes
$a and $c are correct, and $b is wrong.

[24-Oct-2002 10:49:19] PHP Warning:  open_basedir: File should be in /www/doc/www.aaa.ch-80, but is in /www/doc/
www.bbb.ch-80/html/visions/php/include/globals.inc in
/www/doc/www.aaa.ch-80/index.php on line 2

[24-Oct-2002 10:49:19] PHP Warning:  open_basedir: File should be in
/www/doc/www.aaa.ch-80, but is in /www/doc/
www.bbb.ch-80/html/visions/php//wrapper.php in
/www/doc/www.aaa.ch-80/index.php on line 6
  
[24-Oct-2002 10:53:45] PHP Warning:  open_basedir: File should be in
/www/doc/www.aaa.ch-80, but is in /www/doc/
www.bbb.ch-80/html/visions/php//include/globals.inc in
/www/doc/www.aaa.ch-80/index.php on line 2
 
[24-Oct-2002 10:53:45] PHP Warning:  open_basedir: File should be in
/www/doc/www.aaa.ch-80, but is in /www/doc/
www.bbb.ch-80/html/visions/php//wrapper.php in
/www/doc/www.aaa.ch-80/index.php on line 6

This bug is critical and not fixed in cvs. I just tried
the newest snapshot and it's not fixed.

Martin

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-10-31 09:01 UTC] mbr at freebsd dot org
Note that this bug is similar to a other bug,

http://bugs.php.net/bug.php?id=19292

It's not the same bug. There were some checks wrong
in fopen_wrappers.c. This is fixed in cvs.

This bug does show similar results as 19292,
but the source of the problem is completly different.

This a webserver with ~400 virtual servers, ~100
have php enabled.

I see the bug happen if I access frequently
pages of customer 1 (php enabled) and at the same time
customer 2.
 [2002-10-31 11:27 UTC] mbr at freebsd dot org
Previous dump was not the right one, sorry. I had
dumps for children disabled. This is now the right one ...

(gdb) bt
#0  0x280de8e1 in strlen () from /usr/lib/libc.so.4
#1  0x17 in ?? ()
#2  0x2836decb in php_check_open_basedir (path=0x8c79c98 "/www/doc/www.skkonline.ch-80/top/scripts2/schools.php")
    at fopen_wrappers.c:211
#3  0x2836e19f in php_fopen_and_set_opened_path (
    path=0x8c79c98 "/www/doc/www.skkonline.ch-80/top/scripts2/schools.php", mode=0x284e1ac3 "rb",
    opened_path=0xbfbff8d8) at fopen_wrappers.c:309
#4  0x2836e89d in php_fopen_with_path (filename=0x8c79c98 "/www/doc/www.skkonline.ch-80/top/scripts2/schools.php",
    mode=0x284e1ac3 "rb", path=0x81ebb50 ".", opened_path=0xbfbff8d8) at fopen_wrappers.c:494
#5  0x2836edc0 in php_fopen_url_wrapper (path=0x8c79c98 "/www/doc/www.skkonline.ch-80/top/scripts2/schools.php",
    mode=0x284e1ac3 "rb", options=1, issock=0xbfbfe6f0, socketd=0xbfbfe6ec, opened_path=0xbfbff8d8)
    at fopen_wrappers.c:612
#6  0x2836e26d in php_fopen_wrapper (path=0x8c79c98 "/www/doc/www.skkonline.ch-80/top/scripts2/schools.php",
    mode=0x284e1ac3 "rb", options=1, issock=0xbfbfe6f0, socketd=0xbfbfe6ec, opened_path=0xbfbff8d8)
    at fopen_wrappers.c:335
#7  0x2836b38c in php_fopen_wrapper_for_zend (
    filename=0x8c79c98 "/www/doc/www.skkonline.ch-80/top/scripts2/schools.php", opened_path=0xbfbff8d8) at main.c:583
#8  0x28336463 in open_file_for_scanning (file_handle=0xbfbff8d0) at zend_language_scanner.c:2952
#9  0x28336611 in compile_file (file_handle=0xbfbff8d0, type=2) at zend_language_scanner.c:3009
#10 0x2835bb4f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:823
#11 0x2836d0b9 in php_execute_script (primary_file=0xbfbff8d0) at main.c:1399
#12 0x28367d82 in apache_php_module_main (r=0x8c78038, display_source_mode=0) at sapi_apache.c:98
#13 0x28368c2c in send_php (r=0x8c78038, display_source_mode=0,
    filename=0x8c79c98 "/www/doc/www.skkonline.ch-80/top/scripts2/schools.php") at mod_php4.c:684
#14 0x28368c9f in send_parsed_php (r=0x8c78038) at mod_php4.c:703

(gdb) list
206                     char *newpath;
207                     char *ptr;
208                     char *end;
209
210                     pathbuf = estrdup(PG(open_basedir));
211                     newpath = estrdup(zend_get_executed_filename(TSRMLS_C));
212
213                     ptr = pathbuf;
214                     while (ptr && *ptr) {
215                             end = strchr(ptr, DEFAULT_DIR_SEPARATOR);
 [2002-10-31 11:57 UTC] sniper@php.net
If you try a snapshot, put the version correctly here.
Also, you added comment to http://bugs.php.net/bug.php?id=19292 that it should be critical, and now you say it's fixed. So what's the real thing here?


 [2002-10-31 15:47 UTC] mbr at freebsd dot org
Hi,

>should be critical, and now you say it's fixed.
>So what's the real thing here?

It seems that we hit two different bugs. I've seen
that bug 19292 was fixed for the part when a safe_mode
include dir was involved. 

But here the problem is more complex. Some global php
variables seem to be corrupted, or not properly initialised.

I'm still in gdb and try to find out why.

Martin
 [2002-10-31 16:15 UTC] mbr at freebsd dot org
Ok, I think I'm a bit smarter now.

zend_get_executed_filename() can only be used if
zend_is_executing(TSRMLS_C) is true. That explains
the uninitialisized values there.

If I do a check for this, the errors go away and the
segfaults are gone.

Buth $path can still point to a wrong virtual server.
That happens in 1/500 requests, and the thing is random.

I try to solve this now.
Martin
 [2002-10-31 16:23 UTC] mbr at freebsd dot org
This is a example:

Correct:

PG(open_basedir)=/www/doc/www.aaa.ch-80, 

Correct:

zend_get_executed_filename() = /www/doc/www.aaa.ch-80/index.php, 

Wrong:

path=/www/doc/www.bbb.imp.ch-80/html/visions/php//ueberuns/mannschaft.php

There is no "/www/doc/www.bbb.imp.ch-80/html/visions/php"
exists, but this is a different customer.

The correct filename would be: "/www/doc/www.aaa.ch-80/ueberuns/mannschaft.php"

Also note the two "//" slashes ...
 [2002-10-31 16:24 UTC] mbr at freebsd dot org
Sorry ...

>There is no "/www/doc/www.bbb.imp.ch-80/html/visions/php"
>exists, but this is a different customer.
This should be:

There is a dir "/www/doc/www.bbb.imp.ch-80 ..."
but this is a different customer.
 [2002-10-31 16:34 UTC] mbr at freebsd dot org
It looks to me that $path is composed somewhere.
And a the old basedir entry was not overwritten
correctly.

So $path is $basedir + $called phpfile and
the $basedir is plain wrong.

Some hint where this happens ?
 [2002-10-31 17:09 UTC] mbr at freebsd dot org
I have tried to do workarounds earlier.

But it seems that this one here now has solved both issues,
the wrong random "basedir message" and the segfaults I encountered with my first two patches.

http://people.freebsd.org/~mbr/patches/patch-main+fopen_wrappers.c

The solution is quite easy. In the onyl case where the error happens, zend_get_executed_filename() is correct.
and can be used.

Since the error happens on perfect legitimate requests,
which work most of the time, I don't think this is a
security risk. If no executed filename is set, I set
$newpath to a empty string.

Note that this is a workaround only. And I print
the errors to syslog, since I can watch that easier.
 [2002-10-31 18:06 UTC] mbr at freebsd dot org
hi all,

I think I can now even provide more information ... :-)

$path beeing wrong does relate from a wrong include_path.
It looks like if the apache child has proceeded a request
from a webserver with include_path or safe_mode_include_dir
set, these are still there. If now a virtual server without
these admin values is called, we fail.

Looks to me like these variables are not properly initialized and still contain their old values.

Of course the openbasedir checks then against the wrong
include path and there we are :-(

I'll look if I can really find the bug and fix it.

Martin
 [2002-11-01 08:22 UTC] mbr at freebsd dot org
My patch explained a bit more ...

The main trick is that we do a stat() on
$path:

if (( stat (path, &statbuf)) < 0) {

If the file does not exist, we can be sure that we triggered the bug and we let the check pass.

As already said, this is only a workaround for the ugly
bug ...

Martin
 [2002-11-02 14:27 UTC] kalowsky@php.net
I'd like to jump this upto a critical standing.  Mainly because it will get someone else to review the patch.  Hopefully that someone else will be a bit more intimately knowledgable with the whole Zend memory system than I. 
 [2002-11-14 03:09 UTC] mbr at freebsd dot org
I can confirm that it still happens with the latest cvs 4.3 snapshot from yesterday (2002-11-13).

If I get some pointers, I could add some debug code.

Funny thing is that the webserver runs about 30min to
2 hours ok, and then I hit begin to hit the bug. Always
after the same files:

It's always the same, you can see it because the filename
has two slashes /www/doc/customer2/html/visions/php//

This path really exists. The thing that does not exist,
is the file wrapper.php. It exists in the customer1 path
so we really really should not end here.

Nov 14 05:37:24 server-bsl1 httpd: open_basedir: Used openbasedir /www/doc/custermer1, file /www/doc/customer2/html/visions/php//wrapper.php executed_filename (/www/doc/customer1/index.php)

It looks to me that this case only happens after the apache
child has processed a include as last thing and then preceeds again a different webserver.

Anyone knows more ?
Martin
 [2002-11-14 11:39 UTC] msopacua@php.net
Could you test the values:
registered_zend_ini_directives
and
EG(ini_directives)

when this bug occurs, to confirm the wrong ini values?

I'm trying to reproduce this, can you confirm, that this bug happens when:
1) there are 2 vhosts, where vhost A has open_basedir restriction in effect, via php_admin_value in <VirtualHost> context and vhost B doesn't
2) vhost B includes a file and subsequently vhost A includes one.

So in order to increase the chances of hitting this bug, one could:
set Max and MinSpareServers to 1 and request the different vhosts?
 [2002-11-14 15:45 UTC] mbr at freebsd dot org
Hi,

>when this bug occurs, to confirm the wrong ini values?

Ok, i'll do that.

>1) there are 2 vhosts, where vhost A has open_basedir >restriction in effect, via php_admin_value in ><VirtualHost> context and vhost B
>doesn't

Nope. Both virtal servers have a open basedir restriction
turned on here.

>2) vhost B includes a file and subsequently vhost A >includes one.

That's correct.

For some strange reason, the bug does not happen on
a test setup with the same apache config. Of course
I was not able to copy all web-stuff over and simulate
true load.

So it is very difficult to reproduce.

Martin
 [2003-01-16 17:22 UTC] mitch at karboneye dot com
I upgraded to 4.3 the other day and ran into this problem big time. Today I went back to 4.2.3 and am still running into the error(s) occasionally... I've made sure that PHP 4.2.3 is installed and running and (according to phpinfo()) it is.

Apache 1.3.27 FreeeBSD 4.7p-1 PHP 4.2.3 and PHP 4.3.0 

Ack!
 [2003-01-21 08:42 UTC] r at orcafat dot com
Have this problem on 4.3.0 RELEASE! and 4.2.3

upgrade Version on this bug please.
 [2003-02-18 15:21 UTC] mitch at karboneye dot com
*sigh*

STILL happening with 4.3.1 FreeBSD 4.7 - 5.0
 [2003-02-18 22:46 UTC] sniper@php.net
Reading the NEWS file or the announcement for 4.3.1
would have told that 4.3.1 does not have ANY other fixes
but the fix for the CGI bug.

Please try the latest STABLE snapshot from http://snaps.php.net/ which has a lot of fixes..

 [2003-02-23 16:46 UTC] sniper@php.net
[mbr at freebsd dot org]

Lot of fixes to quite a many parts have been committed
since your last update. Could you let us know if the latest
snapshot is any better now? (getting desperate here.. :I)

 [2003-04-14 15:59 UTC] mbr at imp dot ch
Hi,

I can confirm that it still happens. After running 32
hours, the bug appeared again a 4-Stable snapshot from
11.4.2003.

Should I make the thing write a core so we see what
really happened before ?

:-(
 [2003-04-23 00:32 UTC] sniper@php.net
Yes, a backtrace might help a bit more than just saying 'this is still happening'. :)

 [2003-05-24 01:23 UTC] sniper@php.net
Still waiting for that backtrace, preferrably generated
with latest stable CVS snapshot, of course.

 [2003-06-02 17:24 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-2020 The PHP Group
All rights reserved.
Last updated: Sun May 31 17:01:26 2020 UTC