CWE-732
Incorrect Permission Assignment for Critical Resource
HIGH
Draft
2008-09-09 00:00 +00:00
2023-06-29 00:00 +00:00
Alerte pour un CWE
Stay informed of any changes for a specific CWE.
Incorrect Permission Assignment for Critical Resource
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.
Informations
Modes Of Introduction
Architecture and DesignImplementation :
REALIZATION: This weakness is caused during implementation of an architectural security tactic.
The developer might make certain assumptions about the environment in which the product operates - e.g., that the software is running on a single-user system, or the software is only accessible to trusted administrators. When the software is running in a different environment, the permissions become a problem.
Installation : The developer may set loose permissions in order to minimize problems when the user first runs the program, then create documentation stating that permissions should be tightened. Since system administrators and users do not always read the documentation, this can result in insecure permissions being left unchanged.
Operation
Applicable Platforms
Language
Class: Not Language-Specific (Undetermined)Technologies
Class: Not Technology-Specific (Undetermined)Class: Cloud Computing (Often)
Common Consequences
| Scope | Impact | Likelihood |
|---|---|---|
| Confidentiality | Read Application Data, Read Files or Directories Note: An attacker may be able to read sensitive information from the associated resource, such as credentials or configuration information stored in a file. | |
| Access Control | Gain Privileges or Assume Identity Note: An attacker may be able to modify critical properties of the associated resource to gain privileges, such as replacing a world-writable executable with a Trojan horse. | |
| Integrity Other | Modify Application Data, Other Note: An attacker may be able to destroy or corrupt critical data in the associated resource, such as deletion of records from a database. |
Observed Examples
| Reference | Description |
|---|---|
| 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. | |
| Anti-virus product sets insecure "Everyone: Full Control" permissions for files under the "Program Files" folder, allowing attackers to replace executables with Trojan horses. | |
| Product creates directories with 0777 permissions at installation, allowing users to gain privileges and access a socket used for authentication. | |
| Photo editor installs a service with an insecure security descriptor, allowing users to stop or start the service, or execute commands as SYSTEM. | |
| socket created with insecure permissions | |
| Library function copies a file to a new target and uses the source file's permissions for the target, which is incorrect when the source file is a symbolic link, which typically has 0777 permissions. | |
| Device driver uses world-writable permissions for a socket file, allowing attackers to inject arbitrary commands. | |
| LDAP server stores a cleartext password in a world-readable file. | |
| Terminal emulator creates TTY devices with world-writable permissions, allowing an attacker to write to the terminals of other users. | |
| VPN product stores user credentials in a registry key with "Everyone: Full Control" permissions, allowing attackers to steal the credentials. | |
| Driver installs its device interface with "Everyone: Write" permissions. | |
| Driver installs a file with world-writable permissions. | |
| Product changes permissions to 0777 before deleting a backup; the permissions stay insecure for subsequent backups. | |
| Product creates a share with "Everyone: Full Control" permissions, allowing arbitrary program execution. | |
| Product uses "Everyone: Full Control" permissions for memory-mapped files (shared memory) in inter-process communication, allowing attackers to tamper with a session. | |
| Database product uses read/write permissions for everyone for its shared memory, allowing theft of credentials. | |
| Security product uses "Everyone: Full Control" permissions for its configuration files. | |
| "Everyone: Full Control" permissions assigned to a mutex allows users to disable network connectivity. | |
| Chain: database product contains buffer overflow that is only reachable through a .ini configuration file - which has "Everyone: Full Control" permissions. |
Potential Mitigations
Phases : ImplementationWhen 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 unauthorized party.
Phases : 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 you to maintain more fine-grained control over your resources. [REF-207]
Phases : Architecture and Design // Operation
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 examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
Be careful to avoid CWE-243 and other weaknesses related to jails.
Phases : Implementation // Installation
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.
Phases : System Configuration
For all configuration files, executables, and libraries, make sure that they are only readable and writable by the software's administrator.
Phases : Documentation
Do not suggest insecure configuration changes in documentation, especially if those configurations can extend to resources and other programs that are outside the scope of the application.
Phases : Installation
Do not assume that a system administrator will manually change the configuration to the settings that are recommended in the software's manual.
Phases : Operation // System Configuration
Ensure that the software runs properly under the United States Government Configuration Baseline (USGCB) [REF-199] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software.
Phases : Implementation // System Configuration // Operation
When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to disable public access.
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 detect the use of library functions that modify permissions, then analyze function calls for arguments that contain potentially insecure values.
However, since the software's intended security policy might allow loose permissions for certain operations (such as publishing a file on a web server), automated static analysis may produce some false positives - i.e., warnings that do not have any security consequences or require any code changes.
When custom permissions models are used - such as defining who can read messages in a particular forum in a bulletin board system - these can be difficult to detect using automated static analysis. It may be possible to define custom signatures that identify any custom functions that implement the permission checks and assignments.
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 the software's intended security policy might allow loose permissions for certain operations (such as publishing a file on a web server), automated dynamic analysis may produce some false positives - i.e., warnings that do not have any security consequences or require any code changes.
When custom permissions models are used - such as defining who can read messages in a particular forum in a bulletin board system - these can be difficult to detect using automated dynamic analysis. It may be possible to define custom signatures that identify any custom functions that implement the permission checks and assignments.
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 modify an active session.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 analyst could evaluate permission assignments in the context of the intended security model of the software.Manual Dynamic Analysis
Manual dynamic analysis may be effective in detecting the use of custom permissions models and functions. The program could then be executed with a focus on exercising code paths that are related to the custom permissions. Then the human analyst could evaluate permission assignments in the context of the intended security model of the software.Fuzzing
Fuzzing is not effective in detecting this weakness.Black Box
Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.
Attach the monitor to the process and watch for library functions or system calls on OS resources such as files, directories, and shared memory. Examine the arguments to these calls to infer which permissions are being used.
Automated Static Analysis - Binary or Bytecode
According to SOAR, the following detection techniques may be useful:
Cost effective for partial coverage:
- Inter-application Flow Analysis
Effectiveness : SOAR Partial
Manual Static Analysis - Binary or Bytecode
According to SOAR, the following detection techniques may be useful:
Cost effective for partial coverage:
- Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
Effectiveness : SOAR Partial
Dynamic Analysis with Automated Results Interpretation
According to SOAR, the following detection techniques may be useful:
Cost effective for partial coverage:
- Host-based Vulnerability Scanners - Examine configuration for flaws, verifying that audit mechanisms work, ensure host configuration meets certain predefined criteria
- Web Application Scanner
- Web Services Scanner
- Database Scanners
Effectiveness : SOAR Partial
Dynamic Analysis with Manual Results Interpretation
According to SOAR, the following detection techniques may be useful:
Highly cost effective:
- Host Application Interface Scanner
Cost effective for partial coverage:
- Fuzz Tester
- Framework-based Fuzzer
- Automated Monitored Execution
- Forced Path Execution
Effectiveness : High
Manual Static Analysis - Source Code
According to SOAR, the following detection techniques may be useful:
Highly cost effective:
- Manual Source Code Review (not inspections)
Cost effective for partial coverage:
- Focused Manual Spotcheck - Focused manual analysis of source
Effectiveness : High
Automated Static Analysis - Source Code
According to SOAR, the following detection techniques may be useful:
Cost effective for partial coverage:
- Context-configured Source Code Weakness Analyzer
Effectiveness : SOAR Partial
Automated Static Analysis
According to SOAR, the following detection techniques may be useful:
Cost effective for partial coverage:
- Configuration Checker
Effectiveness : SOAR Partial
Architecture or Design Review
According to SOAR, the following detection techniques may be useful:
Highly cost effective:
- Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
- Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Effectiveness : High
Vulnerability Mapping Notes
Rationale : While the name itself indicates an assignment of permissions for resources, this is often misused for vulnerabilities in which "permissions" are not checked, which is an "authorization" weakness (CWE-285 or descendants) within CWE's model [REF-1287].Comments : Closely analyze the specific mistake that is allowing the resource to be exposed, and perform a CWE mapping for that mistake.
Related Attack Patterns
| CAPEC-ID | Attack Pattern Name |
|---|---|
| CAPEC-1 | Accessing Functionality Not Properly Constrained by ACLs In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to. |
| CAPEC-122 | Privilege Abuse An adversary is able to exploit features of the target that should be reserved for privileged users or administrators but are exposed to use by lower or non-privileged accounts. Access to sensitive information and functionality must be controlled to ensure that only authorized users are able to access these resources. |
| CAPEC-127 | Directory Indexing An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks. |
| CAPEC-17 | Using Malicious Files An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface. |
| CAPEC-180 | Exploiting Incorrectly Configured Access Control Security Levels An attacker exploits a weakness in the configuration of access controls and is able to bypass the intended protection that these measures guard against and thereby obtain unauthorized access to the system or network. Sensitive functionality should always be protected with access controls. However configuring all but the most trivial access control systems can be very complicated and there are many opportunities for mistakes. If an attacker can learn of incorrectly configured access security settings, they may be able to exploit this in an attack. |
| CAPEC-206 | Signing Malicious Code The adversary extracts credentials used for code signing from a production environment and then uses these credentials to sign malicious content with the developer's key. Many developers use signing keys to sign code or hashes of code. When users or applications verify the signatures are accurate they are led to believe that the code came from the owner of the signing key and that the code has not been modified since the signature was applied. If the adversary has extracted the signing credentials then they can use those credentials to sign their own code bundles. Users or tools that verify the signatures attached to the code will likely assume the code came from the legitimate developer and install or run the code, effectively allowing the adversary to execute arbitrary code on the victim's computer. This differs from CAPEC-673, because the adversary is performing the code signing. |
| CAPEC-234 | Hijacking a privileged process An adversary gains control of a process that is assigned elevated privileges in order to execute arbitrary code with those privileges. Some processes are assigned elevated privileges on an operating system, usually through association with a particular user, group, or role. If an attacker can hijack this process, they will be able to assume its level of privilege in order to execute their own code. |
| CAPEC-60 | Reusing Session IDs (aka Session Replay) This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay. |
| CAPEC-61 | Session Fixation The attacker induces a client to establish a session with the target software using a session identifier provided by the attacker. Once the user successfully authenticates to the target software, the attacker uses the (now privileged) session identifier in their own transactions. This attack leverages the fact that the target software either relies on client-generated session identifiers or maintains the same session identifiers after privilege elevation. |
| CAPEC-62 | Cross Site Request Forgery An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie. |
| CAPEC-642 | Replace Binaries Adversaries know that certain binaries will be regularly executed as part of normal processing. If these binaries are not protected with the appropriate file system permissions, it could be possible to replace them with malware. This malware might be executed at higher system permission levels. A variation of this pattern is to discover self-extracting installation packages that unpack binaries to directories with weak file permissions which it does not clean up appropriately. These binaries can be replaced by malware, which can then be executed. |
Notes
The relationships between privileges, permissions, and actors (e.g. users and groups) need further refinement within the Research view. One complication is that these concepts apply to two different pillars, related to control of resources (CWE-664) and protection mechanism failures (CWE-693).References
REF-62
The Art of Software Security AssessmentMark Dowd, John McDonald, Justin Schuh.
REF-207
Building Secure Software: How to Avoid Security Problems the Right WayJohn Viega, Gary McGraw.
REF-594
Top 25 Series - Rank 21 - Incorrect Permission Assignment for Critical ResponseJason Lam.
http://software-security.sans.org/blog/2010/03/24/top-25-series-rank-21-incorrect-permission-assignment-for-critical-response
REF-199
United States Government Configuration Baseline (USGCB)NIST.
https://csrc.nist.gov/Projects/United-States-Government-Configuration-Baseline
REF-1287
Supplemental Details - 2022 CWE Top 25MITRE.
https://cwe.mitre.org/top25/archive/2022/2022_cwe_top25_supplemental.html#problematicMappingDetails
REF-1307
CIS Microsoft Azure Foundations Benchmark version 1.5.0Center for Internet Security.
https://www.cisecurity.org/benchmark/azure
REF-1327
CIS Google Cloud Computing Platform Benchmark version 1.3.0Center for Internet Security.
https://www.cisecurity.org/benchmark/google_cloud_computing_platform
Submission
| Name | Organization | Date | Date Release | Version |
|---|---|---|---|---|
| CWE Content Team | MITRE | 1.0 |
Modifications
| Name | Organization | Date | Comment |
|---|---|---|---|
| CWE Content Team | MITRE | updated Description, Likelihood_of_Exploit, Name, Potential_Mitigations, Relationships | |
| CWE Content Team | MITRE | updated Potential_Mitigations, Related_Attack_Patterns | |
| CWE Content Team | MITRE | updated Name | |
| CWE Content Team | MITRE | updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Modes_of_Introduction, Observed_Examples, Potential_Mitigations, References | |
| CWE Content Team | MITRE | updated Relationships | |
| CWE Content Team | MITRE | updated Potential_Mitigations, Related_Attack_Patterns | |
| CWE Content Team | MITRE | updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Relationships | |
| CWE Content Team | MITRE | updated Potential_Mitigations, Relationships | |
| CWE Content Team | MITRE | updated Potential_Mitigations | |
| CWE Content Team | MITRE | updated Demonstrative_Examples, Description, Relationships | |
| CWE Content Team | MITRE | updated Common_Consequences, Relationships, Taxonomy_Mappings | |
| CWE Content Team | MITRE | updated Relationships | |
| CWE Content Team | MITRE | updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings | |
| CWE Content Team | MITRE | updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings | |
| CWE Content Team | MITRE | updated Potential_Mitigations | |
| CWE Content Team | MITRE | updated References | |
| CWE Content Team | MITRE | updated Detection_Factors, Relationships | |
| CWE Content Team | MITRE | updated Related_Attack_Patterns, Relationships | |
| CWE Content Team | MITRE | updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings | |
| CWE Content Team | MITRE | updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings | |
| CWE Content Team | MITRE | updated Relationships | |
| CWE Content Team | MITRE | updated Maintenance_Notes, Relationships | |
| CWE Content Team | MITRE | updated Applicable_Platforms, Description, Detection_Factors, Modes_of_Introduction, Relationships | |
| CWE Content Team | MITRE | updated Relationships | |
| CWE Content Team | MITRE | updated Relationships | |
| CWE Content Team | MITRE | updated Observed_Examples, Relationships | |
| CWE Content Team | MITRE | updated Demonstrative_Examples, Observed_Examples, References | |
| CWE Content Team | MITRE | updated Applicable_Platforms, Description, References | |
| CWE Content Team | MITRE | updated Demonstrative_Examples, Description, Potential_Mitigations, References, Relationships | |
| CWE Content Team | MITRE | updated Mapping_Notes, Relationships |
2024©
tesweb SA
