Re: GTK+-1.2.9 Released



On Mon, 5 Mar 2001 Valdis Kletnieks vt edu wrote:

> On Mon, 05 Mar 2001 15:14:20 EST, Havoc Pennington said:
> > Perhaps the best solution is a combination, GTK_ALLOW_INSECURE enables
> > makes the gtk_disable_security_check() function do something, by
> > default gtk_disable_security_check() would be a no-op. So then you
> > need both the app author and the user to agree to make the app
> > insecure.
>
> 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.
>
> 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.

An [albeit Linux only] solution would be to check /proc/$pid/exe which is
a symlink pointing to the real inode where the executable lies. So you
could simply readlink /proc/$pid/exe and compare that to /path/to/program
in said file and would be on the safe side.

Nils
-- 
         Nils Philippsen / +49.711.96437.250 / nils redhat de
       Red Hat GmbH / Hauptstätter Straße 58 / D70178 Stuttgart
The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offence.                  -- Edsger W. Dijkstra





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]