Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Privacy
|
Changes
|
Wishlist
During the initial authentication phase of a network connection, PuTTY marks its own prompts with a 'trust sigil': a small copy of the PuTTY icon, to the left of the text. This distinguishes prompts that PuTTY emitted itself from identical text sent by a server.
The idea is to protect against spoofing attacks in which a server lets you log in without any password, and then pretends that it's still PuTTY itself doing initial authentication, and presents a prompt for something like your SSH private key passphrase. You might be fooled into telling the server that passphrase, which shouldn't ever leave the client machine. The trust sigil offers some protection, because the server can't make PuTTY display one of those, so it can't make its spoof password prompt look just like the real one.
In the older protocols such as Telnet and Rlogin, there is no formal authentication phase in the protocol itself: if the server presents a password prompt then it does it as part of the main session data. So trust sigils are not usually shown at all.
However, there's an exception. proxy-password-prompt introduced the ability to enter a password interactively when connecting to your server through a network proxy. So a trust sigil can be used in a Telnet session: it might appear during proxy authentication, before the Telnet session itself begins at all.
When this happened in 0.83 and before, the trust status was accidentally not cleared between proxy authentication and the main session. So the whole session would have trust sigils down the left-hand side.
I committed the fix for this in public, thinking it was just a silly bug. (When your whole Telnet session has those symbols down the side, you're surely going to realise they're a mistake, and not be fooled.) But since then, I've re-thought: it is a minor vulnerability, because what if the first thing the Telnet server (or MITM) sends is a request for your proxy password, perhaps pretending your previous entry of it was unsuccessful? That's still be a piece of information you don't want attackers knowing, and you might be fooled by the trust sigil into believing the request, before you find out that the rest of your session is all marked with that same sigil. By the time you notice that, it's too late – the damage is done.
So I'm classifying this as a vulnerability, although its impact is surely very small compared to most vulnerabilities. (Especially since it requires you to be using an old insecure login protocol like Telnet.)