Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107862
Content-Type: multipart/alternative; boundary=Apple-Mail-2CC6A52C-DF2A-4E7E-99BD-F548F3466670
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Tue, 26 Nov 2019 17:11:50 +0100
Message-ID: <A7F945D0-C227-462C-9505-159EBA78B979@gmail.com>
References: <CAAupm8h5Aa4EmnGnHX1iVgcQTCpmW-3yD4e6m7aouZFiSCtGrA@mail.gmail.com>
Cc: internals@lists.php.net
In-Reply-To: <CAAupm8h5Aa4EmnGnHX1iVgcQTCpmW-3yD4e6m7aouZFiSCtGrA@mail.gmail.com>
To: Ian Littman <iansltx@gmail.com>
Subject: Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8
From: benjamin.morel@gmail.com (Benjamin Morel)

--Apple-Mail-2CC6A52C-DF2A-4E7E-99BD-F548F3466670
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Ian,

IMO, eval() is secure, as long as:

- you=E2=80=99re not using it, or
- you=E2=80=99re using it properly

I=E2=80=99d say that as soon as your server has been compromised, eval() is t=
he last of your worries, as pretty much anything becomes possible, including=
 writing PHP code to a file and including/executing it. So I feel like disab=
ling eval() will just make =C2=AB hackers =C2=BB have a good laugh.

Regarding (arguably) legitimate use cases that would suffer from eval() bein=
g disabled, is a Schema.org parser library I wrote, that dynamically creates=
 objects that implement arbitrary interfaces:

https://github.com/brick/schema/blob/master/src/ObjectFactory.php

IMHO, disabling eval() would not increase the security of PHP, and could be a=
nnoying for libraries relying (sparingly) on it, for lack of anything better=
.

Best,
Benjamin

> Le 26 nov. 2019 =C3=A0 16:52, Ian Littman <iansltx@gmail.com> a =C3=A9crit=
 :
>=20
> =EF=BB=BFHi all,
>=20
> Let's just say that eval() and create_function() are the cornerstone of
> PHP-based exploit toolkits. Yes, if the hackers get in there are other
> problems with your codebase, but as a defense in depth measure most
> applications need neither create_function() nor the eval() language
> construct, so they might as well be disabled.
>=20
> create_function() is easy enough to drop with a didabled_functions ini
> directive, and is going away "no later than PHP 8.0", per its deprecation
> notice as of 7.2. eval() on the other hand can't be disabled that way, as
> it's not actually a function. So this seems like an excellent candidate fo=
r
> another ini setting, as from a security standpoint you *want* this change
> to be global. Yes, if every shared host turned this on by default, old cod=
e
> would break. But I Suhosin allows doing this anyway (
> https://stackoverflow.com/questions/25037015/suhosin-and-disable-eval) so
> it's not like the option hasn't been available...though it's been over fou=
r
> years since we've had a stable release of Suhosin.
>=20
> Similar to disable_functions, if the ini setting turning off eval() got
> set, you shouldn't be able to override it via ini_set() in code. We can us=
e
> a similar warning to the display_disabled_function one here.
>=20
> One alternative to adding an entirely new INI setting would be to allow
> disabled_functions to work on eval. That means that somewhere in the INI
> parsing/stubbing/warning process (and maybe all three places) will get a
> bit more complex, but that would have the benefit of not having to explain=

> to anyone editing the ini file that eval() is a language construct rather
> than a function and thus can't be disabled the normal way (I was just
> apprised of this mistake last today).
>=20
> =46rom taking a quick look at Suhosin code, the way they're handling this m=
ay
> be somewhat informative for creating a patch directly to core, but as a
> bolt-on it looks like they can't be as efficient, so any patch to core
> would be inspired by, rather than a copy of, how that extension's
> eval-handling is built.
>=20
> I feel strongly enough about this to help with the text side of the RFC,
> and maybe even dive into php-src to assist with a patch, though I have
> neither karma for posting the former nor enough C acumen to do the latter
> all by myself. But I want to make sure I won't get immediately shot down i=
f
> I try going down that road...and if other folks like the idea, I could use=

> some help here putting it together.
>=20
> What do y'all think about getting this into PHP 8?
>=20
> Thanks in advance,
>=20
> Ian Littman

--Apple-Mail-2CC6A52C-DF2A-4E7E-99BD-F548F3466670--