Impact
For Erlang/OTP's internal usage (TLS client with OCSP stapling)
- Clients running TLS (SSL) may accept connections to servers with revoked certificates
- Clients may transmit sensitive data to compromised servers
- Requires attacker to control or MITM the server being validated
- Note: Erlang/OTP TLS (SSL) server does not support OCSP stapling
- Note: For legacy reasons the client was actually implemented and documented to
do a best effort validation, which by default makes it unreliable. This is now addressed
and a must staple behavior is enforced unless user implements its own fallback validation
if the staple is missing.
For applications using public_key:pkix_ocsp_validate/5 API
- Impact depends on usage context
- Server-side client certificate validation: authentication bypass
- Other scenarios: variable impact
Workarounds
For TLS (SSL) users
- Do not enable OCSP validation setting (current default is
{stapling, no_staple})
- Use CRL-based revocation checking by setting the
{crl_check, true} SSL option instead
For applications using public_key:pkix_ocsp_validate/5 directly
- Pass
{is_trusted_responder_fun, Fun} option with a function that validates trusted responder certificates
- Restrict OCSP responder access to trusted endpoints via network controls (only applicable if you control the OCSP infrastructure)
Affected/Unaffected Versions
A version larger than or equal to one of the listed patched versions is unaffected; otherwise, a version that satisfies an expression listed under affected versions is affected, and if it does not, it is unaffected.
The documentation of the new OTP version scheme describes how versions should be compared. Note that versions used prior to OTP 17.0, when the new OTP version scheme was introduced, are never listed since it is not well defined how to compare those versions.
In the case of this vulnerability, versions prior to OTP 27.0 are unaffected.
Credits
Thanks to Igor Morgenstern at Aisle Research for finding and responsibly disclosing this vulnerability to the Erlang/OTP project.
Impact
For Erlang/OTP's internal usage (TLS client with OCSP stapling)
do a best effort validation, which by default makes it unreliable. This is now addressed
and a must staple behavior is enforced unless user implements its own fallback validation
if the staple is missing.
For applications using public_key:pkix_ocsp_validate/5 API
Workarounds
For TLS (SSL) users
{stapling, no_staple}){crl_check, true}SSL option insteadFor applications using
public_key:pkix_ocsp_validate/5directly{is_trusted_responder_fun, Fun}option with a function that validates trusted responder certificatesAffected/Unaffected Versions
A version larger than or equal to one of the listed patched versions is unaffected; otherwise, a version that satisfies an expression listed under affected versions is affected, and if it does not, it is unaffected.
The documentation of the new OTP version scheme describes how versions should be compared. Note that versions used prior to OTP 17.0, when the new OTP version scheme was introduced, are never listed since it is not well defined how to compare those versions.
In the case of this vulnerability, versions prior to OTP 27.0 are unaffected.
Credits
Thanks to Igor Morgenstern at Aisle Research for finding and responsibly disclosing this vulnerability to the Erlang/OTP project.