Re: SSH revised

[Marcus Brinkmann]

At Fri, 24 Mar 2006 12:32:08 +0000,
Sam Mason <address@hidden> wrote:
> On Fri, Mar 24, 2006 at 03:53:11AM +0100, Marcus Brinkmann wrote:
> > The malicious user catching your passphrase would immediately use it
> > to start a man-in-the-middle attack.
> 
> That's probably more difficult as they would have to guess the correct
> username.

It's a good idea to always assume that the malicious party has all the
knowledge in the world, except a well defined small number of private
secrets.

> > Here is something you can do to avoid leaking the passphrase even if
> > you enter it: the system could run the user's authentication code in a
> > confined environment.  In this case, no information can be passed from
> > the authentication code to the user's session, so giving this piece of
> > code a sensitive password would not cause any problems.  This
> > mechanism would require a couple of additional steps, and make it more
> > difficult (but not impossible) to support things like one time
> > passwords.
> 
> I keep forgetting that you can do this confined execution thing.

Yeah, but note its limitation.  The malicious login agent could just
authenticate you without checking any credentials.  After that, you
are connected to the malicious session, which imitates your own
session.  Because your own password was not revealed, there can't be a
man in the middle attack.  But assuming that the session looks close
enough to your normal work place, you still might be lured into
entering private information.

So, it seems to me that what we are aiming here is to make it very
difficult to accidentially choose the wrong session to attach to.  The
confinement itself does not do much about that.

> Here's
> an idea that I've just spent a while thinking about.
> 
> Each user would register an agent with the system that performs the
> authentication checks (this could be done though the syslog idea you
> came up with previously).  This process would be isolated from all
> but a specific set of surrogate processes that would perform more
> complicated checks (interacting with kerberos servers, keeping track
> of one-time-passwords).

All these "complicated" (actually: non-confined) checks would have to
be carefully controlled system services.

> At authentication time this agent would be
> given a capability to the login device (terminal/SSH byte stream) and
> would be expected to interact with it and return if the authentication
> was successful or not.  When authentication has passed successfully,
> the terminal would be passed to the user's session init code.  The
> surrogate processes could have the option of attaching tokens to the
> login device that identify their state.

I don't understand the last sentence.  Apart from that, it comes close
to what I was thinking.

> > However, to really make this work you would also have to
> > indicate to the user when the authentication phase is over (because
> > that is when it is no longer necessarily safe to enter a secret), and
> > you could still not be sure if you are actually logged into the right
> > session (the malicious user's auth daemon could just grant you access).
> 
> This would be specific to each login device, and could be done by the
> controlling login process.

Would have to be done by it, actually.  Still, it sounds cumbersome.

> > The problem of leaking the password already exists in totally
> > different scenarios as well.  For example, I sometimes happen to enter
> > my IRC password into the wrong emacs buffer, much to the amusements of
> > my friends.  And I always wonder if the sysadmin of a remote machine
> > does not log my failed attempts at remembering the right password, to
> > fish for valid passwords on different machines I have accounts on.
> 
> I don't think we're going to solve that one just yet though :)

Actually, by consistently using public key authentication and a
passphrase caching agent, I think I could solve it for me.

> > > I'm aware that it also places limits on authentication mechanisms, but
> > > I'm having trouble reconciling these arguments.
> > 
> > I like the concept that sitting at a terminal (and entering a user
> > name) is necessary and sufficient proof for the human to be able to
> > assign the terminal to any user in the system.
> 
> yes, this would be nice.  but can only be done in situations where no
> sensitive information is stored or you know that physical access to the
> machine is controlled somehow.
> 
> I would like to have my computer at home running like this for example.
> But I would also like to have data/programs on it that are only
> available when more proof of identity has been given.

Oh sure.  I didn't say that having access to the terminal is
sufficient proof that the user you attach you uses the terminal in any
way!  A good default configuration would make the user first attach an
authentication daemon to the terminal to check who is sitting at the
terminal.
> > > That's all starting to sound a bit frightening and I guess we just want
> > > a way of passing the unencrypted packets to user space and back. . .
> > > Humm, I think the SSH server has just become fully trusted!  or can you
> > > use the containment bits of coyotos to verify that it is only going to
> > > be sending your data encrypted to the correct socket?
> > 
> > The system part of the SSH server is of course system code, just like
> > any other terminal hardware driver.
> 
> that seems obvious in retrospect!  I was mainly concerned that a bug in
> the SSH server wouldn't allow one user's session to observe (or worse,
> interact in) another users session.  But I think this sort of thing
> should be easy to guarantee.

It could.  But that's already true in the same way that a bug in the
network stack may allow you to sniff into other TCP/IP connections,
and a bug in the kernel may allow you to inspect other processes.

Now, it's correct that adding the shared SSH server adds another place
of vulnerability.  That can be avoided by the other idea to multiplex
connections at the TCP/IP level instead of the SSH connection level.
However, this raised other problems.

We can't hope to solve all problems in the world :)

Thanks,
Marcus