web security.

[starfighter]

Hey Everyone,
I ran across this link today about a "bug" in Gallery. The creator claims that this is because of server owners using inadequate flawed security policies. I'm not puting anyone on the spot I just want to learn more about this security stuff.
http://gallery.menalto.com/modules.php?op=...order=0&thold=0 (http://gallery.menalto.com/modules.php?op=modload&name=News&file=article&sid=67&mode=thread&order=0&thold=0)
Thanks
Dan

[starfighter]

Anybody have any ideas/comments?

Dan

[Joe]

From that link:

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).



-------------


We use both models above, PLUS one additional layer of protection.

Part of the issue with Gallery, the author refuses to mention is that ownerships of Gallery albums, etc. are changed BY GALLERY during installation and continued use. They're changed SO much, that when you decide to remove Gallery, you can't delete the directorys as site admin - they have to be deleted from Root. NOT GOOD!

So not good in fact, that several providers are now refusing to allow Gallery scripts. I won't go that far, but so far, we've got our bases covered.

Thanks for the link, and the discussion

Joe

[Anonymous]

From that link:

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).



-------------


We use both models above, PLUS one additional layer of protection.

Part of the issue with Gallery, the author refuses to mention is that ownerships of Gallery albums, etc. are changed BY GALLERY during installation and continued use. They're changed SO much, that when you decide to remove Gallery, you can't delete the directorys as site admin - they have to be deleted from Root. NOT GOOD!

So not good in fact, that several providers are now refusing to allow Gallery scripts. I won't go that far, but so far, we've got our bases covered.

Thanks for the link, and the discussion

Joe



Joe,
Now that I've played with both Gallery and another Gallery type software that you recommended I can see why you and many other service providers either have or are considering banning Gallery from your systems. I have customers who wanted o[galleries iin their websites and have moved them away from Gallery as well. Maybe the creators of this software wiill get the hint and changed the way they write the new version that they have been working on for months.


Dan

[starfighter]

The owner of this software says that he Can't chown the files because he believes that this is such a bis security issue because of the global permissions that must be invoked that he will not consider the idea even though it would appear to help his users more than it would hurt them.


Dan

[Anonymous]

We use both models above, PLUS one additional layer of protection.

Part of the issue with Gallery, the author refuses to mention is that ownerships of Gallery albums, etc. are changed BY GALLERY during installation and continued use. They're changed SO much, that when you decide to remove Gallery, you can't delete the directorys as site admin - they have to be deleted from Root. NOT GOOD!


Joe, if you are using suEXEC with PHP like you say, then PHP runs as the individual user all files created by PHP as CGI are automatically created as the individual user not as Apache. And as you know, Unix prevents user-level chown of files from one user to another. So it should be impossible for your users to have this problem.

So which is it? Are you using suEXEC properly or do you not have the problem? Can you describe your suEXEC configuration?
[/quote]

[Anonymous]

so what about an answer joe !

[Joe]

So, as the supposed author of Gallery - can you tell me why your script changes ownerships of directories and files to apache instead of their rightful owner?

I constantly get mails like this:



3. /var/www/html/gallery/albums/.user/ has improper ownership. It's set to owner/group 48 and not admin like the rest of my files.

4. /var/www/html/gallery/.htaccess also has improper ownership. It's set to owner/group 48 and not admin like the rest of my files

Are these improper ownerships coming from the configuration of gallery via the php scripts. These files get created automagically at the last step of the online configuration. I'm assuming that apache is running under a different account than my admin@domin.tld and causes me to not have sufficient access to this files once they are created.

[Anonymous]

am also very interested in hearing bharat answer!

[Anonymous]

So, as the supposed author of Gallery - can you tell me why your script changes ownerships of directories and files to apache instead of their rightful owner?

I constantly get mails like this:



3. /var/www/html/gallery/albums/.user/ has improper ownership. It's set to owner/group 48 and not admin like the rest of my files.

4. /var/www/html/gallery/.htaccess also has improper ownership. It's set to owner/group 48 and not admin like the rest of my files

Are these improper ownerships coming from the configuration of gallery via the php scripts. These files get created automagically at the last step of the online configuration. I'm assuming that apache is running under a different account than my admin@domin.tld and causes me to not have sufficient access to this files once they are created.

Joe,

Yes, I am the Gallery author. I'll log in and get an account, etc if you'd like me to, but I figured that since I'm not a HostPC customer I'd just lurk.

Apache/PHP runs as a user-level process. It's got no special kernel level permissions. Gallery is a script that is run by Apache/PHP. Therefore it is literally *impossible* for Gallery to change the ownership on a file, since that operation is restricted to accounts with elevated permissions (ie, root). This is a fact of Unix of which I'm sure you're aware.

What's really happening here is that PHP (embedded in Apache) is creating files for the user. Of course this has to happen because Gallery is running as a web-based application and the webserver is Apache, running as your Apache user. When Gallery creates data files, it can only create files owned by the userid that Apache is running as. I refer you to the essay I wrote on my website because I feel that it explains the problem fairly thoroughly.

http://gallery.menalto.com/modules.php?op=...order=0&thold=0 (http://gallery.menalto.com/modules.php?op=modload&name=News&file=article&sid=67&mode=thread&order=0&thold=0)

Now above you state that you're using PHP with suEXEC. But if you're really running in that configuration, then PHP is running as a separate CGI process outside of Apache, and suEXEC changes the owner of the PHP process so that it's owned by your customer. In that configuration, all files created by PHP (including those created by Gallery) would be owned by your customer and you wouldn't be getting the emails that you're referencing above. The fact that you're still getting these emails indicates that you do not have the right suEXEC configuration.

For those of you following along at home :-P I refer you to this article on suEXEC.
http://www.linuxplanet.com/linuxplanet/tut...torials/1445/1/ (http://www.linuxplanet.com/linuxplanet/tutorials/1445/1/)

If you read this carefully you should understand the inherent contradiction
in what Joe's saying above.

Joe, it's not my goal to show up on your forums and pick a fight with you. I'm here because Dan Headly picked a fight with me on the Gallery website forums and offered you up as an example of an ISP that is doing everything right but still has the problem. So I'm trying to be a good citizen here and follow up with you to demonstrate that this problem is a very common one in this class of application (where the webserver manages your data for you) and to demonstrate that this problem can ONLY be fixed by having the ISP configure their webserver in a secure manner. If you want me to go away, fine just say the word. But sadly this problem won't go away quite so easily. So I'll be happy to help you resolve it, if you'll let me.

-Bharat
Principle Gallery Developer
http://gallery.sourceforge.net

[Joe]

Bharat -

Please understand, I am VERY willing to work with you to help our mutual clients remedy these problems. I would like to get to the bottom of this, and welcome your constructive comments.

Yes, we're using PHP with suEXEC ... we run it successfully on Ensim.We also have Plesk servers, and the results are identical. On Plesk, it breaks the same way it breaks on Ensim - and since multiple hosts are experiencing the same issue, I have to think it's not a problem with our suEXEC version - as thats not on Plesk!

One thing that disturbs me about this is your (author - bharat) script called "cleanup" (which runs under the exact same version of suEXEC that Gallery does):

http://gallery.sourceforge.net/docs.php?artid=22

"This script allows you to change the permissions on old album directories so that you can delete them. Download this php file, unzip it and put it on your webserver as cleanup.php then go to it and enter the path to your albums directory. It will change the permissions on your albums so that you can delete them. "

Now, where are the "inherent contradictions" ?

Joe

[Anonymous]

Bharat -

Please understand, I am VERY willing to work with you to help our mutual clients remedy these problems. I would like to get to the bottom of this, and welcome your constructive comments.

Yes, we're using PHP with suEXEC ... we run it successfully on Ensim.We also have Plesk servers, and the results are identical. On Plesk, it breaks the same way it breaks on Ensim - and since multiple hosts are experiencing the same issue, I have to think it's not a problem with our suEXEC version - as thats not on Plesk!


I'm not sure that we're successfully communicating here. Files created with suEXEC are owned by the customer, not by Apache. Therefore if your suEXEC config is correct this problem does not exist. So again I have to ask: how is your suEXEC configured?

Try this simple test. Create a PHP script and put the following in it:

----
My user id is: <?php print getmyuid(); ?>
----

Install this script in a regular user account, and then load it up in your web browser. It will tell you the actual user id of the process running PHP. Any files created by PHP will be owned by this user id, no matter what Gallery does. If this script gives you the userid of the customer, then you're all set. But from your problems it sounds like this script is going to give you the user id of your Apache user (probably uid 48 from your prior post). This is the crux of the problem.



"This script allows you to change the permissions on old album directories so that you can delete them. Download this php file, unzip it and put it on your webserver as cleanup.php then go to it and enter the path to your albums directory. It will change the permissions on your albums so that you can delete them. "

Now, where are the "inherent contradictions" ?


Of course, this script can change the file's permissions That's not a problem because the files are stilled owned by the Apache user and are set only to be writeable by the Apache user. Again, this isn't a problem with permissions, it's a problem with file ownership When suEXEC is set correctly, files created by PHP are owned by the customer and this problem goes away.

My guess, based on what you've told me so far, is that you've got suEXEC configured properly, but you're not running PHP as CGI. It's easy to check this. Just post a link to a .PHP page containing:

<?php phpinfo ?>

One of the first things that we'll see there is the "Server API" column which needs to say "CGI" if you're expecting PHP to operate under the auspices of suEXEC.

Then, as a final example, create a script like this:

----
<?php fopen("/tmp/who_owns_this_file?", "w"); ?>
----

This is an incredibly simple script and as you can see it doesn't change file ownership or modes. Then do a:

ls -al /tmp/who_owns_this_file?

And I believe that you'll see that the file is owned by your webserver user, and not by your customer.

I hope that this will all demonstrate that this particular problem applies to *any* webserver-driven software that manages files on your webserver. Once you've got your suEXEC and PHP-as-CGI settings configured properly you'll notice that:

1. The first script will tell you the customer's uid, not the webserver's
2. The second script will report that it's using the CGI Server API
3. The third script will create a file owned by the customer, not the
webserver.

-Bharat

[starfighter]

Bharat,
As YOU suggested in the posting on your own site that this script could be found by an easy search of the support forums on your site, I attempted to locate it. I tried every combination of search terms that I could and was NEVER able to locate it. I would be very interested in what search terms you would use to locate this file in your forums. Also I highly suggest that since many users never get to your site beyond your sourceforge one that you include some of the things that you have said that we should obviously know in your distributions so that we know this stuff. Your self-righteous attitude to your customers will not get you as far as treating them with respect.
With that said I let you go back to your cat fight with the owners here.

[Anonymous]

Your self-righteous attitude to your customers will not get you as far as treating them with respect.

I write Gallery in my spare time and I give it to you for free. I try to do the best that I can to provide a quality product with what resources I have available. I apologize that my best efforts have turned out to be so inadequate that they've caused you such obvious pain. Perhaps you'll have better luck with another product in the future.

-Bharat