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).
I read this "old" piece about PuTTY the other day and it still seems just as absurd:
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
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.
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.
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.
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.
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.
PuTTY is also much quicker and easier to set up.
(To be clear, I have nothing against the GPL, but some corporate environments avoid it like the plague.)
What will it take to get a version 1.0? Sentience?
difficulty: fun: Just needs tuits, and not many of them.
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.
> 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.
All quite unlikely attack vectors and hard to pull off remotely, but I've seen exploits that looked harder from the outside.
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)
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.)"