Sudo: local root compromise with krb5 enabled Jun 07 2007 01:57AM
Thor Lancelot Simon (tls rek tjls com) (2 replies)
Re: Sudo: local root compromise with krb5 enabled Jun 07 2007 05:13PM
James Downs (egon egon cc) (1 replies)
Re: Sudo: local root compromise with krb5 enabled Jun 07 2007 07:55PM
Mark Senior (senatorfrog gmail com) (1 replies)
Re: Sudo: local root compromise with krb5 enabled Jun 07 2007 08:05PM
Todd C. Miller (Todd Miller courtesan com)
Re: Sudo: local root compromise with krb5 enabled Jun 07 2007 03:19AM
Thor Lancelot Simon (tls rek tjls com) (1 replies)
MIT krb5: makes sudo authentication issue MUCH worse. Jun 07 2007 03:37AM
Thor Lancelot Simon (tls rek tjls com)
On Wed, Jun 06, 2007 at 11:19:01PM -0400, Thor Lancelot Simon wrote:
> On Wed, Jun 06, 2007 at 09:57:25PM -0400, Thor Lancelot Simon wrote:
> >
> > But woe betide any system
> > administrator who accidentally puts a Kerberos-enabled sudo on a host
> > that's configured as a Kerberos client only!
>
> Actually, if you link sudo to MIT krb5 (rather than Heimdal) it's worse
> than that, I think: users can override the system keytab setting and
> cause sudo to *think* there's no keytab when there actually is one, and
> then have it ask their fake Kerberos servers, and make them root.

And it's worse than that. If one ships sudo linked to libkrb5, even
if the system's not configured with kerberos turned on, one can override
the kerberos *client* config file (krb5.conf) location with the proper
environment variable, authenticate against his fake KDC, and become
root.

Evidently modern MIT krb5 has krb5_verify_user too and though it pokes
around in the library internals it doesn't set profile_secure in the
context. For that, with MIT krb5, one has to call krb5_init_context_secure()
instead of the standard krb5_init_context().

Anyone using MIT krb5 with any application that verifies passwords should
be very, very afraid. Even if krb5.conf and krb5.keytab are set up
correctly, one can simply override them via environment variable and
auth with fake servers.

This is clearly more MIT's fault than sudo's fault, and the initial patch
to sudo I posted won't protect against it (since one can override the keytab
and krb5.conf locations and just force a bogus keytab to be checked against
a bogus server). Now to find a nice neat way to cause applications to *never*
link correctly against MIT krb5...

Thor

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus