DTLS Plaintext Recovery Attack (CVE-2011-4108) ============================================== Nadhem Alfardan and Kenny Paterson have discovered an extension of the Vaudenay padding oracle attack on CBC mode encryption which enables an efficient plaintext recovery attack against the OpenSSL implementation of DTLS. Their attack exploits timing differences arising during decryption processing. A research paper describing this attack can be found at http://www.isg.rhul.ac.uk/~kp/dtls.pdf Thanks go to Nadhem Alfardan and Kenny Paterson of the Information Security Group at Royal Holloway, University of London (www.isg.rhul.ac.uk) for discovering this flaw and to Robin Seggelmann <seggelmann> and Michael Tuexen <tuexen> for preparing the fix. Affected users should upgrade to OpenSSL 1.0.0f or 0.9.8s. Reference: http://openssl.org/news/secadv_20120104.txt
Seems to be the fix here: http://cvs.openssl.org/chngview?cn=21942 (0.9.8) http://cvs.openssl.org/chngview?cn=21931 (1.0.0)
Research paper states following: In TLS, MAC errors must result in connection termination. In DTLS, the receiving implementation may simply discard the offending record and continue with the connection. [ ... ] Not sending error messages clearly complicates the task of the adversary, since it is the presence of these messages (and their timings) that allowed previous attacks on TLS; however not terminating the connection in the event of an error proves to be very useful in building a reliable padding oracle that can be accessed as many times as the adversary wishes. Described "discard and continue" behaviour is not what OpenSSL DTLS implementation used originally: http://rt.openssl.org/Ticket/Display.html?id=2229&user=guest&pass=guest Relevant commit removing connection drop and error alert message on errors: http://cvs.openssl.org/chngview?cn=19576 (head, 19575 for 1.0.0, 19574 for 0.9.8)
Actually we do not have this changeset (19574) in the RHEL-5 openssl package.
And we do not have the changeset 19575 in the RHEL-6 openssl package either.
Right, I failed to mention that we don't have that change in RHEL-5 and RHEL-6 openssl. Though my understanding is that connection dropped and alert sent back should still be good enough for the attack, making it similar to the older TLS attack. Sounds like 19574/19575 is what we should pick in addition to 21942/21931.
openssl-1.0.0f-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
Created mingw32-openssl tracking bugs for this issue Affects: fedora-all [bug 773330] Affects: epel-5 [bug 773331]
Created attachment 555132 [details] Proposed patch for RHEL-5 openssl The DTLS implementation in RHEL-5 is multiple serious bugfixes behind the current openssl upstream. This patch fixes not only the exact CVE problem (which is not exactly reproducible on RHEL-5 anyway but might be reproducible with different techniques), but it fixes also a few more serious problems in the implementation. It still does not make it completely on-par with the current upstream.
openssl-1.0.0f-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
The fix for this issue introduced a regression, which may allow remote attacker to crash DTLS server. That issue is tracked via CVE-2012-0050 - bug #782795.
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2012:0060 https://rhn.redhat.com/errata/RHSA-2012-0060.html
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2012:0059 https://rhn.redhat.com/errata/RHSA-2012-0059.html
Statement: This issue did not affect the versions of openssl as shipped with Red Hat Enterprise Linux 4 as they do not include support for DTLS protocol.
This issue has been addressed in following products: JBoss Enterprise Application Platform 6.0.0 Via RHSA-2012:1308 https://rhn.redhat.com/errata/RHSA-2012-1308.html
This issue has been addressed in following products: JBoss Enterprise Application Platform 5.1.2 Via RHSA-2012:1307 https://rhn.redhat.com/errata/RHSA-2012-1307.html
This issue has been addressed in following products: JBoss Enterprise Web Server 1.0.2 Via RHSA-2012:1306 https://rhn.redhat.com/errata/RHSA-2012-1306.html