CVE-2024-24783

What it actually does

A vulnerability exists in Go's `crypto/tls` package where processing a specially crafted TLS certificate chain can cause a panic. Specifically, if a certificate in the chain uses an unknown public key algorithm, the `Certificate.Verify` function will panic, leading to an unhandled exception that terminates the entire process.

Why it matters to the business

This vulnerability can be exploited to cause a Denial of Service (DoS) against applications written in Go. Any service that acts as a TLS client (e.g., connecting to external APIs) or a TLS server configured for mutual authentication (mTLS) is at risk. Successful exploitation will crash the service, leading to downtime, service unavailability, and potential disruption of dependent systems. Repeated attacks can prevent a service from running, impacting reliability and customer trust.

How an attack unfolds

An attacker can exploit this vulnerability by presenting a malicious TLS certificate to a vulnerable Go application during a TLS handshake. For a server-side vulnerability (where the Go application is a server configured for mTLS), the attacker acts as a client and sends a crafted client certificate. The server attempts to verify this certificate, encounters the unknown public key algorithm, and panics. For a client-side vulnerability, the attacker must control the server the Go application connects to (e.g., via DNS hijacking or by owning the endpoint). When the Go client connects, the attacker's server presents a crafted server certificate, causing the client to panic and crash upon verification.

How to fix it

To remediate this vulnerability, you must upgrade the Go toolchain to a patched version (e.g., Go 1.22.1 or Go 1.21.8 and later) and recompile your applications. Simply updating the Go runtime on a system is not sufficient; the binaries themselves must be rebuilt with the fixed standard library.

How to confirm the fix worked

To validate that an application is no longer vulnerable, first verify the Go version used to build the binary. You can use the command `go version -m /path/to/your/binary` to check the build information. Ensure the reported version is a patched one. Additionally, you can perform a security test by attempting to connect to the service (or have the client connect to a test server) using a certificate with an invalid public key algorithm. A patched application should reject the connection gracefully with an error, while a vulnerable application will crash.

Typical attack path

1. The attacker crafts a X.509 certificate that specifies an unknown or unsupported public key algorithm.
2. The attacker identifies a target Go application that either acts as a TLS client or is a TLS server configured to verify client certificates.
3. The attacker positions themselves to present the certificate to the target. For a server target, this involves initiating a TLS handshake. For a client target, this involves intercepting its connection or controlling its destination endpoint.
4. The malicious certificate is sent to the victim application as part of the TLS handshake.
5. The Go application's `crypto/tls` library attempts to parse and verify the certificate.
6. The verification process fails on the unknown algorithm, triggering a panic that crashes the application.
7. The application becomes unavailable, resulting in a Denial of Service.

How to detect it

A successful exploit will cause the target Go application to crash. To detect exploitation, monitor application and system logs for unexpected process terminations and panic stack traces. A panic originating from the `crypto/tls` package during certificate verification is a strong indicator of an attempted or successful exploit. Monitor application availability and restart counts; a sudden spike in restarts for a Go-based service could indicate repeated exploitation attempts.

• log_message_pattern: panic: crypto/tls: unknown public key algorithm
• log_message_pattern: panic: runtime error: invalid memory address or nil pointer dereference

What your security team should do

• Identify all applications built with Go and use tools like `go version -m <binary>` to determine which are built with a vulnerable version of the compiler.
• Prioritize patching and redeploying publicly exposed services or services that use mutual TLS (mTLS) for authentication, as they are the most likely targets.
• Update all build pipelines and developer environments to use a patched version of the Go compiler to ensure no new vulnerable software is created.