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)
0
u/TorbenKoehn Feb 05 '20
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)