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.