php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #34793 php-cli searches php.ini from current dir which can be abused
Submitted: 2005-10-09 18:13 UTC Modified: 2006-11-02 23:40 UTC
Votes:5
Avg. Score:4.6 ± 0.5
Reproduced:5 of 5 (100.0%)
Same Version:0 (0.0%)
Same OS:2 (40.0%)
From: glen at delfi dot ee Assigned: edink (profile)
Status: Closed Package: Feature/Change Request
PHP Version: 5.1.0RC1 OS: PLD Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: glen at delfi dot ee
New email:
PHP Version: OS:

 

 [2005-10-09 18:13 UTC] glen at delfi dot ee 
Description:
------------
php cli searches for php.ini from current dir, and when   
current directory appears to be world writable directory,   
then malicious user can put there php.ini loading malicious   
extension.   
   
php cli is used for example to install PEAR packages, and   
for PEAR install to succeed it needs to be run as root.   
 

Reproduce code:
---------------
1. create /tmp/php.ini containing 
[PHP]
extension=/../../../tmp/malicious.so
2. create php extension and save it to /tmp/malicious.so
3. wait for root run any php-cli program in /tmp
4. your code in malicious.so gets executed.

Expected result:
----------------
php should not read php.ini from arbitary locations, it 
should read it only from hardcoded paths, or one specified 
from commandline. 

Actual result:
--------------
  
$ strace -eopen php -m  
open("/etc/ld.so.cache", O_RDONLY)      = 6  
open("/usr/lib/libphp_common-5.1.0RC1.so", O_RDONLY) = 6  
open("/lib/libcrypt.so.1", O_RDONLY)    = 6  
open("/lib/libm.so.6", O_RDONLY)        = 6  
open("/lib/libz.so.1", O_RDONLY)        = 6  
open("/lib/libresolv.so.2", O_RDONLY)   = 6  
open("/lib/libpthread.so.0", O_RDONLY)  = 6  
open("/usr/lib/libxml2.so.2", O_RDONLY) = 6  
open("/lib/libdl.so.2", O_RDONLY)       = 6  
open("/lib/libhistory.so.5", O_RDONLY)  = 6  
open("/lib/libreadline.so.5", O_RDONLY) = 6  
open("/lib/libncurses.so.5", O_RDONLY)  = 6  
open("/lib/libc.so.6", O_RDONLY)        = 6  
open("/lib/libtinfo.so.5", O_RDONLY)    = 6  
open("/etc/localtime", O_RDONLY)        = 6  
open("/tmp/php.ini", O_RDONLY)          = 6  
open("/tmp/php-cli.ini", O_RDONLY)      = -1 ENOENT (No  
such file or directory)  
open("/etc/php/php-cli.ini", O_RDONLY)  = 6  
open("/etc/php/conf.d", O_RDONLY|O_NONBLOCK|O_LARGEFILE| 
O_DIRECTORY) = 6  
open("/etc/php/conf.d/pcre.ini", O_RDONLY) = 6  
open("/etc/php/conf.d/xml.ini", O_RDONLY) = 6  
open("/usr/lib/php//../../../tmp/malicious.so", O_RDONLY) =  
6  
open("/usr/lib/php/pcre.so", O_RDONLY)  = 6

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-10-09 19:14 UTC] sniper@php.net 
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
 [2005-10-10 00:05 UTC] glen at delfi dot ee 
in fact i know that documentation says so. but that doesn't  
mean it supposed to be like this? can't you at least  
consider securing it, by adding some option to  
enable/disable this? 
 
so i changed category to feature request!
 [2005-10-10 00:06 UTC] adamg at agmk dot net 
I believe this behaviour is wrong and PHP should be fixed not to look for php.ini in the current directory for the reasons described by glen. Ideally (as I see it) is a fixed location in /etc and (optionally) in home dir of user running the script.

Why do you think this bug report is bogus? What are the reasons for keeping such behaviour?
 [2006-01-17 15:49 UTC] glen at delfi dot ee 
to put this into another light. how should i run php cli  
program, with *not* reading ./php.ini?  
 
a real live situation: i have a PHP program defined as CVS 
loginfo handler. 
CVS server accessed via ssh. now if i happen to commit 
php.ini in such CVS setup, the  
php.ini is first uploaded to cvs server and then a PHP  
program is executed in that directory (where commited 
files were uploaded). as the php.ini is  
not for the OS where the PHP program is ran. i get fatal  
error from PHP interpreter and no code is executed: 
 
# cvs ci -m '- disable zend, broken' php.ini 
Checking in php.ini; 
/usr/local/cvs/sw/apache/php.ini,v <-- php.ini 
new revision: 1.7; previous revision: 1.6 
done 
PHP Warning: PHP Startup: Unable to load dynamic library 
'./pcre.so' - ./pcre.so: cannot open shared object file: 
No such file or directory in Unknown on line 0 
PHP Warning: Unknown: failed to open stream: No such file 
or directory in Unknown on line 0 
PHP Warning: Unknown: Failed opening '/www/vars.inc' for 
inclusion (include_path='.:/usr/share/pear') in Unknown on 
line 0
 [2006-11-02 23:36 UTC] glen at delfi dot ee 
you should close this bug with message like "RESOLVED in 
5.2.0"
 [2006-11-02 23:40 UTC] bjori@php.net 
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php

:)
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Thu Apr 03 23:01:31 2025 UTC