A weakness ?

While reading the actual posts around the allegations of a so-called backdoor in the OpenBSD IPSec code, which would have been inserted by the FBI through a developer, some comments have been posted on both Slashdot and LWN about “long-standing bugs in SSH2”. The page which details the criticism can be found here. These comments were done by Bernard Perrot when he was patching OpenSSH to comply with the (dumb) restrictions to the use of cryptography in France by the French law.

“I often like to point out an incomprehensible weakness of the protocol concerning the “padding” (known as covered channel): in both version 1 and 2 the packets, have a length which is a multiple of 64 bits, and are padded with a random number. This is quite unusual and therefore sparing a classical fault that is well known in encrypting products: a “hidden” (or “subliminal”) channel. Usually , we “pad” with a verified sequence as for example, give the value n for the byte rank n (self describing padding). In SSH, the sequence being (by definition) randomized, it cannot be checked. Consequently, it is possible that one of the parties communicating could pervert / compromise the communication for example used by a third party who is listening. One can also imagine a corrupted implementation unknown by the two parties (easy to realize on a product provided with only binaries as generally are commercial products). This can easily be done and in this case one only needs to “infect” the client or the server. To leave such an incredible fault in the protocol, even though it is universally known that the installation of a covered channel in an encryption product is THE classic and basic way to corrupt the communication, seems unbelievable to me . It can be interesting to read Bruce Schneier’s remarks concerning the implementation of such elements in products influenced by government agencies. (http://www.counterpane.com/crypto-gram-9902.html#backdoors).”

The author says that SSH1 and SSH2 are vulnerable to covert-channel attack.

Covert-channel attacks

A covert-channel attack is an attack in which an attacker makes use of a protocol to embed data inside it, with the objective of evading intrusion detection software, antivirus, etc. simply to not get caught. The covert-channels exist in almost every protocols at all layers. Hackers used to embed covert rootshells inside ICMP ping datagrams, udp, inside HTTP, inside HTML comments, …

Basically, any protocol that allows two different ways of communicating the same information is vulnerable (and heck most protocols have a lot of ways present the same data in different forms).

A Covert-channel attack is possible on SSH2, by at least two means, as described in the referenced paper :

• The padding field is said to contain purely random padding. The goal of the padding field is to pad the packet in order to get the whole packet a multiple of the blocksize (a blocksize is the size of cleartext being encrypted/decrypted after each call to a cryptographic routine). It has no cryptographic intent, its content is not checked, but however, it’s encrypted and part of the HMAC (a HMAC primitive is a symmetric and fast tool to verify the integrity of data).
  In order to act as a covert channel, this field has to be filled in by either the SSH server or SSH client, because it is encrypted. Any attempt to change it during the transport will be seen because the HMAC won’t match.
• There are specific packet types (SSH_IGNORE and SSH_DEBUG) which implementations should accept but discard immediately. Of course, these packets are the best place to insert any data you’d like to send over the encrypted session, but in this case you still need to have a corrupted server and client.

My point here is that these covert channels do exist, but there’s nothing you can do about it at all. The idea of an encrypted session is to ensure the confidentiality end to end. That confidentiality means that you’re free to send any data you want, and nobody will know about it. That also the point on the SSH RFC, 9.3.6 page 20 : the protocol was not designed to avoid covert channels.

Conclusion

My conclusion is simple : it’s not a bug, it’s a feature. Call me when it’s possible to insert data into an encrypted SSH data stream, without knowledge of the session key. At the best of my experience, there is no way to insert data into a stream without altering the integrity of a packet and thus being detected by either of the parties.

If the parties are compromised, there’s no covert channel. One could simply open a channel with its own malicious data and nobody will know. I’m also curious to see how one would design a protocol to transmit encrypted, confidential and arbitrary data which is immune to covert channel attacks, when both sides are compromised. If the attacker couldn’t hide data in the protocol, he’d hide it in the transmitted data.