How will a server become vulnerable with chmod 777

Question

I often read articles saying something along the lines of "chmod 777 is bad!"

I was wondering:

How do I become vulnerable when I execute 'chmod 777' on a file?

What is a real world example of this that I can reproduce?

Answer 1

It allows filesystem content to be viewed and/or modified by anyone: assuming the attacker already has general system access which is very common on shared hosting platforms .. some are more "hardened" than others from the start. Here is a small incomplete list of possible attack vectors:

1. "your safe code" could be overwritten with "their malicious code" which runs within the same web-server context .. could steal passwords/trojan, expose DB, delete content, etc. That is, someone else's code can run under your security context.
2. Content (e.g. "script source") can possibly be viewed outside of the web-server (or owner) context. Have a "secure" password to connect to the DB? Well, not anymore...
3. If content was protected by permissions (e.g. web-server couldn't access before), the web-server might be able to access/list sensitive information... not good if you didn't mean to share it. Different web-server configurations will also treat "listings" differently, which can also expose more than is desired.

In the above I also assume "group" to include the web-server principal and that there is a web-server (and/or shared hosting) involved which can be used as a primary attack vector and/or security vulnerability. However, and I stress this again: the list above is not complete.

While not "guaranteed safety", using the most specific permissions can mitigate some vulnerabilities / exposure.

Answer 2

chmod is the CHange MODe command. The 777 indicates the permissions. there are three groups of people who can have permissions (each one gets their own digit), in order: Owner (of the file or directory, the first 7), group (everyone who belongs to the same group as the owner, second 7), and world (third 7).

Owner is the user of the file - that'd be you. In the *nix world, users belong to groups. So you might be user/owner Bob in group Marketing. This model lets you do things like say Bob can read/write the file, the rest of marketing can only read the file, and other users can read the file.

Each digit in the 777 is a binary representation of: rwx (read/write/execute). So a chmod of 755 means: 111(7) - Owner can read write execute 101(5) - other in the group can execute or read, no write 101(5) - rest of world can read and execute, no write.

That setup means you can read/write and execute your files, but the people visiting your site can only read or execute the file. Thus you need to set programs in your cgi-bin to 755, so people can execute the file as a program.

If you set the permissions to 'chmod 644', you get a file that can be written by you, but can only be read by the rest of the world. This is good for straight HTML files so that no hanky panky goes on. But try and execute a file with permissions of 644 and you'll get an error.

CHMOD 777 will allow everyone to make changes to the files of your server, it will give them WRITE condition and everyone knows that it's bad.

Answer 3

If a malicious entry reaches your app, website, etc. No matter what it does to the code. The critical point is at the database and there is no possible protection against "writing" on it. So chmod 777 permissions are nothing dangerous at all.

Answer 4

Each digit in the chmod command represents an octal (3-bit) number. With three digits, that's 9 bits total. Each bit represents a permission; 1 == has permission, 0 == does not have permission.

The three bits in each digit represent read (binary 100 == decimal 4), write (binary 010 == decimal 2), and execute (binary 001 == decimal 1). Decimal 7 is read+write+execute permission.

The first digit of a chmod command represents the permissions of the owner of a file or directory. The second is for the group. The third is for the "universe" -- that is, everyone else.

So, chmod 777 represents read, write, and execute permission for you, the group, and everyone. This is usually much greater access than is required.

For your real-world example, imagine if a file called my_bank_account_credentials were altered with chmod 777. Not very safe! A malicious user could change what's in there or just read it and happily take your money.

For servers, the chief danger is that an exploited bug in the server code could allow an attacker to access anything that the server process has rights to -- which would include anything that has the 777 permission set.

Answer 5

If the attacker only has access to the web interface (not to the files, say, via another account on the same shared hosting) then mode 777 doesn't directly open any vulnerabilities. What it does is make it easier for the attacker to change things on the site once they get in some other way.

For instance, suppose you have a WordPress site and there's a bug somewhere that allows the attacker to execute arbitrary PHP code under the credentials of the server daemon (this has happened many times in the past and will no doubt happen again in the future). The code for WordPress itself is stored in .php files that the server daemon can read. If those files are mode 777 then the attacker can write to them - which means they can modify the code - changing what your site does. Perhaps they install a "drive by exploit" kit and now everyone who visits your site gets their browser hacked. Perhaps they install a SEO spam kit and now Google thinks you're selling Viagra (but if you visit the site directly it's invisible -- yes, this really happens).

If the .php files are mode 755, and owned by a user who isn't the server daemon, then the attacker can't permanently change what the site does.

Note that this means WordPress's self-upgrade-from-the-admin-panel feature is risky, since it only works if WordPress can modify itself -- you can't have that and also have the adversary unable to modify files once they can execute arbitrary PHP.

Note also that you're only 100% safe in this regard if there are no files and no directories that the server daemon can modify. Even just allowing file upload to a single directory can still be a problem - even if the only thing you let anyone put in there is image files. (If that seems impossible, have a look at http://lcamtuf.coredump.cx/squirrel/.)