Re: GTK+-1.2.9 Released

["J. Ali Harlow" <gtk-list avrc city ac uk>]

On Mon, 05 Mar 2001, Valdis Kletnieks vt edu wrote:
> That's a bit better.  I'm still leery of using an env variable to say
> "please do it", simply because a hacker about to use an exploit WILL
> say "please".
> 
> Better would be:
> 
> a) the app sets a global variable saying "It's OK'.
> b) The GTK lib then does something like:
> 
>    if (app_set_insecure_ok) {
>       /* check / isn't world/group writable */
>        /* check /etc isn't world/group writable */
>        /* check /etc/gtk_perms is not group/world writable */
>        
>        /* open /etc/gtk_perms and see if our app name is in there */
>        /* if so, do it *.
>    }
> 
> Yes, the checks on /etc and / are needed, to prevent rename races.

Overkill. If / or /etc is writeable you have much more to worry about than
an exploit via a GTK application.

> Checking in /etc/gtk_perms for argv[0] isn't safe, an attacker could
> play execve() games.  Probably better would be to store a triple in
> the file of (argv[0], filesystem, inode) as returned by stat(), and
> compare those to the results of stat'ing the currently running binary
> (which can be tricky to identify).  Also, that has an annoying tendency
> to break if you apply updates and/or dump/restore the filesystem when
> the inode number changes.

Get the app to supply the key as part of your step (a). Why would the app
lie? Plus there's a good chance that it would be unique.

> I'm sure there's other attacks I haven't thought of yet, this is the
> quick off-the-top-of-my head version.
> 
> And of course, what we end up is an ISO-standard band-aid, with bells,
> wistles, gauges, buttons, and supporting documentation, which still won't
> fix the problem of programmers who don't take the time to write secure
> code.
> 
> You're probably better off sticking with the current code. ;)

And end up with application writers who _will_ defeat it. We have too much time
invested, and too much to loose. What does that gain anybody? That you can
stand back and say it's our fault. Well we know that. The question is how can
we provide an incentive to the application writer to fix it properly while
making as sure as we possibly can that the end-user is aware of the problem and
that as far as possible it requires a positive step by the computer owner to
make themselves vulnerable.

If I've got to tell my users that they're going to have to add Slash'EM to a
list of insecure applications and if they get a warning every time they play
telling them that their system is vulnerable, I am going to have one powerful
incentive to fix this as soon as I can. If I defeat the check, I don't even
have to tell anybody (although I would). Once I've done it, I can pretty much
forget it. I may have the best intentions in the world, but I'm going to get
distracted by this feature that would improve the game or fixing that bug
somebody has found.

-- 
Ali Harlow                              Email: ali avrc city ac uk
Research programmer                     Tel:   (020) 7477 8000 X 4348
Applied Vision Research Centre          Intl: +44 20 7477 8000 X 4348
City University                         Fax:   (020) 7505 5515
London                                  Intl: +44 20 7505 5515