3 ms·

> Makes me wonder if you can simply disable to the 'eval' command in php and avoid all these hacks? I wish. > Is it ever used by legitimate scripts? There ar

by maratd 14y ago

> Makes me wonder if you can simply disable to the 'eval' command in php and avoid all these hacks? I wish. > Is it ever used by legitimate scripts? There are edge cases, but I haven't found a need for it in almost a decade of coding. I really wish there was an option to disable it while compiling the PHP binary or using php.ini ... Keep in mind, removing eval wouldn't have stopped this hack. It would have simply made it more obvious, since they wouldn't be able to encode/compress their injected code.

Xylakant 14y ago
There are some legitimate uses. The pear SOAP library used it to generate access classes based on WSDL-Files - don't know if they still do that. Anyways, disabling eval doesn't buy you much: If you really want to execute code, write it to a file and then require that file. You can plug that one by making all directories you can load code from unwriteable, but then I could just go and call create_user_func() which is eval in disguise.
- nivla 14y ago
  >disabling eval doesn't buy you much: If you really want to execute code, write it to a file and then require that file. Eval is used by most attackers to avoid detection. A one liner add to the end of a legitimate random php file along with extra padding to push it off the screen will make most users to miss it. Creating directories and files not only requires appropriate permissions but is also more susceptible to be noticed by a user browsing through them.
  - Xylakant 14y ago
    Do you really think anybody would have noticed a "include 'common/footer.php'" at the end of the file? If you have write access to the download tarball, all is lost. Disabling eval on the deploy machine doesn't buy you anything. In general: If you can write to any file in the deployed app, every bet is off - eval or not. Disabling eval helps you in cases where the legitimate code uses eval and can be tricked into passing code snippets of your choice to the call.
maratd 14y ago
Apparently there is a way: http://stackoverflow.com/questions/1865020/php-how-to-disable-dangerous-functions http://stackoverflow.com/questions/1865020/php-how-to-disabl...

by maratd 14y ago

Xylakant 14y ago

There are some legitimate uses. The pear SOAP library used it to generate access classes based on WSDL-Files - don't know if they still do that. Anyways, disabling eval doesn't buy you much: If you really want to execute code, write it to a file and then require that file. You can plug that one by making all directories you can load code from unwriteable, but then I could just go and call create_user_func() which is eval in disguise.

nivla 14y ago
>disabling eval doesn't buy you much: If you really want to execute code, write it to a file and then require that file. Eval is used by most attackers to avoid detection. A one liner add to the end of a legitimate random php file along with extra padding to push it off the screen will make most users to miss it. Creating directories and files not only requires appropriate permissions but is also more susceptible to be noticed by a user browsing through them.
- Xylakant 14y ago
  Do you really think anybody would have noticed a "include 'common/footer.php'" at the end of the file? If you have write access to the download tarball, all is lost. Disabling eval on the deploy machine doesn't buy you anything. In general: If you can write to any file in the deployed app, every bet is off - eval or not. Disabling eval helps you in cases where the legitimate code uses eval and can be tricked into passing code snippets of your choice to the call.

maratd 14y ago

Apparently there is a way: http://stackoverflow.com/questions/1865020/php-how-to-disable-dangerous-functions http://stackoverflow.com/questions/1865020/php-how-to-disabl...