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

Pidgin trac at pidgin.im
Sat Aug 25 19:41:52 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:                 
 Keywords:          |  

Comment(by ioerror):

 Replying to [comment:36 datallah]:
 > Replying to [comment:35 ioerror]:
 > > You stated: ''If you read my comments, I already explained why this is
 not critical. Just because a potential vulnerability exists in a
 particular library doesn't mean that it's possible to run into it our use
 case.'' That is confusing as all get out to me.
 > >
 > > In your sentence, you stated that ''this'' wasn't an issue, so I
 advocated moving the discussion back to my original bug. I can't even
 reopen my own bugs on this tracker. So yeah, it's pretty painful. How
 about meeting me halfway here?
 > I'm fine with combining the bugs - my point was that if we do so, don't
 take what I had previously said when this bug only referred to
 CVE-2010-4831 tout of context, which frustratingly, appears to still be
 happening in the latest reply.
 > At any rate, I'll try to move forward.

 Great to hear - if we're combining the bugs, I'll paste what I wrote in
 the other bug (#15281) as issues that seem at least slightly concerning:


 expat 2.0.1 - the current stable version is 2.1.0


 libpng 1.4.0 - the current stable version is 1.5.12


 zlib 1.2.2 - the current stable is 1.2.7


 I might be wrong about few of those versions but the GTK packages have
 some really really far off dates from the past.

 I think that libpng is settled - it has issues and we've agreed it needs
 to go.
 I think updating zlib is probably a good idea as well - though 1.2.3 is
 not as bad as 1.2.2, I think. I admit, I didn't read all of the changes
 between 1.2.3 and 1.27 - it seems prudent to just ship the newest thing as
 the API hasn't changed.
 I also think that expat is probably a ripe target - I've been trying to
 find a way to hit GTK's xml parser over the network and I'm not convinced
 it is unreachable. Lucky for us, svg isn't a normal buddy icon format...

 There are these libraries that I see:
 -rw-r--r-- 1 nobody nogroup  535264 2010-02-05 13:03 freetype6.dll
 -rw-r--r-- 1 nobody nogroup   25294 2010-02-07 12:30 gdk-pixbuf-query-
 -rw-r--r-- 1 nobody nogroup   24264 2009-09-02 13:13 gspawn-win32-helper-
 -rw-r--r-- 1 nobody nogroup   25718 2009-09-02 13:13 gspawn-
 -rw-r--r-- 1 nobody nogroup   26251 2010-02-07 12:35 gtk-query-
 -rw-r--r-- 1 nobody nogroup  104861 2008-01-24 14:54 intl.dll
 -rw-r--r-- 1 nobody nogroup  150664 2009-06-01 02:07 libatk-1.0-0.dll
 -rw-r--r-- 1 nobody nogroup  904525 2010-02-20 04:12 libcairo-2.dll
 -rw-r--r-- 1 nobody nogroup  143096 2009-01-31 13:42 libexpat-1.dll
 -rw-r--r-- 1 nobody nogroup  279059 2010-02-05 12:55 libfontconfig-1.dll
 -rw-r--r-- 1 nobody nogroup   53043 2010-02-07 12:37 libgailutil-18.dll
 -rw-r--r-- 1 nobody nogroup  252150 2010-02-07 12:30
 -rw-r--r-- 1 nobody nogroup  827670 2010-02-07 12:31 libgdk-
 -rw-r--r-- 1 nobody nogroup  482872 2009-09-02 13:14 libgio-2.0-0.dll
 -rw-r--r-- 1 nobody nogroup 1100888 2009-09-02 13:13 libglib-2.0-0.dll
 -rw-r--r-- 1 nobody nogroup   31692 2009-09-02 13:13 libgmodule-2.0-0.dll
 -rw-r--r-- 1 nobody nogroup  314501 2009-09-02 13:13 libgobject-2.0-0.dll
 -rw-r--r-- 1 nobody nogroup   40146 2009-09-02 13:13 libgthread-2.0-0.dll
 -rw-r--r-- 1 nobody nogroup 4740156 2010-02-07 12:35 libgtk-
 -rw-r--r-- 1 nobody nogroup  337702 2010-02-07 23:27 libpango-1.0-0.dll
 -rw-r--r-- 1 nobody nogroup   95189 2010-02-07 23:27
 -rw-r--r-- 1 nobody nogroup  686030 2010-02-07 23:27 libpangoft2-1.0-0.dll
 -rw-r--r-- 1 nobody nogroup  102774 2010-02-07 23:27
 -rw-r--r-- 1 nobody nogroup  219305 2010-01-12 06:05 libpng14-14.dll
 -rw-r--r-- 1 nobody nogroup   27101 2010-02-07 23:27 pango-
 -rw-r--r-- 1 nobody nogroup   55808 2004-10-04 17:08 zlib1.dll

 If I had to guess, I'd also say that the font stuff is bad news,
 specifically if GTK ever touches a web view of any kind...

 > > I have written proof of concept examples because it was stated that
 the *GTK release* is fine and that is does not suffer from remote
 exploitation. Clearly you mean to say that the single CVE in question is
 not remotely exploitable, which seems to be stated as *the GTK release*
 being fine overall. It isn't actually fine and other issues with GTK, not
 covering that CVE are collapsed into this bug report.
 > We need to clarify terminology, because I think that's part of the
 problem.  Usually for support reasons, "GTK" refers to the entire stack,
 and if you want to do that, then sure "GTK" is "vulnerable", however, in
 this context it only makes sense to refer to specific libraries, and not
 the whole stack.  I'm sure I've used the term in a confusing manner, and
 that hasn't helped.

 Ok. That is where a lot of confusion stems from, I think.

 >  * GTK+ 2.6.16 itself is fine except for CVE-2010-4831 - it doesn't need
 to be updated, and this really the library that I don't want to update
 because it'll break stuff.


 >  * libpng 1.4.0 is problematic - I've agreed about that since the first
 time we started talking about it.  It should be updated.


 >  * expat, freetype have some CVEs, but at an initial look, they don't
 appear to be a problem for pidgin

 It is expat that concerns me the most, freetype is probably not easily
 reached over the network.

 > Going forward, let's use the terms "GTK+ Bundle" to refer to the stack
 and "GTK+" to refer to the specific GTK+ library in the bundle.

 Ok. Sounds reasonable.

 So then, the goal of this ticket is to upgrade the GTK+ Bundle to include
 the same build of GTK+ 2.6.16 (even though it has CVE-2010-4831 because it
 will require a lot of pidgin work) and to change out each of core
 vulnerable the libraries (libpng, etc) that it links against.

 > > Yes and I'm talking about jumping to the latest stable GTK 2.4.x
 version that contains bug fixes relevant to this discussion. To apply such
 fixes, we'd need to explore what it will take to build GTK packages from
 source. I also opened a bug with Gnome to ask them to update things. So,
 I'd like to think I'm helping things along in parallel while also offering
 to do more heavy lifting.
 > My point is that none of these are actually in GTK+ itself, so the
 discussion about upgrading GTK+ is silly, hopefully my previous comment
 clarifies that.

 I understand. I agree that many of the CVEs are not in GTK+ itself. My
 concern about GTK+ is that older versions  even shipped by other groups
 appear (#15282) to also have issues - perhaps even similar issues.

 > > I have repeatedly made the point that other CVEs are indeed an issue,
 they were not addressed in this bug and that the opening parent bug was
 about the version of GTK shipped - which has many bugs and at the time of
 being opened had *other* CVEs!
 > >
 > > >none of these issues are in GTK+ itself, they're all in other third
 party libraries that >are built by the GTK+ folks and distributed with
 > >
 > > I'm sorry to say it but I think that you are wrong.
 > >
 > > GTK+ is *also* vulnerable to other issues as I demonstrated in #15282
 - so yes, absolutely these issues are in GTK+ itself. It is *also* true
 that GTK+ uses known to be vulnerable libraries and that Gnome ships
 seemingly vulnerable binaries on their website.
 > >
 > > I have address that issue with them (
 https://bugzilla.gnome.org/show_bug.cgi?id=682642 ) and we'll see where
 that goes. However, pidgin redistribute their object code and uses GTK's
 API - it is *precisely* that use that leaves users vulnerable. If we look
 for the specific issues that I mentioned in my other bug, I clearly stated
 the third party libraries that should be updated. I also stated that GTK+
 should also be updated (again, #15282) because not every fix gets a CVE.
 > I have no idea what the issue is in #15282, but I don't see anything
 indicating it is a bug in the the GTK+ library.  #15282 sounds like
 something completely different - it may be a GTK+ bug, but let's not
 complicate things by jumping to conclusions.  For all I know, it is caused
 by some old version of some library shipped in ubuntu natty, or some
 ubuntu patch.  If we figure out what the situation is there, we'll worry
 about it at that point.

 Sadly, that bug was closed by someone else. So yes, I agree, we should
 triage it as it certainly seems to impact part of the discussion here. :(

 > > > As I've said before, I don't want to upgrade the entire GTK+ stack
 right now unless there is a compelling reason to do so (which I haven't
 seen) because it's likely to cause more serious problems (and who knows,
 maybe introduce more vulnerabilities), so the talk about updating GTK+ is
 a distracting sidenote that you keep bringing back.
 > >
 > > This is pretty frustrating on a number of levels. You're basically
 saying that this still isn't compelling to upgrade the "entire" stack - I
 specifically suggested backporting security fixes and rebuilding the GTK
 object files. I also asked how the object files are compiled.
 > I'm struggling to communicate here - just because I say the whole stack
 doesn't need to be updated doesn't mean that we can't release an updated
 "GTK+ Bundle" containing GTK+ 2.6.16 with libpng 1.4.12, in fact that is
 exactly what I want to do.

 Ok. We agree - hooray!

 > > Honest question: Do you want me to write a test case for each library
 that I think is problematic?
 > No, I don't. I haven't heard any disagreement about my assessments of
 these CVEs - if you think I'm saying something is not a problem and it
 actually is, then please say which particular library and CVE.

 I think that expat is probably worth updating as well as zlib. Unless
 there is a certainty that there is no network reachable path.

 > All I've been trying to say the whole time is that I'm not willing to
 upgrade something just because it is old, because updating is more likely
 to break stuff than fix stuff based on past experience.  I'd be fine
 updating expat and freetype in addition to libpng if it's easy to do, I
 just am not fine updating the specific GTK+ library to a version newer
 than 2.6.16 right now unless there is a compelling reason.  I don't know
 how to make that more clear.

 I understand. I hope that we can triage #15281 to reach a decision even
 though it has been closed by someone else.

 > > In any case, we didn't move back to the other bug - I only saw
 arguments about how things are fine unless proven otherwise. That's a
 really huge uphill battle, if you ask me. You're still saying it too. As
 far as I can tell, I've got to show you that each library is problematic
 before we'll decide that it is worth dealing with things. That is a lot of
 > It's silly to move to move to another bug ticket at this point, but if I
 had realized it'd be so confusing, I would have done so that at the

 Ok. I will open other bugs as if I find anything serious and reference
 them here as the master ticket.

 > I'm not asking you for a test case, I'm just not willing to update to a
 newer version "because it's newer".

 My bar for entry on replacing a library is that it has a CVE or serious
 changes that probably would have warranted a CVE. The reason to update
 because it is newer, the reason is because updating probably takes less
 time than auditing code to determine if any one of ten CVEs impact
 something. And even then, if my assessment is wrong, I will have failed in
 a way that leaves people vulnerable.

 > It was enough that you pointed out the CVEs in libpng, it was pretty
 clear what the situation was when I looked at those, there was no need for
 anything beyond that.

 Perhaps. It did help me shake out the potential GTK+ bug in #15281.

 > > Yeah, I agree and have agreed that we should update the problematic
 components at the very least. I have also argued that based on resources,
 we should find a solution that makes sense - both in terms of time and in
 terms of leaving users vulnerable. Users are vulnerable right now and it
 seems like fixing that should be the primary goal.
 > So, with that in mind, I'm hoping the GTK+ folks will release a libpng
 1.4.12 binary, we'll swap that out and release a "" GTK+ Bundle
 with the next pidgin release (and if we have an updated expat and freetype
 too, so much the better).

 I haven't seen any response to the bug from the GTK+ people. If you have a
 way to reach them, I guess that's a blocker.

 > If that doesn't seem to be happening in the next few weeks, then we can
 think about a "Plan B".

 Shall we set a time out? Say, September 18th?

 > Alternatively, if you're really motivated to figure out how to build a
 version of libpng 1.4.12 that is binary compatible with the rest of the
 GTK+ bundle, far be it from me to stop you, but again, it is much
 preferable to me to use a binary from the GTK+ folks.

 Ideally, I think it would be prudent to find a way to do builds of their
 bundle from source. I'm pretty sure the GTK+ bundle will have more than
 one critical and remotely exploitable bug in its lifetime. It may not be
 required this time around but it certainly seems unsafe to hope the GTK+
 people will keep things updated, especially with how out of date it is

Ticket URL: <http://developer.pidgin.im/ticket/14571#comment:37>
Pidgin <http://pidgin.im>

More information about the Tracker mailing list