Versions of PuTTY and pterm between 0.54 and 0.65 inclusive have a potentially memory-corrupting integer overflow in the handling of the ECH (erase characters) control sequence in the terminal emulator.
To exploit a vulnerability in the terminal emulator, an attacker must be able to insert a carefully crafted escape sequence into the terminal stream. For a PuTTY SSH session, this must be before encryption, so the attacker likely needs access to the server you're connecting to. For instance, an attacker on a multi-user machine that you connect to could trick you into running cat on a file they control containing a malicious escape sequence. (Unix write(1) is not a vector for this, if implemented correctly.)
Only PuTTY, PuTTYtel, and pterm are affected; other PuTTY tools do not include the terminal emulator, so cannot be exploited this way.
The purpose of ECH is to erase multiple characters within a single line. To this end, it includes a numeric parameter to specify the number of characters to be erased. PuTTY accumulates this one digit at a time in an integer variable. As part of the processing of ECH, the check_boundary function checks whether the start or end of the erased range falls in the middle of a double-width character (such as a kanji ideograph) so that it can ensure that the whole character is erased. Each character cell in the live terminal is held as a structure containing among other things the character code and a word of attributes. A double-width character is recorded by having a special value called UCSWIDE as the character code in the second cell, and when check_boundary detects that value, it resets the character code of both cells to a fixed value and copies the attributes from the left one to the right one.
The vulnerability arises because PuTTY uses signed integer variables to hold the number of characters to be erased and doesn't adequately check for overflow. This means that by passing a very large parameter to ECH, an attacker could cause check_boundary to inspect memory outside the terminal buffer. Were it to find UCSWIDE there, it would corrupt some nearby memory. This might be exploitable if the attacker could arrange for UCSWIDE to be in memory somewhere near a sensitive data structure.
This bug was found with the help of American Fuzzy Lop and has been assigned CVE ID CVE-2015-5309.
Fixed with Version 0.66