CWE-732: Incorrect Permission Assignment for Critical Resource

Description:
The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.

Extended Description:
When a resource is given a permission setting that provides access to a wider range of actors than required, it could lead to the exposure of sensitive information, or the modification of that resource by unintended parties. This is especially dangerous when the resource is related to program configuration, execution, or sensitive user data. For example, consider a misconfigured storage account for the cloud that can be read or written by a public or anonymous user.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, Cloud Computing
Parent weaknesses: CWE-285, CWE-668

Consequences:
  - Confidentiality: Read Application Data
  - Access Control: Gain Privileges or Assume Identity
  - Integrity: Modify Application Data

Detection methods:
  - Automated Static Analysis: Automated static analysis may be effective in detecting permission problems for system resources such as files, directories, shared memory, device interfaces, etc. Automated techniques may be able to 
  - Automated Dynamic Analysis: Automated dynamic analysis may be effective in detecting permission problems for system resources such as files, directories, shared memory, device interfaces, etc. 
                   However, since 
  - Manual Analysis: This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and m
  - Manual Static Analysis: Manual static analysis may be effective in detecting the use of custom permissions models and functions. The code could then be examined to identifying usage of the related functions. Then the human a

Mitigations:
  - [Implementation] When using a critical resource such as a configuration file, check to see if the resource has insecure permissions (such as being modifiable by any regular user) [REF-62], and generate an error or even exit the software if there is a possibility that the resource could have been modified by an unaut
  - [Architecture and Design] Divide the software into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully defining distinct user groups, privileges, and/or roles. Map these against data, functionality, and the related resources. Then set the permissions accordingly. This will allow yo
  - [Architecture and Design] Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. 
                   OS-level ex
  - [Implementation] During program startup, explicitly set the default permissions or umask to the most restrictive setting possible. Also set the appropriate permissions during program installation. This will prevent you from inheriting insecure permissions from any user who installs or runs the program.

Demonstrative examples:
The following code sets the umask of the process to 0 before creating a file and writing "Hello world" into the file.
After running this program on a UNIX system, running the "ls -l" command might return the following output:
#define OUTFILE "hello.out" 
                      umask(0); FILE *out; 
                      /* Ignore link following (CWE-59) for brevity */ 
                      
                      out = fopen(OUTFILE, "w"); if (out) { fprintf(out, "hello world!\n"); fclose(out); }
-rw-rw-rw- 1 username 13 Nov 24 17:58 hello.out

This code creates a home directory for a new user, and makes that user the owner of the directory. If the new directory cannot be owned by the user, the directory is deleted.
Because the optional "mode" argument is omitted from the call to mkdir(), the directory is created with the default permissions 0777. Simply setting the new user as the owner of the directory does not explicitly change the permissions of the directory, leaving it with the default. This default allows any user to read and write to the directory, allowing an attack on the user's files. The code also fails to change the owner group of the directory, which may result in access by unexpected groups.
function createUserDir($username){ $path = '/home/'.$username; if(!mkdir($path)){ return false; } if(!chown($path,$username))

Real-world examples:
  - CVE-2022-29527: Go application for cloud management creates a world-writable sudoers file that allows local attackers to inject sudo rules and escalate privileges to root by winning a race condition.
  - CVE-2009-3482: Anti-virus product sets insecure "Everyone: Full Control" permissions for files under the "Program Files" folder, allowing attackers to replace executables with Trojan horses.
  - CVE-2009-3897: Product creates directories with 0777 permissions at installation, allowing users to gain privileges and access a socket used for authentication.
  - CVE-2009-3489: Photo editor installs a service with an insecure security descriptor, allowing users to stop or start the service, or execute commands as SYSTEM.
  - CVE-2020-15708: socket created with insecure permissions