REDHAT-BUG-2536969: High severity maven/io.netty/netty-handler-ssl-ocsp vulnerability
Missing Extended Key Usage (EKU) check in OCSP Client allows certificate revocation bypass
A public GitHub Security Advisory (GHSA-jhjp-5q4f-8wr2) describes the following issue:
Summary Netty's OcspClient does not verify that an OCSP responder certificate contains the id-kp-OCSPSigning Extended Key Usage (EKU). A bad actor with any valid certificate issued by the same CA can forge "GOOD" OCSP responses for revoked certificates, bypassing revocation checks.
Details In io.netty.handler.ssl.ocsp.OcspClient, validateSignature uses CertPathBuilder to validate the responder's certificate chain to the trust anchor. However, it fails to verify if the responder is authorized to sign OCSP responses. Per RFC 6960, delegated OCSP responders must explicitly hold the id-kp-OCSPSigning EKU. Because OcspClient omits this check, any CA-issued certificate can successfully sign forged OCSP responses.
https://datatracker.ietf.org/doc/html/rfc6960#section-4.2.2.2
Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing the use of the id-kp-OCSPSigning value as described above. ... They MUST reject the response if the certificate required to validate the signature on the response does not meet at least one of the following criteria:
1. Matches a local configuration of OCSP signing authority for the certificate in question, or
2. Is the certificate of the CA that issued the certificate in question, or
3. Includes a value of id-kp-OCSPSigning in an extended key usage extension and is issued by the CA that issued the certificate in question as stated above.
PoC The following test in io.netty.handler.ssl.ocsp.OcspClientTest demonstrates the vulnerability. A bad actor creates a forged OCSP response signed by a standard, non-OCSP-signing certificate. Netty validates the signature without throwing an exception.
java @Test void validateSignatureWithoutEkuSucceedsBypass() throws Exception { X509Bundle caRoot = new CertificateBuilder() .algorithm(CertificateBuilder.Algorithm.rsa2048) .subject("CN=TrustedRootCA") .setIsCertificateAuthority(true) .buildSelfSigned();
X509Bundle badActorCert = new CertificateBuilder() .algorithm(CertificateBuilder.Algorithm.rsa2048) .subject("CN=BadActorServer") .buildIssuedBy(caRoot);
X509CertificateHolder badActorHolder = new JcaX509CertificateHolder(badActorCert.getCertificate());
BasicOCSPResp forgedResponse = createBasicOcspResponse( badActorCert, new X509CertificateHolder[]{badActorHolder} );
assertDoesNotThrow(() -> OcspClient.validateSignature(forgedResponse, caRoot.getCertificate()), "Validation should have thrown an exception due to missing EKU."); }
Impact Authorization Bypass. Applications using Netty's OcspClient will accept revoked certificates if a network-positioned bad actor possesses any other certificate from the same CA.
Affected: - maven:io.netty:netty-handler-ssl-ocsp affected >=4.2.0.Final, <=4.2.17.Final; fixed unknown - maven:io.netty:netty-handler-ssl-ocsp affected >= 4.1.0.Final, <=4.1.137.Final; fixed unknown
Fixed versions: see advisory
Advisory: https://github.com/netty/netty/security/advisories/GHSA-jhjp-5q4f-8wr2
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Ensure OCSP responses are rejected/treated as invalid if the OCSP responder certificate is missing the id-kp-OCSPSigning Extended Key Usage (EKU), since Netty's OcspClient does not enforce this EKU check.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Applications using Netty's OcspClient and relying on its OCSP validation to enforce certificate revocation checks are exposed. The issue concerns OCSP responses validated by io.netty.handler.ssl.ocsp.OcspClient.
What does an attacker need to forge an accepted OCSP response?
An attacker needs any valid certificate issued by the same CA as the revoked certificate. The certificate does not need to be authorized for OCSP signing because OcspClient does not enforce the id-kp-OCSPSigning EKU requirement.
Does the client perform any validation of the responder certificate?
OcspClient uses CertPathBuilder to validate the responder certificate chain to a trust anchor. However, it does not verify that a delegated responder certificate is authorized to sign OCSP responses through the required id-kp-OCSPSigning EKU.