openssh unix dev - Feb 2010 - "phishing" (was: [patch] Automatically add keys to agent)

[ Sorry, I did not see the renamed thread until I'd already replied on
  the old one.  Calling this a phishing attack is exactly right. ]

On 2010-01-30, Joachim Schipper wrote:
> If I understand you correctly, you argue that connecting to malicious
> hosts is currently secure, and will remain secure, but that it will
> become easier to convince people to send the passphrase for their key.
Yes.  Exactly.

[ ObDisclaimer: not "is currently secure" but "is currently
secure as
  far as we know" ;) ]
> You are right that this is a concern, but note that an attacker would
> only learn the passphrase to a key, which should be uninteresting
> without the key.
Absolutely.  So it's not a complete compromise of usable credentials.
...Unless the user has reused that passphrase somewhere else, and/or
used a "really good password" as also their passphrase.  The attacker
would have to find some other device on which you've used those
credentials, or gain access to your encrypted private key file some
other way.  (Depending on the environment this may not be as difficult
as it should be, such as internal networks using NFS'ed home
directories, etc.  But that is not ssh's fault.)
> More importantly, as you note, the current situation is no better. If
> you currently use keys, the attacker could send another 'Enter
> passphrase for <keyfile>' message to obtain the passphrase. (And
of
> course, if you currently use passwords, an attacker could obtain your
> password!)
> You are not wrong, but isn't this point applicable to a much wider
> range of cases than those covered by 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.

Thanks,

-- 

Hank Leininger <hlein at korelogic.com>
BE5D FCCA 673B D18B 98A9  3175 896E 3D4A 1B4D C5AC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 443 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20100201/dcacfd06/attachment-0001.bin>

[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.