Re: GTK+-1.2.9 Released



On Mon, 05 Mar 2001, Havoc Pennington wrote:
> "J. Ali Harlow" <gtk-list optosun7 city ac uk> writes:
> > There may be a clear argument, but I have to say that it is
> > unacceptable to me for the GTK team to resort to such
> > nannyisms. While it would not be impossible for the Slash'EM
> > development team to comply with this (and it would also have some
> > fringe benefits) it would take a huge amount of work - we would have
> > to change the graphical interfaces to the game into seperate
> > processes and implement a protocol for communicating with the game
> > core via pipes. It is quite ridiculus for the GTK team to impose
> > their priorities on us in this way.
> > 
> 
> If your app fails the check, your app is a security hole. Someone
> should post it to Bugtraq. The fact that fixing the hole is a lot of
> work doesn't really change the fact that it's a hole. ;-)

Granted. In effect, we consider that providing a hole into the games group is
not serious enough for us to have fixed the problem yet. Surely, this is a
matter between us and our users. By all means spew out a warning telling all
and sundry that you consider the application broken and that the writers should
be shot...

> If the app is for custom or in-house or "not on the net" systems only,
> then it should be acceptable to build a custom version of GTK with the
> check removed, and that's a fine thing. But GTK as shipped protects
> general users who may not be aware of security issues.

Doesn't apply to Slash'EM, but I agree it might be a solution for others.

> Any user who understands the security issue can trivially remove the
> check from their copy of GTK. Or app authors can ship a hacked copy of
> GTK and statically link, thus compromising only their app, and not
> introducing the issue for other apps on the system.

I suspect the vast majority of our users would find hacking GTK a bit of a
challenge. I agree we could ship binaries with statically linked libraries,
but the size would go up something horrid. It also wouldn't be a solution for
those UNIX platforms we only provide source support for.

I do think you are being needlessly heavy handed. Even calling gets(), which
everybody agrees is not on, doesn't actually break the application. And as I
say, I will subvert the check if I have to. At least if you supply a method of
defeating the check you can still issue a warning to the user and everything
will be out in the open.

-- 
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




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