Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72535
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <52FBF8F8.5040107@gmail.com>
References: <CAGa2bXYU0+eVgnDCkqpG6AWvLCX9gV3+5nzoeD-RJge8Rtw-dQ@mail.gmail.com>
 <CAGa2bXZCBxJczqX6FKz0T0_iV9LzdeHkw46c17NQsanuCCJ9rA@mail.gmail.com> <52FBF8F8.5040107@gmail.com>
Date: Thu, 13 Feb 2014 10:30:52 +0900
Message-ID: <CAGa2bXb=2fJisj90HY6ojMKmJeFFGbTwn6J1vZayzxBTLz7fBQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3733e3ec31f04f23fa6b1
Subject: Re: [PHP-DEV] Re: [RFC] No PHP tags
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c3733e3ec31f04f23fa6b1
Content-Type: text/plain; charset=UTF-8

Hi Rowan,

On Thu, Feb 13, 2014 at 7:43 AM, Rowan Collins <rowan.collins@gmail.com>wrote:

> 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.
>

Right. This is what I would like to change.
In other languages, such script inclusion ends up syntax error, end of
attack.

In PHP, this may end up
  - disclosing any information in file, disaster.
  - executing any embedded scripts, fatal disaster.

This difference is enough reason to introduce some kind of protection.

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.

 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).
>

We don't have to care much that other languages cannot protect neither. IMO.

 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.
>

Compile error will not display any code/contents except a piece displayed
as error message.

 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?
>

I think you have enough skill to prevent script inclusion attacks. However,
all PHP users are not. Take a look at vulnerability reports, you'll find
number of LFI that could be prevented by this RFC.

http://packetstormsecurity.com/search/?q=LFI

These are only reported LFI vulnerabilities and there are countless
vulnerable scripts in the wild.

I don't see any reason to keep doors open for attackers. We are better to
close as many doors as possible, especially for fatal disaster(script
execution).

Thank you for the comment!

Regards,

P.S. I was added script()/script_once() to the original RFC. However, it
may be easier for users to have template()/template_once() that parses file
as embedded PHP script mode always and keep include()/require() for script
inclusion. This way, users do not have to rewrite include()/require() to
script(). Anyone has any comments?

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c3733e3ec31f04f23fa6b1--