Wireless Access

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

Hello... is there any updates on this post?

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

What would be your question? What are you looking for?

Hello... is there any updates on this post?

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

As time passes, we want to verify the information is still accurate and has not been superseded by something.   Is it still safe with CBC as the article states above?

Original Message:
Sent: May 15, 2023 09:58 AM
From: Herman Robers
Subject: SSH and AES-CBC

What would be your question? What are you looking for?

Hello... is there any updates on this post?

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