Every month or so, someone contacts the Aruba Security Incident Response Team because their vulnerability scanner of choice reports that use of AES-CBC within SSH is a vulnerability. The vulnerability scanner vendors have been notoriously bad at understanding cryptography (example: interpreting HMAC-SHA1-96 as a 96-bit hash and flagging this as weak), so this is not surprising. I'm going to write this post so that in the future, I can refer people back to it when they ask the question.
The original vulnerability was described in http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf, published in 2008. A CERT database entry exists at http://www.kb.cert.org/vuls/id/958563.
Without forcing you to read the entire paper, the root of the problem was that an attacker could inject SSH packets into a session, and SSH would indicate whether or not the attacker had guessed a valid message length field. An attacker could guess this with probability of 1 in 2^14 (that is a very small number) and if he guessed wrong, the SSH session would terminate. So this by itself is already not a high risk for interactive SSH sessions - a user will notice if his SSH session resets over and over. But for automated sessions that reconnect automatically and have no mitigations in place to detect error conditions, it could be a legitimate concern. What's the problem with CBC? Each block of ciphertext gets used as part of the crypto operation for the next block. If an attacker can recover one block, that potentially lets him recover one additional block. So already in my mind, I'm thinking "Low probability of success, high probability of being noticed, and even if it does succeed, only 32 bits of plaintext are leaked. What's the big deal?"
Well, of course, any crypto leakage can potentially be a big deal. Fortunately, the OpenSSH team made two changes in OpenSSH 5.2:
- They no longer return different error messages upon a failure to find a valid message length field. That makes the attack much less effective.
- In the following release, they cause OpenSSH to continue reading up to the maximum message length even when an error has already been detected. This removes the clue that an attacker would need in order to find a successful attack (an attacker might get a valid message length, but is going to fail on the MAC). From the OpenSSH 5.2 release notes:
* 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.
In other words - in a post-OpenSSH 5.2 world, we do not need to worry about this attack.
As further evidence, the Common Criteria "Network Device Collaborative Protection Profile" (https://www.niap-ccevs.org/pp/cpp_nd_v1.0.pdf), which was written by an international technical community and adopted by the central governments of a wide variety of nations, requires AES-CBC to be supported. Excerpting from the document:
FCS_SSHS_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses
the following encryption algorithms and rejects all other encryption algorithms:
aes128-cbc, aes256-cbc, [selection: AEAD_AES_128_GCM, AEAD_AES_256_GCM, no other
algorithms].
Common Criteria evaluated products are used to protect national security information. My interpretation: If use of CBC mode ciphers in SSH were still a problem, these people would have mandated that it not be used, rather than what we see above.
Conclusion: We at Aruba believe that the vulnerability scanner vendors are wrong on this, and have no plans to change our products to remove CBC support.
Questions? Please reply and let me know.
-Jon