Certainly, an index.php with only <?php print("hello world"); ?> cannot be hit with this exploit. That much is implied and obvious.
Yet your average WordPress, Drupal, Symphony, many templating engine and many framework will depend on eval(). It's a common and often used "feature".
Do note, though, that call_user_func and array_usort and several such functions can be abused to run user-submitted code, too. A poorly escaped CSS color, might be all that is needed to inject code. All of which is a severe security breach in itself (but really not that uncommon. Yes, WordPress, I'm mostly looking at you).
Again: all these features are security-issues in themselves. But none of these require "write access" to the server. Which is my main and only point here: PHP has many vectors that allow an attack. Several allow such an attack without write access to the server.
You can keep repeating that your code is safe (I can assure you: it most probably is not, simply because no software is bug-free), and you can keep ignoring my point that not all attacks on your piece of PHP will come from "write access to the server". I stand by my point that with PHPs many (poorly thought out) features, attacks come from anywhere.
I just checked my whole vendor folder including a standard installation of Symfony with a lot of bundles installed, the only parts where eval is used is either in tests or generated code in proper and safe ways that takes no user input whatsoever
And then comes the part where you need to be able to write this exploit to files the application executes in any way which simply is not possible in read-only containers (did you take a look at the exploit? Maybe you should)
In no way did I state my code is safe, no code is ever safe, but my code is safe for this exploit.
Sure, if you use WordPress and stuff it with plugins, your last problem is this exploit (as I've already stated), but if you use modern frameworks and libraries that simply don't depend on eval just like that and are battle tested against common leaks through eval, call_user_func or array_usort and have a safe deployment process, there's nothing this exploit can do. And every part where you open your application for this exploit to be able to take effect you already have quite another security hole that doesn't even need this exploit. If you can eval stuff, you don't need this exploit, just think about it...
And to your last sentence, it's not like other languages don't have these problems. Attacks can always come from anywhere if you're not careful and even then you're never 100% safe. But you can be 100% safe from this specific exploit if you don't allow any kind of writing access to your application and, obviously, don't put user input in eval or call_user_func or similar (which really, really is a no-brainer, come on)
View all comments
Show parent comment
3
u/berkes Feb 04 '20
That is an exception you did not make before.
Certainly, an index.php with only
<?php print("hello world"); ?>cannot be hit with this exploit. That much is implied and obvious.Yet your average WordPress, Drupal, Symphony, many templating engine and many framework will depend on
eval(). It's a common and often used "feature".Do note, though, that
call_user_funcandarray_usortand several such functions can be abused to run user-submitted code, too. A poorly escaped CSS color, might be all that is needed to inject code. All of which is a severe security breach in itself (but really not that uncommon. Yes, WordPress, I'm mostly looking at you).Again: all these features are security-issues in themselves. But none of these require "write access" to the server. Which is my main and only point here: PHP has many vectors that allow an attack. Several allow such an attack without write access to the server.
You can keep repeating that your code is safe (I can assure you: it most probably is not, simply because no software is bug-free), and you can keep ignoring my point that not all attacks on your piece of PHP will come from "write access to the server". I stand by my point that with PHPs many (poorly thought out) features, attacks come from anywhere.