[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):

 I'm sorry that this is so frustrating for both of us. I'm trying to help
 with improving pidgin's user security. I'm sure I'm messing up conveying
 that information but there it is, again, hopefully clearly this time. :-|

 Replying to [comment:34 datallah]:
 > Replying to [comment:32 ioerror]:
 >
 > *SIGH* this is more painful than it should be.

 I know. I'm sighing too.

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

 As expected, triage of such a library is really hard and other people
 triage similar bugs together. So yes, it seems clear that the specific
 issue of search paths is not vulnerable over the wire, directly. However,
 the bug was also about *the shipping version of GTK* which is the same,
 right?

 > I feel like I've wasted far too much time replying to this ticket that I
 could have used for something useful.

 I feel like I have invested a lot of time in this ticket and about ten
 others. I am doing that because I want to help improve pidgin and to help
 keep pidgin users safe.

 If you feel like it is a waste, I'd urge you to consider that to be a very
 unmotivated way to frame this discussion. It sure makes me wonder if any
 progress is possible other than simply waiting.

 >
 > > 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.
 >
 > No, I'm talking about the latest stable GTK+ 2.x version, the same as
 you, not some unreleased version.

 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.

 I have no question in my mind that jumping to 2.99.x is probably a lot of
 work. That said - either way, it's a lot of work and I've repeatedly
 offered to help with that work.

 > With the exception of CVE-2010-4831, which is not a problem for us
 (whether you believe that or not)

 I wonder if you realize that I have never said that CVE-2010-4831 was a
 problem? Is that unclear?

 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.

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

 To belabor the point - the binaries shipped inside of the gtk-
 runtime-2.16.6.0.zip are vulnerable to a number of well know issues. Many
 of them have CVEs and at least *one* of them is known to be reachable over
 the network. It would be prudent to consider that unless someone takes the
 time to triage every security bug in detail, it is not safe to declare the
 GTK object code safe or to declare that Pidgin's use of that object code
 is safe.

 The core issue is that gtk-runtime-2.16.6.0.zip needs to be repackaged,
 without *known* the vulnerabilities and bugs. It doesn't matter how this
 happens - from gnome releasing an updated binary to us building it
 ourselves.

 > Let's limit the scope of this to talk of updating *SPECIFIC* problematic
 libraries (currently only libpng), and not the whole stack.
 >

 Honest question: Do you want me to write a test case for each library that
 I think is problematic?

 Why don't we say that the vulnerable libraries are worth updating and try
 to move forward with that? Wouldn't that also be reasonable?

 > > 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.
 >
 > Your other bug was merged with this bug because they both refer to
 potential security issues in the GTK+ stack that we distribute.

 Yes and I asked if we should move the discussion back to the other ticket.
 I didn't have any takers and as I have already said, I can't reopen that
 bug. So if we're not moving to another bug, I'm reasonably adding details
 about the issues with the GTK+ stack that pidgin distributes.

 >That doesn't make what was said previously in this ticket suddenly apply
 to all of the issues that you mentioned in your other ticket.  You bring
 back what I said a year ago (referring to CVE-2010-4831) out of context as
 if I was talking about the libpng issues; I've already corrected you on
 this, but here it is again.

 I understand what you are saying now loud and clear - it seems to me that
 the confusion stems from three issues. The first is that the opening bug
 report says ''This GTK+ version''. The second is that my very specific bug
 that doesn't even mention CVE-2010-4831 was closed as dupe of this one.
 Finally the third is that I asked if we should move to another bug and had
 no takers. At points when I found other seemingly related issues, I opened
 other bugs to avoid further confusion.

 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.

 >
 > > > > > 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. :(
 >
 > Even with this mindset, we should still only be updating particular
 problematic components, not the whole stack.

 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.

 If you want to only talk about CVE-2010-4831 in this bug, I'm happy to
 start over in another bug.  I can open a different bug for every CVE and
 we can triage each issue, if you'd like. Whatever works, really!

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