[ACCEPTED]-In a PHP / Apache / Linux context, why exactly is chmod 777 dangerous?-chmod

Here's one scenario:

1. You have an unprotected directory that users can upload to.
2. They upload two files: a shell script, and a php file that has a system() call in it to the shell script.
3. they access the php script they just uploaded by visiting the url in their browser, causing the shell script to execute.

If this directory is 12 777, that means that anybody (including 11 the user apache, which is what php script 10 will execute as) can execute it! If the 9 execute bit is not set on that directory 8 and presumably the files inside the directory, then 7 step 3 above would do nothing.

edit from 6 the comments: it's not the PHP file's permissions 5 that matter, it's the system() call inside the PHP 4 file that will be executed as a linux system 3 call by the linux user apache (or whatever 2 you have apache set to run as), and that 1 is PRECISELY where the execution bit matters.

It greatly increases the vulnerability profile 36 of your website to malicious activity because 35 it's only necessary to break into one account.

Anyone 34 that gains access to your system with any 33 login can do whatever they want to your 32 pages, including changing them to read "This 31 website is really insecure so please give 30 me your credit card info."

EDIT: (To clarify 29 and address comments)

Many servers have more 28 than one purpose in life. They run multiple 27 services. If you carefully isolate those 26 services from each other by assigning each 25 a unique user and managing file permissions 24 accordingly, yes, you are still in hot water 23 if someone compromises the credentials for 22 an account, but the damage they can do is 21 limited to that one service. If you just 20 have one generic account and set the whole 19 file system to 777, one compromised account 18 jeopardizes everything on the machine.

If 17 your server is dedicated to only running 16 Apache/PHP and serves no other purpose in 15 life, and there is only one account under 14 which Apache/PHP is being run, having that 13 one account compromised is as good as having 12 the whole machine compromised from the point 11 of view of your application (although you 10 should still have system files protected 9 and non-writable by the account used to 8 run PHP... that should still only be possible 7 for an admin account/root).

If they can write 6 a file, and it is executable, they can change 5 it to something that executes on your machine 4 (executable or script) and then use PHP's 3 shell_exec to run that executable. If you're 2 configured not to allow shell_exec, they 1 can change your configuration as well

There are many good general reasons to follow 3 minimalism when it comes to permissions, but 2 in the context of a LAMP webhost, the few 1 that come readily to mind are

• On a shared hosting platform, other users sharing your host can now read and write to your scripts.
• On a dedicated host, rogue processes can read/write and accidentally delete your files. Let's say there is a custom logging process running in the background as user nobody which has a bug that results in it trying to rm -rf /. Now generally this will be harmless because there would hardly be any file that nobody should have write permissions on but this rogue process will now take your files with it.
• To deface your website, someone needs to only gain access as any user, even say nobody or some such dummy account. Generally, the attacker would have to do a further user level escalation attack to get to the place where he can do some damage. This is a real threat. Some non-critical services may be running under dummy accounts and might contain a vulnerability.

Let's suppose you have a software package 9 installed in your server and there is a 8 zero day vulnerability into it, the attacker 7 gains access to your Admin Control Panel 6 with uploading files capabilities, if you 5 set everything to 777 it would be trivial 4 for him to upload a shell script anywhere 3 he wants. However, if you set the permissions 2 properly he can't do it since nobody/www-data/etc 1 won't have write permissions.