PuTTY 0.66 fixes security vulnerability | Hacker News Reader

PuTTY 0.66 fixes security vulnerability

chiark.greenend.org.uk

115 pointsgeococcyxc52 comments

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.

> signing the Putty executable

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).

Their current release key is RSA 2048: http://www.chiark.greenend.org.uk/~sgtatham/putty/keys.html

Which is also not on HTTPS.

I read this "old" piece about PuTTY the other day and it still seems just as absurd:

https://noncombatant.org/2014/03/03/downloading-software-saf...

See http://www.chiark.greenend.org.uk/~sgtatham/putty/keys.html

Also the.earth.li (PuTTY's download host) is available over HTTPS: https://the.earth.li/~sgtatham/putty/latest/x86/putty.exe

But I do agree that HTTPS on both by default would be great

Those keys aren't cross-signed (i.e. from a CA) and are delivered over HTTP. Totally and completely worthless.

A bad guy could just replace them with their own keys (assuming anyone manually checked these to begin with) and I couldn't detect it.

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.

https://sks-keyservers.net/pks/lookup?op=vindex&search=putty...

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.

> 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)

Based on a similarly quick websearch, even a non-EV code signing certificate seems to require jumping through a number of hoops:

https://www.dougv.com/2008/09/my-experience-getting-a-code-s...

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.

http://www.9bis.net/kitty/ Is pretty nice and has updates

You don't often see vulnerabilities in Putty, which considering the amount of corporate systems it's used with is quite amazing.

It may just mean nobody is looking at it.

I still don't understand why PuTTY got so popular (e.g. why not OpenSSH/Cygwin combo)

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.

PuTTY had a great VT100/xterm emulator long before any other free SSH option did. And it's a standalone app, no need for a giant Cygwin install.

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.

Because a lot of us don't need anything else Cygwin has to offer. So using it just to have OpenSSH feels like killing a house fly with a hammer.

PuTTY is also much quicker and easier to set up.

PuTTY is relatively portable, has just enough of a GUI to not require you use cmd.exe to run it, and is not GPL-ware.

(To be clear, I have nothing against the GPL, but some corporate environments avoid it like the plague.)

Cygwin/OpenSSH crashes/dies frequently (at least for me on Windows 7 / Cygwin64). Putty doesn't do that.

I use PuTTY at my job because we do all of our development on a Linux server but have Windows laptops issued to us.

Should check out XShell5. One of the best SSH clients I've used on Windows.

You know what I love about PuTTY? It's been around since the Clinton Administration (debuted in 1998), but it's still only at version 0.66.

What will it take to get a version 1.0? Sentience?

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.

MinTTY in Cygwin is based on the terminal emulation code from PuTTY, is it affected by the same CVE-2015-5309 ?

I'd also like to know this, but won't have time to check. There's also many many forks of PuTTY that'll need to be updated.

> This bug was found with the help of American Fuzzy Lop

  difficulty: fun: Just needs tuits, and not many of them.

What does tuits mean?

There's a phrase "get a round tuit" which is a phonetical approxmaton of "get around to it".

https://en.m.wiktionary.org/wiki/round_tuit

I've also seen it used as a variation on "intuition."

you just beat me tuit!

How do you execute privileged code from this vulnerability (on the client?)? What is the worst case senario?

> 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?

No, they must control the server, and with that they can compromise the client. Or at least this is how I understand it.

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.

Okay, but crashing the client isn't the same thing as compromising the client.

From the linked page describing the bug:

> 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?

My TtyRec player is PuTTY based <_<. Updates.

don't forget to restart, as well.

Is there anywhere sources of putty available?

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.h...

fuzzy lop seems to be quite handy since recently I saw a post here when they found 10s of bugs in ffmpeg.

I think it was more like 1000...

Too bad putty still doesn't support ed25519

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.)"

[1] http://tartarus.org/~simon-git/gitweb/?p=putty-wishlist.git;...

Ed25519 and ChaCha20-Poly1305 support are present in Git but not in any released version yet.

Looks like there is an automatically-built set of binaries that run off the development branch. Have a look here:

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.h...

Reply on news.ycombinator.com