OpenSSL 1.1.1 < 1.1.1v Multiple Vulnerabilities

CVE-2023-3446 and CVE-2023-3817 are algorithmic complexity bugs in OpenSSL's DH_check(), DH_check_ex(), and EVP_PKEY_param_check() functions. When these functions process a crafted DH key with an excessively large p or q parameter, they enter a computationally expensive loop that can cause significant delays. The impact is purely denial-of-service — no memory corruption, no code execution, no data leak. Affected versions: OpenSSL 1.1.1 through 1.1.1u (fixed in 1.1.1v, released July 2023). The same bugs affected OpenSSL 3.0.x and 3.1.x lines and were fixed in their respective releases.

The vendor's MEDIUM / CVSS 5.3 rating is generous for the real-world risk here. Even the CVSS vector acknowledges only Low availability impact (A:L), meaning partial degradation rather than a full crash. Tenable's own VPR engine scored this at 1.2 (Low) — among the lowest possible — reflecting zero exploitation activity, no weaponized PoC, and a very narrow trigger path. Most production TLS servers never call DH_check() on untrusted input during normal handshake flows; the function is primarily used in key-generation and parameter-validation utilities. The vendor MEDIUM overstates the operational risk.

Why this verdict

• DoS-only, Low availability impact: The CVSS vector itself rates availability as A:L — partial degradation, not service crash. No path to code execution, data exfiltration, or privilege escalation exists.
• Narrow trigger path: The vulnerable functions (DH_check, DH_check_ex, EVP_PKEY_param_check) are parameter-validation utilities. Standard TLS handshake flows using ECDHE — which dominate modern deployments — never invoke them on external input.
• Zero exploitation evidence: No KEV listing, no known campaigns, no weaponized PoC, and VPR 1.2 (among the lowest possible scores). Three years post-disclosure with no exploitation activity is a strong negative signal.
• Role multiplier: OpenSSL runs on network edge appliances (F5, Citrix, HAProxy), identity providers, and CI/CD infrastructure. In *all* these high-value roles, the impact ceiling remains DoS — not compromise, not lateral movement, not data theft. A DoS against a load balancer is operationally disruptive but does not meet the floor criteria of domain takeover, fleet compromise, or supply-chain pivot. The floor rule does not apply.

Why not higher?

To warrant MEDIUM, we'd need either active exploitation, a realistic path to service-level outage (A:H), or evidence that a meaningful fraction of deployments call DH_check() on untrusted parameters. None of these conditions hold. The VPR 1.2 is the market's clearest signal that this is background noise.

Why not lower?

We don't drop to IGNORE because OpenSSL 1.1.1 is end-of-life since September 2023 — any host still running it has a broader hygiene problem, and this finding serves as a useful signal to drive migration. The CVEs are also real bugs with a theoretically exploitable path, even if impractical.

1. Prioritize migration off OpenSSL 1.1.1 entirely — OpenSSL 1.1.1 has been EOL since September 2023. These specific CVEs are low-risk, but the branch receives no new security patches. Treat this finding as a migration trigger toward OpenSSL 3.x. No mitigation SLA for LOW — treat as backlog hygiene, but the EOL status should elevate migration priority in your roadmap.
2. Audit application code for DH_check() on untrusted input — Grep your codebase and vendor configurations for calls to DH_check(), DH_check_ex(), or EVP_PKEY_param_check() that operate on externally supplied parameters. If none exist (likely), this CVE is not reachable in your environment.
3. Enforce ECDHE-only cipher suites — Disable finite-field DH key exchange in TLS configurations (DHE-* cipher suites). This eliminates the DH parameter exchange path entirely and is a best practice regardless of this CVE.
4. Apply OS vendor backport patches — RHEL, Ubuntu, Debian, and SUSE all shipped backported fixes. If you can't migrate to OpenSSL 3.x yet, apply your distro's patched 1.1.1 package as an interim step.

Run this on each target host to check the installed OpenSSL version. Requires read access to the openssl binary (no root needed). Example: bash check_openssl_dh.sh

#!/bin/bash
# noisgate verification for Tenable 178475
# CVE-2023-3446 / CVE-2023-3817 — OpenSSL DH_check DoS
# Run on target host. No root required.

OPENSSL_BIN=$(command -v openssl 2>/dev/null)
if [ -z "$OPENSSL_BIN" ]; then
  echo "UNKNOWN — openssl binary not found in PATH"
  exit 2
fi

VERSION=$($OPENSSL_BIN version 2>/dev/null)
if [ $? -ne 0 ]; then
  echo "UNKNOWN — failed to query openssl version"
  exit 2
fi

echo "Detected: $VERSION"

# Extract version string
if echo "$VERSION" | grep -qE 'OpenSSL 1\.1\.1[a-u]?[ -]'; then
  # Matches 1.1.1 through 1.1.1u (letters a-u)
  echo "VULNERABLE — $VERSION is affected by CVE-2023-3446 / CVE-2023-3817"
  echo "NOTE: OpenSSL 1.1.1 reached end-of-life on 2023-09-11"
  exit 1
elif echo "$VERSION" | grep -qE 'OpenSSL 1\.1\.1[v-z]'; then
  echo "PATCHED — $VERSION includes fixes for CVE-2023-3446 / CVE-2023-3817"
  echo "WARNING: OpenSSL 1.1.1 is still end-of-life. Plan migration to 3.x."
  exit 0
elif echo "$VERSION" | grep -qE 'OpenSSL 3\.[0-9]'; then
  echo "PATCHED — $VERSION (OpenSSL 3.x branch). Verify >= 3.0.10 or >= 3.1.2 for full fix."
  exit 0
else
  echo "UNKNOWN — version string not recognized: $VERSION"
  exit 2
fi

Sources

1. Tenable Plugin 178475
2. OpenSSL 1.1.1 Vulnerabilities
3. OpenSSL 1.1.1 EOL Announcement
4. CVE-2023-3446 — NVD
5. CVE-2023-3817 — NVD
6. Red Hat CVE-2023-3817
7. OpenSSL 1.1.1 Release Notes