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

[mancha]

Post by 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).

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

[Bodo Moeller]

Post by mancha
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]

Post by 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 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.

[Salz, Rich]

Post by Florian Weimer
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: ***@jabber.me Twitter: RichSalz

______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org

[Florian Weimer]

Post by Salz, Rich

Post by Florian Weimer
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.

[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

[mancha]

Post by 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.

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

[Bodo Moeller]

Post by Bodo Moeller
I certainly think that the claim that "new SCSV does not help with

Post by Bodo Moeller
[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

Post by Bodo Moeller
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

[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: ***@jabber.me Twitter: RichSalz

______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org

[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).

Post by 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).
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
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Bodo Moeller]

Post by Jeffrey Walton
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

Post by Jeffrey Walton
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

[Andrew Felsher (afelsher)]

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-***@openssl.org; openssl-***@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

[Matt Caswell]

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-***@openssl.org
Automated List Manager ***@openssl.org