It was found that when doing handshake/renegotiation, it's possible to bypass DTLS replay protection by sending a record for the next epoch (which does not have to decrypt or have a valid MAC), with a very large sequence number. This means the right hand edge of the window is moved very far to the right, and all subsequent legitimate packets are dropped causing a denial of service.
Created openssl101e tracking bugs for this issue:
Affects: epel-5 [bug 1369116]
Created openssl tracking bugs for this issue:
Affects: fedora-all [bug 1369114]
Created mingw-openssl tracking bugs for this issue:
Affects: fedora-all [bug 1369115]
Covered now by OpenSSL upstream security advisory and fixed in versions 1.0.1u and 1.0.2i.
DTLS replay protection DoS (CVE-2016-2181)
A flaw in the DTLS replay attack protection mechanism means that records that
arrive for future epochs update the replay protection "window" before the MAC
for the record has been validated. This could be exploited by an attacker by
sending a record for the next epoch (which does not have to decrypt or have a
valid MAC), with a very large sequence number. This means that all subsequent
legitimate packets are dropped causing a denial of service for a specific
OpenSSL 1.0.2 DTLS users should upgrade to 1.0.2i
OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1u
This issue was reported to OpenSSL on 21st November 2015 by the OCAP audit team.
The fix was developed by Matt Caswell of the OpenSSL development team.
This issue has been addressed in the following products:
Red Hat Enterprise Linux 6
Red Hat Enterprise Linux 7
Via RHSA-2016:1940 https://rhn.redhat.com/errata/RHSA-2016-1940.html