OpenSSL 1.1.1 < 1.1.1zb Vulnerability

CVE-2024-9143 is an out-of-bounds memory read/write in OpenSSL's low-level GF(2^m) binary elliptic curve APIs — specifically EC_GROUP_new_curve_GF2m(), EC_GROUP_new_from_params(), and the BN_GF2m_*() family. When an application passes *untrusted explicit values* for the field polynomial into these APIs, the underlying BN_GF2m_poly2arr() function can walk past array boundaries. The bug affects every OpenSSL branch: 1.0.2 < 1.0.2zl, 1.1.1 < 1.1.1zb, 3.0 < 3.0.16, 3.1 < 3.1.8, 3.2 < 3.2.4, and 3.3 < 3.3.3. Disclosed 16 October 2024.

Tenable labels this MEDIUM (CVSS 4.3) but even OpenSSL's own project rates it LOW. The reason is simple: virtually no production application feeds untrusted explicit binary-curve parameters into these low-level APIs. Standard TLS handshakes use named curves. X.509 certificate processing uses X9.62 encoding, which *cannot represent* the malformed input required to trigger the bug. You would need a bespoke application that deliberately parses attacker-controlled curve definitions through the raw EC math layer — a scenario that borders on academic. Tenable's MEDIUM overstates the real-world risk; OpenSSL's own LOW is the honest call.

Why this verdict

• Unreachable code path in production: Standard TLS handshakes, X.509 certificate parsing, and all common OpenSSL consumers (nginx, Apache, curl, Python ssl, Node.js) use named curves or X9.62 encoding. The vulnerable BN_GF2m_poly2arr() function is only reached via exotic explicit binary curve parameter APIs that no mainstream application calls with untrusted input.
• No exploitation evidence or weaponization: Zero in-the-wild exploitation, no KEV listing, EPSS at 0.058. The 17 GitHub PoCs demonstrate controlled crashes via direct API calls — not network-deliverable exploits.
• Role multiplier: OpenSSL is deployed on domain controllers, hypervisors, CI/CD servers, and network appliances — all high-value roles. However, the vulnerable code path (explicit GF(2^m) curve construction from untrusted input) is not exercised by any of these roles' standard operations (TLS termination, LDAPS, SSH, HTTPS). The blast radius is therefore zero in practice across all deployment roles, because reachability — not just presence of the library — determines exploitability. The role-multiplier floor does not apply when the code path is provably unreachable in standard configurations.
• OpenSSL's own LOW rating is authoritative: The project that wrote the code assessed it as LOW severity, explicitly noting the extreme narrowness of the vulnerable scenario. Tenable's MEDIUM (4.3) overweights theoretical network reachability without accounting for API-level unreachability.

Why not higher?

Upgrading to MEDIUM or above would require evidence that production applications actually feed untrusted explicit binary curve parameters into the low-level GF(2^m) APIs. No such application has been identified. The 17 PoCs all require direct programmatic invocation — none demonstrate a network-deliverable attack. Without a reachable attack surface, severity inflation is unjustified.

Why not lower?

IGNORE would be appropriate only if the code were entirely dead. While the GF(2^m) APIs are rarely used, they *are* compiled into the library and theoretically callable. A custom or niche application could conceivably use them with untrusted input. Retaining LOW acknowledges this tail risk and ensures the fix is picked up in normal patching cycles rather than being completely dropped.

1. Audit applications for GF(2^m) API usage — Grep your codebase and linked libraries for calls to EC_GROUP_new_curve_GF2m, EC_GROUP_new_from_params, and BN_GF2m_poly2arr. If none are found (overwhelmingly likely), document the finding and deprioritize. This is backlog hygiene — no mitigation SLA applies at LOW severity.
2. Patch OpenSSL in your normal OS update cycle — Roll the fix in with your next quarterly or annual OS patching window. For RHEL 8 / Amazon Linux 2 / Ubuntu 20.04, apply the vendor-backported openssl package update. No emergency change window is warranted.
3. Consider migrating off OpenSSL 1.1.1 — OpenSSL 1.1.1 reached end-of-life on 2023-09-11. Continued use requires premium support contracts for security patches like 1.1.1zb. Plan migration to OpenSSL 3.x as part of OS lifecycle (RHEL 9, Ubuntu 22.04+). This is a strategic item, not an urgent CVE response.

Run on each target host as any user. Example: bash check_cve_2024_9143.sh. No elevated privileges required — it simply reads the OpenSSL version string.

#!/usr/bin/env bash\n# check_cve_2024_9143.sh — Detect OpenSSL 1.1.1 < 1.1.1zb (CVE-2024-9143)\n# Run on the target host. No root required.\n# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN\n\nset -euo pipefail\n\nVERSION=$(openssl version 2>/dev/null || true)\n\nif [[ -z \"$VERSION\" ]]; then\n  echo \"UNKNOWN — openssl binary not found in PATH\"\n  exit 2\nfi\n\n# Extract version string, e.g. \"1.1.1za\" or \"3.0.16\"\nVER=$(echo \"$VERSION\" | grep -oP '\\d+\\.\\d+\\.\\d+[a-z]*')\n\n# Check if it is in the 1.1.1 branch\nif [[ \"$VER\" =~ ^1\\.1\\.1 ]]; then\n  SUFFIX=${VER#1.1.1}\n  # 1.1.1zb or later is patched. Suffixes: a < b < ... < z < za < zb\n  if [[ -z \"$SUFFIX\" ]]; then\n    echo \"VULNERABLE — OpenSSL $VER (no letter suffix, pre-1.1.1a)\"\n    exit 1\n  fi\n  # Compare suffix lexicographically; zb is the fix\n  # Suffixes go: a..z, za, zb, zc...\n  if [[ ${#SUFFIX} -eq 1 ]]; then\n    echo \"VULNERABLE — OpenSSL $VER (prior to 1.1.1zb)\"\n    exit 1\n  elif [[ ${#SUFFIX} -eq 2 ]]; then\n    if [[ \"$SUFFIX\" < \"zb\" ]]; then\n      echo \"VULNERABLE — OpenSSL $VER (prior to 1.1.1zb)\"\n      exit 1\n    else\n      echo \"PATCHED — OpenSSL $VER (>= 1.1.1zb)\"\n      exit 0\n    fi\n  else\n    echo \"PATCHED — OpenSSL $VER (suffix beyond zb)\"\n    exit 0\n  fi\nelif [[ \"$VER\" =~ ^3\\. ]]; then\n  echo \"UNKNOWN — OpenSSL 3.x branch detected ($VER). Check against 3.0.16/3.1.8/3.2.4/3.3.3 separately.\"\n  exit 2\nelse\n  echo \"UNKNOWN — Unexpected OpenSSL version: $VER\"\n  exit 2\nfi

Sources

1. Tenable Plugin 209149
2. OpenSSL 1.1.1 Vulnerabilities Page
3. NVD — CVE-2024-9143
4. Red Hat CVE Page
5. SentinelOne Vulnerability Database
6. Snyk — CVE-2024-9143
7. Extreme Networks Advisory SA-2024-111