Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 5 Feb 2013 18:32:00 -0500 (EST)
Subject: Re: CVE request: TLS CBC padding timing flaw in various SSL / TLS implementations

Hash: SHA1

Here are the current CVE assignments related to the 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."

"Opera were notified of our attacks in December 2012. Our attacks
are addressed in Opera version 12.13, released 30/01/2013." (see
the advisory)

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

"Network Security Services (NSS) ... the same approach as taken in

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

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

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

"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 ]
Version: GnuPG v1.4.11 (SunOS)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.