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-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
