[Pidgin] #14571: Win32 installer uses insecure GTK+ version
trac at pidgin.im
Fri Aug 24 17:21:17 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:31 datallah]:
> Replying to [comment:28 ioerror]:
> > 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.
> You haven't had to deal with the regressions that we've had almost every
time we've updated GTK+ or you wouldn't be advocating that path.
I think you misunderstand. I am not advocating jumping to the git tip of
their tree. I am advocating jumping to the compatible tip that isn't
vulnerable to multi-year old bugs. Part of that, I assume, is some bug
fixing on the GTK/pidgin side. I am by no means making light of that work.
> > 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.
> Not isn't, it mostly works, but there are issues with focus and the
system tray icon IIRC.
If the current code allows users to be exploited, which it appears is the
case, it is broken *now* and should be motivation enough for change. That
GTK updates andins't backport security fixes isn't pidgin's fault but it
sure is still a problem. That's why it's broken.
> > 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.
> I didn't ask you to provide an exploit for the libpng thing - from the
start, I acknowledged that we were probably vulnerable. I don't think
it's necessary to provide exploits - from the type of CVE we should be
able to tell if it is a problem for us or not.
Yeah, I realize you didn't ask for an exploit. I haven't provided one,
yet. I provided a malformed png to settle the discussion that it is a
problem. You actually stated a year ago: ''This isn't an "over the wire"
vulnerability.'' and so actually, I wouldn't say from the start that this
was an acknowledged bug. Furthermore, my other bug was closed as dupe,
even though it points out another handful of CVEs.
> > > 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
> I disagree. Just because there is a potential issue in a library which
Pidgin uses doesn't mean that it's a problem for Pidgin's usage of the
This is a mindset that causes a lot of security issues. I agree with you
in theory. In practice, you'll have to choose between triaging every
single CVE in a third party library, on a basically unsupported platform
or you can just assume the worst, which is probably a safe case. So yeah,
so, pidgin might not be vulnerable to *all of those CVEs* but pidgin would
be wise to just remove the vulnerable code, rather than trying to figure
that out. Especially when we consider the sheer number of issues. :(
> If it were easy to just update everything, then sure, that would be the
easy fix - however, since that isn't the situation, we can examine the
vulnerabilities and make an evaluation of whether or not it's going to be
a problem for how we use it.
This was already settled - libpng is remotely reachable and it is known to
be vulnerable. No one has produced information on how hard or easy it is
to update everything, so while I believe you when you state that it isn't
easy, it's not easy to help solve those issues either.
> > 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?
> I pointed you to the script that "builds" the gtk.zip we distribute in
one of the comments on this ticket - it is just a repackaging of the
binaries from gtk.org.
I understand. That's not going to get us a safe set of gtk libraries at
I did however file this bug with Gnome:
This bug is also relevant and should similarly be solved by pidgin for the
gtk downloads, regardless of patch version:
> As far as how the gtk.org binaries are built, I don't offhand know how
That seems like the next thing to figure out - if we can build it with
mingw, we can probably produce the win32 library code easily on a free
platform and iron out any Pidgin bugs that will pop up.
Ticket URL: <http://developer.pidgin.im/ticket/14571#comment:32>
More information about the Tracker