"phishing" (was: [patch] Automatically add keys to agent)

[Joachim Schipper]

[Sorry for the wait; I've been/am extremely busy.]

On Mon, Feb 01, 2010 at 04:29:02PM -0500, Hank Leininger wrote:

> On 2010-01-30, Joachim Schipper wrote:
> > [Y]ou argue that connecting to malicious hosts is [and will remain]
> > secure, but that it will become easier to convince people to send
> > the passphrase for their key [once my patch to automatically add
> > keys to the agent has been applied].
> 
> Yes.  Exactly.
> 
> [ ObDisclaimer: not "is currently secure" but "is currently secure as
>   far as we know" ;) ]

<snip agreement: people shouldn't reuse the password to their keys, but
ssh should still try to protect them if they do.>

> > You are not wrong, but isn't this point applicable to [the current
> > situation as much as to] my patch? And do you know why it
> > hasn't been addressed yet?
> 
> Agreed.  Really this has always been an issue--people may debate over
> how large or small, but it has always been there.  I do not know that it
> has been discussed specifically, but it's akin to fake login prompts in
> computer labs / internet cafe's, fake "Good signature" PGP output in the
> top of an email (when using a text reader like pine and pgp4pine, where
> there's no clear delineation between filter-added-headers and message
> body), etc.
> 
> So, I'm not saying the proposed patch introduces a new technical
> vulnerability.  What it (may) do is change people's behavior /
> expectations, making the social / phishing vulnerability larger than it
> was before.
> 
> There is probably room for an entirely different discussion of: can the
> ssh(1) client do anything to reduce the risk of this?  Such as
> canary'ing the prompts, in a way easy for the user to verify, but hard
> for a remote system to blindly guess?  I don't have any good ideas that
> seem clean enough to not be highly annoying (or have untenable
> requirements like "there must be an X display that ssh can talk to, to
> pop the request up in"), but strong enough not to be faked out.  ...If
> that were sufficiently addressed, then this downside to AddKeyToAgent
> would go away too.

I've thought about this a bit. It's possible to solve the more basic
attacks by cribbing telnet's messages:

(All is well, user makes a typo)
    me at myhost $ ssh goodhost
    me at goodhost's password:
    me at goodhost's password:
 >> Connected to goodhost.
    me at goodhost $ exit
 >> Connection closed by foreign host.
    me at myhost $

(Fake prompt; "Connected to..." tips off user)
    me at myhost $ ssh badhost
    me at badhost's password:
 >> Connected to badhost.
    me at badhost's password:

(Ignore exit; lack of "Connection closed..." tips off user)
    me at myhost $ ssh badhost
    me at badhost's password:
    Connected to badhost.
    me at badhost $ exit
 >> me at myhost $

I don't think it's possible to prevent this, though:

(Pretend to crash, user enters password into an unrelated program)
    me at myhost $ ssh badhost
    me at badhost's password:
    Connected to badhost.
 >> Segmentation fault (core dumped)
 >> me at myhost $ sudo -v
 >> Password:

On the other hand, ssh crashing is rare enough to make people pay
attention and checking for this attack is easy (press ~), so the telnet
messages may be good enough. (Note that a watcher process wouldn't help;
people wouldn't know to expect a "Connection closed: ssh crashed"
message.)

Can you spot any flaws? Do you have any suggestions?

		Joachim

P.S. As an UI issue, "Channel closed" should be used instead of
"Connection closed" when closing one channel of a multiplexed
connection.