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

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

 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.


 > 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 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
 GTK+.
 >
 > 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.

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

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

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

 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
 beginning.
 I'm not asking you for a test case, I'm just not willing to update to a
 newer version "because it's newer".  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.

 > 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 "2.16.6.1" GTK+ Bundle
 with the next pidgin release (and if we have an updated expat and
 freetype, so much the better).
 If that doesn't seem to be happening in the next few weeks, then we can
 thing about a "Plan B".
 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.

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