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]

Message-Id: <B0DAA497-490E-4A7B-85C0-9AC6AE946517@egon.cc>
Date: Thu, 7 Jun 2007 10:13:46 -0700
From: James Downs <egon@...n.cc>
To: Thor Lancelot Simon <tls@....tjls.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: Sudo: local root compromise with krb5 enabled

On Jun 6, 2007, at 6:57 PM, Thor Lancelot Simon wrote:

> The 'sudo' package can be built to use Kerberos 5 for authentication
> of users.  When a user is properly authenticated to sudo, sudo grants

It should be noted that Kerberos is not an authorization system.  All  
this case does is allow a user, who can already log into your system,  
and already can use sudo, to bypass their real password.  If the user  
can't do things as root, correct or incorrect password isn't buying  
them much.

This IS a bug in handling kerberos authentication, but if the user  
can log into the system, the user can use any version of sudo, and if  
they're authorized, they already know their password, and can do  
things as root.

There's probably an attack here where an attacker can get in as a  
user without knowing the legitimate password, leverage the weakness  
in sudo to use a fake password, but if you can have people logging  
into accounts without knowing authentication information, you have  
other problems.

> 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.

This assumes that the service keytab is secure.  Does sudo use and  
recognize the KRB5_KTNAME environmental variable?  If so, this step  
isn't secure either.

Cheers,
-j