Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58677
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
Received-SPF: pass (google.com: domain of dmgx.michael@gmail.com designates 10.180.95.105 as permitted sender) client-ip=10.180.95.105;
MIME-Version: 1.0
In-Reply-To: <CAH-PCH6Uah2ig5Ofz7MY8sbVpVPsV33KF41aqsDT5dumZbiD3Q@mail.gmail.com>
References: <CAGovj_NYgm0ruAoz7iA_S0fS62YJ+PpzAG+DJEnuRJRKaqkDGg@mail.gmail.com>
	<CAH-PCH6Uah2ig5Ofz7MY8sbVpVPsV33KF41aqsDT5dumZbiD3Q@mail.gmail.com>
Date: Tue, 6 Mar 2012 12:04:51 -0500
Message-ID: <CAGovj_OaGx8KQdX4r8H5ETTUhb+ZKpg-T6bT4jJgCYrdVauAsw@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [RFC] Namespace and Parse tags on Include and Require
From: dmgx.michael@gmail.com (Michael Morris)

On Tue, Mar 6, 2012 at 11:40 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:

>
> I don't like this, I mean one can end up printing out his sourcecode if
> - those files are publically available through the document root

This can also occur if the server is mis-configured. That said, one
way to deal with this.  One would be to allow the server itself to
start PHP with the file being loaded as tagless.  In either event
though we're dealing with a config change, and users don't always
remember to do those when they switch versions.

Would current software break though?  I don't think so.  Anyone doing
this would (should?) be aware of the ramifications.  I'm personally
not a fan of putting all the PHP files in the web document root, but I
can understand why its done and I know its the current most common
practice.

> or
> - if he somewhere used a wrong argument, and includes a tagless file with
> the (default) with-tags option.
> on the other hand, a html file page with php code examples (but without php
> tags) could be turned into executing those examples if the tagless option is
> used.

That's actually up in the air as to how this is implemented.  If
implemented such that the parser just appends "<?php" to the start of
the file inclusion (the laziest way to implement this feature) then
any code block in there could possibly execute.

To your first point this would mean the first block of code would be
ignored and echoed out if it was mis-imported up until the parser
finds a closing tag, and then finds a new opening tag.  Then code
would begin executing, and an attacker might pull off something with
this.  More likely though the code is going to parse error having come
into the execution at an unexpected moment.

If implemented such that 'tagless' truly means tagless and using php
tags would result in a parse error in that mode the attack becomes
much harder to pull off.

So with your first point the if they import a tagless file with the
wrong file everything gets echoed out as text because there would be
no tags to pick up on unless the attacker is *very* sneaky and puts it
in the quotes of an echo statement.

As to the html, trying to import a html file with php code examples as
a tagless file is going to fail, and fail hard, with the very first
html tag or the doctype declaration of <!DOCTYPE html>

I feel neither example is really a new vulnerability though.  If
anything, it makes code injection a bit trickier. But the basic mode
of exploit isn't going to change.

And the programmer working with this should be able to correct his
mistake and move on.

>
>
> I would support the namespace option though.

Of the two this one is actually the one that scares the heck out me in
terms of what can go wrong if it is misused.