CVE-2014-0221

What it actually does

The dtls1_get_message_fragment function in d1_both.c fails to properly validate DTLS hello messages during an invalid handshake, triggering unbounded recursion that crashes the client process.

Why it matters to the business

Systems relying on DTLS over UDP can be taken offline remotely, causing service outages and requiring manual restarts until patched.

How an attack unfolds

An unauthenticated remote attacker crafts a malformed DTLS hello message inside an invalid handshake sequence and sends it to a vulnerable OpenSSL DTLS endpoint, causing the server or client to recurse until it crashes.

How to fix it

Upgrade OpenSSL to 0.9.8za, 1.0.0m, or 1.0.1h (or later releases) on all affected products including Red Hat Enterprise Linux, Fedora, SUSE, openSUSE, and MariaDB distributions; disable DTLS where not required until patches are applied.

How to confirm the fix worked

Verify OpenSSL version strings match or exceed the fixed releases; test DTLS handshake handling with a fuzzer or the original proof-of-concept packet to confirm absence of crash; review package manifests on deployed systems.

Typical attack path

1. Scan for exposed DTLS services listening on UDP ports
2. Craft and transmit a DTLS ClientHello inside an invalid handshake
3. Trigger recursion in dtls1_get_message_fragment leading to stack exhaustion
4. Observe client or server crash and loss of service

How to detect it

Review DTLS-related crash logs, core dumps, and application event logs on systems running vulnerable OpenSSL versions; correlate UDP traffic spikes with DTLS ClientHello packets preceding service restarts.

What your security team should do

• Prioritize patching all internet-facing DTLS endpoints within 30 days given high EPSS score
• Inventory all systems using OpenSSL DTLS and schedule upgrades
• Apply network segmentation or UDP filtering to limit exposure of DTLS services
• Monitor for unusual DTLS handshake traffic volume as a temporary control