Re: Claimed vulnerability in GTK_MODULES

[Havoc Pennington <hp redhat com>]

Pavel Machek <pavel ucw cz> writes: 
> Then those games are broken.
> 
> Because you are essentially saying: If you want to arbitrarily modify
> high-scores table, you just need to use GTK_MODULES and you'll get the
> access you want.
> 
> Those games should either
> 
> 1) use world-writeable high scores tables, so that everyone knows
> there's no security in there.
>

This overstates the case a bit. The games group setup makes it
necessary to have special knowledge to modify the high score table,
and you can only modify it in ways that the spawned setgid child will
accept (merge entries). You can't e.g. cat /dev/zero > scores, and you
can't add an arbitrary number of entries. So at most you can annoy
other people playing games by filling the 10-entry table with bogus
scores, you can't do anything else.

World-writable would mean people could create an arbitrarily large
file and other such things, which would be dangerous to system
security. Messing up a high scores table is not dangerous to
systemwide security.

> 2) fix gtk so that it is secure.
> 
> 2) might be better idea. It might not be good idea to rely on gtk+
> being secure anytime soon, but you should start with it, if only for
> games.
> 

It's impossible. Tiny programs specifically written to be setuid by
experts (e.g. "su") have had exploits. As Owen says, those programs
are 500 lines long. GTK is 500,000 lines. Even if risk increased
linearly, you have 1000 times the risk. But it isn't linear at all;
it's exponential.

Assuming linear, if you get an exploit in a 500-line program once
every few years, you get an exploit in GTK something like every day. A
more realistic assumption of exponential loss of security means
several exploits a day.

It is simply, flat-out, totally 100% impossible to make GTK or any
other 500,000-line GUI program secure in this way. It can't be done.

If you saw a program with 500K lines of code that was supposed to be
suid, you would just submit it to Bugtraq on principle. Because it's
an absurd idea. Just because the 500K lines are in a shared object
instead of in the app itself doesn't change the situation. The 500K
lines are still part of the program at runtime.

Imagine trying to audit this - and then realize that there are
probably a few thousand new/changed lines of GTK code per day...

Making GTK "semi-secure" (e.g. disabling themes, disabling input
methods, whatever) removes important functionality, and doesn't add
any benefit. The benefit one presumably wants is the ability to use
setuid GTK programs. That benefit is not attainable. Given that, there
is no reason to start handicapping other aspects of GTK in pursuit of
an impossible goal.

Havoc