Random Image
Your security questions, answered
Submitted by bharat on Tue, 2003-02-11 04:51
Recently there was a post on BugTraq, a well known security mailing list that referred to a security hole in Gallery. You should read the post yourself, but the specific issue that the poster was refers to is the fact that on a shared webserver it's possible for other webserver users (ie, other customers of your ISP) to read and write your data files. In this article, I'm going to discuss in detail the problem, explain why this is not a Gallery specific issue, help you to understand if you're at risk, and outline the steps that you can take to increase your security.While the bugtraq post is technically correct, it inaccurately portrays Gallery as having a large gaping security hole that we could fix. The truth is that this is not a problem that can be solved by changing code in Gallery. This problem exists with any content management application on a shared webserver with a weak security policy. This includes all the popular content management systems, bloggers, media management tools, database tools, etc. I'm not going to name names, since I don't want to promote the atmosphere of ill-advised finger pointing. However, it's fair to say that if your webserver is managing data for you via a web interface and your ISP hasn't taken specific steps to prevent it, a malicious user can interfere with your data files.
Some might ask, "Wouldn't we have more security if Gallery used a database instead of flat files?" No. Even if you use a database (as many apps do), you must store your database username and password in a configuration file. On servers with poor security models, a malicious user can read that configuration file and then gain access to read and write to your database.
Let me stress again, this is not a problem that can be fixed by changing the Gallery code. This is a problem with the way that ISPs configure their web server. We are well aware of this issue and have done what we can to minimize it. However, the problem lies entirely under the control of the webserver administrator. If you're on a shared server with a poor security model, the only truly secure solution is to not use any tools that manage your data for you. Kiss those community management tools goodbye - they're all vulnerable.
Say you're with an ISP and using a shared webserver. By shared we mean that the server that delivers your web pages is also used by other folks to deliver their web pages. Even if you have your own domain, if you're on an ISP then unless you paid for the dedicated server option you're almost definitely in this situation. You have an account (let's call it "jdoe") and you log in and create files. These files are owned by you, and you can change them so that nobody else can read them. However, the webserver runs as a different user. Just like you have your account, the webserver has its own account (sometimes they use the account "www" or "nobody" for this purpose). So as your ISP may tell you, any HTML pages that you create to publish have to be readable by this user, otherwise the webserver won't be able to read your files and send them to a web browser. Now the problem occurs when you try to store data using the web interface. You're actually asking the webserver to write some files to the filesystem (or save data in the database) on your behalf. So any files that the webserver wants to write must be set so that they are actually writeable by the webserver user. This means that they wind up being owned by the "www" user, not by you the "jdoe" user. You can see where this is leading -- unless your ISP has taken specific steps to block it, anybody who has the ability to install scripts on the web server can run code as the "www" user allowing them to read and write to your sensitive files. Now all of a sudden, your files are vulnerable to attack.
At this point, some folks will ask "won't PHP's safe-mode solve this problem?" Yes, provided your ISP doesn't give malicious users any other way to get at the files (like CGI scripting). Turning on Safe Mode in PHP but allowing CGI access is like triple-locking the front door but leaving the side window open. It creates the illusion of security but is in fact just a hassle for regular users. Sadly, I see many ISPs that go this route, perhaps because it's a very easy security policy to implement.
So I've mentioned poor security model above and given you an example of a weak (but sadly very standard) configuration. There are two ways to thoroughly fix this problem.
If your ISP uses one of the above models, your data files are suddenly secure (without having to change a line of code in your favorite content management system). If they don't, other users of your server can get at your files and cause all kinds of mischief. If you are unsure whether or not your ISP provides the above functionality to you, you should send them an email and ask them. Send them a pointer to this article and ask them if they can tell you what security model they use. If they use a weak policy, ask them to upgrade their security. If they won't, then consider using a different ISP, consider upgrading to a dedicated server, or be prepared for the possibility that someday somebody may tinker with your files and cause you some pain and suffering.
Some might ask, "Wouldn't we have more security if Gallery used a database instead of flat files?" No. Even if you use a database (as many apps do), you must store your database username and password in a configuration file. On servers with poor security models, a malicious user can read that configuration file and then gain access to read and write to your database.
Let me stress again, this is not a problem that can be fixed by changing the Gallery code. This is a problem with the way that ISPs configure their web server. We are well aware of this issue and have done what we can to minimize it. However, the problem lies entirely under the control of the webserver administrator. If you're on a shared server with a poor security model, the only truly secure solution is to not use any tools that manage your data for you. Kiss those community management tools goodbye - they're all vulnerable.
Say you're with an ISP and using a shared webserver. By shared we mean that the server that delivers your web pages is also used by other folks to deliver their web pages. Even if you have your own domain, if you're on an ISP then unless you paid for the dedicated server option you're almost definitely in this situation. You have an account (let's call it "jdoe") and you log in and create files. These files are owned by you, and you can change them so that nobody else can read them. However, the webserver runs as a different user. Just like you have your account, the webserver has its own account (sometimes they use the account "www" or "nobody" for this purpose). So as your ISP may tell you, any HTML pages that you create to publish have to be readable by this user, otherwise the webserver won't be able to read your files and send them to a web browser. Now the problem occurs when you try to store data using the web interface. You're actually asking the webserver to write some files to the filesystem (or save data in the database) on your behalf. So any files that the webserver wants to write must be set so that they are actually writeable by the webserver user. This means that they wind up being owned by the "www" user, not by you the "jdoe" user. You can see where this is leading -- unless your ISP has taken specific steps to block it, anybody who has the ability to install scripts on the web server can run code as the "www" user allowing them to read and write to your sensitive files. Now all of a sudden, your files are vulnerable to attack.
At this point, some folks will ask "won't PHP's safe-mode solve this problem?" Yes, provided your ISP doesn't give malicious users any other way to get at the files (like CGI scripting). Turning on Safe Mode in PHP but allowing CGI access is like triple-locking the front door but leaving the side window open. It creates the illusion of security but is in fact just a hassle for regular users. Sadly, I see many ISPs that go this route, perhaps because it's a very easy security policy to implement.
So I've mentioned poor security model above and given you an example of a weak (but sadly very standard) configuration. There are two ways to thoroughly fix this problem.
- Use PHP in CGI mode and use suEXEC. suEXEC is an Apache configuration that allows PHP to run as you (user "jdoe") instead of the webserver (user "www"). This is good because now all of a sudden all your files are owned by you and not a shared user so you can lock them down tight and not worry about security problems.
- Use a chroot jail. A chroot jail is a mechanism for compartmentalizing a shared server. Each user gets their own tiny "jail" that has all the amenities that a regular server would have, except that they can't see or touch other users files. This can be tricky to configure correctly, but if done properly can lead to an environment where you not only can't touch another user's files, you can't even tell if they exist or not.
If your ISP uses one of the above models, your data files are suddenly secure (without having to change a line of code in your favorite content management system). If they don't, other users of your server can get at your files and cause all kinds of mischief. If you are unsure whether or not your ISP provides the above functionality to you, you should send them an email and ask them. Send them a pointer to this article and ask them if they can tell you what security model they use. If they use a weak policy, ask them to upgrade their security. If they won't, then consider using a different ISP, consider upgrading to a dedicated server, or be prepared for the possibility that someday somebody may tinker with your files and cause you some pain and suffering.
Very informative, thanks!
A most excelent summation of a problem that I have seen on almost EVERY webserver I have ever encountered.
Bharat,<br />
Instead of just condeming hosting providers, why don't you provide some links to hosting providers that meet your narrow security requirements. <br />
I and many others can't afford the hundreds of dollars that dedicated servers cost and have to deal with being hosted along with other accounts on a server. <br />
I have left your user base for the reason that your scripts create directories that I can't manipulate and have found other scripts, that while they are not quite so polished, don't have the problems that your script creates. <br />
Instead of condeming us to a rock and a hard place how about providing us with some way that these directories can be chowned as they are created back to the user so that we can continue to use your software effectively while we deal with our hosting providers about their security arrangements.
I agree that it is a good idea to post links to hosting providers that an appropriate level of security. I'm working on that (but it takes time, which I don't have a lot of). Perhaps other folks out there could help out in that regard.<br />
<br />
I understand your frustration in dealing with Gallery. However, what you've got to understand is that with the current Apache/PHP model it's currently not possible for me to provide a way for you to chown your directories back to the user and still allow Gallery to manage your images without opening you up to an even *larger* security hole. <br />
<br />
If we chown the files back to you, the user, then the modes on the files have to be set so that they are *world writeable* in order for Apache/PHP (acting on behalf of Gallery) to manage them. This is an even worse situation, security wise, since now an attacker can get to your files even on servers that deny CGI and use open_basedir restrictions. <br />
<br />
Right now, there is simply no solution but to get your ISP to beef up their security. If anybody can demonstrate a flaw in this logic, I'm open to any new ideas.<br />
If you CAN NOT chown the files because of the security issues THE YOU MUST INCLUDE AN UN-INSTALL SCRIPT SO THAT THOSE OF US THAT WOULD LOVE TO USE YOUR SOFTWARE CAN USE IT AND THEN GET RID OF IT WITHOUT INVOLVING THE SYSADMINS. maybe then you will stop the growing effort to ban your software and the sucking sound as people leave your user base. If and when you include this functionality in your new version please tell me and I will again consider your software.
We DO provide such a script. It's called the "cleanup" script and it's been available in the user guide for over a year now.<br />
<br />
Anybody who asks on the forums about this problem gets a pointer to this script so it's all over the forums if you search for this problem. What more can we do?<br />
<br />
Two things:<br />
<br />
1. We provide a cleanup script that makes it easy to change the modes on your files so you can delete them. It's in the user guide. It's been there for over a year. <br />
<br />
2. You say: <i>You claim that its is the service providers fault that the files can be read when it is your software that makes the files and directories owned by the web server and not the user.</i>.<br />
<br />
Again, you don't understand how this model works. Gallery is a PHP script that runs inside Apache. So it's <b>Apache</b> creating the files and <b>WE DON'T OWN APACHE, YOUR ISP DOES</b>.<br />
<br />
I'm sorry if you're unhappy with Gallery. But as yet, I have not heard a solution that allows web-based file management that does not have this problem. If you, or anybody else, has a <b>solution</b> for this problem then we're all ears.<br />
I've seen some serious bitching in here and just want to chime in with something more positive. I really like gallery and the interface. It's simple to configure and then to teach others to use after I have set it up for them.<br />
<br />
I also appreciate the notice about security and will investigate the state of affiars on my hosting site.<br />
<br />
Best regards and don't let the ALL CAPS LOVERS get you down!<br />
<br />
-p<br />
Thank you for posting this, you have saved me some potiential headaches and nightmares from my content management systems I am using and creating. Gallery is an excellent piece of software, and I have used it with quite a bit of success.
One way to lock down Gallery is to run php-cgiwrap. Pair.com (my hosting site, they've been excellent) offers this. You can configure your own server by following <a href="http://gallery.menalto.com/modules.php?op=modload&name=GalleryFAQ&file=index&myfaq=yes&id_cat=2">these </a> instructions. Unfortunately I haven't been able to get Gallery to work like this out of the box with php-cgiwrap, however as soon as I get it figured out, I'll post here to let you know.
As to the people that are complaining that once they have installed Gallery, they can't remove it by themselves, all that you need to do run "sh configure.sh" or manually alter the file permisions through telnet or ftp. Then you can delete the folder normally.
I was hosted by Liquidweb.com, who are really a good host. I had a gallery crash (dat files became corrupted after the locking files failed.) Luckily I had just done a complete site backup 2 days prior. The problem that I had now was that the tar.gz file was 350megs, and the site was 350megs. I had to gunzip first before I could untar. This caused my disk quota to go over so I asked the admin to gunzip it to a temp directory and then untar over my site. The first thing he said was, I see you are running gallery. This is against our TOS. He said that gallery runs more than 15% CPU processes (which is BS) and he said that he didn't want me to have the netpbm files either. You either delete your gallery, or you will lose your account. I said.........C ya. Moved over to my friends server, guy that lives down the street. We know everyone that is on the server, and he told me I can run whatever I want
<br />
So guess that security and cpu processes are a thing of the past...........I guess I just got lucky that liquid web.com gave me a hassle, since I am on a controlled (by us) enviroment.<br />
<br />
As far as controlling gallery nobody files......peice of cake with the cleanup script. In fact the cleanup script is so good, that I use it on other files that get created that way by other scripts...... been looking a script like that for awhile after I was threatened by another ISP for running shell.cgi (formerly called nobody.cgi)<br />
I was hosted by Liquidweb.com, who are really a good host. I had a gallery crash (dat files became corrupted after the locking files failed.) Luckily I had just done a complete site backup 2 days prior. The problem that I had now was that the tar.gz file was 350megs, and the site was 350megs. I had to gunzip first before I could untar. This caused my disk quota to go over so I asked the admin to gunzip it to a temp directory and then untar over my site. The first thing he said was, I see you are running gallery. This is against our TOS. He said that gallery runs more than 15% CPU processes (which is BS) and he said that he didn't want me to have the netpbm files either. You either delete your gallery, or you will lose your account. I said.........C ya. Moved over to my friends server, guy that lives down the street. We know everyone that is on the server, and he told me I can run whatever I want
<br />
So guess that security and cpu processes are a thing of the past...........I guess I just got lucky that liquid web.com gave me a hassle, since I am on a controlled (by us) enviroment.<br />
<br />
As far as controlling gallery nobody files......peice of cake with the cleanup script. In fact the cleanup script is so good, that I use it on other files that get created that way by other scripts...... been looking a script like that for awhile after I was threatened by another ISP for running shell.cgi (formerly called nobody.cgi)<br />
Bharat,<br />
<br />
Thanks for this long and informative piece. Also you are much more congenial to some of those who posted above then they deserve. The behave as if you charged them $500 for software that they are unhappy with. File cleanup issues? Why would you ever need to uninstall such a great program???
<br />
For the record Armorama.com has had over 6000 plus images online for over several months now with little or no problems. <br />
<br />
I eagerly await G2!<br />
<br />
Jim<br />
Webmaster/Armorama.com
I forgot to mention in my above post, that even though I have had my fair share of problems with Gallery, I still think that gallery is fantastic. It has a great team, it is FREE, has a great interface, and is one of the driving traffic features of my website. I am very much looking forward to G2 with mysql support. I say to all the complainers, go buy yourself a commercial high dollar script if you are unhappy with gallery.
Sorry for this cross post but it's the only place i can send a message.<br />
<br />
First. i cannot find the random photo block for nuke. I see it all over other nuke sites but not for download. can someone point me in the right direction for this? <br />
Also, my gallery pages display an error at the bottom.<br />
<br />
Warning: (null)() [ref.outcontrol]: output handler 'ob_gzhandler' cannot be used twice in Unknown on line 0<br />
<br />
i am using gallery 1.33, and nuke 6.0 with fixes<br />
<br />
tnx for any help,<br />
leon<br />
<br />
Ask this stuff in the forum.
I second that!!<br />
<br />
There is no reason for general tone of some of the messages/flames in this thread. If large amounts of money had changed hands then things may be different.<br />
<br />
People should realise that Bharat and team give up significant amounts of their time FREE OF CHARGE (oops, sorry, must stop that capital letters thing) to develop high quality software products. If they receive this level of abuse, they may change their minds; then we'll all have to pay mega bucks.<br />
<br />
If people feel that they can write a better software product, then do so! Alternatively, why not invest some of your own time to work out how the software can be improved and submit patches for the common good of the project.<br />
<br />
Bharat, please do not give up heart. You're doing a brilliant job!<br />
<br />
Britade.
ever going to fix that broken image?
If you hosting provider _was_ using those security methods then Apache would be running PHP as you and not "www" or "nobody" so you would be able to delete those files. But since your hosting provider is not using those security methods then any files created by Apache (i.e. any program that it runs, PHP, PERL, etc) are owned by that user "www" or "nobody".<br />
<br />
I've talked with hosting providers that after getting an account with them I realized out insecure their setup was. I talked with them about their issues and they insured me that their setup was secure. I was able to browse their entire server and everybody's website and all of their files on this server. Let me just say that I stayed with those providers for less than a day.<br />
<br />
PHP in CGI mode slows down the server and breaks many "canned" php scripts because they lack the required "#!/usr/local/bin/php" line.<br />
<br />
Chroot jails are largely impractical for servers with large numbers of users.<br />
<br />
However, the new Apache 2.0 perchild MPM attempts to solve all this. Although it starts a lot of extra apache modules, it runs EVERYTHING, PHP, CGI, even normal document reads as YOU, rather than as the webserver. (I'm not sure, but I think your logs are still owned by the master user). Unfortunately, support for it is broken at this time on many platforms.<br />
<br />
In the mean time, keeping secure passwords with a one-way hash might be the best security for "common" programs like this one. As far as protecting database passwords, well, that's another issue entirely, and not one I have a quick and ready answer for.
<i>PHP in CGI mode slows down the server and breaks many "canned" php scripts because they lack the required "#!/usr/local/bin/php" line.</i><br />
<br />
Yes, PHP as CGI is slower. See FAQ 2.3. It describes how to override using the Apache module, so you don't need the shebang at the top of the script.