Security issue

Jibap

I was customizing my instance (adding a logo in top bar) and i tested the "root" edit in config... and checking url and files access, i found a breach. I am not sure that is good to explain it here, no ?

Karl

Jibap Feel free to explain ...

Jibap

OK.
Since we know the "classic" architecture of Files.Gallery, it is easy to follow the probable path where the basic configuration file and the users configuration file are located if we assume a usual name such as "admin".

Examples on your demo instances :

We can see passwords in these files (non-encrypted, so it's really important to had added this feature but works only in if set in config modal... maybe a way to check it and force it ?)

In second file we can see "root" path, which inform us about the folders hierarchy...

Of course, on your instance, it is not a harm because we know all with docs and blog and public view, it is not the case of all. I checked it on my instance, and it not works because my hosting has added a feature to block php files download.

I think you can't avoid these breach but recommand in docs to check it, and if necessary add an .htaccess file to protect like this :
<FilesMatch "\.php$"> Require all denied (if PHP >2.4) Order deny, allow Deny from all </FilesMatch>
end of course :
Options All -Indexes

Best regards,

Karl

Jibap Actually, this is a bug on my server, nothing to do with Files Gallery. Did you try to access the config.php file on your own website? They won't display or download. You will just see a blank response..

This is not a bug. This is just that I did some things in Nginx and Cloudflare without thinking. I will fix it tomorrow.

Karl

Jibap I checked it on my instance, and it not works because my hosting has added a feature to block php files download.

That's not entirely accurate. Nothing to do with your hosting. PHP files will always render on server, and in the case of config.php, there is no output, so it will just be a white page. That's why it's entirely normal for applications to store configurations in config.php file.

This is because I have setup my server to only execute PHP for index.php (for security reasons), but I forgot that this will cause config.php files to download in browser instead. Silly me. Thanks for reporting!

Karl

Jibap I think you are misunderstanding completely.

Jibap official basic config : https://demo.files.gallery/_files/config/config.php

This is now fixed on my server. It outputs a blank response. This is how it works on ALL servers.

Jibap i used the term "breach" maybe "vulnerability" is a better translation...

As noted, this was something specific to my server only. It's not possible to replicate this on any other server.

Jibap i meant to say "Web hosting company" in place of "hosting", i get this for my own :

Why does it do that though? You mean 403 for files names config.php? It serves no purpose.

Jibap I suggest to add an advice to check it in your install docs. If you forgot it, anybody can

I already responded to this in my last post. It is not possible to access and read config.php on any servers. The screenshot you have from your own host does nothing. You can try to rename your file from config.php to abcd.php and load it in browser. It will not show anything.

Jibap What about my suggest to auto-encrypt the passwords? It would be safer, no? Feasible?

Did you try the new settings editor? It already encrypts passwords when you save. The reason they are not encrypted in the DEMO examples, is because they are public examples, and I wanted the config files to display the passwords non-encrypted. As stated in the config and in the docs (see comment):

return array (
  'password' => 'elixir', // password is required (non-encrypted for demonstration purpose)
);

Karl

Jibap I apologize if you feel my answer seems arrogant, but I don't know how to say it any differently. Your report doesn't apply, because it is based on factors that simply don't apply.

When someone accesses config.php in browser, it will not show any information. It's really not more complicated.

Jibap That said, I still think that if such a "bug" was present on your server, it can be in others, I do not see what prevents it...

This was stupid of me. We can't do much about this, except write somewhere "Remember to not disable PHP execution on config.php files!", but most people won't even understand what that means. I can't imagine anyone will have servers setup like this anyway. By default, for all normal users who haven't messed around with complex stuff on servers (like I did), this will not be an issue.

Jibap <FilesMatch ".php$">

Yes, but it's kinda pointless to spend time adding a fix for an issue that should not exist in the first place. If it did (like in my case), the owner must be aware of it, and would then fix the issue instead of "patching" it with another fix.

PS! For maximum security, you could create the _files dir outside of the servers document_root, so that it's not even accessible from browser.

Thanks for taking the time report, and sorry if I was rude!

Jibap

The language barrier ! 😉

Karl This is not a bug

i used the term "breach" maybe "vulnerability" is a better translation...

Karl nothing to do with Files Gallery.

i said "I think you can't avoid"

Karl Nothing to do with your hosting

i meant to say "Web hosting company" in place of "hosting", i get this for my own :

I suggest to add an advice to check it in your install docs. If you forgot it, anybody can

What about my suggest to auto-encrypt the passwords? It would be safer, no? Feasible?

Jibap

Karl The arrogance of your answers does not encourage me to report a potential security problem again (I understand that you do not consider it as such but yet you have fixed it...). I’m just sharing my observations, maybe my interpretation is wrong but they are not less real.

When you say

Did you try the new settings editor? ... As stated in the config and in the docs (see comment)

, yes since I indicated

(non-encrypted, so it’s really important to had added this feature but works only in if set in config modal)

So I understood your particular situation but my proposal concerns the users of the application, not the demo site.

I believe that do not try to understand my words, always on the defensive while I do not incriminate you in any way, on the contrary I do not cease to praise in my different messages. I think Files.Gallery is excellent, almost enjoyable for a developer like me, I would have found it a shame to let pass a security breach.

An answer like:

Thank you for this return, indeed there is a bug on my server, but rest assured this case is unlikely on others, so there is no real danger and therefore it is unnecessary to specify in the doc. As for your suggestion to encrypt passwords that would not have been defined in the modal config, it’s not a bad idea, I’ll think about it

would have been more humble and pleasant in this cooperation. I posted in the category "Feedback", not "help" or "features", so the goal is to work together and not make a claim.

That said, I still think that if such a "bug" was present on your server, it can be in others, I do not see what prevents it... One is never too careful!

Jibap

Karl We can't do much about this, except write somewhere "Remember to not disable PHP execution on config.php files!"

As we say in French: "it does not eat bread" 👍Maybe to newbies, saying like that :

To be secure, your server in default configuration doesn't allow to access/download php files, you can check it trying access directly by url: https://myfilesgallery/_files/config/config.php"

Karl Yes, but it's kinda pointless to spend time adding a fix for an issue that should not exist in the first place

Of course, it was a suggestion for protection without knowing the exact origin of the error, now that you have explained it to me, there is no need to do this.

Karl PS! For maximum security, you could create the _files dir outside of the servers document_root, so that it's not even accessible from browser.

Good option, i have seen few days ago, it is with "storage_path" setting, right ?

Karl Thanks for taking the time report, and sorry if I was rude!

Your last answer was humble and reconcilies me to contribute to the improvement of Files.Gallery 😉
Thanks

Karl

Jibap Good option, i have seen few days ago, it is with "storage_path" setting, right ?

Correct. In this case however, because we need to know storage_path option before we can load the config.php file (which is in the storage_path), we need to use _filesconfig.php.

Create _filesconfig.php in same dir as index.php.
In_filesconfig.php: return ['storage_path' => '../path/to/your/_files/storage/path'];.

From there on, it will continue to load the rest of the config from within your custom storage page.

Jibap Your last answer was humble and reconcilies me to contribute to the improvement of Files.Gallery

🙏

Jibap

Karl

I found it in docs in the meantime 👍i checked it but unfortunately the custom files can't work in this case because of uinclude() function :

$src = Path::urlpath($path); // get urlpath for public resource
if(!$src) return; // return if storagepath is non-public (not inside document root)

No worries, I will use default storage_path.

I am very careful about security because i would like to use Files.Gallery to manage my webserver (quicker/prettyer than FTP softwares to edit files and accessible from anywhere)...

Karl

Jibap unfortunately the custom files can't work in this case because of uinclude() function :

True that. I guess we could include the CSS via PHP, but I would need to look into that later. Optionally, you can just use _files/include/head.html and add your own custom CSS file reference to load from a public path.

Jibap I am very careful about security because i would like to use Files.Gallery to manage my webserver (quicker/prettyer than FTP softwares to edit files and accessible from anywhere)...

💯 I will write a post about "security" at some point, as it needs to be high priority when using an app like Files.

I also use it in place of FTP, because FTP is terribly slow and impractical for file operations.

Do you use Files Gallery only for yourself? Or do you also have a "public" front? Obviously, it's much easier to protect and secure a Files Gallery installation which should only be accessible for one person.

Jibap

Karl Optionally, you can just use

Great, it works well ! This alternative suits me perfectly.

Karl Do you use Files Gallery only for yourself?

The two, my Files Gallery instance is public for :

tools for me when i am in customer troubleshooting (i find them quickly without auth)
share a file to my customers (like remote control tool) with a simple link (reassuring because on my domain)
sometimes like a WeTransfer to share a file too big for email or share a movie to my family (temporary file in a hidden folder)
present HTML templates to my customers...

and i have a private access to manage my webserver (i use a different root for my user but it is the same instance)

I have two other instances :

my brother which use it to share project files (videos for advertising spot or weddings) to its customers with one user per customer (temporarly during the project)
a local association whose website I created and which needed a collaborative workspace for the management team

With the multi-users feature, it is almost a cloud data service... simple and efficient ! associated with SyncThing app it can be powerfull. More sexy to manage files in a personal NAS too !

Karl

I created security documentation in the link below:
https://www.files.gallery/docs/security/

Jibap

Hey, great, very nice work!

Here's what I did on my end:

moved the instances I had at the root of my WP sites to a folder dedicated to all my instances (prevents the site owner, who doesn't have FTP access, from being able to modify the configuration files thanks to a plugin that allows access to the WP files).
changed the permissions of " _files/config/config.php" to 632 (read-only)
added JS code that prevents modification of the 'root' parameter if it contains ".." or starts with "."
configText.match(/['"]root['"]\s*=>\s*['"]([^'"]+)['"]/);

I think that way I have secured enough...

Karl

Jibap Thanks for the feedback. It's always a good idea to maximize security.

Just to clarify, in case others come across this post:

Jibap changed the permissions of " _files/config/config.php" to 632 (read-only)

That file would only be "vulnerable" in the first place if you have other PHP applications running on the server, that might have access to view or edit PHP files on the file system.

Jibap added JS code that prevents modification of the 'root' parameter if it contains ".." or starts with "."
configText.match(/['"]root['"]\s=>\s'"['"]/);

There is no "root" parameter that gets forwarded by Javascript, because the "root" is always locked from within the PHP app. It can't be "modified" by Javascript. Furthermore, all paths that get sent from Javascript to index.php are strictly validated, to make sure that the path is within the assigned root dir. It's impossible to target a path that is not within the assigned root dir.

Jibap

Karl There is no "root" parameter that gets forwarded by Javascript

Yes of course, i didn't precise : my JS code prevents the edit of root param in settings modal (can be bypassed disabling JS but i think edition will not works in this case ? )

Karl

Jibap Yes of course, i didn't precise : my JS code prevents the edit of root param in settings modal (can be bypassed disabling JS but i think edition will not works in this case ? )

True. As noted in the section below, allow_settings should only be enabled for trusted users (often only yourself), because it allows changing root and creating new users with full permissions to do anything.
https://www.files.gallery/docs/security/#allow_settings-enabled

So in your case, you have allow_settings enabled for users that you don't completely trust? In this case then yes, your Javascript could be used to block certain modifications of the root option. However, if it was a clever "hacker" who had access to a user with allow_settings enabled, they could probably send any POST they want, bypassing Javascript, so the only true security lies within the PHP file.

There is a better way if you simply want to LOCK root to a specific dir. Simply create a file _filesconfig.php alongside index.php, with pre-assigned config options, which will always override anything from user configs.

Of course and as noted, you would only need to worry about this in the first place if you have other users (untrusted users), who you have enabled 'allow_settings' => true for ... else, they wouldn't have permissions to edit it anyway (by ways of PHP). Essentially, this settings should really be exclusive for admin-type users, or users you exclusively trust.

Jibap

Karl There is a better way if you simply want to LOCK root to a specific dir. Simply create a file _filesconfig.php alongside index.php, with pre-assigned config options, which will always override anything from user configs.

I've seen this tip in your security documentation but it is not compatible with multiple users with distincts root folder, right ?

Karl

Jibap I've seen this tip in your security documentation but it is not compatible with multiple users with distincts root folder, right ?

That's correct. It would LOCK the root to a certain value, so it's kinda useless if your users are supposed to have different user root values. As noted, if your users don't have access to allow_settings, there is nothing to worry about because they can't even modify their own root.

I might implement an option root_lock, which can be assigned in _filesconfig.php (for all users), and forces each user root to be within the root_lock dir. For example 'root_lock' => './content', then each and every user root must point to a dir within ./content (or the dir itself). The only problem, is that this might not work with symlinks ... Perhaps root_lock needs to be an array of allowed dirs.