Weakness (CWE)
CWE-273: Improper Check for Dropped Privileges
The product attempts to drop privileges but does not check or incorrectly checks to see if the drop succeeded.
How to prevent it (3 mitigations)
-
Architecture and Design
Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
-
Implementation
Check the results of all functions that return a value and verify that the value is expected.
-
Implementation
In Windows, make sure that the process token has the SeImpersonatePrivilege(Microsoft Server 2003). Code that relies on impersonation for security must ensure that the impersonation succeeded, i.e., that a proper privilege demotion happened.
Source: MITRE CWE-273
2 results · Clear filters · Feed
-
Critical 9.8
Multiple jail filesystem root escapes
SCM_RIGHTS file descriptor passing did not preserve FD_RESOLVE_BENEATH when a descriptor was transferred. A process could clear the restriction by sending the descriptor to itself over a Unix domain socket. A process in a jail that has received a directory fi…
-
Critical 9.8
Original block tokens are persisted and can be retrieved
In Apache Ozone versions prior to 1.2.0, Initially generated block tokens are persisted to the metadata database and can be retrieved with authenticated users with permission to the key. Authenticated users may use them even after access is revoked.