In a PHP / Apache / Linux context, why exactly is chmod 777 dangerous?

Question

Inspired by the discussion in this question.

We have all been taught that leaving directories or files on Linux-based web hosting with the permission level of 777 is a bad thing, and to set always as little permissions as necessary.

I am now curious as to where exactly lies the danger of exploitation, specifically in a PHP / Apache context.

After all, a PHP script file can be executed from the outside (i.e. through a call to the web server, and subsequently to the interpreter) no matter whether it is marked as "executable", can't it? And the same applies to files called through the command-line php interpreter, right?

So where exactly is the vulnerability with 777? Is it the fact that other users on the same machine can access files that are made world writable?

Solution 1

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 777, that means that anybody (including the user apache, which is what php script will execute as) can execute it! If the execute bit is not set on that directory and presumably the files inside the directory, then step 3 above would do nothing.

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

Solution 2

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

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

EDIT: (To clarify and address comments)

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

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

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

Solution 3

There are many good general reasons to follow minimalism when it comes to permissions, but in the context of a LAMP webhost, the few 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.

Solution 4

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

View more solutions

Comments

[LiraNuna]

it lets EVERYONE read, write and execute the code.

[Pekka]

@LiraNuna yes, but what does EVERYONE mean in this context? Users on the same machine? Users outside the machine - how? What does "execute" mean in a PHP script context, where the file itself is not executable, but gets interpreted no matter what its "executable" flag says?

[user187291]

@LiraNuna, assuming his server has 777 on everything, are you able to "write" to his index.php?

[Ilia Hadzhiev]

You need software to allow you to write. Once you can find a bug that let's you write (not too hard), then you can execute the page using apache. If PHP is setup on the machine, or perl, ... you can put characters at the top of the file to tell the system which binary to run automatically. Thus, the file will be literally executable. For even more fun, you can first upload the interpreter (say pearl) then the file to interpret (say ownme.pl) then run pearl against ownme.pl. Sadly, I am saying this from experience. Thankfully, it was not my code and nobody was hurt.

[Eric J.]

About the "Belongs on Serverfault" vote - this is 100% a StackOverflow question. It's about the security of the software we write.

[Pekka]

@Eric J gains access to my system with what kind of login? A shell login? If somebody from the outside gains access to a shell on my Linux server, it's likely I am already screwed. Is this all there is to chmod 777?

[Yossi Gil]

@Eric J: While valid, if there is a problem with someone having shell access to the machine, aren't there more pressing issues at hand than a random chmod'd 777 directory?

[Pekka]

And @Eric J, I am asking about the execution bit specifically. Why does it matter security-wise whether any of my web site's contents are flagged executable, when they are not executable binaries? That's what I want to understand.

[Eric J.]

@Pekka: If you consistently apply the principal of least access, you will have accounts dedicated to particular purposes and you will restrict those accounts to files related to that purpose. If your server's only purpose is to run PHP, you only have one account for that purpose, the impact is less than if you are running a number of services on the same box, each service has a specific account, and each account is restricted to access files related to that service.

[Pekka]

@Eric J. I totally agree. My question here is about the "7" bit specifically, because I see people getting their (PHP based) sites compromised and others replying "well duh, you had chmod 777 here and there, no wonder you were getting hacked." I want to understand what there is to that specifically - that applying least access is the only way to go is beyond question.

[Pekka]

@Mike this makes sense, but do I need the executable bit set to run a PHP file? I can't test it right now but I would think not, wouldn't read rights for Apache/PHP be enough to run the file?

[Mike Sherov]

no, it's not the PHP file's permissions that matter, it's the system() call inside the PHP file that will be executed as a linux system call, and that is PRECISELY where the execution bit matters.

[Eric J.]

@Pekka: If they can write your file, and it is executable, they can change it to something that executes on your machine (executable or script) and then use PHP's shell_exec to run that executable. If you're configured not to allow shell_exec, they can change your configuration as well.

[Pekka]

aaah I see, this makes sense. Cheers!

[mar]

The other answers are correct about any user on the system being able to modify source code and this being bad. More frightening however is that since apache can also modify files and that means a few web application flaws could allow attacker on the internet (assuming site is public) to own the server - they can have their own code running on the server taking over your infrastructure and also on any of your site's visitor's browsers. I may be biased for I have seen exactly this happen.

[testermaster]

Hello @MikeSherov, sorry to bump up this old question and for the following stupid qustion.. You wrote "You have an unprotected directory that users can upload to." what do you mean with "users"? If they don't have FTP access, how can they upload files in that directory? If I'm on a dedicated server, I should be fine, right?

[Fandi Susanto]

Hi @testermaster AFAIK, unsanitized image of file upload interface in a web page is one of the ways to upload php file to the server.