What are the risks of using 777 permission?

Always when I have folder permissions issue on my Ubuntu OS, I usually give the 777 permission for the 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 squeegee my applications written in PHP.

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

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

But in what sense would that be dangerous?

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

For example, I've heard that a person may have problems with attacks on an application web if there is a write permission 777 in a certain folder. Is that true?

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

Author: Piovezan, 2016-12-06
Source

4 answers

By giving 777 permissions to a file you make it possible for all users to read, write and run the same.

This means that any vulnerability in your system allows an attacker to do what they see fit with that file. Even worse, with the combination of write and read permissions, an attacker with enough knowledge about your system can cause another privileged user to unknowingly perform something.

An example illustrative

Bob is the sysadmin responsible for a JBoss server. Bob's JBoss is running with user jboss. Your application has a harmless script that copies files from a business Folder upload to an apache context folder (user apache) optimized for serving static files; this script runs with user jboss. Sounds like something you see out there doesn't it? For example, for upload of Avatars and stuff from gender.

Let's say Bob, not wanting to struggle with access permissions between jboss and apache went there and ran chmod 777 in the Apache context folder. With this the script in question, even running with the jboss user, can write files in the apache folder without being bothered. Sounds harmless right?

Then Bob started having problems dealing with these user files jboss inside a folder that belongs to apache. Apache did not display the images copied by the script. Bob, in a hurry, went there and changed his script to run a chmod 777 on all the files being copied to the apache folder. Bob saw no risk in doing this since the firm's application had a JavaScript function that validated the extension of the files that were uploaded by users. The application only allowed files with Image Extensions to be sent to the server. Alice, the developer of the firm, copied the function JavaScript of this Soen post and pasted into the web application in question.

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

Mallory then:

  1. opens Chrome's development tools and modifies Alice's validation function to allow upload files .php.
  2. creates a script PHP any, for example, to delete or steal all images from Bob's server.
  3. does upload of the file by Chrome
  4. wait for Bob's script to run
  5. runs the script PHP through the Apache context folder.

User apache is now running Mallory's script. Mallory just gained access to Apache through a vulnerability in an application running on JBoss.

Generalizing the points of the story:

  1. solving a problem using chmod 777 usually creates other problems that 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 for 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 compromised will be able to do whatever they want with the file / folder.
  4. software components interact in non-trivial ways and security flaws are accumulated through the layers (Alice did not validate files in the server-side of her application, Bob did not disable PHP in the Apache context folder and even wrote a bad script). As much as you trust your applications, it's important to maintain security in all layers and this includes the file system permissions.
 49
Author: Anthony Accioly, 2020-06-11 14:45:34

TL; DR;

Giving permission 777 is the same as:

  • " trust everyone, regardless of who they are."
  • "allow anyone to do whatever they want".

You "trust" that no one, absolutely no one, will do anything you do not want and everyone has followed the rules. - (That's why we don't worry about safety is it?)

Because 777, and not 7 or 77

The permission system is based on three access levels.

  • owner-logged in user who created the folder / file.
  • Group - Group in which the user is inserted (analogy for family).
  • 3rd-other users, who are not part of your group (analogy for foreigner).

Horizontally written like this:

Dono | Grupo | 3º

And why 7?

The permission system is also based on three actions.

  • r-Read
  • w-write
  • x - Execute

The possible combinations generate a table like this:

insert the description of the image here

It can soon 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 I want.
  • 5-you are from my family, but I will only leave ler and executar, I do not want you to edit anything.
  • 0-you are foreigner I do not trust you, I do not even want you to read, you will steal my idea.

Why people usually use 777

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

I.e. when I'm giving permission to a file/folder I created apache will be the 3rd (foreign).

As people in a simple mode think, "Ah it's apache that will access" and use 7, but forget that this goes for anyone else. even 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 by both in the same group, so you could restrict accesses.

Changing owner

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

Integrating the same group

  • apache and I are in the same group.
  • so the only need to work with 2 bits and keep the third always at 0.
  • 770 - Me and my group can do what we want, the 3rd has no access to anything.
 39
Author: Guilherme Lautert, 2016-12-08 01:14:18

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

I love those who live in a dangerous way rsrs (joke), it is already 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 hacked...

Imagine I'm walking on your page and I come across in an upload area, let's say that the upload algorithm does not check metadata and nor file extensions, you will simply be lost, the attacker will not have root access, but still can do a good damage, surely he will be able to read many things within your SO, in addition to being able to look at the source codes of your page (php, asp, etc.), can even get the passwords of your database for access (looking at the codes of your page he will be able you can find the connection passwords of your bank), in this case the attacker does not have to be too smart, he would upload a file in the folder folder upload 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 file .php that sends and returns commands (dir, ls, rm) 

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

Of course I'm just talking basic things not to give ideas to the ill-wishers, this is critical, it's the worst case scenario possible, 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 the OS, i.e. it would be a "party" inside your upload folder:- (

Now imagine that your upload algorithm check extensions, but does not look metadata( headers), let's imagine that your algorithm in thesis only let upload files .jpg, imagine that I create the following file: 

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

And Hello like teste.jpg (of course it is a silly example, but it could be something really dangerous), your upload folder would turn into a minefield, malicious codes within allowed extensions :-( I say it is a minefield because the hacker will only need to trigger the trigger, usually this trigger can not be executed from outside, via http, I said "Generally", the hacker will need to use artifices to execute for example a php teste.jpg.

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

 2
Author: ederwander, 2018-09-18 13:07:39

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

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

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

Just passed to give a reinforced. :)

 1
Author: Lucas Palomo, 2018-09-16 13:52:47