[Pidgin] #14571: Win32 installer uses insecure GTK+ version

[Pidgin]

#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:                 
 Keywords:          |  
--------------------+-------------------------------------------------------

Comment(by ioerror):

 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
 vulns here.
 >
 > 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
 library.

 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
 the moment.

 I did however file this bug with Gnome:
 https://bugzilla.gnome.org/show_bug.cgi?id=682642

 This bug is also relevant and should similarly be solved by pidgin for the
 gtk downloads, regardless of patch version:
 https://bugzilla.gnome.org/show_bug.cgi?id=682641

 > As far as how the gtk.org binaries are built, I don't offhand know how
 they're built.

 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>
Pidgin <http://pidgin.im>
Pidgin