Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Re: SECURITY HOLE IN AUTHENTICATION FORWARDINGTatu Ylonen (ylossh.fi)
Sun, 13 Oct 1996 20:24:40 +0300
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Charles M. Hannum: "Re: Excellent host SYN-attack fix for BSD hosts"
- Previous message: Avi Freedman: "Re: Excellent host SYN-attack fix for BSD hosts"
- In reply to: Charles M. Hannum: "SECURITY HOLE IN AUTHENTICATION FORWARDING"
> 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