24

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 feature and apparently the popular Suhosin security patch isn't compatible with PHP 5.4.

So my question is this: is it safe to run a PHP website without the Suhosin security patch? If not, what vulnerabilities would I be leaving myself and other people using my CMF open to?

Note: I'm not concerned about shared hosting. It's expected that anyone using my CMF would have administrative control over their web server.

ck_
  • 3,353
  • 5
  • 31
  • 33
Evan Byrne
  • 1,105
  • 1
  • 12
  • 17
  • 7
    if you can use `` to subvert a site, then you should be hanging out a shingle as a penetration tester. a site is as safe or unsafe as you make it. – Marc B Jan 18 '13 at 18:15
  • 4
    I don't get it, why was this closed? It's a perfectly valid question. – Evan Byrne Jan 18 '13 at 18:24
  • 5
    because you're asking a blanket "is my system safe" without ANY details about your system. is your site just a hello world? is it going to be doing the online banking for Bank of America? They're entire universes apart in security requirements, and there's absolutely not way anyone could give you ANY kind of a valid answer for such a broad spectrum of problems. – Marc B Jan 18 '13 at 18:29
  • 12
    No that's not what I'm asking at all. I'm asking if PHP 5.4 has any known vulnerabilities that Suhosin patched for 5.3, and therefore whether I should stick with 5.3 + Suhosin or upgrade to 5.4. I'm asking this because a lot of people recommend against using PHP without the patch. – Evan Byrne Jan 18 '13 at 18:34
  • 4
    I feel this is a valid question. We can reframe it to : Are the vulnerabilities tackled by Suhosin in PHP 5.3 present/significant in PHP 5.4. – SoWhat Jan 19 '13 at 07:26
  • 1
    There is a Github repo with Suhosin for PHP 5.4, set up by the Suhosin author. So I think there will be suhosin for 5.4 in the near future. – MV. Aug 08 '13 at 07:40

3 Answers3

40

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.

  • 1
    Thanks duskwuff, that's exactly the kind of answer I was looking for :) – Evan Byrne Jan 19 '13 at 19:36
  • 9
    -1 (sorry, always feel bad for that) for a vague answer. Suhosin has [a lot of features](http://www.hardened-php.net/suhosin/a_feature_list.html) and I'd feel much more comfortable if someone could tell me **which** of these features has been rolled into later versions of PHP, and which are not implemented. – artfulrobot Jun 04 '13 at 14:49
  • 1
    Suhosin is a patch AND an extension. You can use the extension without the patch and get extra protection and security features which are not present in a vanilla PHP (not even in 5.4). – MV. Aug 08 '13 at 07:36
7

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)

Richard
  • 281
  • 3
  • 6
  • As a side note: PHP 5.5 will tip you off by itself when /e is used by issuing a deprecation warning ;) – NikiC Oct 03 '13 at 12:47
  • 2
    While your argument for disabling eval makes sense it ignores a more obvious point: filtering user input and securing server access — if a hacker can't inject code with evals they can't use evals to begin with. Understanding how to whitelist input and use proper output encoding is more broadly useful security concept than blacklisting commonly used language features. – Mark Fox Feb 20 '14 at 21:48
  • Haha, my antivirus alerted on this site, saying it has *PHP/Obfuscated.E*. So this is why. – alexia May 04 '14 at 10:23
1

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"...

Chris
  • 53
  • 1
  • 6
    No evidence or rationale for any of these criticisms: just a lot of generic [FUD](http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt) — `neither authoritative nor necessarily correct` is a statement which clearly applies to *this* answer above all else on this page – Mark Fox Feb 20 '14 at 21:35