4.9.0 PHP fatal error: Call to undefined function get_home_path()

@galbaras

Including the file before authentication is probably a security risk …

According to comments included in the beginning of the file:

Functions for reading, writing, modifying, and deleting files on the file system.

dwinden

@dwinden, I get your point, although I wonder if the whole ITSEC_Lib_Config_File class is even included, let alone used, before verifying that the code is being executed after authentication.

Either way, if the WordPress loader hasn’t already defined all the functions by that point, we can declare only what we need by copying it into the file. get_home_path(), regrettably, uses set_url_scheme(), which is defined in wp-includes/link-template.php, which in turn uses force_ssl_admin(), defined in wp-includes/functions.php().

Your get it, right?

I guess a watered-down version of get_home_path(), which ISN’T called the same name, can be used instead. Some thing like:

private function itsec_get_home_path() {
	$home    = get_option( 'home' ); // Skip set_url_scheme
	$siteurl = get_option( 'siteurl' );  // Skip set_url_scheme
	if ( ! empty( $home ) && 0 !== strcasecmp( $home, $siteurl ) ) {
		$wp_path_rel_to_home = str_ireplace( $home, '', $siteurl ); /* $siteurl - $home */
		$pos = strripos( str_replace( '\\', '/', $_SERVER['SCRIPT_FILENAME'] ), trailingslashit( $wp_path_rel_to_home ) );
		$home_path = substr( $_SERVER['SCRIPT_FILENAME'], 0, $pos );
		$home_path = trailingslashit( $home_path );
	} else {
		$home_path = ABSPATH;
	}

	return str_replace( '\\', '/', $home_path );
}

And then, we change line 687 to this:

$home_path = self::itsec_get_home_path();

@galbaras

I was already afraid there would also be additional dependencies … ??

Using a more or less similar itsec function is a good idea.

Though I would add some conditional logic that would decide between using the itsec version of the function or the WP get_home_path() function.
Something like if authenticated use get_home_path() else use itsec_get_home_path(). I’m sure you’ll be able to see the benefits of such approach.

For most WP envs I think there is a simpler solution. I always prefer the simplest solution as it potentially has less impact.

I wondered why iThemes included that get_home_path() function and having looked at what the get_home_path() function exactly does I think I found the answer …

When installing WP there are basically 2 possible scenario’s.

• Install WP in the public_html (home) folder.
• Install WP in a subfolder.

However there is a third scenario. Let’s call it the hybrid …
It’s basically a variant of the second scenario.
For more details there is more info available here.

The difference between the first 2 scenario’s and the 3rd one is that in the first 2 scenario’s the Site Address and the WordPress Address URLs are identical.

So in the first 2 scenario’s using ABSPATH for the .htaccess location is fine.

It turns out the get_home_path() function takes care of the 3rd scenario.
Using ABSPATH in the 3rd scenario would return an incorrect .htaccess file location. The get_home_path() function seems to fix that.
So as long as you don’t customize your WP install you don’t need the get_home_path() function.

So simply change the relevant code in the get_server_config_file_path() function in the class-itsec-lib-config-file.php to what it was in the previous release (4.8.0):

//$home_path = get_home_path();
//$file_path = $home_path . $file;
$file_path = ABSPATH . $file;
//or
//$file_path = str_replace( '\\', '/', ABSPATH ) . $file;

For those who run a hybrid WP install you can use galbaras code until iThemes provides a proper bugfix.

Please note none of the above is tested (as far as I know at this point in time).

dwinden

I’m not getting any more errors.

Additional info.
This bug was introduced because of the following “fix” as described in the 4.9.0 Changelog:

Bug Fix: Fixed issues related to locating .htaccess or nginx.conf files on sites with WordPress installed in a separate directory.

dwinden

Just received an email from the www.remarpro.com repository announcing the iTSec plugin 5.0.0 release …
Even though the changelog only mentions:

* New Feature: Added malware scanning provided by Sucuri SiteCheck.

I noticed the following line of code is added to the get_server_config_file_path() method:

require_once( ABSPATH . 'wp-admin/includes/file.php' );

iThemes seems to be going for the easy and sneaky way … why am I not surprised …
So based on galbaras feedback in post #18 it looks like the 5.0.0 release is NOT going to fix this bug …

The iTSec plugin 5.0.0 release is not yet available for download from the www.remarpro.com site at the time of writing this post so please wait for confirmation.

Read more info about Malware Scanning in the latest iThemes Security (Pro) release here.

dwinden

I see a 5.0.1 is available already. It only describes the change as:

Compatibility Fix: Added support for ITSEC_TEST_MALWARE_SCAN_DISABLE_SSLVERIFY. Setting it to true can bypass “SSL peer certificate or SSH remote key was not OK” errors on servers with bad SSL configurations.

For now I will not try the patch myself but I may if there is no update for this issue soon.

Bruce

Hi All,

The fix for the Fatal Error regarding get_home_path() was released in 5.0.

Can one of the OPs confirm this is no longer an issue for them?

The define( 'ITSEC_TEST_MALWARE_SCAN_DISABLE_SSLVERIFY', true ); is unrelated.

Thanks!

Gerroald

Please totally ignore post #22. It is incorrect.

After testing I can confirm this bug is indeed fixed in the 5.0.1 release.

It turns out the dependencies as mentioned by galbaras in post #18 are met before authentication.

Still wonder whether including the file.php file (WordPress Administration File API) before authentication is a security risk…

Also, why is the bugfix not mentioned in the changelog ?

dwinden

@galbaras post #18

It turns out the iTSec plugin already has its own get_home_path() ITSEC_Lib class method defined in the class-itsec-lib.php file …
It contains a slight code variation which probably makes it even a better method than the WP original …

So all that needs to happen to fix this bug properly is:

//require_once( ABSPATH . 'wp-admin/includes/file.php' );

//$home_path = get_home_path();
$home_path = ITSEC_Lib::get_home_path();

No need to include anything as the class-itsec-lib.php file is already included … Tested the above code and I can confirm it fixes this bug.

The ITSEC_Lib::get_home_path() method is currently actively being used in the File Change Detection feature only.

dwinden

Yep, looks good. Nicely done, @dwinden.

@gerroald, if you’re reading this, a quick patch will be appreciated.