bugtraq - 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-next>] [day] [month] [year] [list]

Message-ID: <20070607015725.GA22190@panix.com>
Date: Wed, 6 Jun 2007 21:57:25 -0400
From: Thor Lancelot Simon <tls@....tjls.com>
To: bugtraq@...urityfocus.com
Subject: Sudo: local root compromise with krb5 enabled

The 'sudo' package can be built to use Kerberos 5 for authentication
of users.  When a user is properly authenticated to sudo, sudo grants
that user (potentially limited) root privileges.  Thus a mistake in
the authentication code in sudo is potentially severe: it can lead
to a local root compromise.

To authenticate a user's password against a Kerberos server, it is
necessary to perform two steps:

1) Use the user's password to get a ticket from the KDC (Kerberos
   server).  This proves that the user entered a password satisfactory
   to the KDC, and returns a "ticket" to the application.

2) Use the returned ticket to request access to a local service from
   the KDC, and confirm that the ticket _for that service_ returned
   by the KDC is correct.  If this step is not performed, it is not
   possible to distinguish a response from a fake KDC that simply says
   "yes" to all requests from a response from the real KDC.

Widely distributed software using Kerberos for password authentication
(e.g. the original Merit RADIUS server code, as I disclosed in the mid
1990s) has had a long and ugly history of failing to perform the second
step, usually because its authors didn't understand that it was necessary.

But sudo has a curious bug: it *tries* to do the second step,
but if that step fails because no local service keys are known, it lets
the user become root anyway, because the (potentially fake) Kerberos server
said so.  For example, on a host without a "keytab" file:

$ sudo /bin/sh
Password for tls@...MPLE.ORG: 
sudo: kerb5: host service key not found: Unknown error -1765328203
#

Needless to say, this should be fixed.  Simply adding local keytabs
with service keys for every host that has a kerberos-enabled sudo
looks, from a cursory inspection of the code in auth/kerb5.c in the
latest sudo distribution (1.6.8pl12) like it will suffice: the other
errors appear to be correctly handled.  But woe betide any system
administrator who accidentally puts a Kerberos-enabled sudo on a host
that's configured as a Kerberos client only!

Or, apply this patch:

*** kerb5-vulnerable.c	Thu Jun  7 01:50:08 2007
--- kerb5.c	Thu Jun  7 01:51:06 2007
***************
*** 274,280 ****
  	log_error(NO_EXIT,
  		  "%s: host service key not found: %s", auth_name,
  		  error_message(error));
! 	error = 0;
  	goto cleanup;
      }
      if (keyblock)
--- 274,280 ----
  	log_error(NO_EXIT,
  		  "%s: host service key not found: %s", auth_name,
  		  error_message(error));
! 	error = -1;
  	goto cleanup;
      }
      if (keyblock)