Go SSH Known Hosts CA Revocation Bypass - Authentication Authentication Enforcement Gap

Vulnerability Description

The vulnerability is a certificate revocation validation bypass in Go's SSH known_hosts package. The root cause is incomplete revocation checking: while the library previously validated whether a host key itself was revoked, it failed to check the @revoked annotation on the Certificate Authority (CA) key that signed the host key. This represents a logic flaw in the revocation enforcement chain—a compromised or revoked CA should invalidate all certificates it issued, but this implementation allowed revoked CAs to remain trusted. The impact is authentication bypass: an attacker possessing a valid host certificate signed by a revoked CA can successfully authenticate to systems trusting that CA, circumventing the intended revocation semantics.

PoC Significance

The proof-of-concept demonstrates that the revocation check operates at only one layer (the leaf key) rather than the full certificate chain (leaf + intermediate/CA). This is reliable and exploitable without special conditions—any system using revoked CA keys in its known_hosts file remains vulnerable until patched. The PoC proves defenders cannot rely on CA revocation as a security boundary in affected versions, making this a fundamental trust model failure rather than an edge case.

Detection Guidance

Monitor for: (1) SSH authentication attempts using certificates where the issuing CA is marked @revoked in known_hosts files, (2) Unexpected successful SSH sessions from hosts with revoked-CA-signed keys, (3) known_hosts file modifications removing @revoked annotations from CA entries, (4) Version strings of golang.org/x/crypto prior to the patched release in SSH server/client logs. Log SSH authentication events and parse known_hosts to build a revocation-status inventory. Check ssh -v debug logs for CA certificate validation outcomes.

Mitigation Steps

1. Immediate: Patch golang.org/x/crypto to the version that implements dual validation (both leaf key and SignatureKey revocation checks)
2. Inventory: Audit all known_hosts files for @revoked CA entries; verify these CAs are actually untrusted
3. Workaround (interim): Manually remove any known_hosts entries for certificates signed by revoked CAs; regenerate host keys and re-sign with trusted CAs
4. Process: Establish a CA key rotation and revocation procedure; ensure all downstream systems receive updated known_hosts distributions
5. Testing: Deploy patched version in staging; validate that revoked-CA-signed certificates are now rejected

Risk Assessment

Likelihood of exploitation is moderate-to-high in large-scale deployments: revoked CAs typically indicate a prior security incident (key compromise, unauthorized issuance), and attackers with knowledge of such events will attempt to reuse certificates. Threat actors actively monitoring certificate authorities and maintaining compromised keys have direct incentive to exploit this. Organizations with complex SSH PKI using CA revocation as a control are highest-risk. This is not a theoretical flaw—it represents a real authentication enforcement gap that likely affects production systems already managing multiple CAs.