Date: Fri, 1 Jun 2001 20:28:13 +0200 From: "Karsten W. Rohrbach" <karsten@rohrbach.de> To: Crist Clark <crist.clark@globalstar.com> Cc: Michael Han <mikehan@mikehan.com>, security@FreeBSD.ORG Subject: Re: Apache Software Foundation Server compromised, resecured. (fwd) Message-ID: <20010601202813.H10477@mail.webmonster.de> In-Reply-To: <3B17C2E8.C24B8262@globalstar.com>; from crist.clark@globalstar.com on Fri, Jun 01, 2001 at 09:29:28AM -0700 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> <3B17C2E8.C24B8262@globalstar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--tcC6YSqBgqqkz7Sb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Crist Clark(crist.clark@globalstar.com)@2001.06.01 09:29:28 +0000: > "Karsten W. Rohrbach" wrote: > >=20 > > 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? >=20 > 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=20 > 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=20 > process on Host_B has access to the authentication materials loaded > in the ssh-agent on Host_A. i understand... so, also, session key and per-session security won't work, regardless of their specific implementation unless the agent forward channel does not get plausibility checking (dunno the exakt word for it, german: plausibilitaetspruefung) and/or the agent itself gets instrumentation to allow/disallow certain auth requests or to have a dialog pop up that does this thing. >=20 > 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=20 > 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). for the environment portion (which is the basis for the root account based attack), would it make sense to lock the pages in memory like gnupg does? ssh is suid root, anyway so this should not be much of a problem, right? >=20 > 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. that for sure, but i am currently thinking about the SSH_ASKPASS interface for X11 which would also allow some better application protocol, thus the possibility of displaying alerts with the askpass executable, including detailed info about the remote side requesting the signature, and the option of user intervention by simply pressing cancel. does this make sense? > 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 ooh. i forgot. wasn't this sent to a mailing list? *grin* i hope nobody sues me for replying to it in public... nevermind ;-) cheers /k --=20 > What can you use used tampons for? Tea bags for vampires. KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.n= et/ karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- catch@spam.de GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 B= F46 --tcC6YSqBgqqkz7Sb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7F969M0BPTilkv0YRAgrUAKCVscH3PVCX6HAhkCot8V11n/odzACfQw4l Ve1CPbty8HRmXjM+8vwmnxY= =XB3W -----END PGP SIGNATURE----- --tcC6YSqBgqqkz7Sb-- 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?20010601202813.H10477>