bugtraq - MIT krb5: makes sudo authentication issue MUCH worse.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070607033737.GB3192@panix.com>
Date: Wed, 6 Jun 2007 23:37:37 -0400
From: Thor Lancelot Simon <tls@....tjls.com>
To: bugtraq@...urityfocus.com
Subject: MIT krb5: makes sudo authentication issue MUCH worse.

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