- Reported
-
- Issued
-
- Package
-
x509-validator
(crates.io)
- Type
-
Vulnerability
- Categories
-
- Keywords
-
#x509
#name-constraints
#certificate-validation
#tls
- Aliases
-
- References
-
- CVSS Score
- 7.4
HIGH
- CVSS Details
-
- Attack Vector
- Network
- Attack Complexity
- High
- Privileges Required
- None
- User Interaction
- None
- Scope
- Unchanged
- Confidentiality Impact
- High
- Integrity Impact
- High
- Availability Impact
- None
- CVSS Vector
- CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
- Patched
-
Description
An excluded_subtrees iPAddress name constraint with an all-zero mask
(0.0.0.0/0 or ::/0) does not restrict iPAddress SANs in certificates issued
beneath it. The mask check treated an all-zero mask as matching nothing, when a
/0 prefix matches every address of its family, so the exclusion was silently
ignored.
CA/Browser Forum Baseline Requirements §7.1.2.5.2 require exactly these
exclusions on every technically constrained sub-CA that may not issue for IP
addresses. As a result, anyone holding (or having compromised) the key of such
a sub-CA can issue a certificate for an arbitrary IP address, and Validator
with RFC5280Policy and ServerIdentityPolicy accepts it for that address. A
permitted_subtrees dNSName entry on the same issuer does not prevent this,
because iPAddress SANs are a different name form.
All users of Validator with RFC5280Policy are affected when a chain can
contain a name-constrained issuer with an all-zero iPAddress exclusion.
The issue is fixed in x509-validator 0.3.1 (commit
da661f8).
Users should upgrade to 0.3.1 or later.
Advisory available under CC0-1.0
license.