Re: 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 <benjamin.morel@gmail.com> wrote: > > > > 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() > of > > a URL into the code and...well, you get code execution that (if you're > > lucky) only leaves a trace in logs. If you have to write a file somewhere > > first, then include it, you've got a bit more of a footprint. > > > > You don't have to hit disk, or have any writable path. You can just create > a stream wrapper > <https://www.php.net/manual/en/class.streamwrapper.php> > that stores the "files" in memory, and include them as you would include a > regular file. > > > Can you work around these restrictions? Yep, but it takes a bit more effort > > than the current setup. It doesn't make a server secure by any stretch, > but > > it reduces its attack surface slightly, and reduces the universe of > > malicious code that won't error out, forcing malefactors to work just a > bit > > harder. > > > > Disabling eval() really doesn't reduce the attack surface at all, if you > ask me. Malefactors will quickly & easily adapt their tools, that script > kiddies will use as before. > > > — Benjamin >