The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.
Time of Introduction
Architecture and Design
Implementation
Operation
Applicable Platforms
Languages
All
Common Consequences
Scope
Effect
Access Control
Confidentiality
Technical Impact: Gain privileges / assume
identity; Read application
data; Read files or
directories
An attacker may be able to access resources with the elevated
privilege that he should not have been able to access. This is
particularly likely in conjunction with another flaw -- e.g., a buffer
overflow.
The following code calls chroot() to restrict the application to a
subset of the filesystem below APP_HOME in order to prevent an attacker from
using the program to gain unauthorized access to files located elsewhere.
The code then opens a file specified by the user and processes the contents
of the file.
(Bad Code)
Example
Language: C
chroot(APP_HOME);
chdir("/");
FILE* data = fopen(argv[1], "r+");
...
Constraining the process inside the application's home directory
before opening any files is a valuable security measure. However, the
absence of a call to setuid() with some non-zero value means the
application is continuing to operate with unnecessary root privileges.
Any successful exploit carried out by an attacker against the
application can now result in a privilege escalation attack because any
malicious operations will be performed with the privileges of the
superuser. If the application drops to the privilege level of a non-root
user, the potential for damage is substantially reduced.
Potential Mitigations
Phases: Architecture and Design; Operation
Very carefully manage the setting, management, and handling of
privileges. Explicitly manage trust zones in the software.
Follow the principle of least privilege when assigning access rights
to entities in a software system.
Phase: Architecture and Design
Ensure that appropriate compartmentalization is built into the system
design and that the compartmentalization serves to allow for and further
reinforce privilege separation functionality. Architects and designers
should rely on the principle of least privilege to decide when it is
appropriate to use and to drop system privileges.
Other Notes
If system privileges are not dropped when it is reasonable to do so, this
is not a vulnerability by itself. According to the principle of least
privilege, access should be allowed only when it is absolutely necessary to
the function of a given system, and only for the minimal necessary amount of
time. Any further allowance of privilege widens the window of time during
which a successful exploitation of the system will provide an attacker with
that same privilege. If at all possible, limit the allowance of system
privilege to small, simple sections of code that may be called
atomically.
When a program calls a privileged function, such as chroot(), it must
first acquire root privilege. As soon as the privileged operation has
completed, the program should drop root privilege and return to the
privilege level of the invoking user.
Weakness Ordinalities
Ordinality
Description
Primary
(where
the weakness exists independent of other weaknesses)
Description
