Loading vulnerability…
OpenSSL DTLS Buffered Handshake Message Memory Exhaustion
CVE-2016-2179 is a resource-lifetime management vulnerability in OpenSSL's DTLS implementation. Out-of-order handshake messages are buffered until they can be processed, but flawed cleanup logic can retain unused messages after the handshake completes. An attacker can leave approximately 15 unnecessary messages buffered per connection. With the default maximum message size of 100 KB, this consumes approximately 1.5 MB of additional memory per connection until the connection closes. Maintaining many crafted DTLS connections can exhaust server memory and cause denial of service. The issue affects unpatched OpenSSL releases before 1.1.0, with fixes available in the 1.0.1 and 1.0.2 branches.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
A remote attacker can cause excessive memory consumption on an affected DTLS server, potentially exhausting available memory and causing the server process to terminate unexpectedly. The demonstrated impact is loss of availability; this vulnerability does not establish confidentiality or integrity compromise.
If you can’t patch tonight, do this now.
Until patched, restrict network access to affected DTLS services and disable unnecessary DTLS functionality. Limiting concurrent DTLS connections and enforcing connection lifetimes can reduce accumulated memory consumption because retained messages are released when connections close. Monitor memory usage and unexpected service termination. These measures reduce exposure but do not correct the underlying cleanup flaw.
Patch, then assume compromise.
Apply a vendor-supported update containing the fix. The upstream fixes were released in OpenSSL 1.0.1u and 1.0.2i. Red Hat addressed the issue through RHSA-2016:1940, including OpenSSL 1.0.1e-48.el6_8.3 for RHEL 6 and 1.0.1e-51.el7_2.7 for RHEL 7. Restart all services linked against the updated OpenSSL library, or reboot the system, to load the corrected code. For current deployments, use a supported OpenSSL or operating-system release rather than remaining on an obsolete branch.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
9 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.