PuTTY vulnerability vuln-modpow

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

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

summary: Vulnerability: serious buffer management bug in modpow()
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 501997ab2b2cadfb0c717ad3f5fb2cd53f19ad37

All versions of the PuTTY suite prior to 0.55 have a memory corruption vulnerability in the modpow() function.

This function performs modular exponentiation: it takes three arguments base, exp and mod, and it raises base to the power exp modulo mod.

Unfortunately, it fails to check that base is at most the same size as mod. By arranging for base to be significantly bigger than mod, 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 base argument 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 base modulo 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 provides exp and 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 CVE-2004-1440 and OSVDB ID 8299.


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 2019-03-21 07:16:27 +0000)