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