Date: Tue, 5 Feb 2013 18:32:00 -0500 (EST) From: cve-assign@...re.org To: oss-security@...ts.openwall.com Cc: cve-assign@...re.org Subject: Re: CVE request: TLS CBC padding timing flaw in various SSL / TLS implementations -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here are the current CVE assignments related to the http://www.isg.rhul.ac.uk/tls/TLStiming.pdf paper: CVE-2013-0169 (a vulnerability in protocols that affects OpenSSL, PolarSSL, OpenJDK, and probably other implementations): "We present a family of attacks that apply to CBC-mode in all TLS and DTLS implementations that are compliant with TLS 1.1 or 1.2, or with DTLS 1.0 or 1.2 ... a MAC check must still be performed on some data to prevent the known timing attacks. But what data should be used for that calculation? The TLS 1.1 and 1.2 RFCs recommend checking the MAC as if there was a zero-length pad." CVE-2013-1618 "Opera were notified of our attacks in December 2012. Our attacks are addressed in Opera version 12.13, released 30/01/2013." (see the http://www.opera.com/support/kb/view/1044/ advisory) CVE-2013-1619 "The GnuTLS implementation of MEE-TLS-CBC deals with bad padding in a different way to that recommended in the RFCs: instead of assuming zero-length padding, it uses the last byte of plaintext to determine how many plaintext bytes to remove (whether or not those bytes are correctly formatted padding). ... This indicates that ignoring the recommendations of the RFCs can have severe security consequences." CVE-2013-1620 "Network Security Services (NSS) ... the same approach as taken in GnuTLS" CVE-2013-1621 "PolarSSL ... The code does not sanity check padlen before running the padding check, meaning that out-of-bounds comparisons may be made" (a possible denial-of-service issue for some applications) CVE-2013-1622 "PolarSSL ... it does not perform any MAC check if this sanity check fails, but instead exits immediately. This would render the implementation vulnerable to a simple timing-based distinguishing attack." (requires a non-default configuration with "TLS alert messages when decryption errors are encountered") CVE-2013-1623 "yaSSL ... CyaSSL code does not perform proper padding checks, but instead just examines the last byte of plaintext and uses this to determine how many bytes to remove." CVE-2013-1624 "The Bouncy-Castle code does careful sanity checking of the padding length (as indicated by the last byte of plaintext) but treats the padding as having length 1 ... This deviates slightly from the recommendation of the RFCs to treat the padding as having length zero" It is possible that MITRE will assign a CVE name for an F5 vulnerability later. (This is referenced by "F5 were notified of our attacks in December 2012. They have informed us that their TLS dataplane traffic is not vulnerable due to cryptographic offload, but that local management ports and virtual editions may be vulnerable. They also informed us that F5s hotfix for this issue will follow shortly after OpenSSL issues their patch." but that statement may mean that the issue existed in OpenSSL code that was shipped within F5 products.) Other CVEs related to other products are obviously also possible. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (SunOS) iQEcBAEBAgAGBQJREZZAAAoJEGvefgSNfHMdGoYH/jJSc4IiM14eSTfWU24QoKig ofmtSlYDWMcvC7p4cbFchWTIPynGGo7Z2WgZ1qRzVpeH5DcXAJbJB7k9W6wz6HN7 NviLEliOV9ZikeQ2tZGKZXLVSKMAQT2ouHgUbK8QgGgE3z31p6BCS0YaYgNk6d7c btCXrK8pE6mOUUE+haXVqAA/1X0F4TldzHZ0z/st3vga7hSnEe2SJaqO5J9WupVg pPwhBnuShXu6KmcIqmskH7wtMERjMkeFe5WPrFC0JuOMBM0qhBt2pJfLOW42DE3H +ZoQZwFEfOUys/qPq+BNo9+mucutY9bdyrRLTmlFaAQ5LLUuXBi1HyvZWCeZyys= =+Wxi -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ