php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #27364 safe mode bypassed
Submitted: 2004-02-23 10:36 UTC Modified: 2004-04-08 11:18 UTC
From: support at nfrance dot com Assigned:
Status: Not a bug Package: *Directory/Filesystem functions
PHP Version: Irrelevant OS: OpenBSD/FreeBSD
Private report: No CVE-ID: None
 [2004-02-23 10:36 UTC] support at nfrance dot com
Description:
------------
When changing permissions on a directory safe mode restrictions for php scripts in this directory can be bypassed 

When directory in chmod 755 safe mode works as exepted, bot not anymore in chmod 751

(note that php run as apache module ans /etc/passwd is of course not owned by the same user as apache is running)

This has been seen on 3 differents servers, 2 with OpenBSD and one with FreeBSD

Tested with PHP 4.2.2 with follonwing configure commands : 
'./configure' '--enable-safe-mode' '--enable-memory-limit' '--with-pgsql=/usr/local/pgsql/' '--with- mysql=/usr/local' '--with-imagic' '--enable-track-vars' '--with-imap=/usr/local/src/imap-2001a' '--with- gd=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-t1lib' '--with-ttf' '-- enable-magic-quotes' '--enable-roxen-zts' '--enable-ftp' '--enable-calendar' '--with-gdbm' '-- enable-zlib=/usr' '--with-gettext' '--with-xml' '--with-dom' '--with-zlib-dir=/usr' '--enable-bcmath' '--with-apache=/usr/local/src/apache_1.3.27'

Tested again after having upgraded to PHP 4.3.4 (and having upgraded apache too) with a clean php.ini and the bug is still active

However, we've tested on others FreeBSD servers with the same PHP version without any problem. Of course configuration was different ont those servers, but it is not normal that safe mode can be bypassed so easily whatever the environment. 

Please advise !




Reproduce code:
---------------
<?
$fp =  fopen("/etc/passwd","r");
$data =  fgets($fp,255);
echo "$data<BR>";
fclose($fp);
?>

(bug has been see with readfile() too)

Expected result:
----------------
Current directory permissions : 
drwxr-xr-x  2 fred  fred   512 Feb 17 10:58 .

Result : 

Warning: SAFE MODE Restriction in effect. The script whose uid is 1003 is not allowed to access /etc/passwd owned by uid 0 in /home/fred/ test/etcpasswd.php on line 3

Warning: fopen("/etc/passwd", "r") - Inappropriate ioctl for device in /home/fred/test/etcpasswd.php on line 3

Warning: fgets(): supplied argument is not a valid File-Handle resource in /home/fred/test/etcpasswd.php on line 5

Warning: fclose(): supplied argument is not a valid File-Handle resource in /home/fred/test/etcpasswd.php on line 9

Actual result:
--------------
Current directory permissions (noting else changed) : 
drwxr-x--x  2 fred  fred   512 Feb 17 10:58 .

Result : 

# $FreeBSD: src/etc/master.passwd,v 1.25.2.5 2002/02/10 11:43:37 obrien Exp $


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-02-24 17:07 UTC] iliaa@php.net
Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

I cannot verify this problem on Linux and it could not be 
verified on FreeBSD 4.9 by the people I've asked. 
The only reason I would imagine this would happen is if 
your OS would refuse to allow PHP to stat the directory 
where the file is located. 
 [2004-02-25 09:12 UTC] support at nfrance dot com
Of course the problem  seems to be environment-dependent, but should not PHP return an error in such situation when not able to get enough information on a directory owner instead of opening the file even with safe mode ?
 [2004-02-25 10:02 UTC] iliaa@php.net
Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

Allowing access to directories about which PHP cannot 
determine information would be contrary to the whole 
concept of safe mode. If your system has a (strange) 
limitation of disallowing stat() of directories with just 
an executable bit set make sure the read bit is also set. 
 [2004-02-25 10:34 UTC] support at nfrance dot com
"Allowing access to directories about which PHP cannot
determine information would be contrary to the whole
concept of safe mode."

That's *exactly* the problem here : even with safe mode files can be opened on those servers when permissions are set too low on the current directory 

"if your system has a (strange)
limitation of disallowing stat() of directories with just
an executable bit set make sure the read bit is also set."

For your Information, we've jsut checked the stat() function and it works as expected in both situations.

But even if it is an unexepected environment which prevent fopen() and others file-handling functions to check the uid/gid depending on permissions on directories, don't you think that there should be, when safe mode is active, en error in such situation ? If it happen on some of ours servers, it can happen on others too, and a simple error check should be able to prevent this potential security hole for all users

In fact there's some others bugs report that could be about the same problem or similar : 
http://bugs.php.net/bug.php?id=19363
http://bugs.php.net/bug.php?id=22368
http://bugs.php.net/bug.php?id=24304

We can provide more informations on our environment if you wish, and perform any test needed
 [2004-04-08 11:18 UTC] sniper@php.net
For all the reasons Ilia already gave and here's another: Safe-mode is not perfect and can be easily by-passed. We know about it. (hint: open_basedir might be better idea, and maybe some chrooted environment where you run your webserver, etc.)

 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 18 15:01:28 2024 UTC