Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59732
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.216.47 cause and error)
Message-ID: <4F859063.1010401@lerdorf.com>
Date: Wed, 11 Apr 2012 07:08:35 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: Yasuo Ohgaki <yohgaki@ohgaki.net>, 
 "internals@lists.php.net" <internals@lists.php.net>
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> <CAGa2bXZKfQ+HqOucwOnBH7gV84hpdxZb5qNY3t3ThF_zMKSGHw@mail.gmail.com> <4F850D06.10701@sugarcrm.com> <CAGa2bXZWrRh8RdMtKK_2_U_XmByC-O6hGRPrJyW5KwvE0CAK-w@mail.gmail.com> <4F8515AF.8060706@sugarcrm.com> <CAGa2bXZWudQeRm5h2eENGmgQDPfOqEmijB9-vPAvfKXLCfDiLw@mail.gmail.com> <4F851FE4.7000706@sugarcrm.com> <CAGa2bXbXdNcfHX_dM2EVVz_2JtS4cc+8pxneSLAd382TuQUg-w@mail.gmail.com> <4F8539E0.1090701@sugarcrm.com>
In-Reply-To: <4F8539E0.1090701@sugarcrm.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 04/11/2012 12:59 AM, Stas Malyshev wrote:
>> Therefore, it should not be misunderstood as perfect LFI
>> countermeasure even if I stressed on security meanings.
>> I'm stressing security because this actually helps PHP being
>> much safer than now.
> 
> I don't see how it is "much safer". Exactly the same problem exists. Not
> only it is not "perfect" countermeasure, it's not countermeasure at all,
> judging from your description. It's like saying "I have SQL injection
> protection, but only if word "please" is not part of the SQL injection".
> It's not a real protection then.

I guess he is saying that it prevents:

   Random bytes
   <?php kill();?>
   More random bytes

Where random bytes might be an image file so finfo_file() might identify
it as a valid image whereas it doesn't prevent:

  <?php kill();?>
  Random bytes

from being mistakenly included. And I guess a secondary thing it might
prevent is an include of something like /etc/passwd since there is no
valid PHP code there and it would error out.

So, those are the pros. The cons are:

1. Creating a new mode for PHP that essentially breaks most existing PHP
code if this mode is enabled puts more pressure on people trying to
write portable code. It would encourage them to never use templating
mode since non-templating mode is the only safe approach that would work
regardless of the configuration. Much the same way that all portable
code uses <?php and no <?

2. Templating is a defining characteristic of PHP. For many people it is
the primary reason they even use PHP. Adding a feature that would
essentially discourage use of a defining feature of PHP is illogical.

3. For the /etc/passwd case, the syntax error might reveal enough data
about the contents of the file that this doesn't actually provide enough
of a benefit unless we also heavily redact what we show in a syntax
error. Of course, the argument here is not to show the error to users,
but people who write code with include $_GET['filename'] aren't likely
to follow best practices in the first place.

4. Only protecting against mid-script injections and not top-of-script
injections is a somewhat subtle concept when the real problem is the
vulnerable include $_GET['filename'] hole. If this really is a prevalent
problem, maybe instead of trying to mitigate the symptoms, why don't we
try to attack the actual cause of the problem. I would love to hear some
ideas along those lines that don't fundamentally change the nature of
PHP for somewhat cloudy benefits.

-Rasmus