Re: GTK+-1.2.9 Released



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.

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. ;)

/Valdis

Attachment: pgpXQswzdgFmU.pgp
Description: PGP signature



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