Sudo can optionally be built with support for Kerberos 5 authentication. A flaw in exists in sudo’s Kerberos 5 authentication that, depending on the local machine’s Kerberos 5 configuration, could allow a malicious user to avoid authenticating with sudo. The user would still be limited by the sudoers file as to what commands could be run (and as what user).
All versions prior to 1.6.9.
Proper Kerberos 5 authentication is done in two steps:
The user is prompted for a password which in turn is used to retrieve a ticket from the Kerberos 5 Server (aka the KDC).
If the ticket was successfully retrieved, it must be verified. This can be accomplished by using the ticket to request access to a service from the KDC. Without this step, it is possible for a malicious user to spoof the KDC in step #1 and with a bogus ticket.
The flaw in sudo is that a failure in step #2 was not treated as a fatal error.
Most sudo installations that utilize Kerberos do so via PAM (Pluggable Authentication Modules). Such sites are unaffected by the flaw.
The only installations that are affected are those that have configured sudo to link directly with the Kerberos 5 libraries and where Kerberos has beeen configured on the machine. Only hosts that are operating as a Kerberos 5 client only (and not a server or slave) are affected. Kerberos clients do not have a Kerberos 5 keytab file present on the local machine.
Exploiting the flaw requires that a malicious user be able generate a bogus KDC response, thus tricking sudo into believing that authentication was successful. Since the user almost certainly had to authenticate in order to login in the first place, there is little impact unless sudo has been configured to use a password other than the user’s for authentication. Even so, sudo will still only allow commands to be run that the user is authorized for.
Much has been made on Bugtraq about MIT Kerberos 5’s use of the
KRB5_KTNAME environment variable. This has no impact on sudo since
the authentication routines (including Kerberos 5) are run with a
zeroed out copy of the environment.
The bug is fixed in sudo 1.6.9.
Install local Kerberos 5 keytab files with the appropriate service keys on the affected machines.
This problem was brought to my attention by Thor Lancelot Simon.