XF 1.3 PHP functions via the disable_functions directive in php.ini

[polle]

When Upgrading I get this message:

-----
The following warnings were detected when verifying that your server can run XenForo:

Your server has disabled core PHP functions via the disable_functions directive in php.ini. Depending on the functions that have been disabled, this may cause unexpected problems in XenForo. All PHP functions should be enabled.

These may affect the proper execution of XenForo at times and should be resolved if possible.
-----

I would like to know which functions does Xenforo need.

Thanks.

 

[Jake Bunce]

I would like to know which functions does Xenforo need.

There is no list of required functions. The error is just saying you might encounter problems, so you should un-disable all PHP functions to be sure.

 

[SamL]

I'm sorry, but that's a cop-out and a disservice to XF customers. There are all kinds of reasons that a specific function might be disabled, particularly by large hosts. As it is, a prospective XF customer that relies on a shared-host environment can't even tell if their current host would support XF fully, because the requisite functions simply aren't published.

XF shouldn't dictate that 'all' functions be enabled. There should simply be a list of functions used, and the end-user can determine compatibility with their environment. And it's definitely not asking too much to have a list of PHP functions used by the core, particularly if upgrades display that kind of message.

This question comes up pretty often. It's time to take that as a cue.

 

[Jake Bunce]

I suggest searching the content's of the XF files for the name of each function that is disabled on your server. That is an easy way to tell if any of the disabled functions are used by XF.

 

[SamL]

And I suggest that the Xenforo developers document their PHP functions, so this conversation would be moot.

 

[Jeremy P]

You want them to create a list of every native function called across every file? That's not only a bit ridiculous but also sounds like a nightmare to maintain.

You're complaining about the wrong end of this equation. You should demand your host document which PHP functions are disabled, and then run a search on the XenForo directory for those functions. Unless your host disabled something very obscure that XF happens to use, or something very common, both of which are rare, you're unlikely to have problems.

This warning displays if there are any functions disabled as a general advisory if errors do pop up.

 

[SamL]

I'm not 'complaining' about anything, and I have no functions disabled on my VPS. But, I see this question come up so often (see the OP of this thread) that it's clear that the functions DO need to be documented.
There's room for improvement here.

 

[Jake Bunce]

Documenting the use of every internal PHP function is time prohibitive. XF has a PHP version requirement. Implicit in that is all core functionality within that PHP version.

I don't know of any PHP application that exhaustively lists all used PHP functions. A PHP version requirement is how it's done.

 

[euantor]

If you list the functions you have blocked, I'm sure somebody could tell you if they are required within the core or not.

 

[polle]

I do not publicly post specific information about any of the security measures I take on my servers. There are several functions that are commonly used for XSS, SQL injection and cross-site attacks that are not normally needed by applications. As a general rule, I disable those functions.

IMO, these functions should be disabled in a shared environment. The vast majority of webmasters do not need these functions. If certain security related functions are required by an application, that application should be run on a server not shared by others.

BTW, for the most part, it is not difficult for coders to write code that does not use any of the commonly known dangerous functions. PHP.net recommends avoiding them and several are being phased out of PHP in future versions.

... so you should un-disable all PHP functions to be sure.

Since the Xenforo warning is "may effect", this is like saying 'you might forget where you left your car keys, so you should leave them in your car." So 'put the other webmasters at risk for the convenience of Xenforo.'

Documenting the use of every internal PHP function is time prohibitive ... I don't know of any PHP application that exhaustively lists all used PHP functions.

Not all functions need be listed because there is a finite set of functions that can be disabled. From PHP.net, re: disable_functions: "This directive allows you to disable certain functions for security reasons."

Responsible web hosts commonly disable many of these functions and, in fact, I block most functions that are used by e.g., shell scripts and SQL injection scripts.

WordPress, SMF and a long list of other applications run just fine on my servers with certain functions disabled for security.

And it's definitely not asking too much to have a list of PHP functions used by the core, particularly if upgrades display that kind of message.

Precisely. Xenforo should provide a requirements page, to include any required functions that may be disabled.

Many application developers list requirements when functions that are commonly disabled are used in their code. (These are most frequently encountered in ecommerce applications, BTW.) Xenforo can easily do the same.

I think the warning from Xenforo is irresponsible, especially the part about enabling all PHP functions. They should avoid using any of the functions that can be disabled and, if that is not possible, clearly state which functions they're using so webmasters can make an informed decision about whether they want to use Xenforo.

Lastly, there is another recommendation by Xenforo that is irresponsible. From their requirements page, "two directories must be set to world writeable (CHMOD 0777)." This is never a good idea. It is not required on many servers, including mine, and creates a serious security problem for webmasters who follow that advice.

Cheers.

 

[euantor]

You can be fairly certain that most of the commonly blacklisted functions (such as exec(), passthru(), shell_exec(), parse_ini_file(), show_source() etc) aren't needed by the core of XenForo (that isn't to say that there are definitely no add-ons using any of them). If XenForo depended on a function commonly known to be a security risk, it would be well documented and would certainly have been brought up before.

Regarding the chmod requirements, chmod can be a tricky thing depending on your setup (some servers and webmasters choose some bizarre settings - I've seen it all too many times on shared hosts). You should use your common sense and take this kind of recommendation with a pinch of salt. It's not a hard requirement that an exact permission level is set, so long as the directories are writable by PHP.

 

[Jake Bunce]

Not all functions need be listed because there is a finite set of functions that can be disabled. From PHP.net, re: disable_functions: "This directive allows you to disable certain functions for security reasons."

"Certain functions" in this case means *all* internal PHP functions. There is no limit on what internal functions can be disabled via that directive. The entire set of internal functions probably numbers in the thousands.

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

 

[erich37]

What about introducing some sort of "XF File Health Check" for "PHP functions" ?

 

[polle]

What about introducing some sort of "XF File Health Check" for "PHP functions" ?

That sounds good.

 

[Chris D]

It's still not really feasible.

There are too many functions.

It's best just to see this notice simply as "advice". It's unlikely you or your hosts will have disabled any functions that XenForo requires to run. XenForo doesn't require anything that's particularly out of the ordinary, and certainly nothing considered to be insecure.

However, if you've seen this notice and you subsequently begin to have issues, at least there's now a starting point to begin troubleshooting it.

 

[SamL]

XenForo doesn't require anything that's particularly out of the ordinary, and certainly nothing considered to be insecure.

If that's true, and I believe that it is, then the warning should not be displayed when functions that aren't used by Xenforo are disabled.

We get it, this is clearly an issue of 'inconvenience' to the developers. But it still needs to be addressed just the same. As it stands, the rote answer given any time this comes up is 'enable ALL PHP functions', which just isn't reasonable in many situations.

A PHP function check would be great. Or, if nothing else, publish a list of PHP functions that XF *doesn't* use and therefore can be safely disabled.

 

[euantor]

Or, if nothing else, publish a list of PHP functions that XF *doesn't* use and therefore can be safely disabled.

Do you have any idea how many functions there are within PHP? Not including extensions? Across different versions? Try putting the following in a PHP file and running it:

<?php

echo "<pre>";
print_r(get_defined_functions());

I just tried it on a fairly minimal install in a Vagrant VM. I had 1772 functions available...

If you have a problem with a piece of functionality not working because a function is blocked, you'll be able to tell from your error logs. Simply unblock the function or don't use that functionality.

 

[Chris D]

There's a really simple solution if you're worried to. It has already been suggested but apparently it would be a huge security risk to reveal what functionality has been disabled in your configuration

The offer is still there, let us know what you have disabled, it is a 5 minute job to check it against the XF and ZF source code (the latter is less significant due to the relatively miniscule part of it that is utilised. If you can't or won't do that, get yourself a decent text editor or IDE and search yourself.

 

[euantor]

As a matter of interest, I just wrote a simple script to look for the unique functions in a standard XenForo package. I found 1100 unique functions, though not all will be core PHP functions (the script does not check for that - it simply uses a Regex pattern to see if the text looks like a function call) and some will be false positives (eg: strings that look like function calls such as some RegEx patterns).

The code for the script can be found here: https://gist.github.com/euantorano/8eccd4fb9eeab567de75

Feel free to download and run it yourself. The output looks like the following (which is just a small snippet, obviously):

microtime - found on line 3 of admin.php
dirname - found on line 4 of admin.php
require - found on line 6 of admin.php
set_time_limit - found on line 6 of deferred.php
ignore_user_abort - found on line 7 of deferred.php
array - found on line 24 of deferred.php
header - found on line 26 of deferred.php
json_encode - found on line 32 of deferred.php
empty - found on line 9 of fb_channel.php
str_replace - found on line 11 of fb_channel.php
preg_replace - found on line 12 of fb_channel.php
htmlspecialchars - found on line 21 of fb_channel.php
realpath - found on line 5 of install/index.php
chdir - found on line 6 of install/index.php
class_exists - found on line 2 of install/templates/error.php
count - found on line 8 of install/templates/error.php
list - found on line 9 of install/templates/error.php
submit - found on line 30 of install/templates/install_step2.php
hide - found on line 31 of install/templates/install_step2.php
strval - found on line 4 of install/templates/PAGE_CONTAINER.php

Even in this small snippet there are a few functions that aren't actually PHP functions ("submit()" being one - it's defined within a JavaScript block...) but it's a start. You could easily write a script to see if any of your blocked functions are in the generated list.