CWE-653 is a design weakness. The product does not properly compartmentalize functionality, processes or resources that need different privilege levels, rights or permissions. When something goes wrong in the part that low-privileged users can reach, there is no strong boundary to stop the damage from spreading to the parts that high-privileged users own. It applies to applications, operating systems, firmware and hardware.
How it happens
Think of one process that both parses untrusted uploads and holds the keys to the database. Or a service where the admin functions sit in the same module, with the same credentials, as public features. Any flaw in the public part now gives the attacker the privileges of everything in the shared space.
MITRE's record includes two examples of the pattern at the hardware and firmware level:
- CVE-2021-33096: improper isolation of a shared resource in a network-on-chip leads to denial of service.
- CVE-2019-6260: a Baseboard Management Controller implements bus bridges that do not require authentication for arbitrary read and write access to the BMC's physical address space.
The lesson is the same at every layer: a boundary that exists on a diagram but is not enforced is not a boundary.
What an attacker gains
The consequence MITRE gives is access control related. Exploiting a weakness in a low-privileged area can be used to reach higher-privileged areas without having to overcome any additional obstacles. One foothold becomes many.
How to find it
The record points to several techniques, listed as useful by the SOAR assessment it cites:
- Compare binary or bytecode to the application permission manifest, which is cost effective for partial coverage.
- Manual source code review, which the record calls highly cost effective, plus focused manual spot checks.
- Architecture or design review, including inspection, formal methods and attack modeling.
In practice, draw the trust boundaries and then check each one: what credentials does each side hold, what can the lower side call, and what happens if it is fully compromised?
How to fix it
MITRE's mitigation is at the architecture and design stage: break up privileges between different modules, objects or entities. Minimize the interfaces between modules and require strong access control between them.
- Separate components by privilege, not just by feature.
- Give each component only the credentials and permissions it needs.
- Keep the interface between components narrow and authenticate every call across it.
- Assume the low-privilege side can be compromised and test what it can reach.
Quick check
Is this fixed by patching one bug?
Patching removes one entry point. The weakness is the missing boundary, so the next bug in the low-privilege area has the same reach until the design changes.
What does MITRE recommend at the design stage?
Break up privileges between modules, minimize the interfaces between them and require strong access control across those interfaces.
