Home page logo
/

oss-sec logo oss-sec mailing list archives

Re: CVE request: TLS CBC padding timing flaw in various SSL / TLS implementations
From: cve-assign () mitre org
Date: Tue, 5 Feb 2013 18:32:00 -0500 (EST)

-----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-----


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault