Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82166
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
Message-ID: <54D7C0BF.7000107@gmail.com>
Date: Sun, 08 Feb 2015 20:02:07 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAGa2bXYzs=5FVF_OXFj+o=S1uq_7fhfMH7Ent9FHfd-ziV_W5Q@mail.gmail.com> <CAN=kQJcmBQZr4nabAUoiASymb8eJxZV6d+RODcPwoNUf3_VG9A@mail.gmail.com> <CAGa2bXa8pEaChqVt1LuJUXMq92kiGtXQG0z9gubRoOpHNu-4hw@mail.gmail.com> <CAN=kQJfi_stYqQEnvwcVYu1TmdT3fozewQZvKchWJi56Y3JGkA@mail.gmail.com> <CAGa2bXYpEaM5uSWRX24jYG1zjeZ=JA8nvY19D6GABRWA-_FvqQ@mail.gmail.com>
In-Reply-To: <CAGa2bXYpEaM5uSWRX24jYG1zjeZ=JA8nvY19D6GABRWA-_FvqQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Introduce scrpt_path
From: rowan.collins@gmail.com (Rowan Collins)

On 08/02/2015 09:03, Yasuo Ohgaki wrote:
>> If this was a PHP_INI_PERDIR setting, then I wouldn't really mind as much.
>> >
>> >But as PHP_INI_USER, I don't like it at all.
> How about allow to set the ini only once during execution?

Like open_baedir [1], it should probably be possible to *tighten* the 
settings, but never *loosen* them. So, you could remove items from 
script_path, or alter them to be more specific; or you could add them to 
upload_path, or alter them to be more general.

The relationship to open_basedir should perhaps be more explicit - for 
instance, your example of require('/etc/passwd') is better handled by 
open_basedir, which also prevents readfile('/etc/passwd').

A file path should ideally be evaluated against 3 tests:

A) should this file be accessible, and readable? (controllable through 
open_basedir; should be a pre-requisite for B and C)
B) should this file be writable? (currently left to OS level protection)
C) should this file be executable as PHP code? (should apply through 
include()/require(), and also if passed as a direct argument to the PHP 
SAPI; the latter part is currently left to the web server configuration, 
while the first part cannot be controlled at all)

Even with all of these, there are still vulnerabilities, just ones which 
require multiple steps, e.g.:
- for any file in (A), read its contents into memory, and trick the 
application into executing it from a string
- find an intersection between (B) and (C), such as a compiled template 
cache, and inject a string from user input, or a file in (A), which will 
then be executed

[1]: http://php.net/manual/en/ini.core.php#ini.open-basedir

-- 
Rowan Collins
[IMSoP]