Home page logo

bugtraq logo Bugtraq mailing list archives

Re: Claimed vulnerability in GTK_MODULES
From: Owen Taylor <otaylor () REDHAT COM>
Date: Thu, 4 Jan 2001 12:05:41 -0500

Kris Kennaway <kris () FreeBSD org> writes:

On Wed, Jan 03, 2001 at 10:40:33AM -0500, Owen Taylor wrote:
What follows is the official GTK+ team position on this matter.  (It
can be found at http://www.gtk.org/setuid.html as well.)  The summary
is that we don't consider it a problem because writing set[ug]id
programs with a GUI toolkit is simply a bad idea and not supported for

Why not force the issue and abort in GTK startup if issetugid() (for
those platforms which have it)?

I do plan on adding some sort of check like this in the next
stable release of GTK+ to help people avoid making this mistake.

The exact check is a little tricky - issetugid() can't be used
because it is too strict - it would disallow programs that drop
privileges before initializing GTK+, because they might
conceivably have acquired access to restricted resources.

While this level of strictness isn't ridiculous, it would prevent
current, arguably valid uses of GTK+. And if the programmer
really wants to create a security hole, they can do it even with
a issetugid() check. issetugid() is intended for different

What we what is a check that catches the cases where the
programmer is definitely doing something wrong. A simple:

 (getuid() != geteuid() || getgid() != getegid())

check is closer to this, though it doesn't handle the case of
POSIX saved IDs properly. On Linux, it is possible to use
getresuid() to make the check somewhat more thorough. [1]


[1] That still doesn't handle setreuid (geteuid(), -1), but in
    the end, if you are writing setuid programs, you do need to
    know something about the dangers.

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]