CWE-296 is about the path from a server's certificate up to a root your product trusts. If the product does not follow that path, or follows it incorrectly, it can trust a certificate it should have refused.
Clients that do their own certificate checking, browsers, TLS libraries and security products are the usual carriers.
How it happens
MITRE lists several ways the chain of trust gets broken:
- A certificate in the chain is self-signed, and it is not the root.
- Not every intermediate certificate is checked, from the original all the way up to the root.
- An intermediate, CA-signed certificate lacks the expected Basic Constraints or other important extensions.
- The root certificate has been compromised or authorized to the wrong party.
The first two are plain logic errors in verification code. A loop that stops one link early, or a check that says "chain ends in a self-signed cert, good enough," accepts forged chains.
Real examples
- CVE-2016-2402: a server allows bypass of certificate pinning by sending a chain of trust that includes a trusted CA that is not pinned.
- CVE-2008-4989: a verification function trusts certificate chains in which the last certificate is self-signed.
- CVE-2012-5821: a web browser uses a TLS-related function incorrectly, so it fails to verify that a server's certificate is signed by a trusted certification authority.
- CVE-2009-3046: a web browser does not check whether any intermediate certificates are revoked.
What an attacker gains
Exploitation can lead to trust in data from a spoofed source. MITRE lists the possible impacts as hidden activity, loss of integrity, confidentiality and availability, access control bypass, gaining the identity of a benign entity and, in some cases, executing unauthorized code or commands. In short, the attacker's data, requests or actions are accepted as if they came from a legitimate entity.
How to find it
MITRE notes that static analysis (SAST) can find some instances by analyzing source or compiled code. Beyond that, test with chains you build on purpose: a chain ending in an unknown self-signed root, a chain with a missing intermediate, and a leaf signed by an intermediate that is not allowed to sign certificates. Each must be rejected.
How to fix it
- Build certificate checking into the design. MITRE says to ensure proper certificate checking is included in the system design.
- Use the platform's validated TLS stack and let it walk the whole chain, rather than writing your own loop.
- Understand and implement every check needed for trust integrity: each link signed by the next, constraints honored, revocation status consulted, and the root coming from your trust store.
- If you use certificate pinning, validate every relevant property, including the full chain of trust, before pinning.
- Keep third party TLS libraries and browsers current, since several of the cases above were library bugs that the fix reached only through an upgrade.
Quick check
Is a self-signed root a problem?
Roots are self-signed by nature. The problem is a self-signed certificate anywhere else in the chain, or a root your product was never meant to trust.
