Bulgarian mirror 10 Gbps

PuTTY vulnerability vuln-ssh1-kex

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

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.