Mirrors | Updates | Feedback | Changes | Wishlist | Team
All versions of the PuTTY suite prior to 0.55 have a memory
corruption vulnerability in the
This function performs modular exponentiation: it takes three
and it raises
base to the power
Unfortunately, it fails to check that
base is at most
the same size as
mod. By arranging for
base to be significantly bigger than
an attacker can cause the
modpow() function to write
memory before the beginning of one of its working buffers. The data
written to that memory is taken from the
itself, so if an attacker can control this value then they can write
data of their choice to PuTTY's memory.
(We are not aware of an actual exploit having been written for this bug, so we cannot be absolutely certain that it can be realistically exploited. It might be, for example, that no particularly sensitive data happens to be within range of the underflowing buffer. However, it would be incautious not to assume the worst and treat this as a potentially disastrous attack.)
The obvious fix is for
modpow() to reduce
mod as the very first thing it
does, thus preserving the mathematical correctness of the function
(and improving performance if anyone should use an overlong
base for a legitimate reason!). PuTTY release 0.55
implements this fix, and is believed not to be vulnerable.
This bug is EXTREMELY SEVERE in SSH-2. SSH-2 uses
Diffie-Hellman key exchange, in which each of client and server
sends a large number to the other, and each one performs a
modpow operation using that large number as the base.
In other words, a malicious server can exploit this bug during the
initial key exchange phase, before the client has received
and verified a host key signature. So this attack can be performed
by a man-in-the-middle between the SSH client and server, and the
normal host key protections against MITM attacks are bypassed. Even
if you trust the server you think you are connecting to,
you are not safe.
The bug is of more limited impact in SSH-1. In SSH-1, all the
modpow operations performed during key exchange involve
the client inventing
base, while the server
mod. Therefore, a
malicious server cannot exploit this bug during SSH-1 key exchange.
They can only exploit it during public key authentication, in which
the server sends an RSA-encrypted value and the client performs a
modpow to decrypt it. This means that the only servers
which can attack you through this bug are servers you trust, since
by the time the server can mount this attack it must already have
proved that it holds an acceptable host key. Also, if you use SSH-1
but do not use public-key authentication, there is no
longer any opening for the server to exploit this bug.
However, see vuln-ssh1-kex for another potential problem in SSH-1 key exchange. Even SSH-1 users who do not use public-key authentication should upgrade.
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, and has been assigned CVE ID CAN-2004-1440 and OSVDB ID 8299.
Audit trail for this vulnerability.