I appreciate the hard work Simon Tatham continues to do on Putty. Has he said anything about the possibility of either signing the Putty executable or at least using HTTPS? Or is he waiting for Let's Encrypt to come on tap?
He even references the threat on that page: "2015-05-19 Malware pretending to be PuTTY." Which would be a lot easier to detect if the software was signed.
But there's a GPG signature file which you can use to verify the download! How? I wouldn't know because I've never bothered. And if I remember correctly, the RSA key is also 1024 bits which is another no-no (this has come up before).
You don't appear to understand how the PGP web of trust works. The current release key is signed by the master key, which in turn has been signed by some keys which are indirectly cross-signed by a huge variety of developers many people are likely recognize.
> You don't appear to understand how the PGP web of trust works. The current release key is signed by the master key, which in turn has been signed by some keys which are indirectly cross-signed by a huge variety of developers many people are likely recognize.
Actually I do. It is just such a niche thing that for the few who will validate the key even fewer will check it on the P2P web of trust (and any person2person trust network is only as good as its members, so there is room for abuse there). Web of trust is a failed concept that the current CA structure destroyed.
Worse still, some people will validate the key only, and if the executable validates they assume it must be by the author. That is a dangerous piece of misinformation that it gives a false sense of security, in particular against state actors.
> I guess it's true to say WOT is useless unless you participate in it, but at this stage, it is of comparable uselessness as the existing CA system.
When you download software on Windows, Mac, and Linux it will first automatically check if the code signing certificate's root CA is in the trusted store, then it will check that the root CA actually signed the client CA, and finally it will check the client CA for validity. It does all of this for you behind the scenes and in a split second, then at least on Windows & OS X it will display a huge warning if it fails (or fail to load the executable entirely by default).
Essentially calling the current CA system "useless" is bizarre when it does all of this checking behind the scenes without any user intervention at all, and then warns the user when it fails. In particular when the web of trust is a convoluted mess of non-integrated software that less than 0.1% of users take advantage of, and even then need to manually remember to use and correctly interpret the result.
The way Putty is signed is non-standard and insecure. Web of trust is a failed concept.
So, what stops someone from getting a malicious app signed by the CA and then MITM your putty download with that? (based on a quick websearch, a code signing certificate is about $70)
If you secure your official download page via HTTPS, MITMing that connection requires getting your website cert signed by a CA. Which, while possible (see: DigiNotar) tends to be something the CAs try to avoid - lest they lose their license to print money by having their certificates revoked by browser vendors.
Because putty is smaller, faster, can work with serial ports too, which lets you use it to configure routers, debug arduinos, etc. It looks nicer, is easier to choose fonts, offers logging, offers easier clipboard control, and a lot of other features. In short, it's just a much more useful program.
I believe that the TTSSH extension to Tera Term fulfilled this before PuTTY. However, it was a separate extension to the Tera Term terminal emulator, so it was a bit fiddly to set up.
Cygwin is a lot bigger and more time consuming to install. Putty is what? Half a meg and you're done? Much much much lower barrier to entry.
There's also the issue that in a corporate environment, having a much smaller attack surface is greatly preferred. Trying to get something like Cygwin past the security dept in a BIG company - quite challenging.
My favourite was the roguelike ADoM, which went up to 0.99, then alpha through gamma, then up to gamma 16, for a final version of 0.99gamma16 before tripping over to 1.0.
> 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?
Looks like ed25519 was added in May 10th, 2015. [1]
We claim version: SSH-2.0-PuTTY_Snapshot_2015_11_08.b003e5c
Server version: SSH-2.0-OpenSSH_6.7p1 Debian-5
Using SSH protocol version 2
Doing ECDH key exchange with curve Curve25519 and hash SHA-256
Host key fingerprint is:
ssh-ed25519 256 <fingerprint>
Initialised ChaCha20 client->server encryption
Initialised Poly1305 client->server MAC algorithm (in ETM mode) (required by cipher)
Initialised ChaCha20 server->client encryption
Initialised Poly1305 server->client MAC algorithm (in ETM mode) (required by cipher)
I'm no expert, and this might not be what you are talking about, but to my untrained eye, it does?
Now, to get back on topic, they believe that the attack would already need access to the server.
"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.)"
He even references the threat on that page: "2015-05-19 Malware pretending to be PuTTY." Which would be a lot easier to detect if the software was signed.