Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72533
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
Message-ID: <52FBF8F8.5040107@gmail.com>
Date: Wed, 12 Feb 2014 22:43:04 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAGa2bXYU0+eVgnDCkqpG6AWvLCX9gV3+5nzoeD-RJge8Rtw-dQ@mail.gmail.com> <CAGa2bXZCBxJczqX6FKz0T0_iV9LzdeHkw46c17NQsanuCCJ9rA@mail.gmail.com>
In-Reply-To: <CAGa2bXZCBxJczqX6FKz0T0_iV9LzdeHkw46c17NQsanuCCJ9rA@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------000505070606060504010407"
Subject: Re: [PHP-DEV] Re: [RFC] No PHP tags
From: rowan.collins@gmail.com (Rowan Collins)

--------------000505070606060504010407
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Yasuo Ohgaki wrote (on 11/02/2014):
> Local script inclusion is*much grater security threat*  than local script
> expose.

I've been trying to follow the pros and cons of this RFC, and I'm really 
scratching my head on what the security benefit is supposed to be.

As I understand it, for this to even be relevant security-wise, it would 
need to involve a dynamic file path being included, and an attacker 
somehow influencing either which file was loaded, or the contents of 
that file.

The scenarios I can see are:

1) the include was intended to be PHP code, and the attacker substitutes 
different PHP code of their choice
2) the include was intended to be PHP code, and the attacker accesses 
non-PHP data already on server
3) the include was intended to be non-PHP data, and the attacker 
substitutes PHP code of their choice
4) the include was intended to be non-PHP data, and the attacker 
accesses different non-PHP data already on server

This sentence in the RFC Summary sounds like it's talking about 3:

 > However, embedded scripts are serious security risk as it can 
executes any PHP code in any files.

But if somebody is using include() for non-PHP data, they're using the 
wrong function anyway, end of story.

Barring bugs in the engine (e.g. null byte handling) 1 and 4 are 
something that no language can guard against: substituting code for 
code, or data for data (if include() couldn't do it, file_get_contents() 
could). There's a lot of talk in the RFC about validating file 
*contents*, but it seems to me that careful whitelisting of file 
location and naming is generally more relevant (e.g. "/etc/passwd" 
doesn't end in ".php", so it's kind of obvious you shouldn't be passing 
it to an include statement).

2 seems to be more relevant to me: without the "always echo if no <?php 
found" rule, it's easier to trick include() into acting like readfile(). 
The failure to load the expected PHP code would probably cause a Fatal 
Error anyway, but the contents might be exposed first.

But that doesn't seem to be the exploit that is being discussed on this 
RFC. Or am I misunderstanding completely?

Could somebody enlighten me with an artificially simplified example of a 
code execution attack that is possible today but would be prevented (or 
preventable) with the proposed change?

Thanks,
-- 
Rowan Collins
[IMSoP]

--------------000505070606060504010407--