Download: Stable · Pre-release · Snapshot | Docs | Changes | Wishlist
Up to and including version 0.70, the PuTTY tools had no way to indicate whether a piece of terminal output was a genuine user-authentication prompt (such as a prompt for a password, or for an SSH private key passphrase), or whether it was a faked version sent by the server after PuTTY's authentication phase had already completed.
For example, suppose that a malicious server let you log in without any authentication at all, and then started the session by sending text that looked exactly like PuTTY prompting you for your private key passphrase. If you didn't know for sure that you didn't expect that prompt, the server might trick you into entering your passphrase, which should not have been sent to any remote server.
If the server had also acquired a copy of your encrypted key file (which, for example, you might have considered safe to copy around because it was securely encrypted), then this would give it access to your private key.
This is a user-interface weakness rather than the usual kind of software vulnerability, so it requires a user-interface fix. It's also difficult to fix because the Unix terminal model gives the server so much control over what is displayed. For example, it wouldn't be enough for PuTTY to display a separator line between the real authentication prompts and the start of the main session, because the server could immediately send escape sequences that moved the cursor back up by a line and erased the separator! If you looked away from the screen and didn't catch the (probable) rapid flicker, you might easily miss that completely, and then the separator line would have been useless.
As of 0.71, we're using the following combination of strategies to distinguish legitimate from fake authentication prompts.
In GUI PuTTY: any line of the terminal containing data that was legitimately emitted by the local PuTTY during SSH connection setup is marked with what our code describes as a ‘trust sigil’. A trust sigil must be something the server can't cause PuTTY to display by sending escape sequences. We've chosen a small copy of the PuTTY program's icon, because it's multicoloured and distinctive. (You can think of it as the name of the speaker in a chat: it's indicating that PuTTY is saying whatever is written next to it.)
In Plink: at the point where authentication ends and the main session begins, we print a new interactive message: ‘Access granted. Press Return to begin session’. Then we wait for the user to acknowledge it by pressing Return, which means that even if the server overwrites the message immediately afterwards, the user will have seen it already and will know to be suspicious.
This additional interactive prompt is rather annoying (especially if you had set up one-touch authentication via a passphraseless SSH key or Pageant), so we provide as many methods as possible to avoid it:
-batchoption, it is assumed that you already know that you're not expecting any interactive authentication prompts, so you'll already be suspicious of anything that resembles one. So the new prompt is not given.
-no-antispoofoption, which unconditionally eliminates the new prompt.
rsync, which was the original use case for Plink in any case. The new prompt should only appear if you're using Plink for terminal-based interactive login, and even there, you have a choice of ways to suppress it.
During authentication (in all tools, GUI and console): prompts
and text sent by the server as part of the authentication phase (e.g.
SSH banners, or
login prompts) are prefixed with a vertical-bar symbol
|’) on each line, and their line lengths are limited so
that on a default 80-column terminal the server can't mimic an
unprefixed prompt by word wrapping. This should allow you to
distinguish a legitimate request for your passphrase from a fake one
sent by the server, even if the server sends it during
(This does mean that banners that previously took up the full width of a terminal, e.g., 79 or 80 characters, will now wrap and look ugly. This is unavoidable.)
This vulnerability was found as part of a bug bounty programme run under the auspices of the EU-FOSSA project.