Lucene search

K
securityvulnsSecurityvulnsSECURITYVULNS:DOC:17227
HistoryJun 11, 2007 - 12:00 a.m.

MIT krb5: makes sudo authentication issue MUCH worse.

2007-06-1100:00:00
vulners.com
50

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