3

I would like to take steps to limit the damage a compromised Wordpress install can cause on the rest of my system. What system calls does Wordpress need? What can I put in the disable_functions configuration?

Documentation: http://php.net/manual/en/ini.core.php#ini.disable-functions

  • 1
    Keep your WordPress secure and safe. That's just it. – Nicolai Dec 20 '16 at 19:35
  • I am asking for specifics that will help me keep Wordpress safe and replying with "you should keep it safe" is not really that helpful. – Kevin Burke Dec 20 '16 at 20:01
  • 2
    Well, sure you can disable things, but there are a lot of elements you can't disable, which still can be used to do a lot of harm. And if I'd use WordPress to damage, hack systems, wouldn't I optimally use the on a server with WordPress available functions and such. So still, making sure that your WordPress installation isn't compromised in the first place, is the only really useful response - in my mind at least -, so I gave it. – Nicolai Dec 21 '16 at 8:49
  • Do you have a multisite installation? Do you have a single site installation? Do you have multiple single site installations? If you have multiple single-site WordPress installation where they reside? In some cases, my idea would be to also restrict the PHP process. – prosti Dec 24 '16 at 9:49
  • I added the very broad list to the answer. – prosti Mar 16 '17 at 11:47
1

Just to continue few important things on the excellent answer @MarkKaplun provided that should be accepted.

disable-functions

is PHP world.

Here is the more broad list:

exec, passthru, shell_exec, system, proc_open, popen, show_source, apache_child_terminate, apache_get_modules, apache_get_version, apache_getenv, apache_note, apache_setenv, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, posix_getpwuid, posix_uname, pclose, dl, disk_free_space, diskfreespace, disk_total_space, pcntl_exec, proc_close, proc_get_status, proc_nice, proc_terminate, symlink, link, putenv, opcache_get_configuration, opcache_get_status

This is a PHP directive you may set in the php.ini file. You don't specify WordPress functions in there. The comma separated functions you enter will be accepted whenever the PHP interpreter runs or when PHP jit runs (hhvm), these functions will be disabled.

One more thing to cover is the process under which PHP is running. Even though you may have mighty functions in PHP they can do nothing if the process under which PHP executes doesn't have the access rights to do these things.

So the security perspective would be to create an isle. Let your www-data user live only on that isle. Let's say the isle is the /var/www folder.

From the /etc/passwd you can check the details about the www-data user. By default it should be like this:

www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin

Use the chmod and chown to create the isle or the level of isolation you need.

1

For security, the rule of thumb is to disable anything you do not need. In an ideal security world the question will actually be the reverse - what functions are required for wordpress to function. You start by simply not activating any PHP extension that you do not use, and then filter out the unsafe functions in the extensions you activated.

Since this is a server wide setting, it is not enough to look what wordpress needs, but also at what the other application on the server need, but in most web server settings these functions should be disabled - exec,passthru,shell_exec,system,proc_open,popen. Their unique attribute which makes them extra dangerous is the ability to execute anything on your system, which can be mitigated by having a restrictive permissions in all of your server, but in practice it requires discipline to get it right and better to just not open this attack avenue at all. In addition those function also bypass the wordpress security model which might let users access data they should not have access to.

As noted above, since every server is likely to have different PHP modules active, this should not be considered as a complete list, but just a starting point, and you will have to check each of the modules you use to see if they contain functions which might be better to have disabled.

  • how safe is it to disable these functions, seeing how some of the core WP code is using them (exec for data debugging and shell_exec for revisions (from a script))? Will disabling them disable these functionalities in the WP? – dingo_d Jul 19 at 11:19
  • Where in core do you see exec and shell_exec? – Mark Kaplun Jul 19 at 15:19
  • The Text_Diff package in wp-includes that generates diff for revision is using it, and exec is used in WP_Debug_Data class (site health). The other place it's used is deprecated (Snoopy). There are also usage of curl_exec and ssh2_exec in the core... – dingo_d Jul 19 at 15:50
  • well, didn't follow the execution path for the text diff code, but since wordpress works on IIS and there is no GNU diff program on windows AFAIK, most likely you do not get there. The WP_Debug_Data is indeed stupid, but as it is only used to detect if there is ghostscript installed (stupid code fails with that as well most likely) it is not a big loss – Mark Kaplun Jul 19 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.