> 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.)
From the sounds of it, an attacker needs to either compromise the machine you intend to ssh into, or mitm before you first ever connect. Once keys are cached you should easily notice if you've been mitmed.
No, it's much much worse than that. If you cat a log file, and the log file contains untrusted binary data (such as raw logging of an invalid request to a webserver or something), this can potentially exploit the vulnerability.
Yes, they need to compromise the server but they also need to compromise the client. With both compromised they will have the same execution privileges as the original Putty.exe, then they will need to ROPgadget? If they have both compromised by the heck do they need to use putty?
An attacker might just need to get something to show up into a log file that is then viewed using PuTTY. Always escape attacker-controlled data before logging or displaying it.
> This might be exploitable if the attacker could arrange for UCSWIDE to be in memory somewhere near a sensitive data structure.
Crashes are very frequently capable of being exploited, to the point that every crashing bug should be treated as a security vulnerability. At the very least, it's a DoS.
Seems like anyone with root on a server can compromise anyone who logs on to it using putty; e.g. by putting a payload in the motd or /etc/issue. Or setting the command prompt to something nefarious. Or putting something into log files that are cat'ed. Or even a regular account with access to put a log file somewhere, or using /wall. Or maybe a filename that is shown when using ls (like if you uploaded a file to a server and that file was stored with the name you entered as a user; this would require very carefully crafted shell code though).
All quite unlikely attack vectors and hard to pull off remotely, but I've seen exploits that looked harder from the outside.
Maybe you could trick the user into clicking on a link to "telnet:evilserver.example.com" and host a telnet-protocol-compatible TCP server on port 23 that just sends the payload without requiring any user login?
