Hi all,

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.

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 for

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 code

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 four

years since we've had a stable release of Suhosin.

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 use

a similar warning to the display_disabled_function one here.

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).

From taking a quick look at Suhosin code, the way they're handling this may

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.

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 if

I try going down that road...and if other folks like the idea, I could use

some help here putting it together.

What do y'all think about getting this into PHP 8?

Thanks in advance,

Ian Littman