Directory Permission 777 - Security Concern
 

First of all, I understand why the directories that hold the photos are with 777 permission - to allow users upload the photos.

However, I got several emails from our hosts saying something like this:

They are referring to the directory and files under /data/ folder.

Also I found that my index.html page was hacked. With so many folders under /data/, I am a little worried.

I am not knowledgable at this. But I would like to bring this up for discussion and hear some feedback from photopost team on their view on permission security concern.

Thank you!

For a file upload to work the directory has to be 777. The blank index.htm prevents anyone from viewing the directory there should be no security concerns as the way people break in is through scripts and there are no security issues we are aware with in Photopost

Well, our index page did get hacked.

http://www.photozo.com/album/data/index.html

we dont have an index.html page in our source

Chuck, yes you do have index.html under /data directory. See your post here:

http://www.photopost.com/forum/showp...61&postcount=2

Technically speaking, a directory doesn't have to be 777. We tell people that because the technical answer confuses most people. The data directory "has" to be writable by the web server - for example, apache or httpd. This is an obvious requirement because the web server is the process moving the files into the data directory.

So, assuming you wanted to be as restrictive as possible; you could make the owner of the data directory apache.apache (owner.group) and then make the directory rwxr-xr-x - or, if you wanted to own the directory under your userid and make apache the group, you could have yourname.apache and permissions of rwxrwxr-x which removes "world" write from the permissions. I do not recommend the former because as the web admin you'll need write permissions yourself to edit/upload files; so you might look to the second example.

Now, as for "hacking" a file goes; because apache has to have write permissions to the data directory to do it's job, you cannot prevent someone from writing to that directory if they are able to compromise your web server. Let's say, for example, they are able to install a script which gives them file access to your server - because you have to have write permissions on data, then they would be able to alter the files. And because apache created most of the files in that directory, apache would be able to edit/delete them.

You could remove write permissions from the index file all together, but that would only prevent them from modifying that particular file (which isn't necessarily a bad thing, IMO).

The question I would ask is - how did they compromise your server to write to that file to begin with? I can only imagine that they installed a file script using an exploit on one of your scripts and as such, other than what has been outlined in this post there isn't much you can do to prevent them from access/writing to your data directory given the requirements of this script.

Because I had my server compromised via FlashChat; I went through my web directory and removed write permission on all htm, html and php scripts by the apache process. The only person editing these files are me - altough it means I cannot edit config file via the web browser unless I change the permissions manually, but I can live with that. Next, I change the owner of my directories to myname.apache and gave write permissions only to those directories where apache needed it - like the data directories and subdirs.I remove write from all the other directories (like /forum where apache never needs to write a file). This will help minimize the damage should they be able to get in via an unsecure mod I had on my forums again; but it doesn't mean that they won't mean they can't do any harm considering there are directories that need apache write permissions (like data).

pengrus I was referring to Photopost does not have an index.html file in it we use index.htm ;)

Chuck, you are kidding with me, right? What difference does it make? ;) I have checked the downloaded source file, and it is index.html, not index.htm.

Michael,

Thanks for your detailed explanation of the security issues. That makes a lot sense. I personally don't know enough to give a good analysis or suggestion. I can only report what we experienced and hope get your attention and maybe there is a way to make it more secure or better.

And I agree, one file in photopost got changed - the reason might be something outside photopost directory. In my case, I have no idea how they got in.

To be honest i think if there were a security hole in photopost then a lot more of us would have been hacked. The fact that we haven't may mean you should ask your host to look elsewhere to begin with.

That's not to say its nothing to do with photopost but it may not be the first port of call

Correct, we do have .html files as defaults in the distribution file; in the code we make .htm files by default - so if the html file was in 500, 1 or 2, then it came from the distribution - if an html file exists outside those then it was made by a third party.

Slightly confusing and I should make a note to make it uniform.

Very interesting post. My entire server was hacked a while back and according to my system administrator the hacker most likely got in because there was a vulnerability in the version of PP that I had running. The server probable wouldn't have been hacked if I would have upgraded PP on time, so I can only blame myself for that. I can't remember the exact version of PP that I had but after the server was hacked I did a search on securityfocus.com for that particular PP version and I did see that it contained/contains a vulnerability. I must say that I never understood the importance of keeping scripts up-to-date as I do now :-) Anyway, afterwards I found suspicious directories, files and scripts in my PP data directory.

In my case I think that it could have been possible that my server was hacked through PP, since the version I was using contained a vulnerability. I guess that it's also possible that the hacker used another vulnerability to compromise my server in combination with the data directory of PP.

Now that my server has been re-installed and I have the latest version of PP running (and I'm assuming that it doesn't contain a vulnerability or that it at least has not been discovered yet), I do think it's a good idea to give the whole file permissions thing of the data directories some thought. I will show this post to my system administrator and ask him to make it more secure.

If you have any more suggestions then I would really like to hear it. Thanks.

If php runs as a cgi on your server (ie not as an Apache module) then you should be able to run with 755 instead of 777. Ask your host.

Thanks. I sent him this url. I hope he'll look into it soon.

It appears that 'by default' some data directories are owned by Apache and some by my FTP username (so without having made changes to any of the above yet). Since I don't create the data directories myself (PhotoPost does) I am wondering why some dirs are owned by apache and others not. Does this have to do with the setup of my server? Would it cause problems if nothing is changed? I think this is why I'm having problems removing photos, sometimes when I remove photos from the site then they are not being removed from the server.

Something else: I am using Classifieds as well. I suppose that if I would make PhotoPost more restrictive by adjusting the ownership and permissions, that I'd have to do the same thing for Classifieds?

You can changing owners if you wish. Directories like 1 2 and 500 are probally owned by your username cause you uploaded them to the server. Ones owned by apache maybe are created by the application. It all depends on your server. On my server all files uploaded to my site or created by any application on my server are automatically owned by my master account so that is of course the correct way to setup the server. Less permissions issues that way. You host should be able to correct the server this way to ensure you dont have permissions issues.