Incorrect Permission Assignment for Critical Resource

Opis

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

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.

Skutki

• Confidentiality

  Read Application Data; Read Files or Directories

  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

  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

  An attacker may be able to destroy or corrupt critical data in the associated resource, such as deletion of records from a database.

Zapobieganie

• 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 unauthorized party.

• 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]

  Skuteczność: Moderate

• Architecture and Design, Operation · Sandbox or Jail

  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.

  Skuteczność: Limited

• 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.

  Skuteczność: High

• System Configuration

  For all configuration files, executables, and libraries, make sure that they are only readable and writable by the software's administrator.

  Skuteczność: High

• 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.

• Installation

  Do not assume that a system administrator will manually change the configuration to the settings that are recommended in the software's manual.

• Operation, System Configuration · Environment Hardening

  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.

• 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.

Przykłady podatności

• 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
• CVE-2009-3289 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.
• CVE-2009-0115 Device driver uses world-writable permissions for a socket file, allowing attackers to inject arbitrary commands.
• CVE-2009-1073 LDAP server stores a cleartext password in a world-readable file.
• CVE-2009-0141 Terminal emulator creates TTY devices with world-writable permissions, allowing an attacker to write to the terminals of other users.
• CVE-2008-0662 VPN product stores user credentials in a registry key with "Everyone: Full Control" permissions, allowing attackers to steal the credentials.
• CVE-2008-0322 Driver installs its device interface with "Everyone: Write" permissions.
• CVE-2009-3939 Driver installs a file with world-writable permissions.
• CVE-2009-3611 Product changes permissions to 0777 before deleting a backup; the permissions stay insecure for subsequent backups.
• CVE-2007-6033 Product creates a share with "Everyone: Full Control" permissions, allowing arbitrary program execution.
• CVE-2007-5544 Product uses "Everyone: Full Control" permissions for memory-mapped files (shared memory) in inter-process communication, allowing attackers to tamper with a session.
• CVE-2005-4868 Database product uses read/write permissions for everyone for its shared memory, allowing theft of credentials.
• CVE-2004-1714 Security product uses "Everyone: Full Control" permissions for its configuration files.
• CVE-2001-0006 "Everyone: Full Control" permissions assigned to a mutex allows users to disable network connectivity.
• CVE-2002-0969 Chain: database product contains buffer overflow that is only reachable through a .ini configuration file - which has "Everyone: Full Control" permissions.

Słabość nadrzędna

• CWE-285 Improper Authorization
• CWE-668 Exposure of Resource to Wrong Sphere

Słabości podrzędne

• CWE-276 Incorrect Default Permissions
• CWE-277 Insecure Inherited Permissions
• CWE-278 Insecure Preserved Inherited Permissions
• CWE-279 Incorrect Execution-Assigned Permissions
• CWE-281 Improper Preservation of Permissions
• CWE-766 Critical Data Element Declared Public
• CWE-1004 Sensitive Cookie Without 'HttpOnly' Flag

Kiedy powstaje

• Architecture and Design
• Implementation — 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

Dotyczy

Not Language-Specific, Not Technology-Specific, Cloud Computing

Uwagi

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).

Źródła

1. The Art of Software Security Assessment — Mark Dowd, John McDonald, Justin Schuh, Chapter 9, "File Permissions." Page 495, Addison Wesley, 2006
2. Building Secure Software: How to Avoid Security Problems the Right Way — John Viega, Gary McGraw, Chapter 8, "Access Control." Page 194, Addison-Wesley, 2002
3. Top 25 Series - Rank 21 - Incorrect Permission Assignment for Critical Response — Jason Lam, SANS Software Security Institute, 2010
4. United States Government Configuration Baseline (USGCB) — NIST
5. Supplemental Details - 2022 CWE Top 25 — MITRE, Details of Problematic Mappings, 2022
6. CIS Microsoft Azure Foundations Benchmark version 1.5.0 — Center for Internet Security, Section 3.7, 2022
7. CIS Google Cloud Computing Platform Benchmark version 1.3.0 — Center for Internet Security, Section 5.1, 2022
8. State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation — Gregory Larsen, E. Kenneth Hong Fong, David A. Wheeler, Rama S. Moorthy, 2014