Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8

Assuming preloading (big assumption), disabling `eval()` as well as `include*` and `require*` would probably close off most RCEs. That would break a lot of stuff, but it would certainly make for a very interesting experiment. On Wed, Nov 27, 2019, 00:09 Benjamin Morel wrote: > > > > One interes

Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8

> > One interesting thing with item #1 is that it allows for remote arbitrary > code execution even if no include-able path on a server is writable. This > comes into play if there's a supply chain attack on your app. Say, an > infected update on a CMS plugin. Get an eval() of a file_get_contents()

Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8

Main holes that this closes are: 1. Being able to run code fetched remotely without ever hitting disk 2. Being able to run code transformed directly from an obfuscated state I have examples of both techniques; reply directly to me if you're curious. One of the examples breaks if create_function i

Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8

Hi! > You're right that turning off eval() isn't a silver bullet, and if you can > get external code running on someone's box there are a lot worse things you > can do. I think the important point here is not that you can do worse things than eval() but that you can do *anything*. Once you can ex

Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8

Hi! > 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 > const

Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8

create_function() will be gone as of PHP 8 anyway. For eval(), e.g. psysh uses it (and, as a result, e.g. Laravel Tinker). So defaulting eval to disabled doesn't seem tenable. Not what I'm asking anyway...I just want the *ability* to turn it off (likely only in apache/fpm configs actually, leaving

Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8

> On Nov 26, 2019, at 11:27 AM, Ian Littman wrote: > > You're right that turning off eval() isn't a silver bullet, and if you can > get external code running on someone's box there are a lot worse things you > can do. > > On Tue, Nov 26, 2019 at 10:11 AM Benjamin Morel > wrote: > >> Hi Ian, >>

Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8

Thanks for the reference. For convenience, here's the PR that contains a bit more context: https://github.com/php/php-src/pull/4084 Definitely don't want to screw up Xdebug, so this would require a more nuanced approach (see also: why I don't want to just try to create a patch). Again, this doesn

Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8

For the record, a few months ago, https://github.com/php/php-src/pull/4084 (extending `disable_functions` to handle `eval`) was first merged but finally reverted (requested by Xdebug), and the feature request https://bugs.php.net/bug.php?id=62397 was closed (with an explanation). -- Guilliam Xavi

Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8

You're right that turning off eval() isn't a silver bullet, and if you can get external code running on someone's box there are a lot worse things you can do. That said, if eval() and create_function() fail, the exploit samples that I've recently come in contact with stop working, and it becomes m

Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8

Looks like PHPUnit only uses eval() for mock objects, and Twig only uses it as a last line of defense for building templates. Still breakages, but not of the entire packages (at least those packages) from what I can see. That said, I agree that eval() should stay enabled by default, as too much br

Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8

Hi Ian, IMO, eval() is secure, as long as: - you’re not using it, or - you’re using it properly I’d say that as soon as your server has been compromised, eval() is the last of your worries, as pretty much anything becomes possible, including writing PHP code to a file and including/executing i

Re: [PHP-DEV] Let's allow eval() to be turned off in PHP 8

On Tue, Nov 26, 2019 at 10:53 AM Ian Littman 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 ab

[PHP-DEV] Let's allow eval() to be turned off in PHP 8

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,

Re: [PHP-DEV] Re: file_cache is prone to some configuration changes

On 24.11.2019 at 22:52, Dik Takken wrote: > On 19-11-19 10:44, Christoph M. Becker wrote: > >> On 06.11.2019 at 14:02, Christoph M. Becker wrote: >> >>> while having had a closer look at , I >>> learned that OPcache's file_cache is prone to some configuration >>> change