Bug 136651

This is one of the config files I use (/etc/apache2/vhosts.d/cboltz.de.conf). The other vHosts have similar configs.


<VirtualHost 212.227.64.36:80>
    ServerName cboltz.de
    ServerPath /cboltz.de
    ServerAlias www.cboltz.de
    SuexecUserGroup  cboltz psacln
    UseCanonicalName Off

    DocumentRoot /home/httpd/vhosts/cboltz.de/httpdocs/

    <Directory /home/httpd/vhosts/cboltz.de/httpdocs>
        Allow from all
    </Directory>

    CustomLog /home/httpd/vhosts/cboltz.de/statistics/logs/access_log combined
    ErrorLog /home/httpd/vhosts/cboltz.de/statistics/logs/error_log
    ScriptAlias /cgi-bin/ /home/httpd/vhosts/cboltz.de/cgi-bin/

    php_admin_flag engine on

## the following causes the described bug if enabled ##
## (linebreak inserted by bugzilla) ##
#       php_admin_value open_basedir "/home/httpd/vhosts/cboltz.de/:/home/sprachakt/"

    php_admin_value upload_tmp_dir /home/httpd/vhosts/cboltz.de/tmp/
    php_admin_value session.save_path /home/httpd/vhosts/cboltz.de/tmp/

    <Directory "/home/httpd/vhosts/cboltz.de/error_docs">
        Allow from all
    </Directory>
    Alias "/error_docs" "/home/httpd/vhosts/cboltz.de/error_docs"
    ErrorDocument 404 /error_docs/not_found.html

    CustomLog /home/httpd/vhosts/cboltz.de/statistics/logs/access_log combined
    Alias  /plesk-stat /home/httpd/vhosts/cboltz.de/statistics/
    Alias  /webstat /home/httpd/vhosts/cboltz.de/statistics/webstat
    Alias  /webstat-ssl /home/httpd/vhosts/cboltz.de/statistics/webstat-ssl
    Alias  /ftpstat /home/httpd/vhosts/cboltz.de/statistics/ftpstat
    Alias  /anon_ftpstat /home/httpd/vhosts/cboltz.de/statistics/anon_ftpstat

    <Directory "/home/httpd/vhosts/cboltz.de/statistics">
        AuthType Basic
        AuthName "Domain-Statistiken"
        AuthUserFile /home/httpd/vhosts/cboltz.de/pd/d..plesk-stat
        require  valid-user
    </Directory>

</VirtualHost>

For SL9.1 we will not fix such bugs anymore.

Matthias Keller <linux AT matthias-keller DOT ch> just reported that he has the same problem on SUSE Linux 10.0 after installing the latest security updates. See his mail in suse-linux mailinglist
    Subject: Troubles with newest apache2-mod_php4 update on Suse10.0
    Message-ID: <43A48FDA.9090600@matthias-keller.ch>

Is it worth fixing now? ;-)

I'm the one who reported it again on the suse mailing list....
I'm running the apache2 with 34 virtualhosts at the moment...

This bug is quite annoying and it seems to have appeard only with the last update (apache2-mod_php4) as I havent seen it before but seen it a lot ever since

I'd be happy to provide you with more information about my setup...

The initial bug report sounds that the error is occuring every time - in my case it just occurs maybe every 50th time - i noticed it on a self-updating statistic page....
The other 49 times it's running correctly....

folks can somebody tell me what is the **real** error message when it fails ???

is this problem reproducible using mod_php5 ???

there are a lot reported problems about this topic


http://bugs.php.net/bug.php?id=34656
"
[14 Dec 6:29am CET] sniper@php.net

We really don't support PHP 4 anymore. If you don't test with PHP 5, we
consider the bug fixed there."


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

I also kindly suggest stop supporting PHP4 in the next SUSE version.

Great
I cant just switch from PHP4 to PHP5 on a running productive system :-(

Here's the exact error: (i've replaced the random local domain with 'domain.com'). But this is NOT the open_basedir line from the currently used virtualhost!

*Warning*: Unknown(): open_basedir restriction in effect. File(/usr/share/amavis-stats/amavis-stats.php) is not within the allowed path(s): (/www/common/:/www/domain.com/) in *Unknown* on line *0*
*Warning*: Unknown(/usr/share/amavis-stats/amavis-stats.php): failed to open stream: Operation not permitted in *Unknown* on line *0*
*Warning*: (null)(): Failed opening '/usr/share/amavis-stats/amavis-stats.php' for inclusion (include_path='/usr/share/php') in *Unknown* on line *0
* 

Cristian (without "h" ;-)  - http://bugs.php.net/bug.php?id=34656 is _NOT_ topic of this bug report.

I just found that the problem I reported here is already discussed on bugs.php.net:

http://bugs.php.net/bug.php?id=21564
http://bugs.php.net/bug.php?id=25753

There's also a small patch in the latter one.

If I read the bugs.php.net reports correctly, this problem is not restricted to open_basedir - it can appear on _all_ settings you do using php_admin_value. It also can affect other vHosts if you use php_admin_value in one of your vHosts.

Christian (with "h" ;-) ) :

about the links you mentioned.

first link ( php bug 21564)

it's an old bug report, very unlikely to apply actually.

second link ( php bug 25753)

older version too, and the metioned code it's for apache SAPI (that means apache 1.x) SAPI used here is "apache2handler" ;-)

odd thing, random crashes are a pain in the.... :(


novell@matthias-keller.ch :

for inclusion **(include_path='/usr/share/php')** in *Unknown* on line *0

so..you are also using the infamous include_path "fix" ..

will look this issue later.. sadly Im running my own PHP RPM's (5.1.2-dev) and I  'm unlikely to downgrade just to test a possible fix...(crash and burn system anyone??)

I've now been experimenting with an exact clone of the server but with PHP5 and i still get the same error, tough it seems to appear a bit more rarely:

--
Warning: Unknown: open_basedir restriction in effect. File(/usr/share/amavis-stats/amavis-stats.php) is not within the allowed path(s): (/www/common/:/www/domain.ch/) in Unknown on line 0

Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0

Warning: Unknown: Failed opening '/usr/share/amavis-stats/amavis-stats.php' for inclusion (include_path='.:/usr/share/php5:/usr/share/php5/PEAR') in Unknown on line 0
--

What's it about that 'infamous include_path fix' ? I'm running the default suse10 setup, but here i also needed to add the PEAR path for another application... with php4 this was directly under /usr/share/php

novell@matthias-keller.ch :

see Bug 129682 for information about the 'infamous include_path fix'


Petr: I think this problem is produced due the latest patches against sapi/apache2handler/sapi_apache2.c

this patch obsoletes: 

Patch65:      php-%{version}-mod_rewrite-fix.patch
Patch68:      php-%{version}-CVE-2005-3392.patch
Patch69:      php-%{version}-errordocument-fix.patch
Patch27:      php-%{version}-save_path-segfault.patch

Created attachment 61661 [details]
please try with this patch.

Just figured Petr is on vacation...he will be back on January 2...

anyone feeling brave and testing the suggested patch ???

Unfortunately I dont have the knowledge to compile and test it myself.
It would be great if someone could test it - I hate to have open_basedir disabled for much longer... :-(

Thanks

since this issue is quite interesting , I had made hands on testing on a server provided by M.Keller ;-) with the 10.1 PHP packages ( PHP 5.1.2) and problem is no longer reproducible :-)

the suggested patch , merges the latest available corrections to apache2handler SAPI and should fix this weird issue.

I fixed it by upstream patch phpbug-35571.patch from bugreport (php#35571 - "fixed crash in Apache 2 SAPI when more then one php script is loaded via SSI include")  for PHP5 in 9.3, 10.0  and for PHP4 in 9.1, sles9, 9.2, 9.3, 10.0
 
It is fixed with security update in [#143696]

More people is reporting frecuently this problem now.

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

Short Story : USE PHP 5.1.x

(In reply to comment #19)
> Short Story : USE PHP 5.1.x

Unfortunately, the story isn't that short - this still happens with PHP 5.1 on a 10.1 server :-(

Versions:
php5-5.1.2-29.19
apache2-2.2.0-21.7

upgrading severity because this bug doesn't allow to have secure PHP settings (like open_basedir) and/or strict apparmor profiles per vHost.

fixed in upstream
for php-4.4:
http://cvs.php.net/viewvc.cgi/php-src/sapi/apache2handler/apache_config.c?r1=1.1.2.3.8.1&r2=1.1.2.3.8.2
http://cvs.php.net/viewvc.cgi/php-src/sapi/apache2filter/apache_config.c?r1=1.28.2.1.8.1&r2=1.28.2.1.8.2

for php-5.1
http://cvs.php.net/viewvc.cgi/php-src/sapi/apache2handler/apache_config.c?r1=1.7.2.1&r2=1.7.2.2
http://cvs.php.net/viewvc.cgi/php-src/sapi/apache2filter/apache_config.c?r1=1.34.2.1&r2=1.34.2.2

reassign to Ales Nosek (new maintainer of php, congratulation :))

right, this needs to be fixed in the next round of security fixes.. ;-)

Hi, could I fix this problem together with another security bug, or should I fix it now?

see bug #210503 for candidates to fix with this ;)

(In reply to comment #25)
> see bug #210503 for candidates to fix with this ;)

"Access Denied" - I assume it's a security relevant bug?

BTW: If you have some test packages available, I'll happily try them.

What other security bug?

I meant the future security bugs

ping ;-)

security team: when can fixed packages for this be expected?

Note: This bug is really security relevant!
Being unable to restrict open_basedir means that scripts from one vHost can modify data of any other vHost. Since I have running Typo3 (including file upload via PHP) on several vHosts, lots of files and directories are writeable by wwwrun - therefore the "no write permissions on filesystem level" argument unfortunately is not valid here.
-> I'd vote for releasing the fix ASAP.

Ales: Is it possible to make some test packages available?

Another security update is in the queue. This bug will be fixed along with it.

I submitted fixed packages:

php4  10.0-all
php4  9.2-all   
php4  9.3-all   
php4  sles9-all 

php5  10.0-all
php5  9.3-all
php5  sles10-all

Just FYI: I upgraded my server to 10.2 - right now it looks like this bug is finally fixed there :-)

Anyway: What's the status of fixed packages for <= 10.1?

MaintenanceTracker-8539

updated packages approved.

I'm afraid this bug isn't (completely?) fixed yet :-(

Currently, I have 85 vHosts on a 10.2 x86_64 server. 4 of them have open_basedir set, the others don't have open_basedir restrictions.

Now I have seen the well known error message in the log (domain names replaced):

PHP Warning:  Unknown: open_basedir restriction in effect. File(/home/www/domain.foo/httpdocs/wiki/index.php) is not within the allowed path(s): (/home/www/otherdomain.foo/:/home/www/all) in Unknown on line 0, referer: http://domain.foo/index.php

- domain.foo does not have open_basedir restrictions set
- otherdomain.foo does have open_basedir restrictions - but is another vHost

My config files still look like in comment #1, the only change are
- added AppArmor AADefaultHatName statements
- removed some aliases
Both changes shouldn't be relevant to this bug.

I just happened to see this problem again too recently (I'm the one from #4) where an upload virus check failed because of wrong directories being used.

The domain in question has the default upload_tmp_dir defined as /tmp
Another domain has its upload dir as /www/domain1.ch/temp

This log shows, that the file was really uploaded to /www/domain1.ch/temp, whereas the script executed was from domain2.ch (which should have used /tmp ):

Nov  3 17:54:44 server VIRUSCHECK: error checking /www/domain1.ch/temp/php49YiwG: lstat() failed. ERROR
Nov  3 17:54:44 server suhosin[14799]: ALERT - fileupload verification script disallows file - file dropped (attacker 'x.x.x.x', file '/www/domain2.ch/public_html/somefile.php')

Matt

can you please try with 10.3 or the packages available from 
http://download.opensuse.org/repositories/server:/php/ and tell me if that works ?



ps: debugging this kind of bugs is a real fun.....;)

if someone can provide reliable information on how to reproduce this bug again please reopen, otherwise it will be inpossible to fix due to it's weirdness,

The SWAMPID for this issue is 53280.
This issue was rated as critical.
Please submit fixed packages until 2013-07-01.
When done, please reassign the bug to security-team@suse.de.
Patchinfo will be handled by security team.

The SWAMPID for this issue is 53281.
This issue was rated as critical.
Please submit fixed packages until 2013-07-01.
When done, please reassign the bug to security-team@suse.de.
Patchinfo will be handled by security team.