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 isn't available. The other two break if eval() isn't available. 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. 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. To be crystal clear, **I am not asking for disabling eval() by default**. Just for it to be disable-able, as create_function already is. This isn't a resolution for all things security-related. Just one more thing to slow attackers down. Heck, if we can't agree on having the ability to disable eval() (which, again, Suhosin has), how about catching cases where someone throws eval into disabled_functions and warning them that the difference between a function and a language construct renders their INI declaration useless? Ian On Tue, Nov 26, 2019 at 4:21 PM Stanislav Malyshev <smalys...@gmail.com> wrote: > 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 > > construct, so they might as well be disabled. > > I get defense in depth, but I don't understand what it means in this > case. Since you're talking about disabling functions, I assume we're > talking about the situation where there's code execution access. From > that point, you can execute any code. What is the value of disabling > eval() here? You don't need eval, you can run any code you want > directly! Am I missing something here? > > -- > Stas Malyshev > smalys...@gmail.com >
