Trick user to send private key password to compromised host
roman.fiedler at telbiomed.at
Tue May 20 17:56:02 EST 2008
Hi Damien and Kevin,
> On Sat, 17 May 2008, Kevin Buhr wrote:
>> Hi, Roman,
>> I commented on this issue quite some time ago. See:
>> 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).
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
More information about the openssh-unix-dev