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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ