OpenSSL 1

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.

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.

1. 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.
2. 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.
3. 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.
4. 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.

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.

#!/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

Sources

1. Tenable plugin 121383
2. OpenSSL Security Advisory 2018-10-30
3. OpenSSL Security Advisory 2018-11-12
4. Ubuntu CVE-2018-0734
5. Red Hat RHSA-2019:0483
6. OpenCVE CVE-2018-0734
7. OpenCVE CVE-2018-5407
8. PortSmash proof of concept