Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72611
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.47 as permitted sender)
Message-ID: <52FE4DF0.3040906@gmail.com>
Date: Fri, 14 Feb 2014 17:10:08 +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" <internals@lists.php.net>
References: <CAGa2bXYU0+eVgnDCkqpG6AWvLCX9gV3+5nzoeD-RJge8Rtw-dQ@mail.gmail.com> <CAGa2bXZCBxJczqX6FKz0T0_iV9LzdeHkw46c17NQsanuCCJ9rA@mail.gmail.com> <52FBF8F8.5040107@gmail.com> <CAGa2bXb=2fJisj90HY6ojMKmJeFFGbTwn6J1vZayzxBTLz7fBQ@mail.gmail.com>
In-Reply-To: <CAGa2bXb=2fJisj90HY6ojMKmJeFFGbTwn6J1vZayzxBTLz7fBQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] No PHP tags
From: rowan.collins@gmail.com (Rowan Collins)

Yasuo Ohgaki wrote (on 13/02/2014):
>
>     But if somebody is using include() for non-PHP data, they're using
>     the wrong function anyway, end of story.
>
>
> Right. This is what I would like to change.
> In other languages, such script inclusion ends up syntax error, end of 
> attack.

I was talking here about my cases 3 and 4, where the author is 
*deliberately* using include for something other than code. There is 
already a correct function for that, which is readfile(), or more likely 
file_get_contents() and then some processing, so no changes are needed 
to introduce it.


> There are number of ways to inject piece of PHP code into files. 
> Attacker can exploit other feature/vulnerability to take over server 
> completely. Session file is one of the common method.

Are session files relevant to this discussion, or was this just a side note?


> Compile error will not display any code/contents except a piece 
> displayed as error message.

That's not quite true. A fatal error can occur after output has been 
flushed through to the browser. The include statement will succeed 
(acting like readfile()), and the fatal error, if any, will happen 
afterwards, e.g. because an expected class definition was not loaded.


> Take a look at vulnerability reports, you'll find number of LFI that 
> could be prevented by this RFC.

I looked at some of the examples in the RFC, but I don't understand how 
they relate to this proposal. No amount of links to vulnerability 
reports can tell me that, but you can.

What I am asking for is an example - real or artificial, I don't mind - 
with an explanation of how it behaves now, and how that behaviour would 
be improved by the proposed change.

Note that I'm not trying to shoot down your proposal - on the contrary, 
I'm trying to make sure its benefits are clearer, so that people will 
have a better means of judging it.

Regards,
-- 
Rowan Collins
[IMSoP]