4 ms·

eval(gzuncompress(base64_decode('eF... Classic PHP injection hack.

tomjen3 14y ago
Makes me wonder if you can simply disable to the 'eval' command in php and avoid all these hacks? Is it ever used by legitimate scripts?
- halfdan 14y ago
  http://geekmonkey.org/articles/42-the-anatomy-of-an-exploit http://geekmonkey.org/articles/42-the-anatomy-of-an-exploit
- 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...
- rplnt 14y ago
  I would worry so, yes. There was/is so many PHP (and Java for that matter) jobs available that even the worst coders get hired in the end.
  - rjbond3rd 14y ago
    This doesn't seem like a "PHP coding quality" issue to me -- more like a trust issue, because the site admin opened the security hole by installing a WP plugin. That could happen in any language / framework / situation. It's rogue code that got trusted.
    - rplnt 14y ago
      Yes, you are right. I was responding to the use of eval in production code.
  - camus 14y ago
    Saying that doesnt make you a better programmer, nor smart.
- RobAley 14y ago
  Yes, you can disable any arbitrary internal function in PHP using disable_functions[1] directive in php.ini [1] http://php.net/manual/en/ini.core.php#ini.disable-functions http://php.net/manual/en/ini.core.php#ini.disable-functions Edit: Also, as noted below, this wouldn't prevent this or many other similar hacks as you need write access to the PHP script to put the eval in in the first place, so you could just write other code in there directly (and pull in extra scripts to execute by writing to disk etc. if necessary). Eval is typically dangerous, in its own right, when it is used by the legitimate developer who then allows unchecked code to be passed to it.
  - degenerate 14y ago
    And how to use it: http://www.cyberciti.biz/faq/linux-unix-apache-lighttpd-phpini-disable-functions/ http://www.cyberciti.biz/faq/linux-unix-apache-lighttpd-phpi... Just remove anything you use. I use cURL, so I took it out.
  - infinity 14y ago
    The problem with disable_functions is that eval is not an internal function, but a language construct. From the manual: Only internal functions can be disabled using this directive. It is possible to generate something like a list of all available internal functions, eval is missing here: $arr = get_defined_functions(); var_dump($arr['internal']); The Suhosin extension will let you block eval, if it is available: http://www.hardened-php.net/suhosin/configuration.html#suhosin.executor.disable_eval http://www.hardened-php.net/suhosin/configuration.html#suhos...
    - RobAley 14y ago
      Apologies, you are correct, I was thinking of exec.
- mcovey 14y ago
  I've used it in a template renderer to render templates from files or strings. You can use eval('?>'.$string). There may be a better method, I never bothered looking after that worked.
ohwp 14y ago
I think your comment just triggered Microsoft Security Essentials on my PC because it was saved as cache on my disk :)

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

halfdan 14y ago
http://geekmonkey.org/articles/42-the-anatomy-of-an-exploit http://geekmonkey.org/articles/42-the-anatomy-of-an-exploit
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...
rplnt 14y ago
I would worry so, yes. There was/is so many PHP (and Java for that matter) jobs available that even the worst coders get hired in the end.
- rjbond3rd 14y ago
  This doesn't seem like a "PHP coding quality" issue to me -- more like a trust issue, because the site admin opened the security hole by installing a WP plugin. That could happen in any language / framework / situation. It's rogue code that got trusted.
  - rplnt 14y ago
    Yes, you are right. I was responding to the use of eval in production code.
- camus 14y ago
  Saying that doesnt make you a better programmer, nor smart.
RobAley 14y ago
Yes, you can disable any arbitrary internal function in PHP using disable_functions[1] directive in php.ini [1] http://php.net/manual/en/ini.core.php#ini.disable-functions http://php.net/manual/en/ini.core.php#ini.disable-functions Edit: Also, as noted below, this wouldn't prevent this or many other similar hacks as you need write access to the PHP script to put the eval in in the first place, so you could just write other code in there directly (and pull in extra scripts to execute by writing to disk etc. if necessary). Eval is typically dangerous, in its own right, when it is used by the legitimate developer who then allows unchecked code to be passed to it.
- degenerate 14y ago
  And how to use it: http://www.cyberciti.biz/faq/linux-unix-apache-lighttpd-phpini-disable-functions/ http://www.cyberciti.biz/faq/linux-unix-apache-lighttpd-phpi... Just remove anything you use. I use cURL, so I took it out.
- infinity 14y ago
  The problem with disable_functions is that eval is not an internal function, but a language construct. From the manual: Only internal functions can be disabled using this directive. It is possible to generate something like a list of all available internal functions, eval is missing here: $arr = get_defined_functions(); var_dump($arr['internal']); The Suhosin extension will let you block eval, if it is available: http://www.hardened-php.net/suhosin/configuration.html#suhosin.executor.disable_eval http://www.hardened-php.net/suhosin/configuration.html#suhos...
  - RobAley 14y ago
    Apologies, you are correct, I was thinking of exec.
mcovey 14y ago
I've used it in a template renderer to render templates from files or strings. You can use eval('?>'.$string). There may be a better method, I never bothered looking after that worked.

ohwp 14y ago

I think your comment just triggered Microsoft Security Essentials on my PC because it was saved as cache on my disk :)