Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59701
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <A633CF2D7C7BED41B41F1E64F25507B806A5CDD6C2@MAILR001.mail.lan>
References: <CAGa2bXZ6G=Cphjrde3u1Mq3AAw-4yJk3s28vNe+Aybt2nGTumg@mail.gmail.com>
 <CAGa2bXZh4uMeUH_BSCFmfNgxS-SZC0svA9BPcSROjwmbfrtFyQ@mail.gmail.com>
 <CAGa2bXbhi4zdgd9Udo6KsoycDwg_Ke0Xe5h3_-fVDMvn_VfAjQ@mail.gmail.com> <A633CF2D7C7BED41B41F1E64F25507B806A5CDD6C2@MAILR001.mail.lan>
Date: Wed, 11 Apr 2012 11:51:50 +0900
Message-ID: <CAGa2bXZKfQ+HqOucwOnBH7gV84hpdxZb5qNY3t3ThF_zMKSGHw@mail.gmail.com>
To: John Crenshaw <johncrenshaw@priacta.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi,

I've reorganized benefits in the RFC and would like to share

https://wiki.php.net/rfc/nophptags?&#why_this_is_better_than_now


2012/4/11 John Crenshaw <johncrenshaw@priacta.com>:
> From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo Ohgaki
>>
>> Hi,
>>
>> It seems motivation of this RFC is better to be stated.
>> Motivation to have this RFC is
>>
>> 1. "File Includes" is fatal security breach.
>> 2. The reason why PHP is unsecure to "File Include" than other language is "Mandatory embed mode"
>> 3. Non mandatory embed mode gives option users to better security.
>>
>> With this RFC, PHP could be as safe as other scripting languages with respect to file includes. This RFC is fully compatible with current code. Writing backward compatible code is as few as 3 lines.
>
> No, I understood the reasons, but I reject the assumption that you are making. The "embed mode" doesn't have a measurable impact on the security of this system. The vulnerable code can be exploited in countless ways with or without embed mode.

You are making bad assumption.
If we follow your assumption, we should not  implement any mitigation like
null byte protection nor open_basedir.

Bottom line is LFI is real thread and critical. This RFC provides feasible way
to remove the main cause. (i.e. Mandatory embedded mode)

>
>> Most of security measures are not perfect solutions, but mitigation, just like canary and DEP. I suppose people who are concerned with security understand the value of these protections.
>
> Look, I'm the first to stand up for improved security, but that's now what we have here. Just calling this a security improvement doesn't make it true.

Please read reorganized section and other description in the RFC.

>
>> Is there any good reasons not to have non mandatory embed mode as a additional security measure? Why not to make it harder for attackers to exploit?
>
> Yes. This fundamentally breaks the language. PHP was first and foremost a template language. In fact, the strong template integration is a huge part of why one would build a web site in PHP, not C++.

You misunderstood the RFC. It does *NOT* break anything. It's the best
of both embedded and non-embedded language.

>> In short, I'm really annoyed to hear "PHP is insecure than Ruby/Perl/Python/etc"
>
> Anyone who says this is wrong. Ruby is in fact far less secure, because it doesn't even have cursory escaping functions and a variety of unpredictable behaviors (implicit returns) can lead to wild results.

Yes, I know where Ruby/Perl/Python can be insecure than PHP.
I don't audit Python/Perl much but I do PHP/Ruby (and others)

If LFI vulnerability was uncommon, I would not insist this RFC strongly.
Mandatory embedded scripting far more insecure than non embedded or
optionally embedded languages.

I think you misunderstood the RFC, so I reorganized a little.
Please read and comment, if any.

https://wiki.php.net/rfc/nophptags

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net