segurança – What are the risks of using 777 permission?

Question:

Whenever I have folder permissions issue on my Ubuntu OS, I usually give the 777 permission for the certain folder. I often do this in the development environment.

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

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

But I always see recommendations that we should use 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 can have problems with attacks on a web application if there is a 777 write permission on a certain folder. That's true?

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

Answer:

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

This means that any vulnerability in your system allows an attacker to do whatever they want with that file. Worse still, with the combination of write and read permissions, an attacker with sufficient knowledge of your system can unknowingly cause another privileged user to do something.

An illustrative example

Bob is the sysadmin responsible for a JBoss server. Bob's JBoss is running as user jboss . His application has a harmless script that copies files from a business upload folder to an apache context folder ( apache user) optimized to serve static files; this script runs as user jboss . Sounds like something you see around, doesn't it? For example, for uploading avatars and the like.

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

Then Bob started having problems dealing with these jboss user files inside a folder that belongs to apache . Apache did not display the images copied by the script . Bob, in a hurry, went over 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 as the firm's application had a JavaScript function that validated the extension of files that were uploaded by users. The application only allowed files with image extensions to be uploaded to the server. Alice, the firm's developer, copied the JavaScript function from this SOen post and pasted it into the web application in question.

Mallory then verifies that PHP is installed on Apache; running even in the static images folder… Again Bob didn't see the need to keep messing with Apache configuration files since the folder in question would only have images.

Mallory then:

  1. Opens Chrome's development tools and modifies Alice's validation function to allow .php file upload .
  2. Create any PHP script , for example, to delete or steal all images from Bob's server.
  3. Upload the file from Chrome
  4. Wait for Bob's script to run
  5. Run the PHP script through the Apache context folder.

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

Generalizing the story points:

  1. Solving a problem using chmod 777 often 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 the door 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 compromised will be able to do whatever they want with the file/folder.
  4. Software components interact in non-trivial ways and security flaws accumulate across layers (Alice didn't validate files on the server-side of her application, Bob didn't disable PHP in Apache's context folder, and even wrote a lousy script ). As much as you trust your applications, it is important to maintain security at all layers and that includes file system permissions.
Post Views: 6
Scroll to Top