Trick user to send private key password to compromised host

[Roman Fiedler]

Hi Damien and Kevin,

> On Sat, 17 May 2008, Kevin Buhr wrote:
>
>> Hi, Roman,
>>
>> I commented on this issue quite some time ago.  See:
>>
>>          http://marc.info/?t=95066120400001&r=1&w=2
>>
>> It didn't generate much interest at the time, but I probably explained
>> it poorly.  I agree with you that it is not a show-stopper, but I
>> still think it represents a significant security problem.

Bad, some new scenarios, I did not think about previously.

> Simple workaround: set IdentityFIle=none in the system-wide ssh_config
> and make your users use ssh-agent.

Yes, this works, and I tried also the -v (verbose) thing. After making 
my mind up over the weekend, I think of proposing a patch for the 
--paranoid option, which is somehow parallel to the standard debugging 
options. I want to modify some debugging if conditions, so that they 
write the log line if (loglevel>DEBUG_SOMELEVEL)||paranoidFlag. A login 
procedure with paranoid could look like that:

# ssh --paranoid root at localhost
Connecting to localhost [127.0.0.1] port 22.
Found host key in /home/admin/.ssh/known_hosts:1
Authentications that can continue: publickey (/home/admin/.ssh/identity)
Authentication succeeded (publickey), entering interactive session.
Last login: Mon May 19 14:11:38 2008 from 192.168.160.31

The last line is already from server.


> Fixing this is not as simple as putting a "you are now authenticated"
> message somewhere. Keyboard-interactive authentication can display
> arbitrary prompts, so a compromised server may display the spoofed
> question prior to authentication success.
>
> Furthermore, in a ttyful environment, connections any warning message
> can be erased through terminal manipulation.

That's nasty, I did not think about that. But

* interactive ssh cannot ask for additional passwords, so it will fail 
if login process missbehaves. So no additional messages are 
usefull/wanted here, and speed matters

* --paranoid: used mainly from commandline/tty, speed does not matter 
that much. Ssh could write all local messages, wait 1 sec so that one 
can take a short look (paranoids are fast) and then move the messages up 
above the first line of the screen. The ssh tty output would then start 
in the first line, any attempt to modify/overwrite the local ssh 
messages would cause their duplication (the original ones first, the 
modified ones afterwards).

Does someone know about tty controls, is such implementation possible/wise?

> A so-compromised server could also pretend to fail pubkey authentication
> entirely and ask for the user's password, which seems to be a more grave
> threat (and completely impossible to defend against from the client side).

That's true, but if a server refuses my pubkey, I'll go to the console 
directly (or RAC).

> -d
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev