OpenSSL: timing side channel in DSA signing can leak the private key

CVSS 5.9CVE-2018-0734Kernel, userspace & hypervisorcurated

Impact

Variations in the DSA signing path leak information an attacker can accumulate across many observed signatures to recover the private key. On a GPU fleet the practical concern is any long-lived DSA key used by an OpenSSL-linked service - SSH host material, internal TLS, or signing services - where an attacker who can request large numbers of signatures and measure timing precisely may eventually reconstruct it. The attack needs many samples and a low-noise measurement path, which is why the record scores it high-complexity rather than critical; a co-tenant on the same host is a far better position for it than a remote client.

Who can reach it

An attacker able to trigger and precisely time many DSA signing operations - a local or co-resident user on the node is the realistic case, a remote client over a noisy network much less so. No special privileges beyond being able to request signatures.

What to do

Upgrade OpenSSL to 1.1.1a, 1.1.0j or 1.0.2q, or the distribution backport (Red Hat shipped it in RHSA-2019:2304 and RHSA-2019:3700), and restart every service linked against the library. Keys that may have been exposed should be rotated, not just re-signed by a patched library. Prefer retiring DSA keys entirely where the service supports ECDSA or Ed25519.

References

https://nvd.nist.gov/vuln/detail/CVE-2018-0734 https://access.redhat.com/errata/RHSA-2019:2304 https://access.redhat.com/errata/RHSA-2019:3700

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.