Re: SECURITY HOLE IN AUTHENTICATION FORWARDING

[ylo () ssh fi (Tatu Ylonen)]

> Herein I describe an attack on ssh's authentication forwarding
> mechanism that allows another user on the same machine to steal a
> connection to your authentication agent.  This allows said user to
> connect to servers as yourself.

> By having access to the bound port in the ssh process, you can get
> access to the other side, simply by connecting, closing the
> connection, and then binding the port yourself and waiting for the
> agent to connect to you.  After doing this, you have access to the
> original authentication tunnel, and can submit queries to it yourself.
> This obviously allows for a man in the middle attack.
>
> As I said, this relies on a race condition, and as such may not be
> easy to exercise.  But as with most security holes with such serious
> consequences, I recommend not taking the chance.

I'm now just acknowledging that the problem is real; this was my
screwup (I never came to think that you can fool the real client to
close its socket before the agent connects).  The reasons why the
whole connection is made in such a complicated and stupid way are
historical, relating to how the code evolved when it first used a file
descriptor, then was fixed to support multiple connections, and then
changed to support unix-domain sockets (which have caused problems
before).

The attack essentially allows a local user to use another user's
agent; however, in practice this is quite difficult (but certainly not
impossible).

> In the case where you're using a Un*x-domain socket for the agent,
> this is really easy to fix, just by ripping out the use of the local
> IP port, and simply allowing multiple connections to the socket.
>
> In the case where the agent is using an inherited file descriptor,
> it's a bit more complicated.  One option is to create temporary named
> Un*x-domain sockets and bind them; however, if you do this, it's not
> clear that it's worth using the inherited descriptor at all.

I agree with your proposed fixes.

I'm very much inclined to at the same time entirely remove file
descriptor based forwarding, and only leave unix-domain sockets.  It
will simplify the code a lot, and also removes a lot of troublesome
stuff from the configure process.  The simpler it is, the easier it is
to make reliable.

Thanks for reporting this.  A patch should be available in a few days.

    Tatu