tenable:121383 · OpenSSL 1.0.2 < 1.0.2q Multiple Vulnerabilities

01 · The Real Story

This is more like hearing a safe click through the wall than finding the vault door wide open

Tenable plugin 121383 flags OpenSSL versions before 1.0.2q for two issues: CVE-2018-0734, a timing side-channel in DSA signature generation, and CVE-2018-5407 (*PortSmash*), a local SMT/Hyper-Threading side-channel affecting OpenSSL ECC scalar multiplication. Upstream marks both as Low severity. The affected upstream range for the plugin is OpenSSL 1.0.2 through 1.0.2p, but distro backports matter: many enterprise Linux builds kept older-looking version strings while shipping the fixes.

The vendor's MEDIUM label overstates operational risk in most enterprise fleets. Both bugs are about private-key leakage via timing, not direct remote code execution or easy network compromise; one requires a very specific DSA signing path, and the other requires local co-residency on the same SMT-capable system plus careful measurement. The impact can be serious *if* you have the right cryptographic workload and attacker position, but the reachable population is narrow and the exploitation friction is high.

"This is old, real, and mostly impractical: two low-grade side channels hiding behind a medium label."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Land on a host that actually runs vulnerable OpenSSL

The attacker first needs a target using upstream OpenSSL < 1.0.2q or an unbackported distro build. Nessus detects this by version only, so the finding often includes patched vendor builds that still report 1.0.2k or 1.0.2g. In practice the first job is separating *real* vulnerable binaries from backported packages.

Conditions required:

OpenSSL is present and the vulnerable code path is in use
The scanner result is not a false positive from distro backporting

Where this breaks in practice:

RHEL, Ubuntu, Debian, and others commonly backported fixes without changing the upstream-looking version
Many hosts carry OpenSSL but never expose the affected signing paths

Detection/coverage: Good version-based coverage from Nessus/Tenable; weak exploitability coverage. Package-level verification is required.

STEP 02

Find the right crypto primitive

For CVE-2018-0734, the attacker needs a service performing DSA signatures through vulnerable OpenSSL code. For CVE-2018-5407, the target must use the affected ECC scalar multiplication path during ECDSA/ECDH operations. That already narrows the population: DSA is uncommon in modern enterprise TLS, and not every OpenSSL consumer hits the affected ECC implementation in a useful way.

Conditions required:

For CVE-2018-0734, DSA signing is enabled and used
For CVE-2018-5407, ECC operations occur on a shared SMT-capable CPU

Where this breaks in practice:

Modern PKI and TLS deployments rarely rely on DSA
Some environments use RSA certs or hardware-backed crypto instead
Many systems expose OpenSSL libraries without exposing the affected workload

Detection/coverage: Scanners usually do not validate whether DSA or the vulnerable ECC path is actually exercised.

STEP 03

Collect usable side-channel traces

The attacker then needs a high-quality timing vantage. For PortSmash, that usually means running local code on the same physical core sibling thread and using the public bbbrumley/portsmash research PoC or equivalent tooling; for the DSA issue, it means a custom timing harness collecting enough signature timing variation to infer key material. This is not spray-and-pray exploitation; it is measurement-heavy research-grade work.

Conditions required:

Attacker can gather repeated observations with low noise
For PortSmash, attacker has local execution and SMT co-residency

Where this breaks in practice:

Scheduler noise, virtualization, container placement, and CPU contention reduce signal quality
Disabling SMT/Hyper-Threading kills the PortSmash path
Remote timing collection over noisy networks is unreliable

Detection/coverage: EDR may catch the local foothold or unusual co-resident process behavior, but there is no clean network IDS signature for the side channel itself.

STEP 04

Recover the private key and turn it into impersonation

If the attacker succeeds, the prize is key material, not shell access. That can enable service impersonation, forged signatures, or decryption opportunities depending on how the recovered key is used. The blast radius is therefore bounded by where that specific key is trusted, not by arbitrary code execution across the host.

Conditions required:

Successful key recovery from the side channel
Recovered key is still trusted and usable in production

Where this breaks in practice:

Many keys are rotated, segmented, or isolated per service
Compromising one key does not automatically mean host takeover

Detection/coverage: No reliable direct detection of key theft from the side channel; downstream signals are certificate misuse, anomalous authentication, or suspicious key rotation events.

03 · Compensating Control

Eliminate DSA use — Find and retire DSA certificates, host keys, or signing workflows so CVE-2018-0734 becomes irrelevant. For a LOW verdict there is no SLA; treat as backlog hygiene, but get this done in the next normal crypto hygiene cycle because DSA is legacy debt you should not be carrying anyway.

Isolate sensitive crypto workloads — Keep untrusted code, shared-user workloads, and hostile tenants away from systems that hold valuable private keys. For a LOW verdict there is no SLA; treat as backlog hygiene, but prioritize shared jump boxes, CI workers, VDI, and multi-tenant Linux hosts first.

Disable SMT on crown-jewel shared hosts if patching lags — For the small subset of systems where private keys are high value and local co-residency is plausible, disabling Hyper-Threading/SMT cuts off the PortSmash path. For a LOW verdict there is no SLA; treat as backlog hygiene, so use this selectively where business risk justifies the performance hit.

Verify backports before escalating — Do not burn cycles emergency-patching every 1.0.2k or 1.0.2g string you see; confirm whether your distro package already includes the fix. For a LOW verdict there is no SLA; treat as backlog hygiene, and this validation step will shrink false positives fast.

What doesn't work

A WAF does not help; these are not HTTP parsing bugs or request-shaping issues.
Perimeter ACLs do little for PortSmash because the hard prerequisite is local execution/co-residency, not internet reachability.
Certificate expiration monitoring alone does not help; if the key is leaked, the cert can still be abused until you rotate and replace trust.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No evidence these CVEs are in CISA KEV. I found no credible reporting of broad active exploitation campaigns; this looks like research/PoC territory, not commodity tradecraft.
Proof-of-concept availability	`CVE-2018-5407` has a public research PoC: `bbbrumley/portsmash`. For `CVE-2018-0734`, public exploit indexing exists, but I did not find a widely cited, turnkey operational exploit.
EPSS	`CVE-2018-0734`: about 5.1% EPSS (`0.05057`), roughly 90th percentile. `CVE-2018-5407`: about 0.844% EPSS (`0.00844`), roughly 70th percentile.
KEV status	`CVE-2018-0734`: No. `CVE-2018-5407`: No.
CVSS reality check	Tenable anchors on `CVE-2018-0734` at `CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N` = 5.9 Medium. That network vector hides the real-world catch: exploitation still needs a fragile timing leak and a DSA signing workload.
Affected versions	Upstream affected range is `OpenSSL 1.0.2` through `1.0.2p`. Tenable plugin `121383` keys on any detected version before `1.0.2q`.
Fixed versions and backports	Upstream fix target is `1.0.2q`. Backported distro examples include Ubuntu 16.04 `1.0.2g-1ubuntu4.14`, Ubuntu 18.04 openssl1.0 `1.0.2n-1ubuntu5.2`, and RHEL 7 `openssl-libs-1.0.2k-16.el7_6.1` for the PortSmash erratum.
Scanning and exposure reality	There is no useful Shodan/Censys/GreyNoise style fingerprint for these flaws because they are not straightforward remote network exploits. Exposure is driven by package version, crypto algorithm use, and host co-residency conditions.
Disclosure timeline	`CVE-2018-0734` advisory: 2018-10-30. `CVE-2018-5407` advisory: 2018-11-12. OpenSSL `1.0.2q` shipped on 2018-11-20.
Researchers	`CVE-2018-0734` was reported by Samuel Weiser. `CVE-2018-5407` was reported by Alejandro Cabrera Aldaya, Billy Brumley, Sohaib ul Hassan, Cesar Pereida Garcia, and Nicola Tuveri.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to LOW (2.8/10)

Why this verdict

Downward pressure: CVE-2018-5407 is post-initial-access. PortSmash requires local code execution plus SMT co-residency on the same host, which implies the attacker is already on the box or co-tenant system.
Downward pressure: CVE-2018-0734 needs the right crypto workload. A host must actually perform vulnerable DSA signing, and that is a niche path in modern enterprise TLS and PKI.
Downward pressure: both bugs are side channels, not one-shot exploits. High-quality timing collection, low-noise conditions, and repeated observations are required; EDR, scheduler noise, and ordinary infrastructure variance all work against the attacker.
Upward pressure: successful exploitation leaks real key material. If the attacker gets the key, they can impersonate a service or sign as it, so the impact is not zero.
Downward pressure: blast radius is key-scoped, not host-wide RCE. Even successful abuse usually compromises a certificate or signing key, not arbitrary execution across every vulnerable host.

Why not higher?

This is not remotely comparable to a pre-auth RCE or wormable service bug. The chain is choked by attacker-position requirements, workload specificity, and signal-collection difficulty, so the practical exposure across 10,000 enterprise hosts is much smaller than the package count suggests.

Why not lower?

I did not mark it IGNORE because private-key exposure is still meaningful, and some older estates do still carry DSA or shared multi-tenant crypto workloads. Also, the plugin maps to a genuinely old branch (1.0.2), so the finding can still help smoke out neglected cryptographic dependencies even if the immediate exploit risk is low.

06 · Verification

Crowdsourced verification payload.

Run this on the target Linux/Unix host that Nessus flagged, not from your scanner. Invoke it as bash verify_openssl_102q.sh with normal user rights for openssl version, but package-manager checks are more reliable with root or sudo available; it outputs exactly VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# verify_openssl_102q.sh
# Purpose: classify likely exposure for Tenable plugin 121383 / OpenSSL < 1.0.2q
# Output: VULNERABLE | PATCHED | UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

out_unknown() { echo "UNKNOWN"; exit 2; }
out_vuln() { echo "VULNERABLE"; exit 1; }
out_patched() { echo "PATCHED"; exit 0; }

OPENSSL_BIN="$(command -v openssl 2>/dev/null || true)"
PKG_INFO=""
VER_STR=""

if [ -n "$OPENSSL_BIN" ]; then
  VER_STR="$($OPENSSL_BIN version 2>/dev/null || true)"
fi

# Helper: package query
if command -v rpm >/dev/null 2>&1; then
  PKG_INFO="$(rpm -q openssl-libs openssl openssl1.0 2>/dev/null | tr '\n' ' ' )"
elif command -v dpkg-query >/dev/null 2>&1; then
  PKG_INFO="$(dpkg-query -W -f='${Package}=${Version} ' openssl libssl1.0.0 libssl1.0.2 2>/dev/null || true)"
elif command -v pkg_info >/dev/null 2>&1; then
  PKG_INFO="$(pkg_info 2>/dev/null | egrep '^(openssl|libssl)' | tr '\n' ' ' )"
fi

# Known patched distro backports for this advisory family
case "$PKG_INFO" in
  *"openssl-libs-1.0.2k-16.el7_6.1"*|*"openssl-1.0.2k-16.el7_6.1"*) out_patched ;;
  *"openssl=1.0.2g-1ubuntu4.14"*|*"libssl1.0.0=1.0.2g-1ubuntu4.14"*) out_patched ;;
  *"openssl1.0=1.0.2n-1ubuntu5.2"*|*"openssl1.0=1.0.2n-1ubuntu6.1"*) out_patched ;;
esac

# If no OpenSSL binary and no package metadata, we can't tell
if [ -z "$VER_STR" ] && [ -z "$PKG_INFO" ]; then
  out_unknown
fi

# Normalize binary version parsing for upstream-style builds
# Examples:
#   OpenSSL 1.0.2p  14 Aug 2018
#   OpenSSL 1.0.2q  20 Nov 2018
#   OpenSSL 1.1.1w  11 Sep 2023
BIN_VER="$(printf '%s' "$VER_STR" | awk '{print $2}')"

if [ -n "$BIN_VER" ]; then
  case "$BIN_VER" in
    3.*|2.*|1.1.*) out_patched ;;
    1.0.2q|1.0.2r|1.0.2s|1.0.2t|1.0.2u|1.0.2v|1.0.2w|1.0.2x|1.0.2y|1.0.2z|1.0.2za|1.0.2zb|1.0.2zc|1.0.2zd|1.0.2ze|1.0.2zf|1.0.2zg|1.0.2zh|1.0.2zi|1.0.2zj) out_patched ;;
    1.0.2|1.0.2a|1.0.2b|1.0.2c|1.0.2d|1.0.2e|1.0.2f|1.0.2g|1.0.2h|1.0.2i|1.0.2j|1.0.2k|1.0.2l|1.0.2m|1.0.2n|1.0.2o|1.0.2p) ;;
    *) ;;
  esac
fi

# If upstream-vulnerable binary version is seen, verify whether package naming strongly implies backporting
# If we have a vulnerable-looking upstream version but packaged distro metadata exists and is not recognized,
# prefer UNKNOWN over false-positive VULNERABLE.
if [ -n "$BIN_VER" ]; then
  case "$BIN_VER" in
    1.0.2|1.0.2a|1.0.2b|1.0.2c|1.0.2d|1.0.2e|1.0.2f|1.0.2g|1.0.2h|1.0.2i|1.0.2j|1.0.2k|1.0.2l|1.0.2m|1.0.2n|1.0.2o|1.0.2p)
      if [ -n "$PKG_INFO" ]; then
        out_unknown
      else
        out_vuln
      fi
      ;;
  esac
fi

# Fall back to package clues for obviously newer major branches
case "$PKG_INFO" in
  *"openssl=1.1."*|*"openssl=3."*|*"libssl3="*|*"libssl1.1="*) out_patched ;;
esac

out_unknown