Directories Set to 777 are Safe/Unsafe?
I will first say this as a disclaimer: I’m not a hacker, cracker, or a server security expert! This post is more of a question than an answer. Okay, now that that’s said I can get on with this short article. To the best of my knowledge, and after doing some research on the subject, and reading eighteen million conflicting versions of this information, I must tell you that manually setting directory permissions to 777 is not safe! Or at least I don’t think it is? I’m pretty sure if you set directories/folders on your server to 777 you can be cracked and probably will be, eventually — unless said directories were created with a server side scripting language thus taking ownership away from “Apache,” “Nobody,” or whatever the common default owner name on your server is.
Lots of top-shelf applications instruct users to set directories or folders CHMOD permissions to 777 — as in read-write-execute (-rwx-rwx-rwx-) for owner, group, and everyone, respectively — to allow functions such as file uploading. But this seems to be unsafe advice as they are telling users to do this via the server or via FTP thus not giving ownership over to the application itself. I feel it’s better to give ownership to the application (assuming the application is inherently secure) so as to allow the application access without providing a broader level of access. It seems they should provide a function to make a directory with the application using, for example, the PHP function mkdir(). That way the permissions can be reverted back to 755 which is safe. But this function can be tricky as the server side language must be allowed to do this in the first place.
As it relates to work on a web application I’ve been involved with for quite some time, I have researched this high and low. I’ve read accounts where one says it’s safe, then another will come along with alleged authority and say it’s not, only to be overridden by someone else boasting even greater authority on the subject to reclaim its safe use, only to be overridden by yet another — on and on it seems to go. The common thread I’ve found is that nobody seems to agree. This leaves me with questions, not answers, and I must rely on my own knowledge of it, which is to say it’s not safe, even on a dedicated server with all the proper security blocks in place.
Going out to find the answers yielded none, thus I hoping the answers will come to me. What’s your take on the subject? Are folders set to 777 safe? I say no, but I may be wrong. What’s the real deal?
Dan responds:
Posted: November 10th, 2006 at 4:42 am →
It’s a defence in depth thing IMHO. My understanding is that folders with permissions set to 777 are not at risk from your general site users, or from script-kiddies. For anyone to take advantage of those permissions they would need access to your server and its filesystem. That could be through a vulnerability in software (e.g. the vulnerability exploited in awstats 6.2 last year) or by direct access via ssh or telnet.
If they have the ability to do that then either you have much bigger security problems to worry about (weak or compromised passwords, poorly configured shared server, etc) or they know enough for restrictive file and folder permissions to be less of a barrier to them.
But that doesn’t mean it’s good practice to ignore file permissions. Set permissions to be as restrictive as possible without preventing your site functioning, and keep up to date on exploits and vulnerabilities that might effect your third party packages by subscribing to the SecurityFocus or F-Secure bulletins.
Robert Wellock responds:
Posted: November 10th, 2006 at 8:25 am →
It is not something I would recommend for a live web server. About the only time would be during automated installation ‘Everybody can do everything to this file’ is rarely a sensible idea, and once installed they should be CHMOD moved down to something more secure.
Adam responds:
Posted: November 10th, 2006 at 9:31 am →
Agreed. Not safe. Couple months ago, I had a file that got saved with 777 with a folder with 777 (byproduct of some hasty programming on my part). I came to visit my admin site one day, and I had a nice little message from a hacker.
Now, thankfully this hack was nice enough not to do anything malicious. Hell, all he even did was comment out my page, and inserted his own. It was a warning message more than anything else. After some discussion with my host, he used a weakness not in mysite, but someone else on the server to get in.
Moral of the story, do not leave yourself vulnerable like that. ESPECIALLY if you are on a shared host and not able to control all the variables.
Neal V responds:
Posted: November 10th, 2006 at 1:25 pm →
I don’t understand why a public folder would have to be set to executable anyway. If you are using the classic LAMP set up, or something similar, you should only have to worry about granting write permissions, nothing needs to be executable.
Really, permissions is just another set of barriers. Folder permissions are not the first thing that a would-be cracker comes across in trying to bring down a site, nor is it the last barrier. Some people make all their folders read-only, except ones that are used for catching uploads. Of course that is pointless if you are using an FTP account with permissions to change file permissions.
Look, bottom line is that folder permissions are good to have, but not the be-all and end-all. A cracker has to break through several other barriers before worrying about file permissions. But why give out permissions that aren’t necessary? That would be like giving all of your employees keys to the back door of your store, but not worrying because the building is alarmed. Can employees break in easily? No. But why give them any help?
Mike Cherim responds:
Posted: November 10th, 2006 at 1:53 pm →
Hello Neal,
In the application I’ve been working on we deal with directories that are uploaded or created via FTP, which sets default permissions to 755. This unfortunately doesn’t allow PHP to upload files/images to that directory because PHP is not the directory owner. The way around this is to have PHP do the directory creation which leaves it as public readable but with group and public security by leaving the permissions as 755. The other way around the uploading conundrum is to set folder permissions to 777 leaving the entire domain vulnerable by way of the hole it leaves. There is a third alternative and that’s to pre-create the contents via FTP which allows the folder to be set to 775 while still allowing overwritability but disabling public write/execute access. In either of the last two instances the folder needs to be set to 777 temporarily (a minute or so) to allow PHP to do its thing. I have no folders set to 777, anywhere, but Jona and I have spent months trying to come up with workarounds that’ll work on every server so our application can work to its fullest without compromising security. We have one but it’s still in the works. In our workaround PHP does all the work but leaves the default permission level as is.
I understand folder permission are just one method of cracking a site/server, but currently it is the method we are concerned with as all other access points seem to be a non-issue at this time. Everything else seems to be sewn up properly.
Adam responds:
Posted: November 13th, 2006 at 3:01 pm →
I was using a method similar to what you described where I used FTP connection to alter the permissions, upload, change back to original. I found a better solution was to use a different package of PHP my host offered to run as my user rather than as NOBODY. Turns out this methos was much more secure for me.
Granted, in creating an app for distribution, this does not work. But, I am heppy with it.
Mike Cherim responds:
Posted: November 13th, 2006 at 3:04 pm →
Yeah, I’ve given up trying to make anything significant like a content management system for public consumption. The problem is epidemic. It’s very sad.
David Zemens responds:
Posted: November 14th, 2006 at 7:58 am →
Does this mean that you are no longer going to offer the GBCMS to the public, Mike?
Mike Cherim responds:
Posted: November 14th, 2006 at 9:49 am →
I closed the downloads a couple months ago, David. Any future versions will be private release only.
Glenn responds:
Posted: November 17th, 2006 at 5:44 am →
Mike, an interesting line of investigation.
What we do with our blogs is to have a generic hardening script that (after any work, installation of plug ins etc):
- changes owner and group of everything in the tree
- sets permissions to 744 (and 755 for directories)
- creates ‘null’ index.php files in directories that might not have them
- opens up permissions for the upload directories only (to 777) to allow image uploads for posts.
We have modified our template to store parameterised data in tables, to avoid the need to customise css or php files (e.g. addition of urchin, custom CSS). So theme directories can stay closed.
This strategy was based on the following: http://codex.wordpress.org/Hardening_WordPress
The codex article doesn’t say it directly, but implies that 777 permissions on upload areas are harmless. Potentially image files could be altered/deleted (annoying, but not a disaster, and easy to recover from).
If you are interested in the full Linux hardening script, let me know and I can send it to you.
This is the section that creates null index.php files:
#if an index.php file doesn't exist in each directory, create one for dir in `find . -type d -print` do if [[ -e $dir/index.php ]] then echo " $dir/index.php exists" > /dev/null else # echo " Creating $dir/index.php" cp /home/bin/index.php $dir fidone
Interested in any opinions on the strategy in the codex.
Mike Cherim responds:
Posted: November 17th, 2006 at 7:29 am →
I’d appreciate that Glen. You can access my regular email.
chris kane responds:
Posted: November 30th, 2006 at 8:47 pm →
hi, i just found my site a bit hacked by some script kiddie called ‘wildinc’, now, he only got into the one folder, the 777 one, he deleted it’s contents and replaced it with his own, so he’s found a way to access the folder from outside the site, security was tight (so i thought) and only certain file types were allowed, but even the files containing such security code were deleted, he left his calling card in an index.php file, he didn’t manage to get anywhere else on the site.
when php is in Safe Mode, chmod() won’t work, i’m grappling with the FTP method but finding it a struggle.
my answer (777 => “not safe”)
chris kane responds:
Posted: November 30th, 2006 at 9:30 pm →
ok, i tried this and it worked, this will only work with FTP enabled so if your php won’t connect and you know your details are right, your screwed, find a new host, or host yourself, but not over wireless it sucks.
function changemode($xcite) { $ftp_details = array( ftp_user_name => 'username', ftp_user_pass => 'password', ftp_user_root => '/public_html/', ftp_server => 'ftp.something.org' ); $path = "public"; $mod = intval($xcite, 8); // extract ftp details (array keys as variable names) extract ($ftp_details); // set up basic connection $conn_id = ftp_connect($ftp_server); // login with username and password $login_result = ftp_login($conn_id, $ftp_user_name, $ftp_user_pass); // try to chmod $path directory if (ftp_site($conn_id, 'CHMOD '.$mod.' '.$ftp_root.$path) !== false) { $success=TRUE; } else { $success=FALSE; } // close the connection ftp_close($conn_id); return $success; } // then call it where required, an example: changemode(777, directory); if (@copy("$tempname", "$fullfilename")) $done = "yes"; changemode(755, directory);for those of you, like me, who were looking for a way to make an ‘un-hackable’ uploader, here’s the closest i got, now for a field test, good luck!
chris kane responds:
Posted: November 30th, 2006 at 9:30 pm →
that smily face ruined the code, click View Source to get the code without it.
chris kane responds:
Posted: November 30th, 2006 at 9:32 pm →
or maybe not, i just did and it’ll take you ages that way, instead, replace
with 8 ) (you can remove the space for tidiness if you like)
Mike Cherim responds:
Posted: November 30th, 2006 at 9:54 pm →
I fixed it for you with a character entity
8.