OpenSSL AES Timing Attack

This finding tracks back to Daniel J. Bernstein's 2005 paper *Cache-timing attacks on AES*, which demonstrated that the lookup-table (T-table) AES implementation in OpenSSL 0.9.7a leaked key material through CPU cache timing on an 850 MHz Pentium III running FreeBSD 4.8 — across a localhost loopback. Affected versions in Tenable's plugin are roughly OpenSSL ≤ 0.9.8 / 0.9.7g and earlier, before AES-NI was standard and before constant-time bitsliced AES (aes_core rewrites, AES-NI dispatch, and later EVP_aes_*_ctr) became the default code path. The plugin checks the reported OpenSSL banner version and flags anything in the susceptible range.

Vendor severity is MEDIUM (CVSS2 5.1 / 5.9) and that is *generous*. Even Bernstein's original demonstration required tens of millions of timed queries against the same key on the same loopback with a cooperative server, and over 20 years of follow-up research has shown the attack collapses across realistic WAN jitter, modern CPUs with AES-NI, and OpenSSL's later constant-time paths. There has never been a credible in-the-wild exploitation of CVE-2005-1797 against a production system. If your scanner is lighting this up, you are looking at *ancient OpenSSL*, and that is the real problem — not the timing attack.

Why this verdict

• No weaponized exploit exists — only Bernstein's 2005 academic PoC, which was demonstrated on localhost. 21 years and zero in-the-wild use.
• AES-NI obsoletes the attack — every CPU built since ~2010 (Westmere onward) executes AES in constant time via dedicated instructions, and OpenSSL auto-dispatches to AES-NI when available.
• TLS session-key rotation destroys the sample requirement — the attack needs a stable long-lived key across millions of operations; modern protocols don't provide one.
• WAN jitter kills the timing signal — Bernstein himself measured on loopback. Real network paths add microseconds of noise that overwhelm the nanosecond cache-line delta.
• Role multiplier: Even on a high-value role (TLS terminator, VPN concentrator, identity provider), the chain does not close because those roles have already migrated off OpenSSL 0.9.x or use AES-NI hardware. There is no realistic deployment where this CVE alone leads to fleet compromise.
• The real signal is the OpenSSL version itself — if you're running 0.9.8, you have an EOL crypto library with dozens of higher-severity issues. Fix that, and this finding disappears.

Why not higher?

MEDIUM would imply some realistic chance of practical exploitation against a real target. There isn't one. CVSS2 5.1 reflects the theoretical confidentiality impact assuming all preconditions are met, but the preconditions never align outside a lab. Going to HIGH would be indefensible — no KEV, no EPSS signal, no campaigns.

Why not lower?

Not IGNORE because the *presence* of OpenSSL 0.9.x as detected by this plugin is itself a meaningful finding — that codebase is EOL and carries unrelated, far more serious vulnerabilities. The plugin is useful as an indicator, even if the named CVE is not a real threat.

1. Treat the plugin hit as an EOL OpenSSL detector, not a timing-attack finding — If 17769 fires, your real exposure is *every other CVE* against OpenSSL 0.9.x — heartbleed-adjacent issues, padding-oracle, RNG, ASN.1 parsing. No mitigation SLA for the timing attack itself; address the EOL crypto library on the 365-day remediation track.
2. Inventory and migrate OpenSSL 0.9.x consumers to 3.0 LTS or 1.1.1 (where vendor-supported) — Use find / -name 'libcrypto.so.0.9*', package manager queries, and SBOM scans to locate. Migration is the only durable fix. Schedule within the 365-day window per noisgate remediation SLA.
3. Confirm AES-NI is in use on TLS-terminating hosts — Run openssl speed -evp aes-128-gcm and confirm the throughput is hardware-accelerated. If AES-NI is in play, this CVE is moot regardless of OpenSSL version.
4. Enforce TLS 1.2+ with ephemeral key exchange — ECDHE/DHE ciphersuites prevent any single AES key from being reused across enough sessions to be attackable. Disable static RSA key exchange and any AES-CBC-without-EtM legacy modes.

Run on the target Linux/Unix host as a non-privileged user. Invoke as ./check_openssl_aes_timing.sh — no arguments needed. Checks installed OpenSSL version against the affected range and reports AES-NI availability since that alone neutralizes the issue.

#!/usr/bin/env bash
# noisgate verification for tenable:17769 / CVE-2005-1797
# OpenSSL AES cache-timing vulnerability
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -u

echo "[*] noisgate :: OpenSSL AES timing attack check"

if ! command -v openssl >/dev/null 2>&1; then
  echo "UNKNOWN: openssl binary not found on PATH"
  exit 2
fi

VER_RAW=$(openssl version 2>/dev/null | awk '{print $2}')
echo "[*] OpenSSL version: ${VER_RAW}"

# Anything 0.9.x is in the affected, EOL range
if echo "${VER_RAW}" | grep -Eq '^0\.9\.'; then
  AFFECTED=1
else
  AFFECTED=0
fi

# AES-NI check — if present, the vulnerable T-table path is not used
AESNI=0
if grep -qw aes /proc/cpuinfo 2>/dev/null; then
  AESNI=1
  echo "[*] CPU reports AES-NI support"
fi

# Confirm OpenSSL is actually dispatching to AES-NI
if command -v openssl >/dev/null 2>&1; then
  if OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp aes-128-cbc 2>&1 \
       | grep -q 'aes-128-cbc'; then
    : # speed test ran; presence of HW path inferred from AESNI flag
  fi
fi

if [ "${AFFECTED}" -eq 1 ] && [ "${AESNI}" -eq 0 ]; then
  echo "VULNERABLE: OpenSSL ${VER_RAW} (0.9.x EOL) without AES-NI dispatch"
  exit 1
fi

if [ "${AFFECTED}" -eq 1 ] && [ "${AESNI}" -eq 1 ]; then
  echo "VULNERABLE: OpenSSL ${VER_RAW} is EOL — timing attack mitigated by AES-NI, but library MUST be upgraded for unrelated CVEs"
  exit 1
fi

echo "PATCHED: OpenSSL ${VER_RAW} is outside the affected 0.9.x range"
exit 0

Sources

1. Tenable plugin 17769
2. Bernstein – Cache-timing attacks on AES (2005)
3. OpenSSL release strategy / EOL policy
4. Attacking AES Using Bernstein's Attack on Modern Processors (Springer)
5. A Cache Timing Attack on AES in Virtualization Environments (FC12)
6. Countermeasures against Bernstein's remote cache timing attack
7. Intel AES-NI overview
8. CISA KEV Catalog