What are the risks of using permission 777?

Question

Always when I have folder permissions problem on my Ubuntu operating system, I usually give permission 777 for a particular folder. I usually do this in the development environment.

In some situations, I have already given this type of permission in production environment on a Linux server, where I run my applications written in PHP.

For example, when I had a specific upload file writing problem in the folder public/uploads of a certain system, I gave permission 777 in this folder.

But I always see recommendations that we should use permission 755 or 644, why use 777 is dangerous.

But in what sense it would be dangerous?

Why experienced developers always recommend using other values for folder permissions in production instead of 777?

For example, I have heard that a person may have problems with attacks on a web application if there is a writing permission 777 in a given folder. This is true?

It would also be nice if the answer could explain better about the differences between 644, 755 and 777.

Answer 1

When giving permissions 777 for a file you make all users can read, write and run the same.

This means that any vulnerability of your system allows an attacker to do as they please with that file. Even worse, with the combination of write and read permissions, an attacker with enough knowledge about your system can make another privileged user run something unknowingly.

---

An illustrative example

Bob is the sysadmin responsible for a Jboss server. Bob’s Jboss is running with the user jboss. Your application has a script harmless copying files from a business folder upload to an apache context folder (user apache) optimized to serve static files; this script wheel with the user jboss. Sounds like something you see around? For example, for upload of avatars and things like that.

Let’s say Bob, not wanting to fight with access permits between the jboss and apache went there and executed chmod 777 in the Apache context folder. With this script in question, even running with the user of jboss, can write files to apache folder without being bothered. Seems harmless right?

After Bob started having problems dealing with these user files jboss inside a folder belonging to the apache. apache did not display images copied by script. Bob, in a hurry, went there and altered his script to rotate a chmod 777 in all the files being copied to the apache folder. Bob saw no risk in doing so since the firm’s application had a Javascript function that validated the extension of files that were sent by users. The application only allowed files with image extensions to be sent to the server. Alice, the firm’s developer, copied the Javascript feature of that Soen post and in the relevant web application.

Mallory then checks that PHP is installed in Apache; running even in the still image folder... Again Bob saw no need to keep messing with Apache configuration files since the folder in question would only have images even.

Mallory then:

1. Opens Chrome development tools and modifies Alice’s validation function to allow upload archival .php.
2. Creates a script Any PHP, for example, to delete or steal all images from Bob’s server.
3. Makes upload from archive by Chrome
4. Is waiting for the script bob’s spin
5. Executes the script PHP via Apache context folder.

The user apache is now running the script de Mallory. Mallory has just gained access to Apache through a vulnerability in an application running on Jboss.

Generalizing the points of history:

1. Solve a problem using chmod 777 usually creates other problems they call for chmod 777 (permissions are there for a reason)
2. chmod 777 gives access to writing and executing a file. This combination opens doors to various types of exploits
3. chmod 777 means that your file can be read, written and executed by any user. This means that any user who is committed will be able to do whatever they want with the file / folder.
4. Software components interact in nontrivial ways and security holes are being accumulated through the layers (Alice did not validate files in server-side of its application, Bob did not disable PHP in the Apache context folder and wrote a script lousy). As much as you trust your applications, it is important to maintain security in all layers and this includes file system permissions.

Answer 2

TL;DR;

Giving permission 777 is the same as :

• "Trust everyone, no matter who you are".
• "Allow anyone to do what they want".

You "trust" no one, absolutely no one, will do nothing you do not want and everyone followed the rules. - (That’s why we do not worry about safety is not even?)

Because 777, not 7 or 77

The permission system is based on three levels of access.

• Owner - Logged in user who created folder/file.
• Group - Group in which the user is inserted (analogy for family).
• 3º - Other users, who are not part of your group (analogy for foreign).

Horizontally written like this :

Dono | Grupo | 3º

And why 7?

The permission system is also based on three actions.

• r - Read
• w - Write
• x - Run

Possible combinations generate a table like this :

Soon it can be seen that 7 would be general permission, RWX

Access + Actions

So we can define exactly who and what can be done in the file/folder.

• 7 - I am the owner, I can do whatever you want.
• 5 - You are my family, but I will only let ler and executar, I don’t want you to edit anything.
• 0 - You are a foreigner I don’t trust you, I don’t even want you to be able to read, you will steal my idea.

Why people usually use 777

The answer to this is in the access, because the owner of the file is a "common" user and apache is an "advanced" user responsible for managing the server. And they’re not even in the same group utilizadores, rede.

That is when I am giving permission for a file/ folder I created apache will be the 3rd (foreign).

People in a simple way think, "ah it is the apache who will access" and use 7, but forget that this is true for anyone else. including the malicious ones.

Addendum

On servers this is more difficult to happen, but it is possible to change the owner of the file/folder, or even put the two in the same group, so you could restrict the accesses.

Changing owner

• I created the folder, but who will change and write is apache so not to use 777.
• I say the Apache is the new owner. chown apache file.
• As apache user I change the permission to 700.

In the same group

• Me and Apache are in the same group.
• So the only need to work with 2 bits and keep the third always at 0.
• 770 - My group and I can do what we want, 3rd has no access to anything.

Answer 3

For example, when I had a specific file writing problem uploaded to the public/uploads folder of a particular system, I gave the 777 permission in this folder.

I love who lives in a dangerous way rsrs(joke), it is more than explained the reasons, the previous answers spoke everything, I just came here to add with practical examples what can happen, how your Operating System can be invaded...

Imagine that I am walking on your page and I find myself in an upload area, let’s say that the upload algorithm does not check metadata or file extensions, you will simply be lost, the attacker will not have root access, but still can do a lot of damage, surely he will be able to read many things inside his SO, besides being able to look at the source codes of your page (php, Asp, etc.), you can even get the passwords of your database for access (looking at the codes of your page you can find the connection passwords of your bank), in this case the attacker does not need to be very smart, it would upload a file into the upload folder ex. hack.php(a code that opens files and shows on the screen), then just run and see the return...

http://meusite/upload/hack.php?var=/etc/passwd

If he’s a little smarter, he’d make a. php file that sends and returns commands (dir, ls, rm)

http://meusite/upload/comandos.php?var=ls&local=/etc/

Of course I’m only saying basic things not to give ideas to the malicious, this is critical, is the worst possible scenario, the hacker could upload any file and use php, Asp, java, python, etc to run, could try to scale root using exploits and have full control of OS, ie it would be a "party" inside your upload folder :-(

Now imagine that your upload algorithm checks extensions but doesn’t look at metadata (headers), let’s imagine that your algorithm in theory just lets upload files .jpg, imagine that I create the following file:

<?php echo "<p>Ola Mundo</p>"; ?>

And save as teste.jpg(of course it’s a silly example, but it could be something really dangerous), your upload folder would become a minefield, malicious code within allowed extensions :-( I say that it is a minefield because the hacker will only need to fire the trigger, usually this trigger can not be executed from outside, via http, I said "generally", the hacker will need to use artifices to perform for example a php teste.jpg.

These are just superficial examples of how to upload a folder with chmod 777 can become the heel of your heel SO.

Answer 4

As stated above, using 777 permission is not a good choice as you allow everyone to read, write and execute.

Permissions using chmod with numbers is very complicated to use the letter table with the + and options - as shown above.

Another option is that no one quoted that it is recommended to run along with chmod is to use the command chown (chown changes the file owner and while chmod changes permissions)

I just came by to give it a boost. :)