Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Changes
|
Wishlist
From version 0.76, PuTTY will include an option to abandon an SSH connection if the SSH server ends the user authentication phase of the protocol without requiring any substantive input from PuTTY.
This option is available in the GUI in the Connection > SSH >
Auth config panel ("Disconnect if authentication succeeds trivially"),
or on the command line as -no-trivial-auth.
This is intended as a second line of defence against the same class of problem we describe in vuln-auth-prompt-spoofing, and addressed in 0.71 via a system of trust sigils (in GUI PuTTY) and post-authentication confirmation prompts (in command-line Plink).
The general class of attack is: you expect PuTTY itself to request
some kind of input from you during authentication (such as prompting
you for your key passphrase), but the server is either compromised or
malicious, and instead, it sends a
SSH_MSG_USERAUTH_SUCCESS response immediately, and then
the server tries to request the same input, by arranging for
you to receive a similar-looking prompt during the main session.
In this way, for example, you might be tricked into sending your private key's decryption passphrase to the server, when it never should have left your own machine.
This class of issue was reported to us in 2019, and in 0.71, we fixed it by the trust sigil system. Anything the server sends to try to trick you into thinking that authentication is still ongoing will lack the PuTTY icon to its left.
However, AUT-milCERT suggested to us that it makes life easier for the user not to have to spot the presence or absence of that small sigil. If you're expecting the server not to let you in without actually presenting some authentication (be it a password, a public-key signature, a one-time token or whatever), then you can now tell PuTTY that, and if the server should be taken over so as to attempt this kind of spoofing, PuTTY will disconnect before even presenting the spoof prompt. In addition to making this suggestion, AUT-milCERT also did the bulk of the work to implement it.
(But note that it's not a perfect defence in all cases. If an SSH server is configured to require two forms of authentication in sequence, then it could terminate early after the first of them, and this option wouldn't know anything was wrong!)
This is a new option, not enabled by default. That's because it is perfectly legal for an SSH server to let you in without any authentication! Some servers do it entirely on purpose, typically because they are SSH wrappers around some other service that presents its own login prompt not integrated with the SSH layer.
CVE-2021-36367 refers to this new option as a fix for a vulnerability, and describes the vulnerability as "PuTTY through 0.75 proceeds with establishing an SSH session even if it has never sent a substantive authentication response". With respect to the author of that text, we consider that to be misleading. It is perfectly legal for the server to waive authentication, and actually useful in some legitimate use cases; it is perfectly legal for PuTTY to proceed with the connection regardless; and the trust sigil system introduced in 0.71 already defends against every spoofing attack we know of that a server could attempt by doing this unexpectedly. This new option is a UI improvement, but not in and of itself a vital vulnerability fix.