From Gallery Codex
Gallery 2 Security
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, ..).
Introduction
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:
- Make sure nobody can read / write to your Gallery 2 files
- Make sure the account has not more rights than it needs to have
- Don't expose more information about your Gallery 2 / G2 version than necessary
- How to identify an insecure webhost
- Miscellaneous security related topics
Contact Information
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 gallery.menalto.com. 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!
Short Check List
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.
- Filesystem permissions of config.php: Make sure no one but you / the webserver can read from (or even write to) the config.php file. Change the permissions of your config.php file with your FTP client to 444 (readable for everyone). Most shared webhosting setups don't allow restricting the permissions more than readable for everyone. In some cases you can restrict it even more. Read on for the details.
- Prevent viewing of your Gallery code: If you already have a file with the name .htaccess in your gallery2/ folder, add the following code (copy and paste) at the top of it. If there is no such file yet, just create it with a text editor. You may have to rename the file via FTP to .htaccess since Windows doesn't like files without a name before the dot that well. The following code should be part of that .htaccess file:
<Files ~ "\.(inc|class)$"> Deny from all </Files>
- Note: The .htaccess instructions only apply to websites hosted on a Apache server (and most are). Also, if you have access to the configuration file of this webserver, you could put those changes directly into httpd.conf instead of into .htaccess.
- Filesystem permissions of the gallery2/ folder: Make sure nobody can write to the gallery2/ directory, not even the webserver user. Change the permissions of your gallery2/ directory with your FTP client to 555 (read+list permission for everyone). In some cases you can restrict it even more. Read on for the details.
- Storage folder location: The storage folder (by default 'g2data/') must not be web-accessible, i.e. it should be outside of the document root.
Learn the Basics about your Webserver
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:
- The account under which all PHP scripts are executed on your website
- The (local) value of the PHP open_basedir setting
- The Server API, whether PHP is run as a Apache / IIS / ... module or as (fast-)cgi
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.
Does PHP run under your own Account or under a Generic Account?
There are basically two different ways PHP scripts can be run on a webserver.
- Either all PHP scripts are run by the same account for all PHP scripts on the webserver. On a shared webhosting plan, PHP scripts of all domains / accounts run under the same generic user.
- Or the webserver differentiates between different accounts / domains. That means that on a shared webost your PHP scripts are run by your user (probably the same as your FTP user account) while PHP scripts of other websites on the same server run under another user. For security, this is much better!
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.
Restricting Read & Write Access to Gallery 2 Files and Directories
In this section, we make sure that:
- nobody can read the contents of your config.php (where your setup password is stored) and that
- nobody can read / write to your g2data (storage) directory.
We need to differentiate three different cases:
a) PHP as mod_php and open_basedir is not set / too open
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?
- Another customer could use PHP to read your config and get your password and do other things with your password.
- And if you left your config.php writable, the other user could write an invalid configuration or the configuration could be changed to use other data to damage you in some way
- Another customer could use PHP to read / write from / to your Gallery 2 storage directory (g2data)
What you can do in such an environment:
- Restrict config.php to 444 (read permissions for everyone)
- Use another password for your G2 admin account than for the setup (the one you entered during the G2 installation)
- Remove the upgrade/ folder since one can access this folder with the setup password, which is stored in config.php
- Also see How do I secure Gallery2
b) PHP as mod_php and open_basedir is set restrictive enough
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.
- Set the permissions of config.php to 444 (read permissions for the owner, group, and public/world)
- Set the permissions of g2data to 777 (read+write+execute permissions for everyone). Apply the permissions recursively (also for all subfolder, files, ...).
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:
- Set the permissions of config.php to 400 (read permissions for the owner, no other permissions)
- Set the permissions of g2data to 700 (read+write+execute permissions for owner, no other permissions). Apply the permissions recursively (also for all subfolder, files, ...).
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.
c) PHP as cgi and scripts run under your user
You are lucky. If PHP is run under your user, we can remove all filesystems for other users.
- Set the permissions of config.php to 400 (read permission for the owner/you, no permissions for anyone else).
- Set the permissions of g2data to 700 (read+write+execute permissions for owner/you, no permissions for anyone else). Apply the permissions recursively (also for all subfolder, files, ...).
- In G2 site admin -> general, set the permissions for new directories to 700 and the permissions for new files to 600.
Restricting the Rights of the Webserver User
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
- Read+Write+Execute for g2data and its subfolders
- Read+Write for all files in g2data and the files in its subfolders
- Read+Execute for gallery2 folder and its subfolders
- Read for all files in gallery2 and the files in its subfolders
- Read+Execute for the binaries and the folder the binaries are in (imagemagick, netpbm, ffmpeg, dcraw, unzip, zip, ...)
- You should also block all access to your storage directory (by default 'g2data/'). Just add the following content in a file called .htaccess in your storage folder:
Deny From All
Don't Expose Information About Your Gallery 2
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.
- In your webserver configuration (httpd.conf / .htaccess for Apache), you can block all access to sourcecode files and file integrity checksum files (MANIFEST).
<Files *.inc> Deny From All </Files> <Files *.class> Deny From All </Files> <Files MANIFEST> Deny From All </Files>
- Remove directory listings on your website. Add the following:
<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.
- Remove README.html from your gallery2 folder
- Lower the PHP error reporting level since PHP Notices / Warnings etc. can expose the absolute filesystem paths and other information. In php.ini (the PHP configuration file), change the error_reporting level to at least:
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 .
How to Identify an Insecure Webhost
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.
How to Configure a Secure Webserver
This is a larger topic and this section just provides a summary of the basics:
- If you're using a dedicated webserver, you can use mod_php. Be sure to use another user for running the webserver than for other processes and give this user only minimal permissions (as described in the above sections)
- If you want to offer shared webhosting, do not use mod_php. Use php-fastcgi + suexec + apache2 + chroot jails to create a secure environment for your customers such a customer can only be harmed by the customer's own scripts and not by anyone else's scripts. Unlike php-cgi, php-fastcgi can be as fast as mod_php and does not increase the load of your system more than mod_php would do. But php-fastcgi might need a little more memory for the overall system compared to mod_php if used in a shared webhosting environment.
- Don't define a crossdomain.xml and if you absolutely need to offer a service for cross-site Flash access, make crossdomain.xml very restrictive. Note that the Macromedia / Adobe Flash plugin had a related vulnerability up to version 8. If you need crossdomain.xml, please ask for advice in the forums how to protect yourself from CSRF.
Multisite / Embedded G2
Securing multisites / embedded G2's can be a little more complicated in some cases. Possible issues:
- PHP open_basedir of embedded G2 / of the multisite does not include the Gallery 2 path.
- Solution: change the open_basedir to include the path too or change the location/path of Gallery 2
- PHP runs under your account and you installed it from one account/domain (multisite -> codebase, embedded G2 -> Gallery 2) and now you access Gallery 2 from the multisite or embedded with another domain/account.
- Solution:
- Multisite: After the initial installation from the codebase, you will never have to access the multisite from the codebase again. Even upgrading is done from the multisite. Thus, just run chown -R multisite_accountName multisite_g2data (replace the name/g2data paths with correct values), that is, just change the owner of g2data and config.php of the multisite to the multisite owner. Also, make sure the codebase is open enough that all multisite users can read the gallery2 files and read+execute the gallery2 folders.
- Embedded G2: You'll need to make sure that both users (G2 standalone domain, Embedded g2 domain) have the necessary permissions described in the last section.
General Remarks
- Use another password for Gallery 2 than for other applications / systems, use another password for your admin user than the one that you specified during the installation
- Make use of the Gallery 2 image firewall. If the g2data directory is not outside the document root (the public_html, html, www, . folder), the image permissions can be worked around by browsing to an image in the g2data directory directly
- Warning: If you add a path to your local upload path list in site admin -> general, then all your Gallery 2 users with add item permission can use add items -> from local server and add files from this local path.
- All Gallery 2 site administrators can do everything in your Gallery 2 installation. Delete all albums with a single click, delete users, etc. Make sure you trust the users that you add to your site administrator group. Generally, we recommend to not add anyone to this group and we even recommend to use another Gallery 2 user acocunt for your everyday tasks / browsing for yourself, similar to how one should not use the linux root user / Windows administrator user for everyday work.
FAQ
What about PHP safe_mode?
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 option.
Also see G2 FAQ: Does G2 work with Safe_Mode?
What is PHP open_basedir?
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.
How can other Customers on the same webhost harm my Gallery 2 installation?
- Malicious customers can use PHP to read/write to your config.php / g2data directory if not properly secured
- Other customers don't even have to be malicious, it suffices that a single PHP script installed by another customer has a security vulnerability and it could be exploited to not only do harm to the other customer's data / website, but to any other website on the same webhost too. Unless the webserver is properly secured.
- Other programming languages can also be used for an attack, it doesn't have to be PHP. Any language that is available on this webhost can be a possible security threat.
- If customers have telnet/ssh access, they can also access and manipulate your data / website, unless you set the permissions correctly / the webserver is properly secured.
What about SELinux?
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.
What about Apache mod_security?
mod_security doesn't work by default with Gallery 2. It needs special configuration, see Known Issues.
What about using symlinks and open_basedir together?
Currently, you can't use symlinks and open_basedir together in Gallery 2. Please see: How to configure open_basedir for G2.
Do I need to delete the install/ and upgrade/ folders after the installation?
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).
What about the Database?
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.
What does web-accessible mean / what is the document root?
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.
01-16-2008, 01:47 PM 
Posts
