Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72615
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.41 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <52FE4DF0.3040906@gmail.com>
References: <CAGa2bXYU0+eVgnDCkqpG6AWvLCX9gV3+5nzoeD-RJge8Rtw-dQ@mail.gmail.com>
 <CAGa2bXZCBxJczqX6FKz0T0_iV9LzdeHkw46c17NQsanuCCJ9rA@mail.gmail.com>
 <52FBF8F8.5040107@gmail.com> <CAGa2bXb=2fJisj90HY6ojMKmJeFFGbTwn6J1vZayzxBTLz7fBQ@mail.gmail.com>
 <52FE4DF0.3040906@gmail.com>
Date: Sat, 15 Feb 2014 07:28:08 +0900
Message-ID: <CAGa2bXYR2KiBvKHf3WoWDOiFjmwPSwXpS5OMn0mTVZKpVU-rJw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3ce326a15ac04f26554a8
Subject: Re: [PHP-DEV] Re: [RFC] No PHP tags
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c3ce326a15ac04f26554a8
Content-Type: text/plain; charset=UTF-8

Hi Rowan,

On Sat, Feb 15, 2014 at 2:10 AM, Rowan Collins <rowan.collins@gmail.com>wrote:

>
>
>>     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.
>
>
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

These are abuse of feature. It's better to disable such usage.


>
>
>  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?


Yes, it is relevant as PHP executes fragment of code in a file always. Many
codes save user supplied data in session. i.e. It can be used for LFI
attack that executes arbitrarily codes .


>  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.


When a language executes data files as program, it ends up with syntax
error during compile time almost always. PHP compiles script, then
executes. Program may output something before data file inclusion, but it
must be intended output. Data file inclusion results in syntax error and
content would not be exposed.

Attacker may disguise script a data file. Insufficient data file validation
may permit script execution in other languages, too. I'm not concerned much
about this case. New RFC will address this issue, though.


>  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.


I'll abandon this RFC since I came up with better idea. New RFC will
address all issues have been discussed in this and other threads. All
discussions were valuable. Thanks a lot to all!

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c3ce326a15ac04f26554a8--