| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| fix-ext-info-s-check.patch | Fix check for "ext-info-s". ssh2_scan_kexinits must check to see whether it's behaving as an SSH client or server, in order to decide whether to look for "ext-info-s" in the server's KEXINIT or "ext-info-c" in the client's, respectively. This check was done by testing the pointer 'server_hostkeys' to see if it was non-NULL. I think I must have imagined that a variable of that name meant "the host keys we have available to offer the client, if we are the server", as the similarly named parameter 'our_hostkeys' in write_kexinit_lists in fact does mean. So I expected it to be non-NULL for the server and NULL for the client, and coded accordingly. But in fact it's used by the client: it collects host key types the client has _seen_ from the server, in order to offer them as cross- certification actions in the specials menu. Moreover, it's _always_ non-NULL, because in the server, it's easier to leave it present but empty than to get rid of it. So this code was always behaving as if it was the server, i.e. it was looking for "ext-info-c" in the client KEXINIT. When it was in fact the client, that test would always succeed, because we _sent_ that KEXINIT ourselves! But nobody ever noticed, because when we're the client, it doesn't matter whether we saw "ext-info-c", because we don't have any reason to send EXT_INFO from client to server. We're only concerned with server-to-client EXT_INFO. So this embarrassing bug had no actual effect. |
Simon Tatham <anakin@pobox.com> | no | upstream, https://git.tartarus.org/?p=simon/putty.git;a=commit;h=9e099151574885f3c717ac10a633a9218db8e7bb | 2023-12-18 | |
| refactor-ext-info-s-check.patch | Factor out the check for ext-info-* keyword. I'm about to want to use the same code to check for something else. It's only a handful of lines, but even so. Also, since the string constants are mentioned several times, this seems like a good moment to lift them out into reusable static const ptrlens. |
Simon Tatham <anakin@pobox.com> | no | upstream, https://git.tartarus.org/?p=simon/putty.git;a=commit;h=f2e7086902b3605c96e54ef9c956ca7ab000010e | 2023-12-18 | |
| refactor-confirm_weak.patch | Refactor confirm_weak to use SeatDialogText. This centralises the messages for weak crypto algorithms (general, and host keys in particular, the latter including a list of all the other available host key types) into ssh/common.c, in much the same way as we previously did for ordinary host key warnings. The reason is the same too: I'm about to want to vary the text in one of those dialog boxes, so it's convenient to start by putting it somewhere that I can modify just once. |
Simon Tatham <anakin@pobox.com> | no | upstream, https://git.tartarus.org/?p=simon/putty.git;a=commit;h=9fcbb86f715bc03e58921482efe663aa0c662d62 | 2023-12-18 | |
| strict-kex.patch | Support OpenSSH's new strict kex feature. This is enabled via magic signalling keywords in the kex algorithms list, similarly to ext-info-{c,s}. If both sides announce the appropriate keyword, then this signals two changes to the standard SSH protocol: 1. NEWKEYS resets packet sequence numbers: following any NEWKEYS, the next packet sent in the same direction has sequence number zero. 2. No extraneous packets such as SSH_MSG_IGNORE are permitted during the initial cleartext phase of the SSH protocol. These two changes between them defeat the 'Terrapin' vulnerability, aka CVE-2023-48795: a protocol-level exploit in which, for example, a MITM injects a server-to-client SSH_MSG_IGNORE during the cleartext phase, and deletes an initial segment of the server-to-client encrypted data stream that it guesses is the right size to be the server's SSH_MSG_EXT_INFO, so that both sides agree on the sequence number of the _following_ server-to-client packet. In OpenSSH's modified binary packet protocol modes this attack can go completely undetected, and force a downgrade to (for example) SHA-1 based RSA. (The ChaCha20/Poly1305 binary packet protocol is most vulnerable, because it reinitialises the IV for each packet from scratch based on the sequence number, so the keystream doesn't get out of sync. Exploiting this in OpenSSH's ETM modes requires additional faff to resync the keystream, and even then, the client likely sees a corrupted SSH message at the start of the stream - but it will just send SSH_MSG_UNIMPLEMENTED in response to that and proceed anyway. CBC modes and standard AES SDCTR aren't vulnerable, because their MACs are based on the plaintext rather than the ciphertext, so faking a correct MAC on the corrupted packet requires the attacker to know what it would decrypt to.) |
Simon Tatham <anakin@pobox.com> | no | upstream, https://git.tartarus.org/?p=simon/putty.git;a=commit;h=244be5412728a7334a2d457fbac4e0a2597165e5 | 2023-12-18 | |
| add-missing-aes-selector-flags.patch | Add missing flags to AES selector vtables. They ought to have the same data as the real AES implementations they will hand off to. |
Jacob Nevins <jacobn@chiark.greenend.org.uk> | no | upstream, https://git.tartarus.org/?p=simon/putty.git;a=commit;h=58fc33a155ad496bdcf380fa6193302240a15ae9 | 2023-12-18 | |
| terrapin-warning.patch | Warn about Terrapin vulnerability for unpatched servers. If the KEXINIT exchange results in a vulnerable cipher mode, we now give a warning, similar to the 'we selected a crypto primitive below the warning threshold' one. But there's nothing we can do about it at that point other than let the user abort the connection. |
Simon Tatham <anakin@pobox.com> | no | backport, https://git.tartarus.org/?p=simon/putty.git;a=commit;h=0b00e4ce26d89cd010e31e66fd02ac77cb982367 | 2023-12-18 | |
| remove-fatal-error-reporting-from-scan_kexinit.patch | Remove fatal-error reporting from scan_kexinits. This will allow it to be called in a second circumstance where we're trying to find out whether something _would_ have worked, so that we never want to terminate the connection. |
Simon Tatham <anakin@pobox.com> | no | upstream, https://git.tartarus.org/?p=simon/putty.git;a=commit;h=fdc891d17063ab26cf68c74245ab1fd9771556cb | 2023-12-18 | |
| terrapin-warning-reconfiguration.patch | Terrapin warning: say if reconfiguration can help. The Terrapin vulnerability affects the modified binary packet protocol used with ChaCha20+Poly1305, and also CBC-mode ciphers in ETM mode. It's best prevented by the new strict-kex mode, but if the server can't handle that protocol alteration, another approach is to change PuTTY's configuration so that it will negotiate a different algorithm. That may not be possible either (an obvious case being if the server has been manually configured to _only_ support vulnerable modes). But if it is possible, then it would be nice for us to detect that and show how to do it. That could be a hard problem in general, but the most likely cause of it is configuring ChaCha20 to the top of the cipher list, so that it's selected ahead of things that aren't vulnerable. And it's reasonably easy to do just one fantasy-renegotiation, having moved ChaCha20 down to below the warn line, and see if that sorts it out. If it does, we can pass on that advice to the user. |
Simon Tatham <anakin@pobox.com> | no | backport, https://git.tartarus.org/?p=simon/putty.git;a=commit;h=b80a41d386dbfa1b095c17bd2ed001477f302d46 | 2023-12-18 |