Re: SSH revised

[Marcus Brinkmann]

At Thu, 23 Mar 2006 23:34:10 +0000,
Sam Mason <address@hidden> wrote:
> 
> On Thu, Mar 23, 2006 at 11:39:01PM +0100, Marcus Brinkmann wrote:
> > This is pretty accurate.  However, we also consider a variation.  In
> > the variation, in step 1 _only_ the username is supplied to the
> > system.  The system does not do authentication.  Then step 2 and 3
> > happen.  Before step 4, the user code would do the authentication
> > itself.
> 
> I'd be slightly worried about this; if I misspelled my username,
> wouldn't my password be sent to some random users password logger?

The malicious user catching your passphrase would immediately use it
to start a man-in-the-middle attack.

Note that the underlying problem is well known, and exists for example
in SSH.  That's why SSH has the "known hosts" file.  The problem is
that without knowing who you are we can't look up the right "known
hosts" file for you (ie, the list of user names you think you can use
safely).  That's a chicken and egg problem.  It needs to be
bootstrapped in some way, and there are a couple of things you can do
to improve the situation:

First of all, it's a good policy for the sysadmin to not allow
usernames which are too similar.  For example, there shouldn't be a
user "O13" and "013", or "Marcus" and "Mracus".  This is rather simple
to do, and avoids the problem of any spelling errors, also on the side
of the administrator (the log-on mechanism is not the only case where
there could be misspellings, it's the same with email, the admin
granting a user special privileges, etc).

Another thing is: don't misspell your username.  Or if you do, press
the Escape sequence that resets the terminal.  Now, this requires that
you know that you misspelled your username.  One way to help with that
is to display the username on a secure display device at the terminal.
This could be a protected frame on the screen, or an LCD device etc.
The log-on manager could help you avoid entering the wrong username in
the first place by displaying a custom picture when you enter your
username (again, the system should not allow users to have similar
identifying pictures---in fact, it would be best to let the system
assign/generate the pictures).  Say, you always get a picture of a
goose when you log in.  Then the picture of an elephant should make
you nervous.  The picture serves of course as a sort of "fingerprint"
identifying your account (but one that can be checked visually in a
split-second).

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

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.

You could also customize your own user authentication agent and your
session, making it difficult to imitate.  For example, you can run a
simple reverse challenge-response protocol with your authentication
agent, where you ask the agent something private that is not known to
other potentially malicious users.  The malicious user would have a
hard time faking such an agent.  However, this solution is quite
inconvenient.

I think that of the above, probably the only solution that could
actually work in practice is the "picture displayed before login"
idea.  For text-based terminals you can make it ASCII art, or a catchy
quote by some famous person, or for geeks a real fingerprint of the
user name :) In any case, it provides an instant visual verification
that you did the right thing, and it is enforced by the system code.

The arguments above have various weaknesses, that's why I am saying
it's a variation that's under consideration.  However, my observation
is that it is very easy to harden the system by adding a mandatory
user-to-system authentication step, that comes before any user-to-user
authentication step.  That's a straightforward local change to the
code/design, so I am not overly worried.

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

Let me give you another example: I could set up, as a user, my account
in a way that allows anybody at "terminal 3" to see my finger
information, just by entering my username at the login prompt, even if
they don't have an account.  That's a flexibility that you can't do if
the system requires full authentication before assigning the terminal.
 
> > > this relies on each user registering some login agent with each
> > > authentication process in the system (i.e. local terminal login,
> > > SSH login, etc.) before logins to the user's account can happen.
> > 
> > Not really.  First, we do not need to send the capability to the user,
> > the user can ask for it with a blocking fetch operation.
> 
> OK, the mechanics don't bother me much at the moment.  But some user's
> process would have to contact some central process for any login to occur.

Yes.  It can also work the other way around, where the system invokes
the user's server.  But that's only possible because of some weird
properties of terminal servers in particular and doesn't generalize
well.  The user should do the system service invocation "get next
(terminal log in) event".
  
> > > This raises
> > > the question of what to do with an account that severs all ties with
> > > the outside world -- which could very well be a very useful thing to do!
> > 
> > You can't log on to that account using the terminals, then, of course.
> > 
> > You could still communicate to that account via other capabilities, if
> > they exist.
> 
> I was more interested in determining when a process had lost all
> communication with the outside world and should be killed off.  I guess
> this should be the admin's job though.

It's difficult to decide when a process has lost all abilities to
communicate, because memory may be shared, and that's an expensive
semantical check.  This is likely not something that will be handled
at all.  The operating system can garbage collect non-reachable
objects from the object store, though.  The storage will be given back
to the space bank, but I don't think the user's reserve can be
increased again, so for the user the storage is effectively leaked.

The solution to this is to use nested space banks and clean up the
resources of a program that you want to kill by shooting the sub space
bank.  We don't want to do reference counting and implicit destruction
on deallocation of the last reference (except for the POSIX emulation
layer).

But this is really a very different topic :)

> > So, in order to support other
> > functions of SSH, you need to separate the protocol handling into a
> > system layer and a user layer.  The interface between the system and
> > the user needs to reflec this.  Ie, the system needs to pass off the
> > SSH connection, with some of its state, to the user.  It was not clear
> > to me that this is possible, although Niels mail told us that it is.
> 
> Strange, I don't think I got Niels email.  

The list was CC'ed, but it didn't went through (yet?).
 
> > In particular, if we want to do the variation above, the username
> > needs to be received by the system code, but the credential
> > verification needs to be done by the user.  So, the split may happen
> > at an inconvenient place, and certainly long before the pty creation
> > step.
> 
> Baring my concerns above, I agree.
> 
> > In other words: Terminals consist of physical or logical devices that
> > the user needs to know how to use.  For SSH, there will be some funny
> > logical device, that is not a PTY, but represents an existing SSH
> > connection, with channels and what not.
> 
> are you suggesting that this "logical device" is only to be used in the
> context of SSH connections? or would it make sense to try and generalise
> this a bit?  i.e. the other end of the connection wants to set up a new
> PTY, a new incoming/outgoing port, wants access to your file system!

I don't know how the interface of the logical device would/should look
like.  I suppose that the logical device would sort of represent the
encrypted low level transport layer to the client side.

The user would have to implement all the higher level protocol stuff
of SSH themselves.  Ie, PTY set up, new ports, etc.

> 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.
 
Thanks,
Marcus