First published: 30th November 2008
A design flaw in the SSH protocol has been discovered by Martin Albrecht, Kenny Paterson and Gaven Watson from the Information Security Group at Royal Holloway College, University of London. The design flaw allows an attacker that is able to listen to an encrypted Secure Shell (SSH) connection and actively steal the network connection (TCP) to, in some situations obtain up to 4 bytes of cleartext data from the session. The attack attempt causes the attacked connection to be disconnected immediately. The attack works only against protocol sessions that are encrypted using a block cipher algorithm in the cipher-block chaining (CBC) mode. Exploiting this vulnerability is very difficult.
As the issue is caused by a protocol design flaw, it is believed to affect all SSH implementations. It has been confirmed as affecting:
- OpenSSH 4.7p1
- SSH Tectia Client and Server and ConnectSecure 6.0.4 and older in the 6.x series
- SSH Tectia Client and Server and Connector 5.3.8 and older in the 5.3.x series
- SSH Tectia Client and Server and Connector 5.2.4 and older in the 5.x series
- SSH Tectia Client and Server and Connector 4.4.11 and older in the 4.x series
- SSH Tectia Server for Linux on IBM System z 6.0.4
- SSH Tectia Server for IBM z/OS 6.0.1 and 6.0.0
- SSH Tectia Server for IBM z/OS 5.5.1 and older
- SSH Tectia Client 4.3.3-J (Japanese) and older in the 4.x-J series
- SSH Tectia Client 4.3.10-K (Korean) and older in the 4.x-K series
SSH Communications Security has issued a security advisory concerning this vulnerability for its SSH Tectia product-line and has released fixed versions of the affected products. Currently active Maintenance Customers can download the installation packages from SSH Customer Download Centre at https://downloads.ssh.com. The products provided there include valid license files.
In the absence of a fixed version, the most straightforward solution is to use CTR mode instead of CBC mode, since this renders SSH resistant to the attack. In practice this is achievable with the SSH Tectia products by utilising either CryptiCore or Arcfour encryption algorithms.
The attach is considered very difficult, it recovers only four bytes of cleartext, and the connection is broken by the attack, so the chance of this vulnerability being used to achieve a significant security breach in most situations is small. However, SSH users will be naturally cuatious, and therefore want to apply the fix without delay.
Updated: 12th December 2008
Questions and Answers
Some questions we have received about this vulnerability, and our answers:
If we use SFTP only to transfer files (not allow telnet) in SSH Tectia server for windows, whether this design flaw affects our case or not. In the announcement of www.ssh.com, it just said that "the attacker is able to listen to an encrypted Secure Shell (SSH) connection", but did not mentioned SFTP to transfer files.
An sftp connection is, in fact, an ssh connection, with an additional higher protocol layer to handle the file transfer. Therefore, sftp connections are also vulnerable to this attack. This is also true for scp, and for any tunnelling or use of other protocols over ssh (e.g.
rsyncwith the-e sshswitch).If I still use CBC mode, how risky is it?
That depends on the value of the data, and the alternative ways of getting the data. A determined attacker could bypass the encryption entirely by, e.g. bribing your staff or breaking into your data centre. How "expensive" would that be, how "valuable" is the data? Not necessarily the monetary value.
This is not an easy attack, I would think that the attacker would need to want your data badly to even think about trying this (otherwise they'll go for another target with less protection). If they do want your data that badly, it could still be easier to get it by other means. However, you might also need to consider the cost of embarrassment to you.
What information (username and password) can attacker get?
Up to four bytes for each attack. From the description, an attacker could launch the attack at a different point for each connection retry, and therefore build up far more data as the protocol retries automatically. I am not clear whether this could include the username and password. If the attacker did take this approach, the throughput for the legitimate users would plummet.
Is it easy to be attacked?
No.
However, given that the solution is simple, what reason have you got not to apply it? How would it sound if you were giving that reason to the press after a breach?