[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:26 datallah]:
 > Replying to [comment:24 ioerror]:
 > > I think waiting for pidgin 3.0.0 to upgrade GTK is a pretty dangerous
 idea. GTK should be rebuilt for the current pidgin versions. It might
 warrant a new release of pidgin proper because of GTK changes but it sure
 seems like an updated GTK.zip should be produced in any case.
 > >
 > > One of the issues with waiting until 3.0.0 is that the attack surface
 of a totally new major pidgin changes things significantly. Upgrading
 *everything* merely to stop users from using known buggy libraries is
 likely to have other issues. This is how wordpress used to do security
 fixes and it sure caused them a lot of problems. If somone wanted a patch,
 they had to update to the newest wordpress version, which also came with
 say, a bunch of new code that hadn't been audited. Upgrading users would
 fix one known bug and get ten new ones. A bad paradigm for reducing attack
 surface and certainly not a model worth emulating. :(
 >
 > The same "bunch of new code" argument could be made about the GTK+
 stack.
 >

 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.

 > > Also, if that is the path to an updated GTK/libpng/etc, regardless of
 net pidgin attack surface, the library attack surface is still present
 until the 3.0.0 release. It hasn't changed in over a year. I'd put my
 money on stable exploits being around for these issues in private.
 >
 > Updating the GTK+ stack "because it's old" is not a good idea.

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

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

 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?

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