bugtraq - Re: Sudo: local root compromise with krb5 enabled

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]

Date: Wed, 6 Jun 2007 23:19:01 -0400
From: Thor Lancelot Simon <tls@....tjls.com>
To: bugtraq@...urityfocus.com
Cc: Todd.Miller@...rtesan.com
Subject: Re: Sudo: local root compromise with krb5 enabled

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.

This is because of a typical obscurity in the MIT Kerberos library
combined with some rather old code in sudo.  MIT libkrb does this,
in krb5_kt_default_name:

    } else if ((context->profile_secure == FALSE) &&
        (cp = getenv("KRB5_KTNAME"))) {
        if ((size_t) namesize < (strlen(cp)+1))
            return KRB5_CONFIG_NOTENUFSPACE;
        strcpy(name, cp);

So, if profile_secure isn't set in the context, users can simply
set KRB5_KTNAME to some nonexistent file, I think, and away they go
(as root).  Heimdal ignores the environment variable if issetuid()
though I'd be happier if it refused to respect it entirely. 

The MIT library provides several different flavors of krb5_init_context
and only one of them (krb5_init_secure_context()) actually sets the
profile_secure flag.  But sudo uses the standard krb5_init_context()
which does *not* set profile_secure and also doesn't call the obsolete
(and, I think, never documented) old krb5_secure_config_files() function,
which is the only other thing in the MIT library that would set
profile_secure and avoid this root compromise.

So the hole is worse than I thought.  It is probably simplest and best
to remove the current krb5 password validating code from sudo, and
use Heimdal's krb5_verify_user() instead, and make sudo thus no longer
work with MIT krb5, which is a terrible security accident just waiting
to happen.

Thor