Patch to mitigate CVE-2014-3566 ("POODLE")

[Bodo Moeller]

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

[Bodo Moeller]

mancha <man...@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

 

[Florian Weimer]

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
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org

[Salz, Rich]

> 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

[Florian Weimer]

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

[Bodo Moeller]

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

[Salz, Rich]

> 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

[Jeffrey Walton]

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 <bmoe...@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.

[Bodo Moeller]

mancha <man...@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

[Bodo Moeller]

Jeffrey Walton <nolo...@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