[Pidgin] #14571: Win32 installer uses insecure GTK+ version
trac at pidgin.im
Fri Aug 24 16:04:09 EDT 2012
#14571: Win32 installer uses insecure GTK+ version
Reporter: sdierl | Owner: datallah
Type: defect | Status: new
Milestone: 3.0.0 | Component: winpidgin (gtk)
Version: 2.10.0 | Resolution:
Replying to [comment:26 datallah]:
> Replying to [comment:24 ioerror]:
> > I think waiting for pidgin 3.0.0 to upgrade GTK is a pretty dangerous
idea. GTK should be rebuilt for the current pidgin versions. It might
warrant a new release of pidgin proper because of GTK changes but it sure
seems like an updated GTK.zip should be produced in any case.
> > One of the issues with waiting until 3.0.0 is that the attack surface
of a totally new major pidgin changes things significantly. Upgrading
*everything* merely to stop users from using known buggy libraries is
likely to have other issues. This is how wordpress used to do security
fixes and it sure caused them a lot of problems. If somone wanted a patch,
they had to update to the newest wordpress version, which also came with
say, a bunch of new code that hadn't been audited. Upgrading users would
fix one known bug and get ten new ones. A bad paradigm for reducing attack
surface and certainly not a model worth emulating. :(
> The same "bunch of new code" argument could be made about the GTK+
Indeed, one could make that argument for the GTK code as well as Pidgin.
That is why many projects backport security fixes. I assume that if pidgin
doesn't have time to recompile GTK and ship it, backporting fixes is out
of the question; that seems reasonable and it's why I'd advocate for
shipping the latest GTK - no time to test, no time to backport; just ship
the latest code and fix the Pidgin code to reflect that lack of time on
the GTK side.
> > Also, if that is the path to an updated GTK/libpng/etc, regardless of
net pidgin attack surface, the library attack surface is still present
until the 3.0.0 release. It hasn't changed in over a year. I'd put my
money on stable exploits being around for these issues in private.
> Updating the GTK+ stack "because it's old" is not a good idea.
I'm advocating updating the GTK stack because as I said in #15282 - it's
not just old, it has a dozen or more CVEs. It's not just old, it's
vulnerable and sometimes the code is vulnerable, reachable in Pidgin and
has *published* exploit code for the vulnerable library code. That is why
updating GTK is a good idea - to protect the windows users who are
otherwise vulnerable because of the GTK libs that pidgin requires.
Obviously, it's all half measures as the entire GTK library code is
downloaded over HTTP (see my bug #15277 about that issue) anyway but the
threat I'm worried about in this bug is remote code execution, denial of
service, and so on.
>GTK+ on Windows is not used very much and frequently things are broken
that nobody notices for a long >time. There are even things that are
broken if you try to run Pidgin 2.10.6 on GTK+ 2.24.10 - you can >try it
and see if you like.
It's broken, period. My original bug was about fixing the specifics issues
with GTK, it was closed as a dupe; so now I'm posting here to say that
each of the vulnerable components should be updated. Ideally without
having to produce a working exploit for each one, I hope.
> If there are specific issues that necessitate an update (e.g. this
libpng issue), we can update that particular component (as I'm willing to
do when we can get a newer official binary), but to update the whole stack
requires a lot of testing, and I don't foresee having time to do that soon
(nor do I see a good reason to do so).
Every item with a CVE in #15281 should be assumed to be reachable and
anything less seems irresponsible. I mean, we're not talking about 0day
here, which pidgin is rumored to have lots of, we're talking about 600+day
Moving forward here: How do we build a full gtk.zip file from scratch, so
we don't have to rely on gtk's builds for security issues?
Ticket URL: <http://developer.pidgin.im/ticket/14571#comment:28>
More information about the Tracker