This article explains various security aspects of Gallery 2 and how your webserver / hosting account and Gallery 2 can be secured from possible attacks. This article does not explain the Gallery 2 permission system. This article also focuses on linux/unix based servers. But most instructions can be translated to the Windows world directly. E.g. if we talk about permissions, ignore the numbers (e.g. 777) and just follow the long format (read+write+execute, ..).
Securing Gallery 2 has much to do with securing the webserver. Gallery 2 cannot be secured if the server/webserver is not configured with security in mind.
In this article, we address the following topics:
The Gallery project treats security issues very seriously. If you find a security flaw, please do not file a public bug or discuss it in a public forum. Please escalate it directly to our security team by sending an email to security AT galleryproject.org. Please provide as much information as you can including your version of Gallery2 and a description of the flaw. Supporting material such as server logs or a reproducible exploit are very valuable in helping us to clarify the problem. If you notify us about a flaw before we go public with it, you will receive credit with our security release. You may also be eligible for a cash bounty!
If you don't want to spend a lot of time reading this document now in all detail, you can just check the following list of the most important security related issues. In that case, we still recommend coming back later and reading the full document to make sure you have secured your Gallery as well as possible.
<Files ~ "\.(inc|class)$"> Deny from all </Files>
Whether you have an account on a hosted webserver or have a dedicated webserver, first you need to know the basics about your environment. We are interested in the following settings:
To find out the value of these settings, create a file with the name info.php and with the contents
<?php print "PHP runs under the user: [" . system('whoami') . "]<br>"; phpinfo(); ?>
Put it on the webserver in your gallery2 folder or to the folder where you plan to upload gallery2 to. Then browse to the file with your webbrowser.
There are basically two different ways PHP scripts can be run on a webserver.
If your PHP Server API is Apache or IIS or Module / mod_php, then all PHP scripts on this server are run by a generic user. There's no way to run PHP as webserver module and running under different users. mod_php implies that all scripts on this webserver are run by the same generic user. Most probably info.php shows "nobody", "www" or another generic name which is different from your user / account name between the [] tags.
If your PHP Server API is php-cgi or php-fastcgi, then PHP most likely runs under your user. If the info.php page shows your user / account name between the [], then it definitely runs under your account.
Note: Maybe you don't see anything between [], maybe you even receive a Warning that the function "system" has been disabled.
In this section, we make sure that:
We need to differentiate three different cases:
If your PHP is run as mod_php (generic user for all scripts), then your only hope is that PHP open_basedir (see info.php) is set restrictive enough. PHP open_basedir should be set such that your g2data folder and your gallery2 folder are in this path but no other account should be in the account. If your PHP Server API is Apache and open_basedir is empty (no value), then talk to your webhost, this is a large security risk. There's no way to secure your Gallery 2 (unless you have a dedicated server, that is, a server that is dedicated only for you and no other customer). What could happen in such an environment?
What you can do in such an environment:
Your webserver is not really secure, but a restrictive open_basedir setting is better than nothing. You need to keep the config.php file world / publicly readable. Open_basedir will make sure that only PHP scripts of your account can open files that reside in your account.
Another option is to ask your administrator to change the owner of the config.php file and the g2data directory (recursively) such that the generic webserver user owns these files and directories. (command: chown -R username g2data, this command can only be executed by the root user (administrator)). Why would this improve security? In such a scenario, other customers, couldn't read/write your files anymore from the shell (telnet/ssh). Then, you can restrict the permissions to:
Note: Open_basedir only secures from PHP, but not from other script languages. If Perl or other script languages are also allowed on this webserver, your Gallery 2 is still insecure from attacks from other customers or from vulnerabilities of other web-scripts on this server.
You are lucky. If PHP is run under your user, we can remove all filesystems for other users.
You should also make sure that a possible vulnerability in Gallery 2 cannot escalate further than necessary. Restrict the permissions of the user that runs the websever/PHP scripts as far as possible. E.g. never run the webserver as root :)
The user should not have any other rights than
Deny From All
Gallery 2 was written with security in mind. Nevertheless, security vulnerabilities have already been discovered in Gallery 2 (all known issues are fixed). You should make it as hard as possible for visitors of your site to find out the version of your Gallery 2 since once the attacker knows the version of your Gallery 2, it's clear if the Gallery 2 installation is still vulnerable to older exploits. Say you have the exact version string on your frontpage, then an attacker can just use google to find a list of vulnerable installations, including yours.
<Files *.inc> Deny From All </Files> <Files *.class> Deny From All </Files> <Files MANIFEST> Deny From All </Files>
<Directory YOUR WEBROOT PATH> Options -Indexes </Directory>
You can test whether you are exposed or not by going to modules/. If you can list all of the modules installed on your system, then Apache is listing directories.
error_reporting = E_ALL &~ (E_WARNING | E_NOTICE)
or even
error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR
Notice though that the more errors you suppress the harder it is to diagnose a real problem. Once you experience problems, you should change error_reporting to E_ALL .
A shared webserver that runs all PHP scripts under the same generic user and not under the specific account's user can only be secured in a limited way. All mod_php based webservers/webhosts fall into this category. If you don't see php-cgi or php-fastcgi as Server API in your info.php, your webhost falls into this category
If additionally open_basedir is too open or even not set, we discourage from using Gallery 2 on this server.
Reality check: Most shared webhosting plans fall into the above category and we hear from incidents like a Gallery 2 that was somehow deleted over night only very rarely, maybe once a year. So it isn't as bad as it sounds. The chance being on a webhost with a malicious customer should be really small.
The purpose of this section is just to clarify that your webhost actually may not be as secure as you thought. You should at least ask your webhost to change the situation (asking wouldn't hurt and it would signal a general need for a secure webhosting environment). And if you prefer a truly secure environment, a large percentage of professional webhosting companies at least configure the open_basedir path quite restrictively for each account. And a smaller percentage in the lower to middle price class actually offers php-cgi based webhosting.
This is a larger topic and this section just provides a summary of the basics:
Securing multisites / embedded G2's can be a little more complicated in some cases. Possible issues:
Despite its name, PHP safe_mode doesn't imply a secure environment for PHP scripts. It's much too restrictive disabling functionality that would be quite useful even in a secure environment and PHP extensions and other script languages can still work around the safe_mode protections/limitations. Much has been said about PHP safe_mode and to cut a long story short, even the authors of PHP think offering safe_mode was a failure and PHP safe_mode will be removed in PHP 6, it won't even be available as an option.
Also see G2 FAQ: Does G2 work with Safe_Mode?
See PHP open_basedir . If set restrictive enough, and if only PHP and no other computer language can be used on this server by other users and if no ssh/telnet access is granted to customers, open_basedir is not a bad protection for your Gallery 2 installation from other customers on the same webhost.
Please see How to configure open_basedir for G2.
SELinux doesn't work with Gallery 2 if not configured properly. See Gallery 2 Installation on a SELinux enabled Server for more information. We neither recommend SELinux nor discourage from using it, we merely explain how to install Gallery 2 on a SELinux enabled server.
mod_security doesn't work by default with Gallery 2. It needs special configuration, see Known Issues.
Currently, you can't use symlinks and open_basedir together in Gallery 2. Please see: How to configure open_basedir for G2.
No, these folders don't need to be deleted. But you can delete them, Gallery 2 will still work even when they are deleted. One can access the installer only by creating a login.txt file in the gallery2 folder. Usually, that's just a single person. You can't create / edit login.txt with the webbrowser. You can access the upgrader only with the setup password (which is stored in config.php).
Make sure that only your database user has permissions to connect to your database. Your database user needs quite a lot database permissions, including alter table, drop table, same for index etc. So you can't restrict the permissions of this user really well.
We say a file or a folder is directly web-accessible if other people can access it through a web browser or through other web clients. Example: The gallery2/main.php file of your Gallery is web-accessible, everybody can browse to it.
Another example: The Gallery storage folder (e.g. 'g2data/') potentially has some sensitive data in it. If people can access this data just by browsing to a file within your storage folder, security is compromised. Therefore, for maximum security, you should ensure that your storage folder is not accessible from the web.
You can accomplish this by ensuring that the storage folder is above the web document root. The web document root is the filesystem folder in which all your website files and folders are. Usually the name for that folder is 'htdocs', 'www' or 'public_html'. All files and folders within the document root folder are web-accessible.
Example: '/home/yourusername/public_html/' could be your document root. '/home/yourusername/public_html/gallery/g2data/' is within the document root and therefore web-accessible. '/home/yourusername/g2data' is above the document root and therefore not web-accessible, which is how it's supposed to be for the storage folder.
