Is php 5.4 safe without Suhosin?

Question

I\'m currently working on developing a PHP CMF which will eventually be commercially available and I want to use traits. The problem however is that traits are a PHP 5.4 fea

Answer 1

If you can't disable eval() (a language construct, not a function) or have a blacklist within eval to disable most of the hacker's toolbox within eval, then you are running a load of bandwidth that is irresistable to hackers looking for bandwidth to run their payloads. What to blacklist, ideally, can't always be done because 3rd party module writers or even framework core depends on some of these functions within an eval() context:

suhosin.executor.eval.blacklist=include,include_once,require,require_once,curl_init,fpassthru,file,base64_encode,base64_decode,mail,exec,system,proc_open,leak,pfsockopen,shell_exec,ini_restore,symlink,stream_socket_server,proc_nice,popen,proc_get_status,dl,pcntl_exec,pcntl_fork, pcntl_signal, pcntl_waitpid, pcntl_wexitstatus, pcntl_wifexited, pcntl_wifsignaled, pcntl_wifstopped, pcntl_wstopsig, pcntl_wtermsig, socket_accept, socket_bind, socket_connect, socket_create, socket_create_listen, socket_create_pair,link,register_shutdown_function,register_tick_function,create_function,passthru,p_open,proc_close,proc_get_status,proc_terminate, allow_url_fopen,allow_url_include,passthru,popen,stream_select

If you can't filter for these functions then a major component of security is missing.

Here are some examples of Remote Administration Tools (RATS) that will infect your site, through any vulnerable 3rd party module or site user account.

RATs can take many forms, some are easy to grep for:

<?php error_reporting(0); eval(gzuncompress(base64_decode('eF5Tcffxd3 ...

<?php preg_replace("/.*/e","\x65\x76\x61\x6C\x28\ ...

Some are more professional and obfuscated, and cannot really be grepped for, and cannot be found unless suhosin tips you off that they executed:

<?php $_0f4f6b="\x70\x72\x65\x67\x5f\x72\x65\x70\x6c\x61\x63\x65";$_0f4f6b("\x7 ...

<?php require "./.cache/.%D59C%49AA%73A8%63A1%9159%0441"; ?>  

(note in this case the CACHE directory cannot be in source control, therefore cannot be tracked either)

Answer 2

IMHO, the statement above from duskwuff, that things would be fine without Suhosin is neither authoritative nor necessarily correct (especially given the amount of critical holes newer PHP versions have seen since then).

To my mind, it would be definitely better - from a security POV - if Suhosin was available for current PHP version. Of course, as it is not, staying at old (eventually unmaintained) versions of PHP isn't a solution either.

Generally PHP and especially PHP applications are notoriously known for having security issues... so the question is less "are newer PHP versions safe without Suhosin"...

Answer 3

Suhosin was a PHP hardening patch. It did not patch any explicit security vulnerabilities -- it merely made some vulnerabilities in PHP scripts more difficult to exploit.

Some of the changes which Suhosin made were eventually rolled into PHP. For instance, Suhosin's various layers of protection against null bytes in inputs were made unnecessary by PHP 5.3.4, which made null bytes in filenames always throw an error (rather than silently truncating the filename at the null byte).

PHP 5.4 is generally regarded to be reasonably safe without Suhosin involved. Going forward, so long as your application supports it, you will be better off with a newer (5.4+) version of PHP, rather than an older version with the Suhosin patch.