PuTTY vulnerability vuln-ssh1-kex

This is a mirror. Follow this link to find the primary PuTTY web site.

summary: Vulnerability: buffer management bug in SSH-1 key exchange
class: vulnerability: This is a security vulnerability.
difficulty: fun: Just needs tuits, and not many of them.
priority: high: This should be fixed in the next release.
present-in: 0.45 0.46 0.47 0.48 0.49 0.50 0.51 0.52 0.53 0.53b 0.54
fixed-in: 0.55 2a88ce62b6f6c43c7a811bb4dd8f198ef58bb4b6

All versions of the PuTTY suite prior to 0.55 have a memory corruption bug in SSH-1 key exchange, which might lead to a security vulnerability.

The bug lies in the rsaencrypt() function, which performs RSA encryption with PKCS#1 v1.5 padding, as used in the SSH-1 key exchange. This function assumes that the data to be encrypted is smaller than the modulus of the public key. If this is not the case, the memmove() operation at the start of the function will overwrite memory before the input buffer.

A malicious server can trigger this bug by sending an unexpectedly small public key modulus. However, it is not clear that the server can exploit this bug to take control of the client, since the data written beyond the buffer is part of the cleartext invented by the client, not part of the key modulus sent by the server. I (SGT) doubt that a server can do much more than cause the client to crash by exploiting this bug.

Nonetheless, that's more than a server should be able to do, and it is just possible that there is a more damaging exploit in spite of appearances, so this is still a serious bug that needs fixing. PuTTY release 0.55 fixes it by having rsaencrypt() explicitly check that the public key is long enough to allow the encryption of the supplied data.

Although PuTTY verifies the server's host key against its Registry cache before performing the vulnerable encryption operation, this does not protect you from a spoofed server or man-in-the-middle attack. SSH-1 involves two public keys: a server key (changed every hour, for forward security) and a host key (never changed, for server authentication). Some data is encrypted using both keys, and then the server proves its identity by decrypting it. So a MITM can send a maliciously shortened server key and the correct host key; the fact that it does not have the private half of the host key will not matter, since by the time it is challenged to prove its identity by decrypting the doubly encrypted data, the short server key will have already triggered the bug and the damage will be done.

This bug was discovered by Core Security Technologies, and documented in their advisory CORE-2004-0705. It is also mentioned in an advisory by Secunia, numbered SA12212.

If you want to comment on this web site, see the Feedback page.

Audit trail for this vulnerability.

(last revision of this bug record was at 2016-12-27 11:40:22 +0000)