RE: Patch to mitigate CVE-2014-3566 (POODLE)
This patch seems to be the cause of a failure in ‘make errors’: /usr/bin/perl util/ck_errf.pl -strict */*.c */*/*.c /usr/bin/perl util/mkerr.pl -recurse -write Invalid error code SEGMENT_SIZE Invalid error code PRIME_SANITY_LIMIT !! ERROR: SSL reason code 373 assigned twice (collision at SSL_R_RFC5430_CURVE_MISMATCH) I’m guessing this patch (or part of it) was incorporated into 1.0.1j, because this error, and the causal code, showed up after we synced to 1.0.1j. The problem is that both SSL_R_INAPPROPRIATE_FALLBACK (added in this patch) and SSL_R_RFC5430_CURVE_MISMATCH are set to 373. I think the solution is to change the value of SSL_R_INAPPROPRIATE_FALLBACK to 374 (which appears nowhere in openssl/ssl/ssl.h. From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Bodo Moeller Sent: Tuesday, October 14, 2014 7:47 PM To: openssl-us...@openssl.org; openssl-dev@openssl.org Subject: Patch to mitigate CVE-2014-3566 (POODLE) Here's a patch for the OpenSSL 1.0.1 branch that adds support for TLS_FALLBACK_SCSV, which can be used to counter the POODLE attack (CVE-2014-3566; https://www.openssl.org/~bodo/ssl-poodle.pdf). Note well that this is not about a bug in OpenSSL -- it's a protocol issue. If SSL 3.0 is disabled in either the client or in the server, that is completely sufficient to avoid the POODLE attack. (Also, there's only a vulnerability if the client actively falls back to SSL 3.0 in case that TLS connections don't work -- but many browsers still do that to ensure interoperability with broken legacy servers.) If you can't yet disable SSL 3.0 entirely, TLS_FALLBACK_SCSV can help avoid the attack, if both the client and the server support it. Server-side TLS_FALLBACK_SCSV support is automatically provided if you use the patch. Clients that do fallback connections downgrading the protocol version should use SSL_set_mode(ssl, SSL_MODE_SEND_FALLBACK_SCSV) for such downgraded connections. The OpenSSL team will follow up with official releases that will include TLS_FALLBACK_SCSV support. Meanwhile, if you can't simply disable SSL 3.0, you may want to use this patch. Bodo
Re: Patch to mitigate CVE-2014-3566 (POODLE)
On 20/10/14 20:30, Andrew Felsher (afelsher) wrote: I’m guessing this patch (or part of it) was incorporated into 1.0.1j, because this error, and the causal code, showed up after we synced to 1.0.1j. The problem is that both SSL_R_INAPPROPRIATE_FALLBACK (added in this patch) and SSL_R_RFC5430_CURVE_MISMATCH are set to 373. I think the solution is to change the value of SSL_R_INAPPROPRIATE_FALLBACK to 374 (which appears nowhere in openssl/ssl/ssl.h. This patch (well a later version of it) was indeed incorporated into 1.0.1j...so there is no need to apply this patch to that version. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Patch to mitigate CVE-2014-3566 (POODLE)
mancha manc...@zoho.com: Bodo Moeller wrote: I certainly think that the claim that new SCSV does not help with [the SSL 3.0 protocol issue related to CBC padding] at all is wrong, and that my statement that TLS_FALLBACK_SCSV can be used to counter CVE-2014-3566 is right. The point is more nuanced and boils down to there being a difference between CVE-2014-3566 (SSLv3's vulnerability to padding oracle attacks on CBC-mode ciphers) and POODLE (an attack that exploits CVE-2014-3566 by leveraging protocol fallback implementations to force peers into SSLv3 communication). TLS_FALLBACK_SCSV does not fix or mitigate CVE-2014-3566. With or without 0x5600, SSLv3 CBC-mode cipher usage is broken. Sure, I understand that. Disabling SSL 3.0 doesn't fix CVE-2014-3566 either, because SSL 3.0 remains just as broken even if you don't use it. In both cases (TLS_FALLBACK_SCSV or disabling SSL 3.0), it's about avoiding unwarranted use of SSL 3.0 to avoid the vulnerability. Chrome, Firefox, etc. intentionally implement protocol fallback (which I presume is why there are no MITRE CVE designations for the behavior per se). However, one can make a strong case protocol fallback implementations that are MITM-triggerable deserve CVE designations. I agree. If there was such a CVE, that would be the main CVE to point to here. Bodo
Re: Patch to mitigate CVE-2014-3566 (POODLE)
Jeffrey Walton noloa...@gmail.com: Is there a way to compile without the patch? I think I would rather 'config no=ssl3' and omit the additional complexity. Its additional protocol complexity and heartbleed is still fresh in my mind. There's no way to compile without the patch, other than reverting it. It's a tiny amount of extra logic. Disabling SSL 3.0 is a good idea, but note the TLS_FALLBACK_SCSV also addresses similar downgrade attacks to TLS 1.1 or TLS 1.0 (when you should rather be using TLS 1.2). Also, are there any test cases that accompany the patch? I'm trying to figure out when, exactly, SSL_MODE_SEND_FALLBACK_SCSV needs to be set (using the sources as a guide). If you don't use fallback retries (in which you *intentionally* avoid the latest protocol versions), you don't need to set it at all. Presumably I should update the documentation to be more explicit about this. Where did you look for documentation? Do you think that changing the SSL_set_mode man page (SSL_CTX_set_mode.pod) would be sufficient, or do you think that adding guidance to ssl.h is equally (or more) important? Bodo
Re: Patch to mitigate CVE-2014-3566 (POODLE)
Thanks for the patch. Is there a way to compile without the patch? I think I would rather 'config no=ssl3' and omit the additional complexity. Its additional protocol complexity and heartbleed is still fresh in my mind. Also, are there any test cases that accompany the patch? I'm trying to figure out when, exactly, SSL_MODE_SEND_FALLBACK_SCSV needs to be set (using the sources as a guide). On Tue, Oct 14, 2014 at 7:46 PM, Bodo Moeller bmoel...@acm.org wrote: Here's a patch for the OpenSSL 1.0.1 branch that adds support for TLS_FALLBACK_SCSV, which can be used to counter the POODLE attack (CVE-2014-3566; https://www.openssl.org/~bodo/ssl-poodle.pdf). Server-side TLS_FALLBACK_SCSV support is automatically provided if you use the patch. Clients that do fallback connections downgrading the protocol version should use SSL_set_mode(ssl, SSL_MODE_SEND_FALLBACK_SCSV) for such downgraded connections. The OpenSSL team will follow up with official releases that will include TLS_FALLBACK_SCSV support. Meanwhile, if you can't simply disable SSL 3.0, you may want to use this patch. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Patch to mitigate CVE-2014-3566 (POODLE)
On Thu, Oct 16, 2014 at 02:50:58PM +0200, Bodo Moeller wrote: This is not quite the same discussion as in the TLS Working Group, but I certainly think that the claim that new SCSV does not help with [the SSL 3.0 protocol issue related to CBC padding] at all is wrong, and that my statement that TLS_FALLBACK_SCSV can be used to counter CVE-2014-3566 is right. The point is more nuanced and boils down to there being a difference between CVE-2014-3566 (SSLv3's vulnerability to padding oracle attacks on CBC-mode ciphers) and POODLE (an attack that exploits CVE-2014-3566 by leveraging protocol fallback implementations to force peers into SSLv3 communication). TLS_FALLBACK_SCSV does not fix or mitigate CVE-2014-3566. With or without 0x5600, SSLv3 CBC-mode cipher usage is broken. Chrome, Firefox, etc. intentionally implement protocol fallback (which I presume is why there are no MITRE CVE designations for the behavior per se). However, one can make a strong case protocol fallback implementations that are MITM-triggerable deserve CVE designations. TLS_FALLBACK_SCSV could then be accurately described as partially mitigating those CVEs. --mancha pgpLCPRz8jV7G.pgp Description: PGP signature
Re: Patch to mitigate CVE-2014-3566 (POODLE)
On 10/15/2014 01:46 AM, Bodo Moeller wrote: Here's a patch for the OpenSSL 1.0.1 branch that adds support for TLS_FALLBACK_SCSV, which can be used to counter the POODLE attack (CVE-2014-3566; https://www.openssl.org/~bodo/ssl-poodle.pdf). Note that the CVE identifier was assigned to the SSL 3.0 protocol issue related to CBC padding. The new SCSV does not help with that at all. But that's not a problem: when both parties support TLS, OpenSSL is not vulnerable even if both sides still enable SSL 3.0 for interoperability reasons with other peers. MITRE has not issued a CVE for the broken fallback behavior because it is not a security vulnerability—it works as designed. This means that the TLS_FALLBACK_SCSV patch currently has no CVE associated with it. -- Florian Weimer / Red Hat Product Security __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: Patch to mitigate CVE-2014-3566 (POODLE)
Note that the CVE identifier was assigned to the SSL 3.0 protocol issue related to CBC padding. The new SCSV does not help with that at all. What? It prevents silently falling back to the broken protocol. Perhaps we can keep this battle-thread just in the TLS WG mail? /r$ -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Patch to mitigate CVE-2014-3566 (POODLE)
On 10/16/2014 10:41 AM, Salz, Rich wrote: Note that the CVE identifier was assigned to the SSL 3.0 protocol issue related to CBC padding. The new SCSV does not help with that at all. What? It prevents silently falling back to the broken protocol. Perhaps we can keep this battle-thread just in the TLS WG mail? It's unrelated to the TLS WG discussion. MITRE has assigned the CVE name to the SSL 3.0 protocol issue, specifically: “The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which makes it easier for man-in-the-middle attackers to obtain cleartext data via a padding-oracle attack, aka the POODLE issue.” http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566 Securing fallback is a workaround, but does not address the issue. You are still vulnerable if you use SSL 3.0 directly (because one of the peers supports only that), even if both peers implement SCSV. The proper fix comes with TLS 1.0+, and OpenSSL has implemented a transparent protocol upgrade for a long time. Don't be shy—you fixed POODLE before it was discovered, which is great! I had already asked for assignment of a separate CVE for the insecure browser fallback, but I was told that MITRE does not consider *that* a vulnerability because it is expected, documented behavior. This means that fallback-SCSV-related patches do not fix any CVE-named vulnerability, and certainly not CVE-2014-3566. Again, this is not related to the question whether the fallback SCSV is a good idea. It is a procedural issue with CVE naming. Curiously, we recently had the same problem with the bash prefix/suffix patch, which did not fix any concrete CVE-named vulnerability, either. It is confusing, and I think it shows a limitation of the CVE authority file in the light of its current applications. -- Florian Weimer / Red Hat Product Security __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Patch to mitigate CVE-2014-3566 (POODLE)
This is not quite the same discussion as in the TLS Working Group, but I certainly think that the claim that new SCSV does not help with [the SSL 3.0 protocol issue related to CBC padding] at all is wrong, and that my statement that TLS_FALLBACK_SCSV can be used to counter CVE-2014-3566 is right. Yes, regardless of what you do, SSL 3.0 still has that vulnerability. The vulnerability is best avoided by not using SSL 3.0. One way to avoid SSL 3.0 is to entirely disable it. Another way to avoid SSL 3.0 at least in certain scenarios, in case you are not ready to entirely disable it, is to make use of TLS_FALLBACK_SCSV. Deploying TLS_FALLBACK_SCSV has further benefits that indeed have nothing to do with CVE-2014-3566, and deploying TLS_FALLBACK_SCSV will certainly not fully protect against CVE-2014-3566 if you continue to allow SSL 3.0, given that TLS_FALLBACK_SCSV requires client-side *and* server-side support to achieve anything -- so TLS_FALLBACK_SCSV is not *the* fix for CVE-2014-3566. However, in the current implementation landscape, if you *do* have both client-side and server-side support for TLS_FALLBACK_SCSV, this provides perfectly fine protection against CVE-2014-3566 for these connections; so CVE-2014-3566 is a very good reason to deploy TLS_FALLBACK_SCSV support now (or to have it deployed a couple of months ago). In other words, TLS_FALLBACK_SCSV can be used to counter CVE-2014-3566. Bodo
RE: Patch to mitigate CVE-2014-3566 (POODLE)
Again, this is not related to the question whether the fallback SCSV is a good idea. It is a procedural issue with CVE naming. Then take it up with the CVE folks. Not here. :) -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Patch to mitigate CVE-2014-3566 (POODLE)
mancha manc...@zoho.com: Any reason for the s_client -fallback_scsv option check to be within an #ifndef OPENSSL_NO_DTLS1 block? Thanks for catching this. No, there's no good reason for that; I should move it elsewhere. Bodo
Re: Patch to mitigate CVE-2014-3566 (POODLE)
On Wed, Oct 15, 2014 at 01:46:40AM +0200, Bodo Moeller wrote: Here's a patch for the OpenSSL 1.0.1 branch that adds support for TLS_FALLBACK_SCSV, which can be used to counter the POODLE attack (CVE-2014-3566; https://www.openssl.org/~bodo/ssl-poodle.pdf). Hi Bodo. Many thanks for the OOB patch that I just saw commited to git. Any reason for the s_client -fallback_scsv option check to be within an #ifndef OPENSSL_NO_DTLS1 block? Thanks. --mancha pgpQP0dloJSeZ.pgp Description: PGP signature
