Incorrect Permission Assignment for Critical ResourceID: 732 | Date: (C)2012-05-14 (M)2022-10-10 | Type: weakness | Status: DRAFT | Abstraction Type: Class |
Description The software specifies permissions for a security-critical
resource in a way that allows that resource to be read or modified by unintended
actors. Extended DescriptionWhen a resource is given a permissions 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. Likelihood of Exploit: Medium to High Applicable PlatformsLanguage Class: Language-independent Time Of Introduction - Architecture and Design
- Implementation
- Installation
- Operation
Related Attack Patterns Common Consequences Scope | Technical Impact | Notes |
---|
Confidentiality | Read application
dataRead 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 / 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. | IntegrityOther | Modify application
dataOther | An attacker may be able to destroy or corrupt critical data in the
associated resource, such as deletion of records from a database. |
Detection Methods Name | Description | Effectiveness | Notes |
---|
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. | | |
Potential Mitigations Phase | Strategy | Description | Effectiveness | Notes |
---|
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) [R.732.1], 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. [R.732.2] | Moderate | This can be an effective strategy. However, in practice, it may be
difficult or time consuming to define these areas when there are many
different resources or user types, or if the applications features
change rapidly. | Architecture and DesignOperation | 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. | Limited | The effectiveness of this mitigation depends on the prevention
capabilities of the specific sandbox or jail being used and might only
help to reduce the scope of an attack, such as restricting the attacker
to certain system calls or limiting the portion of the file system that
can be accessed. | ImplementationInstallation | | 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. | High | | System Configuration | | For all configuration files, executables, and libraries, make sure
that they are only readable and writable by the software's
administrator. | 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. | | | OperationSystem Configuration | Environment Hardening | Ensure that the software runs properly under the Federal Desktop Core
Configuration (FDCC) [R.732.4] or an equivalent hardening configuration
guide, which many organizations use to limit the attack surface and
potential risk of deployed software. | | |
Relationships Related CWE | Type | View | Chain |
---|
CWE-732 ChildOf CWE-899 | Category | CWE-888 | |
Demonstrative Examples (Details) - The following code sets the umask of the process to 0 before
creating a file and writing "Hello world" into the file.
- The following code snippet might be used as a monitor to
periodically record whether a web site is alive. To ensure that the file can
always be modified, the code uses chmod() to make the file
world-writable.
- The following command recursively sets world-readable permissions
for a directory and all of its children:
- 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.
Observed Examples - 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-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.
For more examples, refer to CVE relations in the bottom box. White Box Definitions None Black Box Definitions None Taxynomy Mappings Taxynomy | Id | Name | Fit |
---|
CERT Java Secure Coding | FIO03-J | Create files with appropriate access
permission | | CERT Java Secure Coding | SEC01-J | Do not allow tainted variables in privileged
blocks | | CERT Java Secure Coding | ENV03-J | Do not grant dangerous combinations of
permissions | | CERT C++ Secure Coding | FIO06-CPP | Create files with appropriate access
permissions | | CERT C Secure Coding | FIO06-C | Create files with appropriate access
permissions | |
References: - Mark Dowd John McDonald Justin Schuh .The Art of Software Security Assessment 1st Edition. Addison Wesley. Section:'Chapter 9, "File Permissions." Page 495.'. Published on 2006.
- John Viega Gary McGraw .Building Secure Software: How to Avoid Security Problems the
Right Way 1st Edition. Addison-Wesley. Section:'Chapter 8, "Access Control." Page 194.'. Published on 2002.
- Jason Lam .Top 25 Series - Rank 21 - Incorrect Permission Assignment for
Critical Response. SANS Software Security Institute. 2010-03-24.
- NIST .Federal Desktop Core Configuration.
|