Re: CVE question: Return of POODLE

["Steven M. Christey" <coley () mitre org>]

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