Lemur: Sub-CA creation never checks `AuthorityPermission` on the parent authority
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 1.9.3
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: poc
- Automatable: no
- Technical impact: partial
Summary
Lemur manages TLS certificate creation. Prior to 1.9.3, POST /api/1/authorities with type=subca did not require AuthorityPermission on the parent authority when ADMIN_ONLY_AUTHORITY_CREATION was false. AssociatedAuthoritySchema resolved the caller-supplied parent and passed it through authority creation to cryptography-issuer, which used the parent authority_certificate.private_key to sign a new intermediate. Any authenticated non-read-only user in that supported configuration could chain a sub-CA to an internal root for which the user held no role. The resulting intermediate could issue trusted certificates and its private key could be used outside Lemur, bypassing normal issuance controls. The fix checks AuthorityPermission on every supplied parent before invoking the issuer. This issue is fixed in version 1.9.3.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: poc · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- Netflix lemur
fixed in 1.9.3
- lemurPyPI
fixed in 1.9.3