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
On 2015-06-15, Gerhard Wiesinger <lists at 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/958563http://www.openssh.com/txt/cbc.adv -- Christian "naddy" Weisgerber naddy at mips.inka.de
On Mon, Jun 15, 2015 at 3:31 PM, Christian Weisgerber <naddy at mips.inka.de> wrote:> On 2015-06-15, Gerhard Wiesinger <lists at 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?
On 15.06.2015 21:31, Christian Weisgerber wrote:> On 2015-06-15, Gerhard Wiesinger <lists at 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/
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.pdfThe 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/
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