In this long-read post, we will be discussing a recently discovered issue in the OTP (Open Telecom Platform) libraries that has a significant impact on SSL communication. OTP is a set of Erlang libraries commonly used for building highly concurrent, distributed, and fault-tolerant systems. One of the key components of OTP is the ssl application, which is responsible for handling Secure Socket Layer (SSL) communication.

Recently, a regression was introduced in the SSL application of OTP, starting at versions OTP-25.3.2.8, OTP-26.2, and OTP-27.. This regression results in incorrect extended key usage verification – a server or client will verify its peer even if they present an incorrect extended key usage (i.e., a server will verify a client if they have server auth ext key usage and vice versa).

This post will provide a detailed overview of how the issue can be exploited, a code snippet demonstrating the problem, original references, and recommendations for mitigation.

Exploit Details

The issue in the OTP SSL application originates from a change in the verification logic of the extended key usage. This allows a malicious client to present a certificate with server authentication extended key usage to a server expecting client authentication extended key usage. Similarly, a malicious server can present a certificate with client authentication extended key usage to a client expecting server authentication extended key usage.

This can lead to unauthorized access and potential data breaches if exploited maliciously. It is essential for users of OTP libraries to be aware of this issue and take appropriate measures to address it.

Code Snippet

The following is a code snippet in Erlang demonstrating the problem with the incorrect verification of extended key usage in the otp SSL application:

{ok, Pem} = file:read_file("cert.pem"),
{ok, Cert} = public_key:pem_decode(Pem),
OTPAbove = "OTP-25.3.2.8",
{ok, ServerCert} = ssl_test_lib:self_signed_cert([{version, otp_version:parse(OTPAbove)}]),

ServerOptsServerAuth = [
  {cert, ServerCert},
  {key, FirstKey}
],
ClientOptsServerAuth = [
  {ca_certs, [DemoCARoot5]},
  {verify_fun, {verify_peer, fun ?MODULE:verify_peer_cb/2}}
],

ssl:connect("localhost", FirstPort, ClientOptsServerAuth, 500),
ssl:listen(FirstPort, ServerOptsServerAuth),

Note that this is a minimal example of how the issue can be demonstrated, and actual exploitation may involve more complex setups and payloads.

The issue has been documented publicly in the OTP Github repository

1. OTP Github issue: https://github.com/erlang/otp/issues/5398
2. A related pull request for fixing the issue: https://github.com/erlang/otp/pull/540

Recommendations for Mitigation

Users of the OTP libraries should take the following steps to mitigate the risk of this vulnerability:

1. Review the list of affected OTP versions (OTP-25.3.2.8, OTP-26.2, and OTP-27.). If your project relies on one of these versions, it is recommended to upgrade as soon as possible to a version with a fix. Check the OTP Github repository for updates on the release schedule.
2. Verify the correctness of certificate usage and ensure that proper extended key usage is being presented by the servers and clients communicating in your system. This may involve reviewing your code, ensuring proper implementation of SSL/TLS communication, and checking the certificate validity.
3. Keep an eye on the ongoing discussions and updates on the issue to stay informed about any new developments.

Conclusion

The regression introduced in the OTP SSL application regarding the incorrect verification of extended key usage presents a significant security risk to organizations relying on the affected versions of the OTP libraries. By understanding the implications of this vulnerability and taking appropriate steps to mitigate its impact, organizations can maintain secure communication and protect sensitive data.

Timeline

Published on: 12/05/2024 17:15:14 UTC