| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| no-trivial-auth.patch | New option to reject 'trivial' success of userauth. Suggested by Manfred Kaiser, who also wrote most of this patch (although outlying parts, like documentation and SSH-1 support, are by me). This is a second line of defence against the kind of spoofing attacks in which a malicious or compromised SSH server rushes the client through the userauth phase of SSH without actually requiring any auth inputs (passwords or signatures or whatever), and then at the start of the connection phase it presents something like a spoof prompt, intended to be taken for part of userauth by the user but in fact with some more sinister purpose. Our existing line of defence against this is the trust sigil system, and as far as I know, that's still working. This option allows a bit of extra defence in depth: if you don't expect your SSH server to trivially accept authentication in the first place, then enabling this option will cause PuTTY to disconnect if it unexpectedly does so, without the user having to spot the presence or absence of a fiddly little sigil anywhere. Several types of authentication count as 'trivial'. The obvious one is the SSH-2 "none" method, which clients always try first so that the failure message will tell them what else they can try, and which a server can instead accept in order to authenticate you unconditionally. But there are two other ways to do it that we know of: one is to run keyboard-interactive authentication and send an empty INFO_REQUEST packet containing no actual prompts for the user, and another even weirder one is to send USERAUTH_SUCCESS in response to the user's preliminary *offer* of a public key (instead of sending the usual PK_OK to request an actual signature from the key). This new option detects all of those, by clearing the 'is_trivial_auth' flag only when we send some kind of substantive authentication response (be it a password, a k-i prompt response, a signature, or a GSSAPI token). So even if there's a further path through the userauth maze we haven't spotted, that somehow avoids sending anything substantive, this strategy should still pick it up. (cherry picked from commit 5f5c710cf3704737e24ffceb2c918e412a2a674f) |
Simon Tatham <anakin@pobox.com> | no | debian | upstream, https://git.tartarus.org/?p=simon/putty.git;a=commit;h=1dc5659aa62848f0aeb5de7bd3839fecc7debefa | 2023-12-21 |
| no-trivial-auth-doc.patch | Document -no-trivial-auth more thoroughly. | Jacob Nevins <jacobn@chiark.greenend.org.uk> | no | debian | upstream, https://git.tartarus.org/?p=simon/putty.git;a=commit;h=413398af85b27cd83134f5618bd82f81758f9603 | 2023-12-21 |
| PTRLEN_DECL_LITERAL.patch | New macro PTRLEN_DECL_LITERAL. This is like PTRLEN_LITERAL, but you can use it in a _declaration_ of a compile-time constant ptrlen, instead of a literal in expression context. 'const ptrlen foo = PTRLEN_DECL_LITERAL("bar");' |
Simon Tatham <anakin@pobox.com> | no | upstream, https://git.tartarus.org/?p=simon/putty.git;a=commit;h=ef843e963833d430be7c29977635e15ff53ff443 | 2023-12-21 | |
| add_to_commasep_pl.patch | Extra utility function add_to_commasep_pl. Just like add_to_commasep, but takes a ptrlen. |
Simon Tatham <anakin@pobox.com> | no | upstream, https://git.tartarus.org/?p=simon/putty.git;a=commit;h=3a54f28a4eab33e322ac526bf8fc74b78c1013ea | 2023-12-21 | |
| 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.) [backport: also pulled in kexinit_keyword_found from commit f2e7086902b3605] |
Simon Tatham <anakin@pobox.com> | no | backport, https://git.tartarus.org/?p=simon/putty.git;a=commit;h=244be5412728a7334a2d457fbac4e0a2597165e5 | 2023-12-21 |