[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:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1133
expat 2.0.1 - the current stable version is 2.1.0
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0876
libpng 1.4.0 - the current stable version is 1.5.12
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3048
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3425
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3048
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0205
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2690
zlib 1.2.2 - the current stable is 1.2.7
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1849
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-
loaders.exe
-rw-r--r-- 1 nobody nogroup 24264 2009-09-02 13:13 gspawn-win32-helper-
console.exe
-rw-r--r-- 1 nobody nogroup 25718 2009-09-02 13:13 gspawn-
win32-helper.exe
-rw-r--r-- 1 nobody nogroup 26251 2010-02-07 12:35 gtk-query-
immodules-2.0.exe
-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
libgdk_pixbuf-2.0-0.dll
-rw-r--r-- 1 nobody nogroup 827670 2010-02-07 12:31 libgdk-
win32-2.0-0.dll
-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-
win32-2.0-0.dll
-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
libpangocairo-1.0-0.dll
-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
libpangowin32-1.0-0.dll
-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-
querymodules.exe
-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.
Ok.
> * libpng 1.4.0 is problematic - I've agreed about that since the first
time we started talking about it. It should be updated.
Ok.
> * 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
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.
>
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
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.
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 "2.16.6.1" 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
currently.
--
Ticket URL: <http://developer.pidgin.im/ticket/14571#comment:37>
Pidgin <http://pidgin.im>
Pidgin
More information about the Tracker
mailing list