What are the risks of using 777 permission?

By giving 777 permissions to a file you can have all users read, write, and execute the same.

This means that any vulnerability in your system allows an attacker to do as he likes with this file. Even worse, with the combination of write and read permissions, an attacker with sufficient knowledge about your system can cause another privileged user to execute something without knowing it.

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 harmless script that copies files from a upload business folder to an apache context folder (user apache ) optimized to serve static files; this script runs with the user jboss . Sounds like something you see out there does not it? For example, for upload of avatars and the like.

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

After Bob began to have problems handling these jboss user files inside a folder belonging to apache . Apache did not display images copied by script . Bob, in a hurry, went there and changed his script to run a chmod 777 on all 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 function from that SOen post and pasted it into the web application in question.

Mallory then checks that PHP is installed in Apache; running even in the folder of static images ... Again Bob did not see need to be messing with Apache configuration files since the folder in question would only have images.

Mallory then:

Opens the Chrome development tools and modifies the Alice validation function to allow upload of .php files.

Create a PHP script , for example, to erase or steal all images from Bob's server.

upload of the file by Chrome

Wait for Bob's script to roll

Run the script PHP through the Apache context folder.

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

Generalizing the story points:

Solving a problem using chmod 777 usually creates other problems that call chmod 777 (permissions are there for a reason)

chmod 777 gives access to writing and executing a file. This combination opens doors to various types of exploits

chmod 777 means that your file can be read, written and executed by any user. This means that any compromised user will be able to do whatever they want with the file / folder.

Software components interact in non-trivial ways and security holes are being accumulated across layers (Alice has not validated files on your server-side server ), Bob has not disabled PHP in the context folder of Apache and still wrote a very bad script ). As much as you trust your applications, it is important to maintain security across all layers and this includes file system permissions.

TL

Giving 777 permission is the same as:

• "Trust everyone, regardless of who they are."
• "Allow anyone to do whatever you want".

You "trust" that no one, absolutely nobody , will do anything you do not want and everyone has followed the rules. - (That's why we do not care about security, do we?)

Because 777, not 7 or 77

The permission system is based on three levels of access.

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

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

The possible combinations generate a table like this:

Youcanseethat7wouldbegeneralpermission,RWX

Access+Actions

Sowecandefineexactlywhoandwhatcanbedoneinthefile/folder.

• 7-Iamtheowner,IcandowhateverIwant.
• 5-Youarefrommyfamily,butIwillonlyleavelerandexecutar,Idonotwantyoutoeditanything.
• 0-Youareaforeigner,Idonottrustyou,Idonotevenwantyoutoread,youhavetostealmyidea.

WhyPeopleUsuallyUse777

Theanswertothisisinaccess,becausethefileownerisa"common" user and apache is an "advanced" user who is responsible for managing the server. And they are not even in the same group utilizadores , rede .

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

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

Addendum

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

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 apache user I change the permission to 700 .

Integrating the same group

• I and apache are in the same group.
• So I just 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.

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

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

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

I just came to give it a boost. :)

    

  

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

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

Imagine that I'm walking on your page and I find myself in an upload area, let's say that the upload algorithm does not check metadata and file extensions, you'll simply be lost, the attacker will not get root access, but even so it can do a good job, surely it will be able to read many things inside your 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 to access (looking at the codes of your page it can find the passwords of your bank connection), in this case the attacker does not need to be very smart, it would upload a file in the folder upload ex file. 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 would send and return commands (dir, ls, rm)

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

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

Now imagine your algorithm upload check extensions, but do not look at metadata (headers), let's imagine that your algorithm in thesis only let you upload .jpg files, 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 could be something really dangerous), your upload folder would become a minefield, malicious code within allowed extensions :-( I say it's a minefield because the hacker it will only need to trigger the trigger, usually this trigger can not be executed from outside, via http , I said "usually", the hacker will need to use artifacts to execute for example a php teste.jpg .

This is only a shallow example of how an upload folder with chmod 777 can become the achilles heel of your SO .