Date: Fri, 01 Jun 2001 09:29:28 -0700 From: "Crist Clark" <crist.clark@globalstar.com> To: "Karsten W. Rohrbach" <karsten@rohrbach.de> Cc: Michael Han <mikehan@mikehan.com>, security@FreeBSD.ORG Subject: Re: Apache Software Foundation Server compromised, resecured. (fwd) Message-ID: <3B17C2E8.C24B8262@globalstar.com> References: <Pine.BSF.4.21.0105311727160.66343-100000@pogo.caustic.org> <3B16E7D9.3E9B78FF@globalstar.com> <20010531183732.B12216@xor.obsecurity.org> <3B16F492.128CB8B0@globalstar.com> <20010531191001.A12808@xor.obsecurity.org> <3B16FD12.B1F251C8@globalstar.com> <20010601012133.A1203@giles.mikehan.com> <20010601162327.G10477@mail.webmonster.de>
next in thread | previous in thread | raw e-mail | index | archive | help
"Karsten W. Rohrbach" wrote: > > Michael Han(mikehan@mikehan.com)@2001.06.01 01:21:33 +0000: > > Crist, I believe your analysis is correct WRT decrypted keys or > > passphrases *not* being available except by compromising the > > originating client hosting the first ssh-agent in a chain. However, > > Kris is correct, as I understand agent forwarding, in that if you > > forward your agent from trusted host A to untrusted host B, a rogue > > superuser on B could copy your SSH_AUTH_SOCK environment and begin > > passing RSA key requests back to your agent on A. There *is* a > > vulnerability introduced by forwarding your agent to an untrusted > > host, which is why I do not usually forward my agent. I try to give my > > understanding of these issues in > > http://www.mikehan.com/ssh/security.html > this would be a standard man in the middle attack, right? > capturing the challenge from one machine passing it (as root) to the > agent, getting the response packet back and passing it on to the > to-be-broken-in server should not work due to session keying, should'nt > it? No. The problem people are describing is not a man-in-the-middle attack. Say you connect from Host_A to Host_B with agent forwarding enabled. When you do this, there is a sshd process on Host_B which is providing your SSH connection at Host_B. Agent forwarding basically means that the sshd process on Host_B can send authentication challenges to your ssh-agent process on Host_A, and the ssh-agent on Host_A will process them and return a response. Normally, if you were to ssh to Host_C from your session on Host_B, the ssh process started on Host_B will try to send auth. challenges to a local ssh-agent, but these get divered through your sshd on Host_B back to the ssh-agent on Host_A. The problem is that if root on Host_B is not (relatively) trusted or if the sshd binary is compromised your ssh-agent on Host_A has no way to know. It receives auth. challenge data from the sshd process on Host_B and responds. There is no way for it to know a priori whether the auth. challenge is legitimate or not. This means that as long as the agent forwarding channel is open, anyone who controls the sshd process on Host_B has access to the authentication materials loaded in the ssh-agent on Host_A. There are several ways to mitigate this attack. The obvious one is not to agent forward. This brings us back to the sourceforge problem. If you used public keys and did not do agent forwarding, the act of just logging in to the compromised sourceforge machine(s) would not have compromised any authentication secrets. A second possibility is to be careful about what keys you allow to forward. That is, if you have a group of machines at a similar level of trust and in the same administrative domain, perhaps one key pair to jump around those, and other keys to move around other groups. Only allow agents to forward the key associated with a domain around that domain. If one machine is compromised, an attacker can only access machines in that domain. It's a balance of usability versus security (as it always is). As for a more long term solution, I think the simplest thing would be to give ssh-agent some sort of logging abilities. One would still be vulnerable to the attack, but one would be aware of any unauthorized activities. -- Crist J. Clark Network Security Engineer crist.clark@globalstar.com Globalstar, L.P. (408) 933-4387 FAX: (408) 933-4926 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B17C2E8.C24B8262>