How will a server become vulnerable with chmod 777?

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.

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

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.