Joomla setting cache sub-folders to 777 permissions Topic is solved

[glitterchickUK]

As far as I’m aware my site has not been hacked. This came up as an issue due to another site on my host’s server being hacked or compromised — I don’t know the details — so they ran a sweep for 777 folders, changed them en masse, and then monitored for changes back to 777 or new folders being created as 777. As my cache sub-folders are being recreated with 777 permissions they then contacted me.

If I make the change mentioned in https://github.com/gantry/gantry5/issue ... -421991143 then all cache sub-folders _except_ the gantry5 one are created with 755 permissions. Both Gantry and Joomla seem, to me, to be doing the same thing with regards to permissions on the cache sub-folders.

[mahagr]

Please read the whole discussion on the issue and especially my last comment here: https://github.com/gantry/gantry5/issue ... -422052139

I'm going to copy/paste part of my reply for those who do not want to read the long discussion:

---
First, I'm really sorry if I've sounded blunt on this issue, I've not had enough sleep and rest during the weekend because of being in training and moving my office at the same time for the past few days. I was trying my best to explain the issue, but sometimes things are hard to explain and it does not help to do it in a foreign language and to be tired while you're doing that.

[...]

What comes to using 0755 everywhere (in this context), it is considered a bad practice for multiple reasons.

* It forces you to use specific server setup and restricts administrators choices on how they want to set up their sites -- it also causes compatibility issues on existing setups.
* It is really easy to miss the permission somewhere in your code (Joomla updater), or you happen to use some library (including Joomla Framework), which does not follow the same practice, not to mention potential hazards if you install a new software to your site.
* It hides the real security issues (both in the code and in the server setup) and makes you feel a false sense of security. It does not prevent attacks from being successful, but it may prevent automated tools from locating the bad code, bad configuration or hacked site.

There are other valid points, but I'm way too tired to think about them.

[...]

There is never a perfect solution, most of what we do is full of compromises. It is still important to pick up the lesser bad whenever possible and in this case, it is better to follow well-known practices for multiple reasons which were brought up in this issue. I know it is frustrating as a moderator or support person to deal with issues like this where there is an "obvious" solution to prevent it. But you cannot fix the real issues by hiding them. What if the site uses 0777 permissions because of it got hacked? Or because of someone made a mistake? Would it be better automated tools to detect the issue than allowing the site to stay compromised because it is more convenient to hide the issue? I am not saying that this is what happened, but at least now we know that there is something wrong with the site.

[mahagr]

If I make the change mentioned in https://github.com/gantry/gantry5/issue ... -421991143 then all cache sub-folders _except_ the gantry5 one are created with 755 permissions. Both Gantry and Joomla seem, to me, to be doing the same thing with regards to permissions on the cache sub-folders.

This may happen for example if there is code that is setting a new umask() somewhere in the code. Caching code in Gantry and Joomla are identical (read: using 0777) and should have identical permissions unless there is either a bug or bad code somewhere in your site causing this to happen. Or if Joomla manually creates some of the folders outside the main caching code.

I recommend you to make sure that there is no umask(0) call anywhere on your site.

[glitterchickUK]

If I make the change mentioned in https://github.com/gantry/gantry5/issue ... -421991143 then all cache sub-folders _except_ the gantry5 one are created with 755 permissions. Both Gantry and Joomla seem, to me, to be doing the same thing with regards to permissions on the cache sub-folders.

This may happen for example if there is code that is setting a new umask() somewhere in the code. Caching code in Gantry and Joomla are identical (read: using 0777) and should have identical permissions unless there is either a bug or bad code somewhere in your site causing this to happen. Or if Joomla manually creates some of the folders outside the main caching code.

I recommend you to make sure that there is no umask(0) call anywhere on your site.

I’m sorry, I meant only that I had to make the change mentioned in Github _and_ change the five 0777 entries in four Gantry files in order to get all the permissions to 755. (And it’s entirely possible only one change is needed in the Gantry files but I changed all five anyway.) A lot of this discussion is going over the top of my head I have to say, but appreciate everyone’s input.

[mahagr]

Sorry, I take my comment back. I was tired and lazy and didn't visit the link.

If you fix the Joomla Cache permissions from the code, it only fixes the issue in Joomla cache; you still have the same issue in Gantry and when dealing with images in Joomla (I didn't read when exactly it can happen). It just hides the issue in your site until the call is made somewhere else.

Please try what Michael Babker suggested in later comment: Add umask(022); call and see what happens. If you add it to the index.php, you should have correct permissions in all the files.

But please do not think that it solved your issue; you really need to find out what is causing it.

[Webdongle]

As far as I’m aware my site has not been hacked. This came up as an issue due to another site on my host’s server being hacked or compromised — I don’t know the details — ...

If one of your sites was hacked on the server and this site is on the same server (part of your Hosting package with same ftp login then chances are that there are hack files hidden in this site as well.

[mahagr]

I am not convinced yet that this site has been hacked, but we will know better when I get reply if adding umask(022); (nothing more) into the beginning of the index.php file fixes the issue or not. Just remember to revert all other file changes as they will mess up the test.

If adding umask() fixes the issue, I bet that there is an issue with PHP configuration, but if not, it is a clear indication of the site being hacked. I hope it is the first one.

EDIT: Even with the second case, it CAN also be a bug in somewhere, but I find it unlikely that anyone would set umask(0) in their code and stay undetected as THAT is a security issue.

[glitterchickUK]

My host has responded with the following:

“Our server's Umask would force the default creation to be 770; based on the advice they were providing lead me to scanning the site and both;

/libraries/src/Application/DaemonApplication.php:

and

/libraries/vendor/joomla/application/src/AbstractDaemonApplication.php

Explicitly reset the umask which would be how those files are able to be set to 777. So it would be worthwhile looking at these also.”

This is in response to the comments in: https://github.com/gantry/gantry5/issue ... t-42199155

("If what you're getting from that snippet is acceptable yet the cache directories are still created with 0777 permissions, that tells me that something is calling umask(0) and you need to scan your install to find it.")

I will just reset the changes I’ve made so far and try the request for umask(022) in a previous comment.

[mahagr]

@glitterchickUK Your response indicates that this may be a configuration issue because of Joomla creates folders by default using 0755, which becomes 0750 which WILL cause trouble in your setup. I bet that someone was trying to fix the issues with file permissions by changing the umask settings and that is causing all your trouble.

[Webdongle]

But even so ... if the default folder Permissions has been altered and then gets fixed ... there is still the issue of a site on the same server being hacked. The whole server could have hack files all over the place.

[mahagr]

Yes, we cannot rule anything out yet, I'm just trying to find all the possibilities.

One thing I'm pretty sure of (without looking into the code): DaemonApplication is likely not to be blamed as I'm pretty sure we wouldn't be the first ones to hear about it.

[glitterchickUK]

I’ve created a temporary PHP file with just the following:

Code: Select all

<?php
echo 'Current umask is: ' . decoct(umask(0022)) . PHP_EOL;
?>

This returns:
Current umask is: 0

[mahagr]

This returns:
Current umask is: 0

The issue is in PHP configuration. Please contact your hosting and tell them what you did to get this result.

Just to confirm: can you edit index.php file in your site root folder and add: umask(022); after <?php (next line). Then clear the cache and see what permissions the new folders will use. I bet it is 0755, am I right?

[glitterchickUK]

This returns:
Current umask is: 0

The issue is in PHP configuration. Please contact your hosting and tell them what you did to get this result.

Just to confirm: can you edit index.php file in your site root folder and add: umask(022); after <?php (next line). Then clear the cache and see what permissions the new folders will use. I bet it is 0755, am I right?

I was just looking to see if anyone had explained where exactly to put that snippet. I’ve removed all of my changes and verified the cache subfolders are being created as 777 again. After adding in that code snippet, clearing the cache again and then loading the site... the sub-folders all have 755 permissions.

If my host are unable to change their server configuration is it OK to leave that snippet there or will there still be folder permissions elsewhere? (Edit: I realise I’ll need to redo it after every update.)

[glitterchickUK]

As far as I’m aware my site has not been hacked. This came up as an issue due to another site on my host’s server being hacked or compromised — I don’t know the details — ...

If one of your sites was hacked on the server and this site is on the same server (part of your Hosting package with same ftp login then chances are that there are hack files hidden in this site as well.

I have no access at all to whichever site it was that was hacked/compromised. I have no idea at all what site it was, I just know I haven’t been told my domain has been compromised or hacked.

[mahagr]

There is something badly wrong in your server. I would not work around this issue and forget about it. There is a chance that the server itself is compromised or that there is extra PHP configuration file (or .htaccess file) in your own site which is changing the server setting. In either way, you and your hosting really need to find out the cause and fix it.

[mahagr]

Just a side note, can the person who reported vulnerability on Gantry, please, please, please take back the VEL report here: https://vel.joomla.org/vel-blog/2185-ga ... 4-26-other

I have really done much more than I would expect anyone to do to solve an issue which is not caused by me or a product which was made by me. It really hurts us to have a bad press like this without any valid reason.

We have already proved that the issue is not restricted to Gantry, but happens to all Joomla cache folders. And we have tracked down the issue to the server. We also have a confirmation from Joomla core team member (Michael) that it is not a bug in Joomla or Gantry.

[glitterchickUK]

There is something badly wrong in your server. I would not work around this issue and forget about it. There is a chance that the server itself is compromised or that there is extra PHP configuration file (or .htaccess file) in your own site which is changing the server setting. In either way, you and your hosting really need to find out the cause and fix it.

I’ve checked the .htaccess file I can see and it seems fine to me. Likewise with PHP.ini though I’m not really familiar with those at all.

I’ve passed back the results of the tests you asked me to do to my host, so will take it from there. I really appreciate you and everyone else trying to solve this.

[Webdongle]

"We have already proved that the issue is not restricted to Gantry"
Yes for this issue but Manville proved there is a problem with Gantry ... although that is a separate issue.

This issue is looking more and more like a hacked server.

[mahagr]

Yes for this issue but Manville proved there is a problem with Gantry ... although that is a separate issue.

If you mean this:

Code: Select all

$success &= @mkdir($dst, 0777, true); 

It is the correct way to implement the method, see what Michael is saying about it, multiple times in the issue. In fact, Joomla breaks against the established practices and recommendations in Folder::mkdir(), though I understand that it is hard to change API that has been there forever. I think that Folder::mkdir() is also the source of the common misconception about how the method is supposed to work as it is dangerous to try to do the same with Joomla API -- you will end up having world writable folders.

Oh Sozzled, I know you are there (Hi!), but I was talking about the other Michael. So I'm not trying to put words to your mouth.

[sozzled]

@ Matias

[glitterchickUK]

My host have made some kind of change at their end. I’ve removed all of the fixes/changes mentioned here which I was able to do, and the cache sub-folders are now being created as 755.

Thank you everyone for your help and advice!

(For those curious, the umask snippet now returns 22.)

[mahagr]

I am happy for you that your issue got fixed and I'm sorry that you got into middle of this.