Chmod 777 Risks

February 14, 2008 10:26 PM

Site security experts: Talk to me about chmod 777 directories.

If I have a content manager that is protected by password, checks the mime type upon a file upload, and then saves the file for access via the public website in a "777" directory in the (unix) web root, is that really all that risky? I do have an htaccess file in that directory which denies anything other than defined "safe" file types (as checked by mime-type when the CMS user uploads). There is also an index file in the 777 directory that redirects folks back out to prevent casual browsing.

Again, the great unwashed are not uploading. The files in this directory (all images) are simply used by the public-side site in various pages.

What are the risks, and how likely are they?

posted by maxwelton to Computers & Internet (14 answers total)

Ahh young grasshoppa, you are not the first to ask.

http://www.google.com/search?q=risk+of+777+on+web+servers&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

You're allowing any process or user on the system to do whatever they want to those files.

Local users, other processes, the web servers, cgi scripts, everything.
posted by iamabot at 10:38 PM on February 14, 2008

Why do you want 777? If it's just images, what's wrong with using 644? Let the web user write, everyone else read only. The chances may be slim that someone will try to exploit it, but why take any unnecessary risk?
posted by team lowkey at 11:28 PM on February 14, 2008

Response by poster: Problem is on this shared host, I cannot create a directory as I do not have permission to do so from PHP, which runs as "nobody" or similar.
posted by maxwelton at 12:09 AM on February 15, 2008

You're trusting the uploader not to lie about the mime type ...
posted by 5MeoCMP at 2:23 AM on February 15, 2008

Response by poster: The uploading community, such as it is, is a small group of trusted folks. A very small group, all available in the flesh to complain to.

I guess another way to phrase this. Let's say I have a web site that is maxwelton-is-a-dork.com. It's all flat HTML, and I store all of my image files in "/dorky_images/" which is set to 777. There is an .htaccess file in there that only allows files of certain extensions, but that's not important because I'm the only person placing files there. Let's say Random Internet User knows the directory name from looking at the source and have make a WAG that it's set to 777.

In this scenario, what havoc can be wreaked by Random Internet User? That's what I'm curious about.
posted by maxwelton at 2:52 AM on February 15, 2008

If your hands are tied and you have to use 777: keep good backups. As long as you aren't storing private information, such as email addresses or credit cards in that directory, you can always restore if you are exploited.

(Its the executable bit that makes people nervous, if someone could upload a shell script -- that's one thing. But if it's possible for them to execute it, then really bad things can happen!)
posted by bprater at 4:00 AM on February 15, 2008

Mode 777 (and the bit you're probably most concerned about is is the "world writable" part of that) is all about who can get on to the server and affect the contents of that directory. This would indicate concern over the possibility of compromise of an otherwise unrelated system or user account rather than the webserver or social engineering of a password from a known uploader. Determining the likelihood of these scenarios depends on the platform, webserver, systems admin processes and so on.

Look at it another way. If you keep good backups, and if there's either nothing on the site that's "important" (by your definition) then mode 777 is neither here nor there. It just comes down to how much time you might be willing to put in to put it all back together if it gets damaged, whether intentionally or by a poorly-written maintenance script that runs on the server.

Setting a more restrictive mode protects you from other users (processes running as other users) on the system. If there's a compromise of the webserver, the mode likely doesn't matter. How bad is it if someone replaces one of those images with a pair of huge, floppy tits? (yes, I'm talking about overgrown, pendulous blue birds here)
posted by 5MeoCMP at 4:55 AM on February 15, 2008

The question is about a directory. Together, "r" and "x" specify who may list files in the directory, and who may open a file knowing its name in the directory.

There are some subtleties however. In order to access a file, it is necessary to utter that object's name. Names are always relative to some directory, for example: ~fbs/text/cs513/www/L07.html. Directories are just files themselves, but in the case of directories:

* The "r" (read) bit controls the ability to read the list of files in a directory. If "r" is set, you can use "ls" to look at the directory.

* The "x" (search) bit controls the ability to use that directory to construct a valid pathname. If the "x" bit is set, you can look at a file contained in the directory.

Thus, for example, the 'x' bit allows a user to make the directory under consideration the current working directory and it needs to be on to read files in the current working directory. So a file can be made inaccessible by turning off the 'x' bit for the directory in which the file resides.

Does 'x' without 'r' access make sense? Yes! This is a directory whose files' names cannot be learned, but whose files are accessible if you happen to know their names. This is actually useful.

Does 'r' without 'x' access make sense? This is a directory whose files' names can be learned, but whose files cannot be accessed. It is not very useful.
http://www.cs.cornell.edu/courses/cs513/2005fa/L07.html

By giving permission bits to the group (middle character of 777) you allow anyone in the named group to perform operations in the directory. By giving permission bits to "other" (last character of 777) you allow anyone to perform operations on the directory. But "group" and "other" refer to Unix-level accounts on the same system; If the directory is owned by the unix account that executes the CMS code, then this doesn't change anything about how users of the CMS can access files.

In the case of shared hosting, giving "other" permissions is a substantial risk, but in the case of dedicated hosting, it is probably a risk that can be taken as all Unix-level accouts may be trusted.
posted by jepler at 5:16 AM on February 15, 2008 [1 favorite]

Mr. Welton - this is probably clear from preceding answers, but just in case it's not: you may well be safe from "random internet user", but what you'd really have to worry about is "other web hosting user". If you're on the same server as "StalkingMax.com", for example, the owner/admin of that site, let's call her "Precocious Wicked College Girl", could possibly get access to your files that "random" could never achieve. Read the more detailed comments above for details.

That said, if you can't even create directories on the server, it may be locked down enough that that's not an issue -- but your code could be put on a different server in the future (I'm struggling through being forced to move a bunch of sites from one host to another right now, due to management issues on the old server).

So, you also have to ask yourself about how bad the consequences would be if the site *were* compromised. Factor that in to the whole risk equation.
posted by amtho at 6:46 AM on February 15, 2008

I'm confused; if you can create files in your mode 777 directory, can't you also just create a directory in that directory and then set better permissions on it?

Anyway, you have two separate problems. One is to protect files uploaded from being modified by the same user later. Unix permissions aren't going to help you with that at all. The other is to protect files uploaded from being modified by other users. A mode 777 directory puts you at significant risk for that. You mentioned a shared hosting environment, that sounds like a recipe for disaster.

If you have to go the 777 route, you're much better off if you can set the sticky bit (1777, or +t) in that directory. That way other users can't delete or overwrite your files.
posted by Nelson at 9:01 AM on February 15, 2008

Response by poster: Thank you all for your explanations, I really do appreciate your time. I knew some of this, but have never actually known what the real evil of a directory set to 777 might be, just that it wasn't best practice.

In this case, I log in using FTP "manually" to create directories, under a username. PHP on the box runs as nobody, and hence cannot modify the directory structure I create under my username unless I change the permissions on the directory first.

I'm using http uploads because it is more user-friendly, it's easy, and I would like to capture some of the information that becomes available. I have seen workarounds where you use PHP's FTP functions to log in, chmod a directory temporarily to 777 for the upload and then put it back to 755 or 644 when you're done, but that seems inelegant.

This web host does not allow other users on the same box to browse the entire box, though I suppose someone dedicated could find a way to do that.
posted by maxwelton at 9:23 AM on February 15, 2008

Can you change the directory's owner or group to "nobody"? Then you could at least do a 774, so that other users and scripts can't overwrite or execute anything. Just you and the web user.
posted by team lowkey at 10:42 AM on February 15, 2008

Another angle is that two things combined that are sort of ok can together make a hole.

Eg, suppose you are running something else on that server which has a bug that means a user can exploit it to execute a local file. Maybe some dodgy PHP script or whatever.

Alone, that's not that useful, but your 777 directory means there's now a place for an attacker to upload that file.
posted by i_am_joe's_spleen at 11:37 AM on February 15, 2008

Response by poster: Joe, I guess that was another thing I'm curious about. A 777 directory sitting on a server somewhere doesn't just give carte blanche to anyone out on the web to throw stuff in it, right? I mean, you'd need some sort of access to the box via something other than http? On a shared server obviously there are some other users of the server who you would legitimately have concerns about, but can the viewing public do anything with that?
posted by maxwelton at 6:30 PM on February 15, 2008