On Tue, Nov 26, 2019 at 10:53 AM Ian Littman <ians...@gmail.com> wrote:
> What do y'all think about getting this into PHP 8? > So long as the default behavior is to leave it available, I'm okay with this. Any app that relies on twig/twig, phpunit/phpunit, many symfony packages, dompdf/dompdf, etc relies on being able to use eval(). On Tue, Nov 26, 2019 at 10:53 AM Ian Littman <ians...@gmail.com> wrote: > 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 >
