Bugtraq mailing list archives
Re: SECURITY HOLE IN AUTHENTICATION FORWARDING
From: ylo () ssh fi (Tatu Ylonen)
Date: Sun, 13 Oct 1996 20:24:40 +0300
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
Current thread:
- antizap2. Digital Dreamer (Oct 08)
- Re: antizap2. Wolfgang Ley (Oct 09)
- novell utility BlackHeart (Oct 09)
- Re: novell utility Bruce M. (Oct 09)
- Re: novell utility Doctor Who (Oct 10)
- Sun Security Bulletin #136 Mark Graff (Oct 10)
- SECURITY HOLE IN AUTHENTICATION FORWARDING Charles M. Hannum (Oct 10)
- Re: SECURITY HOLE IN AUTHENTICATION FORWARDING Tatu Ylonen (Oct 13)
- InterNIC Shenanigans (crypt-pw) Sean B. Hamor (Oct 11)
- Re: InterNIC Shenanigans (crypt-pw) Yiorgos Adamopoulos (Oct 11)
- Re: InterNIC Shenanigans (crypt-pw) Igor Chudov @ home (Oct 11)
- Re: InterNIC Shenanigans (crypt-pw) Steve Reid (Oct 12)
- Re: InterNIC Shenanigans (crypt-pw) Rogue Agent (Oct 12)
- Excellent host SYN-attack fix for BSD hosts Avi Freedman (Oct 11)
- Re: Excellent host SYN-attack fix for BSD hosts Ollivier Robert (Oct 15)
- Re: Excellent host SYN-attack fix for BSD hosts Casper Dik (Oct 16)
- Re: Excellent host SYN-attack fix for BSD hosts David Schwartz (Oct 16)