Home |
Licence |
FAQ |
Docs |
Download |
Keys |
Links
Mirrors |
Updates |
Feedback |
Changes |
Wishlist |
Team
When PuTTY has sensitive data in memory and has no further need for it, it should wipe the data out of its memory, in case malware later gains access to the PuTTY process or the memory is swapped out to disk or written into a crash dump file. An obvious example of this is the password typed during SSH login; other examples include obsolete session keys, public-key passphrases, and the private halves of public keys.
PuTTY 0.63 and earlier versions, after loading a private key from a
disk file, mistakenly leak a memory buffer containing a copy of the
private key, in the function ssh2_load_userkey. The
companion function ssh2_save_userkey (only called by
PuTTYgen) can also leak a copy, but only in the case where the file it
tried to save to could not be created.
This applies to SSH-2 private keys only. It affects all tools in the PuTTY suite which load or save private keys: PuTTY, Plink, PSCP, PSFTP, Pageant and PuTTYgen. If any of those programs loads a private key directly (rather than getting a signature from an SSH agent such as Pageant) then they will have left information equivalent to the private key in memory for their entire run.
(Of course, in Pageant's case, its job is to retain decrypted private keys in memory, so this may not be so important. However, if you ever told Pageant to delete a key from memory, it would not have properly deleted it: it would still have retained a copy by mistake due to this bug.)
PuTTY 0.64 fixes this bug in all the tools.
However, it is still unavoidably very dangerous if malicious software is in a position to read the memory of your PuTTY processes: there is still a lot of sensitive data in there which cannot be wiped because it's still being used, e.g. session keys. And, as mentioned above, Pageant retains decrypted private keys in memory for long periods on purpose if you use it. So this fix somewhat mitigates the risks of malicious access to your PuTTY processes' memory, but no fix can eliminate those risks completely.
This issue is distinct from private-key-not-wiped, which was in a different part of the code and was fixed in 0.63.
This bug has been assigned CVE ID CVE-2015-2157.
Thanks to Patrick Coleman for spotting this issue and sending a patch.
Audit trail for this vulnerability.