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

Message-ID: <20070716172221.GA28225@panix.com>
Date: Mon, 16 Jul 2007 13:22:22 -0400
From: Thor Lancelot Simon <tls@....tjls.com>
To: Ken Raeburn <raeburn@....EDU>
Cc: bugtraq@...urityfocus.com
Subject: Re: Sudo: local root compromise with krb5 enabled

On Fri, Jun 15, 2007 at 02:36:11PM -0400, Ken Raeburn wrote:
> On Jun 14, 2007, at 11:00, Kyle Wheeler wrote:
> >
> >Maybe I'm misunderstanding here, but so what? This sounds like the
> >equivalent of this:
> >
> >     My program respects the $ALLOW_ROOT_COMPROMISE environment
> >     variable. You may think root compromises are bad, and that the
> >     environment variable is ludicrous, and I agree (that "feature"  
> >was
> >     added before I took over), but if I removed it then that would be
> >     an incompatible break from previous versions.
> 
> Don't forget, "... and we have a trivial way to turn it off, though  
> some programs can't be bothered to use it".

Honestly, when one's security software has an "API" consisting of hundreds
of functions (many duplicative) and a long history of not including many
functions used by the maintainers' own application code in that API
documentation, the suggestion "we have another function very much like that
in the API, except that it works right" is... well, I personally don't
consider it a terribly helpful suggestion.  As I'm sure Ken recalls, until
around the year 2000 it wasn't actually possible to write a function
equivalent to krb5_verify_user() without using functions present in MIT
libkrb5, but not documented in the API documentation!  (Or, if it was,
then none of MIT's own example application code did it that way)

Bad library API design like this almost inevitably leads to security holes
in application code.  What Heimdal has done in this instance seems to me
to be a much, much better way out of this particular Kerberos API pit.
There are other ways to pass ancillary data to Kerberized applications that
must run as root than by insanely dangerous use of environment variables.

Thor