From owner-freebsd-security Sat Jun 2 6:52:48 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.webmonster.de (datasink.webmonster.de [194.162.162.209]) by hub.freebsd.org (Postfix) with SMTP id 8A37937B423 for ; Sat, 2 Jun 2001 06:52:42 -0700 (PDT) (envelope-from karsten@rohrbach.de) Received: (qmail 56919 invoked by uid 1000); 2 Jun 2001 13:53:02 -0000 Date: Sat, 2 Jun 2001 15:53:02 +0200 From: "Karsten W. Rohrbach" To: Robert Watson Cc: Kris Kennaway , Crist Clark , security@FreeBSD.org Subject: Re: Apache Software Foundation Server compromised, resecured. (fwd) Message-ID: <20010602155302.A56136@mail.webmonster.de> Mail-Followup-To: "Karsten W. Rohrbach" , Robert Watson , Kris Kennaway , Crist Clark , security@FreeBSD.org References: <20010601143755.B88206@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.org on Sat, Jun 02, 2001 at 08:58:33AM -0400 X-Arbitrary-Number-Of-The-Day: 42 X-URL: http://www.webmonster.de/ X-Disclaimer: My opinions do not necessarily represent those of my employer Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Robert Watson(rwatson@FreeBSD.org)@2001.06.02 08:58:33 +0000: >=20 > On Fri, 1 Jun 2001, Kris Kennaway wrote: >=20 > > On Fri, Jun 01, 2001 at 04:19:51PM +0200, Karsten W. Rohrbach wrote: > > > Kris Kennaway(kris@obsecurity.org)@2001.05.31 19:35:55 +0000: > > > > On Thu, May 31, 2001 at 07:25:22PM -0700, Crist Clark wrote: > > > >=20 > > > > > According to the documentation, this is NOT how the agent forward= ing > > > > > works. The second client passes data, typically a challenge, back= to=20 > > > > > machine one, where the agent does its thing with the private key= =20 > > > > > material, then passes the decrypted challenge information back to > > > > > machine two. > > > >=20 > > > > Okay, I'm willing to admit I could be wrong about the mechanism, but > > > > the trust relationship still exists. The ssh-agent authenticates on > > > > demand, so as long as you're connected to the untrusted system it c= an > > > > authenticate as you to other systems without your permission. > > > this does not lead to a big tragedy since the agent protocol is > > > challenge-response. > >=20 > > Yes, but it's done on demand with no auditing. >=20 > A particularly entertaining scenario is the following one: user has a > private key on host A and C (where they frequently log in directly using a > password), and the paired public key on hosts A, B, C, and D, all in > different trust domains. The user logs into A, and sets up their > ssh-agent with the private key. The attacker compromises B, trojaning its > ssh daemon. The user logs into B from A with agent forwarding enabled, > and the attacker uses access to the agent to build authenticated > connections to A, B, C, and D. The agent uses debugger access on A to > compromise the running ssh-agent and get access to the keying material for > the RSA/DSA private key, or trojans the ssh-agent (either for that user by > manipulating the execution environment, or for the system if privilege is > escalated by modifying/replacing the binary, reordering the path, etc). this did not come to my mind because of my standard firewall setup which allows outgoing ssh connects only from all my workstations in different places. indeed, since the authorized_keys might be the same on the source host (A) this is a possible threat. if (A) does not have authorized_keys for the locally stored identity, this does not pose a problem. this should be added to the ssh docs and perhaps to security(7) by a native american or english speaker. > Note also that in a multiple-key scenario, the SSH client provides no way > to selectively forward keys to hosts, or express policy regarding whether > keys are then forwarded by the host you have connected to. would it be very hard to add this functionality? where would the policies be stored? storing them in the identity would require changing the key file format, so i guess something like an agent configuration would make sense. >=20 > Note that X11 forwarding has similar compromise properties, only it > provides an even more direct path to the user's keying material. sure thing. therefor i propose X11forwarding to be turned off by default in sshd_config and ssh_config. >=20 > The moral of the story, as has been pointed out a number of times, is that > unless you are willing to place substantial trust in the host you're > logging into, you should not forward either X11 or SSH to that host. And > from the perspective of host administrators, it may be that your host is > substantially at risk if a user uses the same private key to access other > hosts than your own host, using the default configuration for many SSH > clients (agent forwarding enabled). In fact, forcing the user to use > one-time passwords on a handheld device combined with SSH as a secure host > transport may provide the best protection from the perspective of a host > administrator. >=20 > SSH can provide a notable improvement over unencrypted communications in > many situations. But in some compromise situations, it can actually make > things much worse by providing access to hosts that previously would be > unaffected by the compromise, as it encourages the use of automatic and > shared authentication. i would go a little further and say that all pkcs based auth system have the explicit need to automate all this, since you as a user would not use it if you had to enter you key data all the time, etc. see 6) further down. to sum this all up: 1) we got a possible threat abusing the agent in several manners since it dumbfire signs all challenges it gets, so: - agent forwarding shoudl be turned off by default - the agent must write a log file with the vital signing process data, also syslogging would make sense sicne the admin could see the messages, too - the agent should get some instrumentation to process policies and allow/disallow certain signing requests - some popup/user intervention interface for signing challenge packets would improve interactive use - maybe it would make sense to have the agent evaluate the state of the session for validity, this would be a big change in the agent interface and most likely introduce new bugs 2) port forwarding poses at least a DoS threat, so this is turned off by default 3) X11 forwarding also poses several threats and should be turned off by default 4) i've seen several (other) os dirstributions allowing root logins over ssh. these should also be disabled in the default config 5) all of the pkcs based auth is good in a trusted environment, but when it comes to connecting to untrusted systems, s/key (or maybe opie) will be a much more sensible choice. 6) de-automation of certain ssh features would be a general objective to work on, it will give the user more fine grained control over what happens with his credentials /k --=20 > May the source be with you! 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 --9amGYk9869ThD9tj 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 iD8DBQE7GO++M0BPTilkv0YRAlE3AJ97LMtgWy6MMj7PhOxO0Wcfy9mHSgCZAV7y DrlHaIYBgBeoTXH0tGrmL7M= =rMzP -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message