Issue between Permissions of “Mission Critical” Files and SiteGround’s New “Site Tools”

[Living Miracles]

Hello,

We’ve been in communication with our web hosting provider (SiteGround) about different issues we’ve been encountering with their new system/interface, called “Site Tools,” that has replaced cPanel. One of the issues that have been discovered is that there is a conflict with their new system due to our websites’ “Mission Critical” files “having permissions that are incorrect and too restrictive.” We’ve been using the “File Lock” page in the back-end of each of our websites to lock the first four files to increase the security based on your documentation in those “Read Me” buttons. However, for our websites to work properly with all aspects of their new system, it requires that those files are “unlocked” by being set to a permission of 644.

One of the questions I asked them was why Site Tools requires insecure permissions (i.e., 644) for those “Mission Critical”/root files. Part of their answer to this was:

The permissions are in no way insecure. Those permissions only allow the owner of those files to write to them and others to read them. These permissions are completely safe as they don’t allow any writing to be done to the files by external sources, other than the user owning them. They are required to be 644 as they need to be read by our internal systems.

I also reminded them that we were using the BulletProof Security Pro plugin across all our WordPress sites and the reason we set the permission to 400 or 404 for these “Mission Critical” files is because it is urged to do so in your documentation for a Web Hosts Server API that is CGI:

Why Lock Mission Critical Files?
Hackers specifically target these files in Mass Code Injection attacks on web hosts. This is done by exploiting the Group Permissions on files located in Root folders for hosts that use CGI. By locking these files with Read Only 400 and 404 permissions the Group Permissions are removed and these files are protected against Mass Code Injection attacks.

Their response to this was:

All files under the account are executed with the USER/GROUP that owns them (when executed via web) so there’s no need for such strict measures. Each site/account has its own user and group and is isolated from other sites which makes those kinds of methods obsolete.

The permissions are restrictive enough so that an outside source cannot exploit them. The permissions themselves won’t allow infection but do keep in mind we cannot guarantee anything as you are running software that may contain bugs, extensions that may contain exploits. In simple terms, these permissions don’t allow exploitation simply based on them.

We would be grateful to hear what you have to say about their responses. Are they correct and/or do you agree with what they’ve shared, and do you feel it is safe for us to have the permissions of these files set to 644 across our WordPress sites indefinitely?

From our perspective, we felt our web hosting provider was essentially asking us to greatly compromise the security of our websites with this requirement for the permission of those files to be set to 644. Therefore, we’d like to get clear with you if that’s actually the case or not here.

Thank you,
Living Miracles

[AITpro Admin]

I am currently in the process of phasing out F-Lock as far as the default file locking settings go.  Your host is correct that locking these files is unnecessary:  wp-config.php, wp-blog-header.php and the index.php file.  Personally I feel it is a good idea to lock the Root htaccess file, not for security reasons and instead to prevent problems.  A lot of plugins write to the Root htaccess file and create problems by adding the standard WP Rewrite htaccess code at the bottom of the Root htaccess file.  So by default these files will no longer be locked in BPS Pro 14.9:  wp-config.php, wp-blog-header.php and the index.php file.  The Root htaccess file lock will remain optional and recommended to prevent problems and not for security reasons.  So go ahead and unlock the files that do not need to be locked.  This will be done automatically during the BPS Pro upgrade to 14.9.

[AITpro Admin]

File locking was done in the very first version of BPS Pro 9 years ago and the only reason I added it is because a lot of people requested that feature.  Yeah bad idea minus locking the Root htaccess file to prevent problems.   😉

[Living Miracles]

Oh, wow. Okay, we weren’t expecting that would be your response, but we appreciate your answer and the context you’ve shared so far.

In this case, can you share exactly why locking these files is unnecessary? Is the reason because “Mass Code Injection attacks” are no longer a concern or issue? Also, we’re curious as to why you feel this security feature was a “bad idea”?

In addition, do you know if there is any way we can know now whether we will run into the possible issue you’ve mentioned of plugins writing to the Root .htaccess file and creating problems since we may not be able to lock this file either with SiteGround’s new system? Is there anything we can do to prevent that without needing to lock that file?

Thank you,
Living Miracles

[AITpro Admin]

I’ll start with this – any time I have added a feature or feature enhancement just because people asked for it I have regretted it.  I stopped doing that years ago.  😉  Some people have made good suggestions over the years for things that have actually improved things in BPS Pro.  The difference is that I researched and tested those ideas vs just adding them because someone asked for it.

To be honest I can’t remember where the phrase “Mass Code Injection attacks” came from that is in the Read Me help text.  Typically that phrase is used when referring to mass SQL Injection attacks vs any sort of file attack such as LFI or RFI file attacks.

Well what happens if you have AutoRestore turned On is that if a plugin adds htaccess code in the Root htaccess file it gets quarantined.  So basically a real problem is prevented.  You just have to delete the quarantined Root htaccess file, which is kind of a nuisance issue.

[Living Miracles]

Okay, thank you.

So to confirm, you’re essentially saying the “Mass Code Injection attacks” that is referred to in the “Read Me” help text is not something we need to be concerned about, at least anymore or maybe we never needed to, and it really is safe for all our websites to not have those “Mission Critical” files locked anymore, right?

[AITpro Admin]

Yep, correct.

[Living Miracles]

Okay, great. Thank you for confirming that for us! With that, this forum post feels complete for us.

Thank you,
Living Miracles

[Author]

Posts