CWE-370: Missing Check for Certificate Revocation after Initial Check
The product does not check the revocation status of a certificate after its initial revocation check, which can cause the product to perform privileged actions even after the certificate is revoked at a later time.
Last updated
Overview
If the revocation status of a certificate is not checked before each action that requires privileges, the system may be subject to a race condition. If a certificate is revoked after the initial check, all subsequent actions taken with the owner of the revoked certificate will lose all benefits guaranteed by the certificate. In fact, it is almost certain that the use of a revoked certificate indicates malicious activity.
Common consequences
What can happen when CWE-370 is exploited.
Gain Privileges or Assume Identity
Affects: Access Control
Trust may be assigned to an entity who is not who it claims to be.
Modify Application Data
Affects: Integrity
Data from an untrusted (and possibly malicious) source may be integrated.
Read Application Data
Affects: Confidentiality
Data may be disclosed to an entity impersonating a trusted entity, resulting in information disclosure.
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
How to prevent it
Practical mitigations for CWE-370, grouped by where in the lifecycle they apply.
Ensure that certificates are checked for revoked status before each use of a protected resource. If the certificate is checked before each access of a protected resource, the delay subject to a possible race condition becomes almost negligible and significantly reduces the risk associated with this issue.
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
The following code checks a certificate before performing an action.
Vulnerable example
if (cert = SSL_get_peer_certificate(ssl)) {While the code performs the certificate verification before each action, it does not check the result of the verification after the initial attempt. The certificate may have been revoked in the time between the privileged actions.
Terminology & mappings
Mapped taxonomies
- CLASP: Race condition in checking for certificate revocation
- Software Fault Patterns: Race Condition Window (SFP20)
Attack patterns
CAPEC attack patterns that exploit this weakness.
Frequently asked questions
Common questions about CWE-370.
- What is CWE-370?
- The product does not check the revocation status of a certificate after its initial revocation check, which can cause the product to perform privileged actions even after the certificate is revoked at a later time.
- How do you prevent CWE-370?
- Ensure that certificates are checked for revoked status before each use of a protected resource. If the certificate is checked before each access of a protected resource, the delay subject to a possible race condition becomes almost negligible and significantly reduces the risk associated with this issue.
- What are the consequences of CWE-370?
- Exploiting CWE-370 can lead to: Gain Privileges or Assume Identity, Modify Application Data, Read Application Data.
References
- MITRE CWE definition (CWE-370) (opens in a new tab)
- CWE-370 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-370
Get alerted the moment a new CWE-370 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.