[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.1412091542220.20143@beijing.mitre.org>
Date: Tue, 9 Dec 2014 15:43:37 -0500 (EST)
From: "Steven M. Christey" <coley@...re.org>
To: Huzaifa Sidhpurwala <huzaifas@...hat.com>
cc: oss-security@...ts.openwall.com,
Mitre CVE assign department <cve-assign@...re.org>
Subject: Re: CVE question: Return of POODLE
Huzaifa Sidhpurwal said:
>It seems some TLS implementations may be vulnerable to POODLE like attack if
>they use SSL 3.0 type padding and the padding bytes are not checked by the
>implementation.
>
>https://www.imperialviolet.org/2014/12/08/poodleagain.html
>https://devcentral.f5.com/articles/cve-2014-8730-padding-issue-8151
>
>CVE-2014-8730 was assigned to this issue (by MITRE i suppose) and its not
>clear if this CVE has been assigned to their code or to the protocol
>weakness.
CVE-2014-8730 was reserved by F5 from the MITRE CNA, but at the time
of assignment, we were not aware of its potential applicability to
other designs or implementations.
>I have not checked if any implementations are vulnerable, but could MITRE
>please confirm if its ok to reuse this CVE if any crypto-libs are found
>vulnerable, or if they plan to assign another CVE id?
The short answer is that based on what I've seen, each affected
implementation might need its own CVE ID.
If this is a fundamental design issue within TLS - that is, if any
implementation that strictly complies with the protocol will also have
this vulnerability - then CVE-2014-8730 is appropriate.
But, if implementations can avoid this issue while also strictly
conforming with the protocol, then separate CVEs per implementation
would be needed. Currently, we treat "behavior that is undefined or
unspecified by the specification" as an implementation issue, since an
implementation could have avoided a vulnerability while still
complying with the specification.
The ImperialViolet disclosure says: "TLS's padding is a subset of
SSLv3's padding so, technically, you could use an SSLv3 decoding
function with TLS and it would still work fine. It wouldn't check the
padding bytes but that wouldn't cause any problems in normal
operation. However, if an SSLv3 decoding function was used with TLS,
then the POODLE attack would work, even against TLS connections."
This strongly suggests an implementation issue, since it appears that a
TLS-compliant implementation could avoid a padding check without violating
the TLS spec. Further, as described discussed in the URLs below, a TLS
implementation "SHOULD" check the padding bytes, but it is not required to
do so (i.e., there is no "MUST" requirement):
https://www.ietf.org/mail-archive/web/tls/current/msg14058.html
https://www.ietf.org/mail-archive/web/tls/current/msg14072.html
So, it seems to me that separate CVE identifiers would be needed for
such implementations.
- Steve
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.
