Date: Sat, 2 Jun 2001 15:53:02 +0200 From: "Karsten W. Rohrbach" <karsten@rohrbach.de> To: Robert Watson <rwatson@FreeBSD.org> Cc: Kris Kennaway <kris@obsecurity.org>, Crist Clark <crist.clark@globalstar.com>, security@FreeBSD.org Subject: Re: Apache Software Foundation Server compromised, resecured. (fwd) Message-ID: <20010602155302.A56136@mail.webmonster.de> In-Reply-To: <Pine.NEB.3.96L.1010602083607.65702I-100000@fledge.watson.org>; from rwatson@FreeBSD.org on Sat, Jun 02, 2001 at 08:58:33AM -0400 References: <20010601143755.B88206@xor.obsecurity.org> <Pine.NEB.3.96L.1010602083607.65702I-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010602155302.A56136>