Re: Claimed vulnerability in GTK_MODULES

[Havoc Pennington <hp redhat com>]

Pavel Machek <pavel ucw cz> writes: 
> Why? Arbitrarily large file is no problem; any user can do this in
> /tmp/.
> 

But that's expected by admins, and many may have taken steps to limit
it (e.g. /tmp on another partition).

> > Messing up a high scores table is not dangerous to
> > systemwide security.
> 
> Still messing up high scores is bad thing, and should be
> prevented. Agreed?

I agree it would be nice, I don't agree that anyone has presented a
feasible way to prevent it. ;-)

> > 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.
> 
> Currently, security of high-scores is a joke. Okay, it is slightly
> better than world-writable file, but not much.
> 
> What I'm arguing for, is semi-secure gtk+. It might get exploit
> published every day, but for high-scores-security that is
> acceptable.
> 

I don't think moving from 0% secure to 0.1% secure, then fixing a bug
every day eventually making it to 5% secure after a few years of work,
would be a worthwhile activity. We do have real functionality and real
bugs to work on! Working on an impossible task on a daily basis is not
very productive.

We are not going to spend loads of time and disable important
functionality just to get some bogus "semi-security" in order to
prevent the more inept subset of crackers from adding false high
scores to a high score table. This is a much-pain zero-gain
proposition.

Havoc