CWE-271: Privilege Dropping / Lowering Errors
ClassLikelihood of exploit: High
The product does not drop privileges before passing control of a resource to an actor that does not have those privileges.
In some contexts, a system executing with elevated permissions will hand off a process/file/etc. to another process or user. If the privileges of an entity are not reduced, then elevated privileges are spread throughout a system and possibly to an attacker.
Consequences
- Access Control: Gain Privileges or Assume Identity
- Access Control, Non-Repudiation: Gain Privileges or Assume Identity, Hide Activities
How to prevent it
- 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.
- Architecture and Design, Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
- Architecture and Design: Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
Recent advisories
- GHSA-vf6j-6739-78m8 — Rancher's Azure AD permission changes are not reflected on active sessions
- GHSA-gc2p-g4fg-29vh — Kubernetes did not effectively clear service account credentials
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor