Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59665
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain priacta.com designates 64.95.72.241 as permitted sender)
To: Yasuo Ohgaki <yohgaki@ohgaki.net>, "internals@lists.php.net"
	<internals@lists.php.net>
Date: Tue, 10 Apr 2012 14:13:59 -0400
Thread-Topic: [PHP-DEV] Disabling PHP tags by php.ini and CLI options
Thread-Index: Ac0W8A1ZtzcdNRefRDale9UqNnvxfQAOS+SA
Message-ID: <A633CF2D7C7BED41B41F1E64F25507B806A5CDD685@MAILR001.mail.lan>
References: <CAGa2bXZ6G=Cphjrde3u1Mq3AAw-4yJk3s28vNe+Aybt2nGTumg@mail.gmail.com>
In-Reply-To: <CAGa2bXZ6G=Cphjrde3u1Mq3AAw-4yJk3s28vNe+Aybt2nGTumg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: [PHP-DEV] Disabling PHP tags by php.ini and CLI options
From: johncrenshaw@priacta.com (John Crenshaw)

From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo Ohgak=
i
>=20
> Hi all,
>=20
> This is the RFC as in the title.
> Although it's not a direct security measure, but it's related to critical=
 security problem prevention.
>=20
> If you are not familiar to how to execute arbitrary PHP code, steal data =
from RDBMS via SQL injection and LFI, it may be interesting.
>=20
> This RFC will not break any existing code. Programmers may keep full back=
ward compatibility while getting better security.
>=20
> https://wiki.php.net/rfc/nophptags

The proposed change will NOT make it safe to write require $_GET['name'];

Nothing can ever make that code safe. Even with remote inclusion turned off=
, even with php tags disabled. That code is fundamentally broken. It uses a=
n uncontrolled input to execute arbitrary code and is only slightly more di=
fficult to exploit than eval($_GET[foo']). In most systems you can upload *=
anything* with a .jpg extension and the app will take it, so you can still =
include the file, and the contents can drop straight into script, no tag ne=
eded. If the temporary upload directory is accessible to the PHP process at=
 all you can also include the file, regardless of extension or content.

Alternately, in the unlikely case that file contents of uploads are validat=
ed, or the exploit file is otherwise not fully under control, you could use=
 a noop slide of sorts (multiline comment, string, or docblock) to "slide" =
past any obligatory starting boilerplate or incontrollable garbage in a fil=
e to quickly reach the code point. Honestly it would be far harder to craft=
 an attack file if you *REQUIRED* the file to start with <?php, since many =
file formats have obligatory tags in the first few bytes. If the file start=
s in code mode these tags can be terminated/jumped into a slide in a vast v=
ariety of ways (`;` or `;/*` or `.'`, just to name a few.) PHP will give a =
notice, but otherwise happily continue (assuming an alphanumeric tag, which=
 is most common).

If that is too complicated, you could bypass the need for a file entirely b=
y using data:// or php://stdin to effectively turn the require into an eval=
. I'm sure there are any number of other inventive exploits that I haven't =
even thought of.

The supposition that a user can (let alone will) make this code secure by d=
isabling script tags is insane. It doesn't actually prevent this type of ex=
ploit in the first place. No shared host or distro could possibly get away =
with disabling this by default, because of the impact to legacy code, and s=
omeone who wrote "require $_GET['name']" isn't watching security on their s=
ide anyway. There's simply no sane reason for such an option, especially gl=
obally.

John Crenshaw
Priacta, Inc.