OpenSSH and CBC

[Gerhard Wiesinger]

Hello,

I saw that OpenSSH release 6.7 removed all CBC ciphers by default. Is
CBC therefore considered as broken and unsecure (in general or SSH
implementation)?

I also read a lot of references (see below) but still not clear to me
what's the actual "security status" of CBC and why it has been removed
in general.

http://www.openssh.com/txt/release-6.7
sshd(8): The default set of ciphers and MACs has been altered to remove
unsafe algorithms. In particular, CBC ciphers and arcfour are disabled
by default.

OpenSSH release 5.2 should have fixed that.

Please clarify it.

Thank you.

Ciao,
Gerhard

-- http://www.wiesinger.com

References:
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
https://en.wikipedia.org/wiki/CBC-MAC

https://crypto.stackexchange.com/questions/1075/why-is-it-insecure-to-use-a-randomized-iv-for-cbc-mac-instead-of-an-all-zero-iv
http://blog.cryptographyengineering.com/2013/02/why-i-hate-cbc-mac.html
Now a quick note: there's nothing really wrong with CBC-MAC, when
implemented correctly. And it's not even that hard to implement
properly. The problem is that many people who use CBC-MAC (rather than
HMAC or a proper AEAD mode) seem incapable of actually doing this.

http://blog.cryptographyengineering.com/2012/05/how-to-choose-authenticated-encryption.html
Vulnerability Name: SSH CBC Mode Ciphers Enabled
https://access.redhat.com/solutions/420283

http://forums.eeye.com/index.php?/topic/2858-11867-ssh-cbc-mode-plaintext-recovery-remote-false-positive/
The reality is that all of the CBC mode ciphers are vulnerable and this
includes the old standby [3DES-CBC] and even, likely, [BLOWFISH-CBC].
We can look at the references provided by the Retina finding for a more
detailed analysis.
The first is the reference from CERT:
http://www.kb.cert.org/vuls/id/958563
This clearly states that ALL CBC mode ciphers are vulnerable and that
the only real mitigation is to use CTR mode, or other secure ciphers
which do not use Cipher Block Chaining (like [ARCFOUR]).

The last reference is from OpenSSH:
http://openssh.org/txt/cbc.adv
They basically suggest that the likelihood of a successful attack is
very low, while acknowledging that there is a vulnerability with ALL CBC
mode ciphers.
The OpenSSH team also suggests a mitigation in which the CTR mode
ciphers "may be preferentially selected" first in the ssh[d]_config files:
Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc

http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt
https://packetstormsecurity.com/files/72061/Vulnerability_Advisory_SSH.txt.html

http://www.cs.washington.edu/homes/yoshi/papers/TISSEC04/
https://homes.cs.washington.edu/~yoshi/papers/TISSEC04/ssh-acmccs.pdf

http://isg.rhul.ac.uk/~kp/SandPfinal.pdf
https://lwn.net/Articles/307873/
http://www.openssh.com/security.html
http://www.openssh.com/txt/release-5.2
Security:
* This release changes the default cipher order to prefer the AES CTR
modes and the revised "arcfour256" mode to CBC mode ciphers that are
susceptible to CPNI-957037 "Plaintext Recovery Attack Against SSH".
* This release also adds countermeasures to mitigate CPNI-957037-style
attacks against the SSH protocol's use of CBC-mode ciphers. Upon
detection of an invalid packet length or Message Authentication
Code, ssh/sshd will continue reading up to the maximum supported
packet length rather than immediately terminating the connection.
This eliminates most of the known differences in behaviour that
leaked information about the plaintext of injected data which formed
the basis of this attack. We believe that these attacks are rendered
infeasible by these changes.

https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

SSH implementation comparison
http://ssh-comparison.quendi.de/comparison.html

Analysis of the SSH Key Exchange Protocol
https://eprint.iacr.org/2011/276.pdf

_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Christian Weisgerber]

On 2015-06-15, Gerhard Wiesinger <li...@wiesinger.com> wrote:

> I saw that OpenSSH release 6.7 removed all CBC ciphers by default. Is
> CBC therefore considered as broken and unsecure (in general or SSH
> implementation)?

CBC modes in SSH use the last encrypted block of the previous packet
as the IV for the next packet. The protocol is specified this way.

> I also read a lot of references (see below) but still not clear to me
> what's the actual "security status" of CBC and why it has been removed
> in general.

These are pertinent:

> http://www.kb.cert.org/vuls/id/958563
http://www.openssh.com/txt/cbc.adv

--
Christian "naddy" Weisgerber na...@mips.inka.de

[shawn wilson]

On Mon, Jun 15, 2015 at 3:31 PM, Christian Weisgerber
<na...@mips.inka.de> wrote:
> On 2015-06-15, Gerhard Wiesinger <li...@wiesinger.com> wrote:
>
>> I saw that OpenSSH release 6.7 removed all CBC ciphers by default. Is
>> CBC therefore considered as broken and unsecure (in general or SSH
>> implementation)?
>
> CBC modes in SSH use the last encrypted block of the previous packet
> as the IV for the next packet. The protocol is specified this way.
>
>> I also read a lot of references (see below) but still not clear to me
>> what's the actual "security status" of CBC and why it has been removed
>> in general.
>
> These are pertinent:
>
>> http://www.kb.cert.org/vuls/id/958563
> http://www.openssh.com/txt/cbc.adv
>

There PoC for that?

[Gerhard Wiesinger]

On 15.06.2015 21:31, Christian Weisgerber wrote:
> On 2015-06-15, Gerhard Wiesinger <li...@wiesinger.com> wrote:
>
>> I saw that OpenSSH release 6.7 removed all CBC ciphers by default. Is
>> CBC therefore considered as broken and unsecure (in general or SSH
>> implementation)?
> CBC modes in SSH use the last encrypted block of the previous packet
> as the IV for the next packet. The protocol is specified this way.

As the new IV depends on the (unknown) key and an unbroken crypto/hash
algorithms I don't see any problem with this assuming normal behaviour
with new keys on a new connection and correct implementation. Am I wrong?

>
>> I also read a lot of references (see below) but still not clear to me
>> what's the actual "security status" of CBC and why it has been removed
>> in general.
> These are pertinent:
>
>> http://www.kb.cert.org/vuls/id/958563
> http://www.openssh.com/txt/cbc.adv
>

But that should be already covered by:
http://www.openssh.com/txt/release-5.2

We believe that these attacks are rendered infeasible by these changes.

BTW: If you didn't know, here you find the details about the attacks
(already in my link list):
http://isg.rhul.ac.uk/~kp/SandPfinal.pdf
I think it was unknown at the time OpenSSH 5.2 was released.
E.g. some assumptions are wrong: After at most 2^14 connections ...
With each new ssh connection I will have a new symmetrical key so the
assumption is not feasible.

Also: One of the main challenges for building an exploit based on our
proof-of-concept code would be to find a service which tolerates SSH
connection failures and reconnects on these failures.
I think such assumptions are just theoretical.
Also according to the paper encrypt then-MAC schemes are also vulnerable
(which are considered secure): But it is not hard to see that this
construction would still be vulnerable to our attacks.

There is another paper available: Some Fixes To SSH
https://eprint.iacr.org/2013/151.pdf

BTW: Jan Zerebecki also doesn't recommend the AES CTR modes as they
disclose packet length.
https://wiki.mozilla.org/Security/Guidelines/OpenSSH
Any comments on this?

Ciao,
Gerhard

-- http://www.wiesinger.com/

[Gerhard Wiesinger]

Jan answered me, as the packet length is transmitted in plaintext, see:
http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html

[Aris Adamantiadis]

Hi Gerhard,

This is not exactly true. CTR modes have the length field encrypted. etm
MAC modes and AES-GCM have the length field in cleartext.
CBC is dangerous because the length field is encrypted with CBC.

aes128-ctr + hmac-sha256 doesn't have any known vulnerability and
encrypts the packet length, but uses the bad practice of e&m.
chacha20-poly1305 encrypts both payload and packet len + uses
authenticated encryption (best practice), even if the implementation
looks very similar to etm.

Aris

[Gerhard Wiesinger]

On 16.06.2015 14:43, Aris Adamantiadis wrote:
> Hi Gerhard,
>
> This is not exactly true. CTR modes have the length field encrypted.
> etm MAC modes and AES-GCM have the length field in cleartext.
> CBC is dangerous because the length field is encrypted with CBC.
>

What's exactly the topic encrypting the length field with CBC?
Any documentation/papers on this to understand (except the source)?

> aes128-ctr + hmac-sha256 doesn't have any known vulnerability and
> encrypts the packet length, but uses the bad practice of e&m.
> chacha20-poly1305 encrypts both payload and packet len + uses
> authenticated encryption (best practice), even if the implementation
> looks very similar to etm.
>

Why is E&M bad practice?

Thank you.

Ciao,
Gerhard

[Gerhard Wiesinger]

On 15.06.2015 16:05, Gerhard Wiesinger wrote:
> http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt
> https://packetstormsecurity.com/files/72061/Vulnerability_Advisory_SSH.txt.html
>

> http://isg.rhul.ac.uk/~kp/SandPfinal.pdf

The success probability in recovering 32 plaintext bits is 2^{-18} when
attacking the OpenSSH implementation of the SSH RFCs. A variant of the
attack against the OpenSSH implementation verifiably recovers 14
plaintext bits with probability 2^{-14}.

Recovering 14 bits: That's basically no better than brute force, so no
real attack, isn't it?
Recovering 32 bits: That's basically a little bit better than brute
force bu think there is also no real attack vector, isn't it?

Especially in the context of OpenSSH 5.2 mitigation and different keys
in different kind of connections.

Any opinions on this?

Ciao,
Gerhard

--
http://www.wiesinger.com/

[Damien Miller]

On Fri, 19 Jun 2015, Gerhard Wiesinger wrote:

> On 15.06.2015 16:05, Gerhard Wiesinger wrote:
> > http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt
> > https://packetstormsecurity.com/files/72061/Vulnerability_Advisory_SSH.txt.html
> > http://isg.rhul.ac.uk/~kp/SandPfinal.pdf
>
> The success probability in recovering 32 plaintext bits is 2^{-18} when
> attacking the OpenSSH implementation of the SSH RFCs. A variant of the attack
> against the OpenSSH implementation verifiably recovers 14 plaintext bits with
> probability 2^{-14}.

That's before our countermeasures, that make this attack AFAIK infeasible.

> Recovering 14 bits: That's basically no better than brute force, so no real
> attack, isn't it?

No, it's a real attack but it is not practical in most configurations.

> Recovering 32 bits: That's basically a little bit better than brute force bu
> think there is also no real attack vector, isn't it?

Depends on what the 32 bits are. If I can recover 32 bits of a password
than you're going to have a bad day.

> Especially in the context of OpenSSH 5.2 mitigation and different keys in
> different kind of connections.
>
> Any opinions on this?

The defaults in recent OpenSSH are safe against this attack. It's not
something you need to worry about if both ends are OpenSSH. If you're
using a non-OpenSSH client or server then you might need to pay more
attention.

-d

[Ángel González]

On 18/06/15 19:25, Gerhard Wiesinger wrote:
>> aes128-ctr + hmac-sha256 doesn't have any known vulnerability and
>> encrypts the packet length, but uses the bad practice of e&m.
>> chacha20-poly1305 encrypts both payload and packet len + uses
>> authenticated encryption (best practice), even if the implementation
>> looks very similar to etm.
>>
>
> Why is E&M bad practice?

First of all Encrypt-and-MAC (E&M) allows an attacker to recognise two
identical messages due to the shared MAC.

The ideal method of composing ciphers and macs is to use
Encrypt-and-MAC, which has the very nice property of not decrypting
anything before authenticating it. For instance, a common error is to
fail early (in a way noticeable by timing) before checking the mac (eg.
such as noticing that the plaintext is corrupt).

Colin Percival explains in
http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html how
only Encrypt-then-MAC is provably secure. See
http://cseweb.ucsd.edu/~mihir/papers/oem.pdf for the detailed proof
comparing the modes.