Opened 5 years ago

Closed 4 years ago

#14571 closed defect (fixed)

Win32 installer uses insecure GTK+ version

Reported by: sdierl Owned by: datallah
Milestone: 2.10.7 Component: winpidgin (gtk)
Version: 2.10.0 Keywords:
Cc:

Description (last modified by sdierl)

Secunia PSI complains about the GTK+ libraries downloaded by the Pidgin Win32 installer. This GTK+ version apparently has a DLL loading vulnerablity, as described in [1] and [2].

This can be fixed by using a recent GTK+ version.

[1] http://secunia.com/advisories/45815/
[2] http://jvn.jp/en/jp/JVN58019849/index.html

Attachments (3)

png-1-width-800-height-2.png (6.4 KB) - added by ioerror 4 years ago.
local-buddy-icon.png (5.6 KB) - added by ioerror 4 years ago.
png-1-width-519-height-2.png (4.2 KB) - added by ioerror 4 years ago.

Download all attachments as: .zip

Change History (44)

comment:1 Changed 5 years ago by datallah

  • Milestone changed from 2.10.1 to 3.0.0

We're planning to bump the GTK+ version with 3.0.0, so this will be addressed at that point.

comment:2 Changed 5 years ago by NishaKitty

Isn't v3.0.0 a little far off to be leaving a security vunrability in the client? v3.0.0 has 62 active tickets and I see no release date at all? Considering this vunrability is classified as Highly Critical and the report has "Successful exploitation may allow execution of arbitrary code.", I find this a little irresponsible unless I am misunderstanding the situation?

P.S Glad to see you guys have reCaptcha now but would be nice if it was just for registrations.

comment:3 Changed 5 years ago by NishaKitty

I just thought I'd leave a note to other users that you can update the bundle yourself I made my own via the individual packages and got rid of the old one. Seems to be working fine for me thus far.

comment:4 Changed 5 years ago by datallah

I guess how critical this depends on your perspective.

This isn't an "over the wire" vulnerability.

To exploit this problem, Pidgin has to be launched so that one of the potentially problematic DLLs is higher up in the search path than the expected DLL.

There are 3 scenarios under which this could happen:

  • The machine has the system DLLs with replaced with hacked versions (in which case, all bets are off and the updated GTK+ will still be just as vulnerable).
  • The Path of the machine has been updated such that a file with the name of one of these DLLs is in the Path (once again, if your machine has hacked files in the Path, you have bigger problems).
  • You can trick Pidgin to launch from a location containing the vulnerable DLLs (the current directory will be in the Path). This is the only situation that I think is worth worrying about. Generally, this type of exploit would be done by making a link to a file in the same directory as the vulnerable DLL and asking Pidgin to open it. Since Pidgin doesn't register any file types, this isn't an avenue that is really viable.

Given the above, I don't believe that this really affects Pidgin without the end user doing something that is already problematic (e.g. running a batch file that modifies the path or changes to a wacky directory and then launches Pidgin), so I don't think it is necessary to release an update to specifically address this issue.

comment:5 Changed 5 years ago by sdierl

  • Description modified (diff)

The DLL search order is described by Microsoft in [1].

As far as I can tell, the only critical case is a disabled SafeDllSearchMode, in which application directory and PWD are searched before the system directory.

The application directory is not critical, however, the PWD might be.

Shell links ("shortcuts") [2] can specify a PWD to use for an application. A possible attack scenario could be: Place a malicious Wintab32.dll and a shell link to Pidgin on a machine. The shell link specifies a PWD containing the malicious Wintab32.dll. If the user launches the shell link, Pidgin is started and loads the malicious library.

Still, this requires user cooperation and is a bit theoretical.

[1] http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx
[2] http://msdn.microsoft.com/en-us/library/bb776891%28v=vs.85%29.aspx

comment:6 Changed 4 years ago by QuLogic

Ticket #15281 has been marked as a duplicate of this ticket.

comment:7 Changed 4 years ago by ioerror

Huh, as I mentioned in #14571 - this seems rather critical unless those libraries are never used. If they're never used, why not just remove them from the .zip file?

comment:8 Changed 4 years ago by ioerror

Ahem, I mean as I mentioned in #15281, sorry.

comment:9 Changed 4 years ago by datallah

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.

It's non-trivial to update the version of the GTK+ stack that we use. Lots of versions newer than the current version are problematic for a variety of reasons. I believe that the latest few GTK+ 2.x releases have resolved most of the critical issues that made it not possible to upgrade for a long time, but I haven't had time to fully investigate.

comment:10 Changed 4 years ago by ioerror

I did read your comments and I am asking a question that has not been previously asked. It is still un-addressed:

Is there an assertion that none of the vulnerable .dll code is used *anywhere* by *anything*?

If so, why not remove the unused .dll files?

If I had a newer dll version locally, yes, I realize that Pidgin *might* load it. However, I don't have a newer version locally, that is why I installed the version provided by the Pidgin installer. It was surprising that it wasn't as current a build as the rest of Pidgin.

Furthermore, when you say it isn't an over the wire vulnerability, how exactly is Pidgin decoding my buddy's PNG icon if not with the libpng code in the .dll?

comment:11 Changed 4 years ago by datallah

You misunderstood what I wrote; the "vulnerable" DLL is used, of course, just not in a way that would be impacted by the vulnerability.

I guess part of the confusion is that the scope of this is being expanded from the original report, which only referred to CVE-2010-4831.

Looking at some of the things mentioned to in #15281, see https://bitbucket.org/pidgin/main/src/release-2.x.y/pidgin/win32/nsis/generate_gtk_zip.sh#cl-19 for the actual versions of the dependencies that are being used.

  • FreeType: This isn't actually used by Pidgin directly, but some plugins use it (guifications for one). Requires problematic font to be installed to be problematic.
  • Expat: This isn't used to parse xml by pidgin itself (we use libxml2 for that) and consequently doesn't parse any remote data. It's used by the GTK+ stack internally, IIRC only for fontconfig/freetype.
  • Zlib: We're using zlib 1.2.3, not 1.2.2.
  • libpng: Some of these are probably potential problems.

comment:12 Changed 4 years ago by ioerror

I didn't close my original bug as a dupe, so perhaps we should move some of this back to the original bug?

comment:13 follow-up: Changed 4 years ago by ioerror

I have two Pidgin clients running, one on a stable Ubuntu and one on a stable Windows release using the GTK libraries from the installer. I have created a few different malformed pngs for testing both local and remote code paths.

Using AIM, I send am image from the Ubuntu client to the Windows client containing one image, png-1-width-519-height-2.png and when it arrives on the remote site, the Windows client has this in the debug log:

(17:16:10) oscar: Parsing IM, charset=0x0000, datalen=376, choice1=ASCII, choice2=CP1252, choice3=
(17:16:10) oscar: Received IM from xxx
(17:16:10) sound: Playing C:\Program Files\Pidgin\sounds\purple\receive.wav
(17:16:10) GdkPixbuf: gdk_pixbuf_new: assertion `height > 0' failed
(17:16:10) GdkPixbuf: gdk_pixbuf_fill: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:16:10) GdkPixbuf: gdk_pixbuf_scale: assertion `GDK_IS_PIXBUF (dest)' failed
(17:16:10) GdkPixbuf: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:16:10) GdkPixbuf: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:16:10) GdkPixbuf: gdk_pixbuf_copy_area: assertion `src_pixbuf != NULL' failed
(17:16:10) GLib-GObject: g_object_unref: assertion `G_IS_OBJECT (object)' failed
(17:16:10) GdkPixbuf: gdk_pixbuf_new: assertion `height > 0' failed
(17:16:10) GdkPixbuf: gdk_pixbuf_fill: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:16:10) GdkPixbuf: gdk_pixbuf_scale: assertion `GDK_IS_PIXBUF (dest)' failed
(17:16:10) GdkPixbuf: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:16:10) GdkPixbuf: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:16:10) GdkPixbuf: gdk_pixbuf_copy_area: assertion `src_pixbuf != NULL' failed
(17:16:10) GLib-GObject: g_object_unref: assertion `G_IS_OBJECT (object)' failed

When png-1-width-519-height-2.png is set as my Ubuntu buddy icon, I am able to send that icon to the remote Windows pidgin. The receiving Pidgin parses the image and the following messages are emitted in the debug log:

(17:22:36) Gdk: gdkgeometry-win32.c:141: ScrollWindowEx failed: Success
(17:22:39) oscar: Incoming rendezvous message of type 1, user xxx, status 0
(17:22:39) util: Writing file C:\users\xxx\Application Data\.purple\icons\a1b087c4cf17061520d9341083190ca680ec21a1.jpg
(17:22:39) GdkPixbuf: gdk_pixbuf_new: assertion `height > 0' failed
(17:22:39) GdkPixbuf: gdk_pixbuf_fill: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:22:39) GdkPixbuf: gdk_pixbuf_scale: assertion `GDK_IS_PIXBUF (dest)' failed
(17:22:39) GdkPixbuf: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:22:39) GdkPixbuf: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:22:39) GdkPixbuf: gdk_pixbuf_copy_area: assertion `src_pixbuf != NULL' failed
(17:22:39) GLib-GObject: g_object_unref: assertion `G_IS_OBJECT (object)' failed
(17:22:39) GdkPixbuf: gdk_pixbuf_scale_simple: assertion `dest_height > 0' failed
(17:22:39) GdkPixbuf: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:22:39) GdkPixbuf: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:22:39) GLib-GObject: g_object_unref: assertion `G_IS_OBJECT (object)' failed

After that error, we have a file on disk that is 800 bytes in size and not the png icon my Ubuntu client sent:

% file a1b087c4cf17061520d9341083190ca680ec21a1.jpg 
a1b087c4cf17061520d9341083190ca680ec21a1.jpg: JPEG image data, JFIF standard 1.01

Over time we see the same error without updating the icon on the Ubuntu side. The Windows side continues to attempt to parse the image:

(17:22:41) imgstore: retrieved image id 2
(17:22:41) imgstore: retrieved image id 2
(17:22:41) GdkPixbuf: gdk_pixbuf_new: assertion `height > 0' failed
(17:22:41) GdkPixbuf: gdk_pixbuf_fill: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:22:41) GdkPixbuf: gdk_pixbuf_scale: assertion `GDK_IS_PIXBUF (dest)' failed
(17:22:41) GdkPixbuf: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:22:41) GdkPixbuf: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:22:41) GdkPixbuf: gdk_pixbuf_copy_area: assertion `src_pixbuf != NULL' failed
(17:22:41) GLib-GObject: g_object_unref: assertion `G_IS_OBJECT (object)' failed
(17:22:44) util: Writing file blist.xml to directory C:\users\xxx\Application Data\.purple
(17:22:44) util: Writing file C:\users\xxx\Application Data\.purple\blist.xml
(17:24:08) GdkPixbuf: gdk_pixbuf_new: assertion `height > 0' failed
(17:24:08) GdkPixbuf: gdk_pixbuf_fill: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:24:08) GdkPixbuf: gdk_pixbuf_scale: assertion `GDK_IS_PIXBUF (dest)' failed
(17:24:08) GdkPixbuf: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:24:08) GdkPixbuf: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:24:08) GdkPixbuf: gdk_pixbuf_copy_area: assertion `src_pixbuf != NULL' failed
(17:24:08) GLib-GObject: g_object_unref: assertion `G_IS_OBJECT (object)' failed
(17:24:15) GdkPixbuf: gdk_pixbuf_new: assertion `height > 0' failed
(17:24:15) GdkPixbuf: gdk_pixbuf_fill: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:24:15) GdkPixbuf: gdk_pixbuf_scale: assertion `GDK_IS_PIXBUF (dest)' failed
(17:24:15) GdkPixbuf: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:24:15) GdkPixbuf: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:24:15) GdkPixbuf: gdk_pixbuf_copy_area: assertion `src_pixbuf != NULL' failed
(17:24:15) GLib-GObject: g_object_unref: assertion `G_IS_OBJECT (object)' failed

Later, if in the Windows Pidgin, I click on the IM window of the buddy that has the malformed icon - I trigger this in the Windows debug log:

(17:29:04) GdkPixbuf: gdk_pixbuf_new: assertion `height > 0' failed
(17:29:04) GdkPixbuf: gdk_pixbuf_fill: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:29:04) GdkPixbuf: gdk_pixbuf_scale: assertion `GDK_IS_PIXBUF (dest)' failed
(17:29:04) GdkPixbuf: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:29:04) GdkPixbuf: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:29:04) GdkPixbuf: gdk_pixbuf_copy_area: assertion `src_pixbuf != NULL' failed
(17:29:04) GLib-GObject: g_object_unref: assertion `G_IS_OBJECT (object)' failed

If I try to set the malformed image (local-buddy-icon.png) on the WIndows client as my buddy icon, I have the following errors in my debug log:

(17:35:44) win32placement: Window RECT: L:988 R:1608 T:161 B:638
(17:35:44) win32placement: Working Area RECT: L:0 R:1600 T:24 B:876
(17:35:44) win32placement: conversation window out of working area, relocating
(17:35:44) win32placement: Relocation RECT: L:980 R:1600 T:161 B:638
(17:35:44) gtkutils: gdk_pixbuf_new_from_file() returned nothing for file C:\Program Files\Pidgin\pixmaps\pidgin: Failed to open file 'C:\Program Files\Pidgin\pixmaps\pidgin': Permission denied
(17:35:54) GdkPixbuf: gdk_pixbuf_scale_simple: assertion `dest_height > 0' failed
(17:35:54) buddyicon: Converting buddy icon to png
(17:35:54) GdkPixbuf: gdk_pixbuf_get_bits_per_sample: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:35:54) GdkPixbuf: gdk_pixbuf_get_width: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:35:54) GdkPixbuf: gdk_pixbuf_get_height: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:35:54) GdkPixbuf: gdk_pixbuf_get_rowstride: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:35:54) GdkPixbuf: gdk_pixbuf_get_has_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:35:54) GdkPixbuf: gdk_pixbuf_get_pixels: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:35:54) buddyicon: Could not convert to png: Fatal error in PNG image file: Invalid IHDR data
(17:35:54) GLib-GObject: g_object_unref: assertion `G_IS_OBJECT (object)' failed
(17:35:54) GdkPixbuf: gdk_pixbuf_scale_simple: assertion `dest_height > 0' failed
(17:35:54) GLib-GObject: g_object_unref: assertion `G_IS_OBJECT (object)' failed
(17:35:54) GdkPixbuf: gdk_pixbuf_scale_simple: assertion `dest_height > 0' failed
(17:35:54) buddyicon: Converting buddy icon to gif
(17:35:54) buddyicon: Could not convert to gif: Unsupported image format for GDI+
(17:35:54) buddyicon: Converting buddy icon to jpeg
(17:35:54) buddyicon: Could not convert to jpeg: Unsupported image format for GDI+
(17:35:54) buddyicon: Converting buddy icon to bmp
(17:35:54) GdkPixbuf: gdk_pixbuf_get_width: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:35:54) GdkPixbuf: gdk_pixbuf_get_height: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:35:54) GdkPixbuf: gdk_pixbuf_get_rowstride: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:35:54) GdkPixbuf: gdk_pixbuf_get_n_channels: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:35:54) GdkPixbuf: gdk_pixbuf_get_pixels: assertion `GDK_IS_PIXBUF (pixbuf)' failed
(17:35:54) GdkPixbuf: Unsupported number of channels: -1
(17:35:54) buddyicon: Could not convert to bmp: Couldn't save
(17:35:54) buddyicon: Converting buddy icon to ico
(17:35:54) buddyicon: Could not convert to ico: This build of gdk-pixbuf does not support saving the image format: ico
(17:35:54) GLib-GObject: g_object_unref: assertion `G_IS_OBJECT (object)' failed
(17:35:54) GdkPixbuf: gdk_pixbuf_scale_simple: assertion `dest_height > 0' failed
(17:35:54) GLib-GObject: g_object_unref: assertion `G_IS_OBJECT (object)' failed
(17:35:54) gtkstatusbox: gdk_pixbuf_loader_write() failed with size=5723: Transformed PNG has zero width or height.

Finally, if I try to set my local windows buddy icon to png-1-width-800-height-2.png - pidgin instantly dies. I ran it in Wine with "relay" level debugging and found this error among others after Pidgin (in Wine) vanished:

X Error of failed request:  BadAlloc (insufficient resources for operation)
  Major opcode of failed request:  53 (X_CreatePixmap)
  Serial number of failed request:  20241
  Current serial number in output stream:  21038

It looks like the above is caused by gdk_pixbuf_new_from_file() is called whenever i select any file, even before I confirm it is the file I want to actually load. If I select png-1-width-800-height-2.png, I have the same issue and pidgin entirely crashes:

X Error of failed request:  BadAlloc (insufficient resources for operation)
  Major opcode of failed request:  53 (X_CreatePixmap)
  Serial number of failed request:  91458
  Current serial number in output stream:  91459

Changed 4 years ago by ioerror

Changed 4 years ago by ioerror

Changed 4 years ago by ioerror

comment:14 Changed 4 years ago by ioerror

I've opened a ticket (#15282) for a similar reliable crash in Ubuntu's Natty release of pidgin which is currently 2.7.11.

comment:15 follow-up: Changed 4 years ago by ioerror

Ok, so, I hacked up a simple way to get the Ubuntu pidgin to send a malformed png to the Windows pidgin:

On my Ubuntu pidgin, I send this message with the raw xmpp console:

<iq from='xxx@jabber.ccc.de' 
    type='set'
    id='vc1'>
  <vCard xmlns='vcard-temp'>
    <BDAY>1476-06-09</BDAY>
    <ADR>
      <CTRY>Italy</CTRY>
      <LOCALITY>Verona</LOCALITY>
      <HOME/>
    </ADR>
    <NICKNAME/>
    <N><GIVEN>Juliet</GIVEN><FAMILY>Capulet</FAMILY></N>
    <EMAIL>jcapulet@shakespeare.lit</EMAIL>
    <PHOTO>
      <TYPE>image/png</TYPE>
      <BINVAL>
iVBORw0KGgoAAAANSUhEUgAAAyAAAAABCAYAAAAmaMpmAAAAAXNSR0IArs4c6QAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9oHDBQcOFLdGC4AABkNSURBVAgdAQIZeZBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFFQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUEfqFndXmwiZQAAAABJRU5ErkJggg==
      </BINVAL>
    </PHOTO>
  </vCard>
</iq>

The server acknowledges it as expected:

<iq from='xxx@jabber.ccc.de' to='xxx@jabber.ccc.de/ccc' id='vc1' type='result'/>

Now over on the Windows pidgin side, I decided to speed the process up and I just requested buddy information on my Ubuntu pidgin user:

(02:45:36) jabber: Sending (ssl) (yyy@jabber.ccc.de): <iq type='get' id='purplec1ab1726' to='xxx@jabber.ccc.de'><vCard xmlns='vcard-temp'/></iq>
(02:45:36) jabber: Sending (ssl) (yyy@jabber.ccc.de): <iq type='get' id='purplec1ab1727' to='xxx@jabber.ccc.de/ccc'><query xmlns='jabber:iq:last'/></iq>

Now the server hasn't parsed the images and so it has no idea that I've loaded a malformed image into my icon. It returns it to the requesting user as expected:

(02:45:38) jabber: Recv (ssl)(4095): <iq from='xxx@jabber.ccc.de' to='yyy@jabber.ccc.de/pidgin-wine-otr' id='purplec1ab1726' type='result'><vCard xmlns='vcard-temp'>
    <BDAY>1476-06-09</BDAY>
    <ADR>
      <CTRY>Italy</CTRY>
      <LOCALITY>Verona</LOCALITY>
      <HOME/>
    </ADR>
    <NICKNAME/>
    <N><GIVEN>Juliet</GIVEN><FAMILY>Capulet</FAMILY></N>
    <EMAIL>jcapulet@shakespeare.lit</EMAIL>
    <PHOTO>
      <TYPE>image/png</TYPE>
      <BINVAL>
iVBORw0KGgoAAAANSUhEUgAAAyAAAAABCAYAAAAmaMpmAAAAAXNSR0IArs4c6QAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9oHDBQcOFLdGC4AABkNSURBVAgdAQIZeZBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
(02:45:38) jabber: Recv (ssl)(4095): QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUF
(02:45:38) jabber: Recv (ssl)(1530): BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFFQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUEfqFndXmwiZQAAAABJRU5ErkJggg==
      </BINVAL>
    </PHOTO>
  </vCard></iq>
(02:45:38) util: Writing file C:\users\xxx\Application Data\.purple\icons\190831cd1b33ca2b5906e3f7e2701df96f4271a1.png
(02:45:38) gtkutils: gdk_pixbuf_loader_write() failed with size=6921: Fatal error reading PNG image file: Decompression Error
(02:45:38) gtkblist: Couldn't load buddy icon on account yyy@jabber.ccc.de (prpl-jabber)  buddyname=xxx@jabber.ccc.de  custom_img_data=00000000
(02:45:38) gtkutils: gdk_pixbuf_loader_write() failed with size=6921: Fatal error reading PNG image file: Decompression Error
(02:45:38) gtkblist: Couldn't load buddy icon on account yyy@jabber.ccc.de (prpl-jabber)  buddyname=xxx@jabber.ccc.de  custom_img_data=00000000
(02:45:38) buddyicon: Deleted cache file: C:\users\xxx\Application Data\.purple\icons\c3399a8e9f4fbf8c151d3e0f32024ca40074c9cc.png
(02:45:38) jabber: Recv (ssl)(174): <iq from='xxx@jabber.ccc.de/ccc' to='yyy@jabber.ccc.de' type='result' id='purplec1ab1727'><query xmlns='jabber:iq:last' seconds='0'/></iq>
(02:45:38) imgstore: retrieved image id 4
(02:45:38) gtkutils: gdk_pixbuf_loader_write() failed with size=6921: Fatal error reading PNG image file: Decompression Error
(02:45:38) imgstore: retrieved image id 4

Now when I click on the name of the user with the malformed icon, I see this:

(02:56:15) gtkutils: gdk_pixbuf_loader_write() failed with size=6921: Fatal error reading PNG image file: Decompression Error
(02:56:15) gtkblist: Couldn't load buddy icon on account yyy@jabber.ccc.de (prpl-jabber)  buddyname=xxx@jabber.ccc.de  custom_img_data=00000000
(02:56:15) gtkutils: gdk_pixbuf_loader_write() failed with size=6921: Fatal error reading PNG image file: Decompression Error
(02:56:15) gtkblist: Couldn't load buddy icon on account yyy@jabber.ccc.de(prpl-jabber)  buddyname=xxx@jabber.ccc.de  custom_img_data=00000000

When I start a chat properly from the Windows pidgin to the Ubuntu Pidgin, I see the following in the Windows debug log, it is repeated over and over:

(02:59:46) gtkconv: Couldn't load icon for conv xxx@jabber.ccc.de 
(02:59:46) gtkconv: setting active conversation on toolbar 02631120
(02:59:46) prefs: /pidgin/conversations/toolbar/wide changed, scheduling save.
(02:59:46) gtkutils: gdk_pixbuf_loader_write() failed with size=6921: Fatal error reading PNG image file: Decompression Error
(02:59:46) gtkblist: Couldn't load buddy icon on account yyy@jabber.ccc.de (prpl-jabber)  buddyname=xxx@jabber.ccc.de  custom_img_data=00000000
(02:59:46) gtkconv: setting active conversation on toolbar 02631120
(02:59:46) gtkutils: gdk_pixbuf_loader_write() failed with size=6921: Fatal error reading PNG image file: Decompression Error
(02:59:46) gtkconv: Couldn't load icon for conv xxx@jabber.ccc.de
(02:59:46) gtkutils: gdk_pixbuf_loader_write() failed with size=6921: Fatal error reading PNG image file: Decompression Error
(02:59:46) gtkblist: Couldn't load buddy icon on account yyy@jabber.ccc.de (prpl-jabber)  buddyname=xxx@jabber.ccc.de  custom_img_data=00000000
(02:59:46) gtkutils: gdk_pixbuf_loader_write() failed with size=6921: Fatal error reading PNG image file: Decompression Error
(02:59:46) gtkblist: Couldn't load buddy icon on account yyy@jabber.ccc.de (prpl-jabber)  buddyname=xxx@jabber.ccc.de  custom_img_data=00000000

It seems that I can indeed reach the remote png parser as expected. Isn't that the libpng png parser?

comment:16 follow-up: Changed 4 years ago by ioerror

I changed the malformed png a bit:

<iq from='xxx@jabber.ccc.de' 
    type='set'
    id='vc1'>
  <vCard xmlns='vcard-temp'>
    <BDAY>1476-06-09</BDAY>
    <ADR>
      <CTRY>Italy</CTRY>
      <LOCALITY>Verona</LOCALITY>
      <HOME/>
    </ADR>
    <NICKNAME/>
    <N><GIVEN>Juliet</GIVEN><FAMILY>Capulet</FAMILY></N>
    <EMAIL>jcapulet@shakespeare.lit</EMAIL>
    <PHOTO>
      <TYPE>image/png</TYPE>
      <BINVAL>
iVBORw0KGgoAAAANSUhEUgAAArwAAAABCAYAAAA8cX3BAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAEwAACxMBAJqcGAAAAAd0SU1FB9oHDBQcOFLdGC4AABXtSURBVAgdAeIVHepBQUFBQUFBQUFBQUFQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBS5SOruRynOEAAAAASUVORK5CYII=
      </BINVAL>
    </PHOTO>
  </vCard>
</iq>

Now I tweak a different error out of the png parser on the Windows pidgin client:

(03:20:04) gtkconv: Couldn't load icon for conv xxx@jabber.ccc.de
(03:20:08) jabber: Recv (ssl)(235): <iq from='xxx@jabber.ccc.de' to='yyy@jabber.ccc.de' type='result' id='purplec08e7da3'><query xmlns='jabber:iq:version'><name>Pidgin</name><version>2.7.11 (libpurple 2.7.11)</version></query></iq>
(03:20:09) util: Writing file blist.xml to directory C:\users\xxx\Application Data\.purple
(03:20:09) util: Writing file C:\users\xxx\Application Data\.purple\blist.xml
(03:20:09) jabber: Recv (ssl)(174): <iq from='xxx@jabber.ccc.de' to='yyy@jabber.ccc.de' type='result' id='purplec08e7da4'><query xmlns='jabber:iq:last' seconds='0'/></iq>
(03:20:09) jabber: Recv (ssl)(214): <iq from='xxx@jabber.ccc.de' to='yyy@jabber.ccc.de' type='result' id='purplec08e7da5'><time xmlns='urn:xmpp:time'><tzo>-07:00</tzo><utc>2012-08-24T10:20:07Z</utc></time></iq>
(03:20:09) imgstore: retrieved image id 1
(03:20:09) gtkutils: gdk_pixbuf_loader_write() failed with size=6933: Fatal error reading PNG image file: [12]SQA: invalid chunk type
(03:20:09) imgstore: retrieved image id 1
(03:20:34) gtkutils: gdk_pixbuf_loader_write() failed with size=6933: Fatal error reading PNG image file: [12]SQA: invalid chunk type
(03:20:34) gtkblist: Couldn't load buddy icon on account yyy@jabber.ccc.de/pidgin-wine-otr (prpl-jabber)  buddyname=xxx@jabber.ccc.de  custom_img_data=00000000

Later, any time I touch that tab or window to IM xxx my debug log shows:

(03:24:33) gtkutils: gdk_pixbuf_loader_write() failed with size=6933: Fatal error reading PNG image file: [12]SQA: invalid chunk type
(03:24:33) gtkblist: Couldn't load buddy icon on account yyy@jabber.ccc.de (prpl-jabber)  buddyname=xxx@jabber.ccc.de  custom_img_data=00000000

It appears that this png doesn't get wiped from disk even though it is clearly malformed. Additionally, I only see those decode errors on the Windows Pidgin, I do not see them on the Ubuntu Pidgin. I think that means that I am hitting the GTK libs that are vulnerable, perhaps?

comment:17 in reply to: ↑ 13 ; follow-up: Changed 4 years ago by datallah

Replying to ioerror:

<SNIP>

If I try to set the malformed image (local-buddy-icon.png) on the WIndows client as my buddy icon, I have the following errors in my debug log:

<SNIP>
> (17:35:54) buddyicon: Could not convert to png: Fatal error in PNG image file: Invalid IHDR data
<SNIP>
> (17:35:54) gtkstatusbox: gdk_pixbuf_loader_write() failed with size=5723: Transformed PNG has zero width or height.

This is an indication that the gdk-pixbuf implementation (which for PNG is libpng) can't can't handle the image. This isn't unexpected, it's an invalid image, so this isn't really a problem.

Finally, if I try to set my local windows buddy icon to png-1-width-800-height-2.png - pidgin instantly dies. I ran it in Wine with "relay" level debugging and found this error among others after Pidgin (in Wine) vanished:

> X Error of failed request:  BadAlloc (insufficient resources for operation)
>   Major opcode of failed request:  53 (X_CreatePixmap)
>   Serial number of failed request:  20241
>   Current serial number in output stream:  21038

This is probably caused by one of the libpng bugs.

It looks like the above is caused by gdk_pixbuf_new_from_file() is called whenever i select any file, even before I confirm it is the file I want to actually load. If I select png-1-width-800-height-2.png, I have the same issue and pidgin entirely crashes:

> X Error of failed request:  BadAlloc (insufficient resources for operation)
>   Major opcode of failed request:  53 (X_CreatePixmap)
>   Serial number of failed request:  91458
>   Current serial number in output stream:  91459

This is the same as the above - the GTK+ file chooser is processing the image to generate a thumbnail when you select the file.

comment:18 in reply to: ↑ 15 ; follow-up: Changed 4 years ago by datallah

Replying to ioerror:

Ok, so, I hacked up a simple way to get the Ubuntu pidgin to send a malformed png to the Windows pidgin:

<SNIP>

Now the server hasn't parsed the images and so it has no idea that I've loaded a malformed image into my icon. It returns it to the requesting user as expected:

> (02:45:38) jabber: Recv (ssl)(4095): <iq from='xxx@jabber.ccc.de' to='yyy@jabber.ccc.de/pidgin-wine-otr' id='purplec1ab1726' type='result'><vCard xmlns='vcard-temp'>
<SNIP>
> (02:45:38) util: Writing file C:\users\xxx\Application Data\.purple\icons\190831cd1b33ca2b5906e3f7e2701df96f4271a1.png
> (02:45:38) gtkutils: gdk_pixbuf_loader_write() failed with size=6921: Fatal error reading PNG image file: Decompression Error
> (02:45:38) gtkblist: Couldn't load buddy icon on account yyy@jabber.ccc.de (prpl-jabber)  buddyname=xxx@jabber.ccc.de  custom_img_data=00000000
> (02:45:38) gtkutils: gdk_pixbuf_loader_write() failed with size=6921: Fatal error reading PNG image file: Decompression Error
> (02:45:38) gtkblist: Couldn't load buddy icon on account yyy@jabber.ccc.de (prpl-jabber)  buddyname=xxx@jabber.ccc.de  custom_img_data=00000000
> (02:45:38) buddyicon: Deleted cache file: C:\users\xxx\Application Data\.purple\icons\c3399a8e9f4fbf8c151d3e0f32024ca40074c9cc.png
> (02:45:38) jabber: Recv (ssl)(174): <iq from='xxx@jabber.ccc.de/ccc' to='yyy@jabber.ccc.de' type='result' id='purplec1ab1727'><query xmlns='jabber:iq:last' seconds='0'/></iq>
> (02:45:38) imgstore: retrieved image id 4
> (02:45:38) gtkutils: gdk_pixbuf_loader_write() failed with size=6921: Fatal error reading PNG image file: Decompression Error
> (02:45:38) imgstore: retrieved image id 4

This is similar to above; the gdk-pixbuf writer can't handle the malformed image, but it isn't really a problem, it's just telling you that it can't handle it.

<SNIP>

When I start a chat properly from the Windows pidgin to the Ubuntu Pidgin, I see the following in the Windows debug log, it is repeated over and over:

<SNIP>

Again, not really a problem.

It seems that I can indeed reach the remote png parser as expected. Isn't that the libpng png parser?

Yes, it is reaching gdk-pixbuf and libpng; this wasn't really ever in doubt.

Like I said, it is likely that the libpng issues are a potential problem, there isn't really any need to do further investigation.

comment:19 in reply to: ↑ 16 ; follow-up: Changed 4 years ago by datallah

Replying to ioerror:

I changed the malformed png a bit:

<SNIP>

It appears that this png doesn't get wiped from disk even though it is clearly malformed. Additionally, I only see those decode errors on the Windows Pidgin, I do not see them on the Ubuntu Pidgin. I think that means that I am hitting the GTK libs that are vulnerable, perhaps?

The fact that the file is still there there isn't a problem; it's just a cached value of what the server sent; we wouldn't want to re-download the same data.

comment:20 in reply to: ↑ 17 ; follow-up: Changed 4 years ago by ioerror

Replying to datallah:

Replying to ioerror:

<SNIP>

If I try to set the malformed image (local-buddy-icon.png) on the WIndows client as my buddy icon, I have the following errors in my debug log:

<SNIP>
> (17:35:54) buddyicon: Could not convert to png: Fatal error in PNG image file: Invalid IHDR data
<SNIP>
> (17:35:54) gtkstatusbox: gdk_pixbuf_loader_write() failed with size=5723: Transformed PNG has zero width or height.

This is an indication that the gdk-pixbuf implementation (which for PNG is libpng) can't can't handle the image. This isn't unexpected, it's an invalid image, so this isn't really a problem.

Right - I wanted to confirm that I could reach the libpng code over the wire, now I think we agree that it can be done.

Finally, if I try to set my local windows buddy icon to png-1-width-800-height-2.png - pidgin instantly dies. I ran it in Wine with "relay" level debugging and found this error among others after Pidgin (in Wine) vanished:

> X Error of failed request:  BadAlloc (insufficient resources for operation)
>   Major opcode of failed request:  53 (X_CreatePixmap)
>   Serial number of failed request:  20241
>   Current serial number in output stream:  21038

This is probably caused by one of the libpng bugs.

Agreed.

It looks like the above is caused by gdk_pixbuf_new_from_file() is called whenever i select any file, even before I confirm it is the file I want to actually load. If I select png-1-width-800-height-2.png, I have the same issue and pidgin entirely crashes:

> X Error of failed request:  BadAlloc (insufficient resources for operation)
>   Major opcode of failed request:  53 (X_CreatePixmap)
>   Serial number of failed request:  91458
>   Current serial number in output stream:  91459

This is the same as the above - the GTK+ file chooser is processing the image to generate a thumbnail when you select the file.

Yes, though I think it might be a different bug in GTK and one that is outstanding, as seems to be the evidence in bug #1452.

comment:21 in reply to: ↑ 20 Changed 4 years ago by ioerror

Replying to ioerror:

Replying to datallah:

Replying to ioerror:

<SNIP>

If I try to set the malformed image (local-buddy-icon.png) on the WIndows client as my buddy icon, I have the following errors in my debug log:

<SNIP>
> (17:35:54) buddyicon: Could not convert to png: Fatal error in PNG image file: Invalid IHDR data
<SNIP>
> (17:35:54) gtkstatusbox: gdk_pixbuf_loader_write() failed with size=5723: Transformed PNG has zero width or height.

This is an indication that the gdk-pixbuf implementation (which for PNG is libpng) can't can't handle the image. This isn't unexpected, it's an invalid image, so this isn't really a problem.

Right - I wanted to confirm that I could reach the libpng code over the wire, now I think we agree that it can be done.

Finally, if I try to set my local windows buddy icon to png-1-width-800-height-2.png - pidgin instantly dies. I ran it in Wine with "relay" level debugging and found this error among others after Pidgin (in Wine) vanished:

> X Error of failed request:  BadAlloc (insufficient resources for operation)
>   Major opcode of failed request:  53 (X_CreatePixmap)
>   Serial number of failed request:  20241
>   Current serial number in output stream:  21038

This is probably caused by one of the libpng bugs.

Agreed.

It looks like the above is caused by gdk_pixbuf_new_from_file() is called whenever i select any file, even before I confirm it is the file I want to actually load. If I select png-1-width-800-height-2.png, I have the same issue and pidgin entirely crashes:

> X Error of failed request:  BadAlloc (insufficient resources for operation)
>   Major opcode of failed request:  53 (X_CreatePixmap)
>   Serial number of failed request:  91458
>   Current serial number in output stream:  91459

This is the same as the above - the GTK+ file chooser is processing the image to generate a thumbnail when you select the file.

Yes, though I think it might be a different bug in GTK and one that is outstanding, as seems to be the evidence in bug #1452.

Ahem, I meant bug #15282

comment:22 in reply to: ↑ 18 ; follow-up: Changed 4 years ago by ioerror

Replying to datallah:

Replying to ioerror:

Ok, so, I hacked up a simple way to get the Ubuntu pidgin to send a malformed png to the Windows pidgin:

<SNIP>

Now the server hasn't parsed the images and so it has no idea that I've loaded a malformed image into my icon. It returns it to the requesting user as expected:

> (02:45:38) jabber: Recv (ssl)(4095): <iq from='xxx@jabber.ccc.de' to='yyy@jabber.ccc.de/pidgin-wine-otr' id='purplec1ab1726' type='result'><vCard xmlns='vcard-temp'>
<SNIP>
> (02:45:38) util: Writing file C:\users\xxx\Application Data\.purple\icons\190831cd1b33ca2b5906e3f7e2701df96f4271a1.png
> (02:45:38) gtkutils: gdk_pixbuf_loader_write() failed with size=6921: Fatal error reading PNG image file: Decompression Error
> (02:45:38) gtkblist: Couldn't load buddy icon on account yyy@jabber.ccc.de (prpl-jabber)  buddyname=xxx@jabber.ccc.de  custom_img_data=00000000
> (02:45:38) gtkutils: gdk_pixbuf_loader_write() failed with size=6921: Fatal error reading PNG image file: Decompression Error
> (02:45:38) gtkblist: Couldn't load buddy icon on account yyy@jabber.ccc.de (prpl-jabber)  buddyname=xxx@jabber.ccc.de  custom_img_data=00000000
> (02:45:38) buddyicon: Deleted cache file: C:\users\xxx\Application Data\.purple\icons\c3399a8e9f4fbf8c151d3e0f32024ca40074c9cc.png
> (02:45:38) jabber: Recv (ssl)(174): <iq from='xxx@jabber.ccc.de/ccc' to='yyy@jabber.ccc.de' type='result' id='purplec1ab1727'><query xmlns='jabber:iq:last' seconds='0'/></iq>
> (02:45:38) imgstore: retrieved image id 4
> (02:45:38) gtkutils: gdk_pixbuf_loader_write() failed with size=6921: Fatal error reading PNG image file: Decompression Error
> (02:45:38) imgstore: retrieved image id 4

This is similar to above; the gdk-pixbuf writer can't handle the malformed image, but it isn't really a problem, it's just telling you that it can't handle it.

Well, I'm not sure it's not a problem, I found this published in 2010(!) and it generates the malformed PNGs in question: http://www.exploit-db.com/exploits/14422

The fact that I can totally take pidgin down with those png files leads me to believe that it is just a matter of working at it, as opposed to it not being used at all or that it "might" be a problem.

<SNIP>

When I start a chat properly from the Windows pidgin to the Ubuntu Pidgin, I see the following in the Windows debug log, it is repeated over and over:

<SNIP>

Again, not really a problem.

If the image has already caused an error, I guess it shouldn't be re-parsed over and over again, especially if it caused some heap or stack corruption each time.

It seems that I can indeed reach the remote png parser as expected. Isn't that the libpng png parser?

Yes, it is reaching gdk-pixbuf and libpng; this wasn't really ever in doubt.

You originally wrote this and it is why I was erasing any doubt: "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."

OK, well, I think we now both agree that it is possible; I'd like to suggest that it is critical to update GTK.

Like I said, it is likely that the libpng issues are a potential problem, there isn't really any need to do further investigation.

It's clearly a problem. I realize it's a pain to update GTK but I think all of the Windows users are seriously vulnerable and have been for a ridiculous amount of time.

comment:23 in reply to: ↑ 19 Changed 4 years ago by ioerror

Replying to datallah:

Replying to ioerror:

I changed the malformed png a bit:

<SNIP>

It appears that this png doesn't get wiped from disk even though it is clearly malformed. Additionally, I only see those decode errors on the Windows Pidgin, I do not see them on the Ubuntu Pidgin. I think that means that I am hitting the GTK libs that are vulnerable, perhaps?

The fact that the file is still there there isn't a problem; it's just a cached value of what the server sent; we wouldn't want to re-download the same data.

Well, pidgin gets rid of it in one case but not in another. Why the difference? It seems like in one case, pidgin removes the image because it is bad; the other case pidgin also has errors but keeps it around. Keeping it on disk may make attacking the image library even easier.

comment:24 follow-up: Changed 4 years ago by 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. :(

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.

comment:25 in reply to: ↑ 22 ; follow-up: Changed 4 years ago by datallah

Replying to ioerror:

Replying to datallah:

Replying to ioerror:

<SNIP>

It seems that I can indeed reach the remote png parser as expected. Isn't that the libpng png parser?

Yes, it is reaching gdk-pixbuf and libpng; this wasn't really ever in doubt.

You originally wrote this and it is why I was erasing any doubt: "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."

This was referring to CVE-2010-4831.

OK, well, I think we now both agree that it is possible; I'd like to suggest that it is critical to update GTK.

It would be good to get libpng upgraded, however it's non-trivial. We avoid building our own dependencies (in the past this has been more problematic and difficult to support than using pre-build "official" binaries); the GTK+ download site doesn't have a new enough version of libpng, so we'd need to get them to supply an updated binary.

comment:26 in reply to: ↑ 24 ; follow-up: Changed 4 years ago by datallah

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

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

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

comment:27 in reply to: ↑ 25 Changed 4 years ago by ioerror

Replying to datallah:

Replying to ioerror:

Replying to datallah:

Replying to ioerror:

<SNIP>

It seems that I can indeed reach the remote png parser as expected. Isn't that the libpng png parser?

Yes, it is reaching gdk-pixbuf and libpng; this wasn't really ever in doubt.

You originally wrote this and it is why I was erasing any doubt: "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."

This was referring to CVE-2010-4831.

Ah, well, I guess we could a new CVE to reference pidgin shipping the old GTK libs and that would clear it up. Shall I request one for this?

OK, well, I think we now both agree that it is possible; I'd like to suggest that it is critical to update GTK.

It would be good to get libpng upgraded, however it's non-trivial.

Well unless I'm mistaken, which I admit is more than likely, I think that a lot more than libpng needs to be upgraded. libpng seems the most easy and relevant thing to upgrade. Why not rebuild it and replace it in the .zip file that pidgin hosts? That seems like the most simple thing unless libpng actually changed in serious ways.

We avoid building our own dependencies (in the past this has been more problematic and difficult to support than using pre-build "official" binaries); the GTK+ download site doesn't have a new enough version of libpng, so we'd need to get them to supply an updated binary.

Sure, this is yet another way forward. It seems like it won't go very quickly. Is there a security contact at the gtk project that will help us?

Alternatively, I think pidgin could build and ship the required GTK libraries. Is the full build process for the required libraries documented somewhere?

comment:28 in reply to: ↑ 26 Changed 4 years ago by ioerror

Replying to datallah:

Replying to 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?

comment:29 follow-up: Changed 4 years ago by datallah

Replying to ioerror:

Ah, well, I guess we could a new CVE to reference pidgin shipping the old GTK libs and that would clear it up. Shall I request one for this?

I don't see why we need a CVE for this; we haven't done that for this type of thing in the past. There's a CVE for each of the issues in libpng already. There's no need to coordinate anything with any downstream distributions or supply a patch.

It would be good to get libpng upgraded, however it's non-trivial.

Well unless I'm mistaken, which I admit is more than likely, I think that a lot more than libpng needs to be upgraded.

If there are other things, we may be able to update them too - I didn't see anything in the list that I thought was necessary in the list you posted.

libpng seems the most easy and relevant thing to upgrade. Why not rebuild it and replace it in the .zip file that pidgin hosts? That seems like the most simple thing unless libpng actually changed in serious ways.

Like I said, I would like to avoid building dependencies.

Sure, this is yet another way forward. It seems like it won't go very quickly. Is there a security contact at the gtk project that will help us?

The win32 side of the GTK+ project is understaffed; the long time win32 maintainer retired from the project a couple years ago and I don't know if someone else has really taken over.

I would file a ticket in bugzilla requesting that a newer libpng binary be distributed.

I guess I'm not worried if this takes a little while; this isn't a new issue and the world will not end if it isn't resolved immediately.

Alternatively, I think pidgin could build and ship the required GTK libraries. Is the full build process for the required libraries documented somewhere?

That's a question for the GTK+ folks, but as I said, I'd rather not go down this path.

comment:30 in reply to: ↑ 29 Changed 4 years ago by ioerror

Replying to datallah:

Replying to ioerror:

Ah, well, I guess we could a new CVE to reference pidgin shipping the old GTK libs and that would clear it up. Shall I request one for this?

I don't see why we need a CVE for this; we haven't done that for this type of thing in the past. There's a CVE for each of the issues in libpng already. There's no need to coordinate anything with any downstream distributions or supply a patch.

Pidgin with these GTK libs is a flock of 365day flying in formation at the moment. That is why - everyone who installed Pidgin on Windows is vulnerable to the libpng bugs at the very least, almost certainly other bugs will impact those users.

It would be good to get libpng upgraded, however it's non-trivial.

Well unless I'm mistaken, which I admit is more than likely, I think that a lot more than libpng needs to be upgraded.

If there are other things, we may be able to update them too - I didn't see anything in the list that I thought was necessary in the list you posted.

I'm guessing the xml parser is probably also a problem. Then again, libxml2 is also in play... Turtles... everywhere.

libpng seems the most easy and relevant thing to upgrade. Why not rebuild it and replace it in the .zip file that pidgin hosts? That seems like the most simple thing unless libpng actually changed in serious ways.

Like I said, I would like to avoid building dependencies.

I don't think that is reasonable. After more than a year of leaving users vulnerable, I think building this code and shipping it, over SSL at that, is a much better way forward.

Sure, this is yet another way forward. It seems like it won't go very quickly. Is there a security contact at the gtk project that will help us?

The win32 side of the GTK+ project is understaffed; the long time win32 maintainer retired from the project a couple years ago and I don't know if someone else has really taken over.

That's too bad. Though I suspect GTK builds just fine, it just needs a new build and a release, right?

I would file a ticket in bugzilla requesting that a newer libpng binary be distributed.

Did you? Or do you mean, I should?

I guess I'm not worried if this takes a little while; this isn't a new issue and the world will not end if it isn't resolved immediately.

So, without sounding hostile, I wonder what you mean that it isn't the end of the world? Does someone have to upload a working libpng exploit that executes arbitrary code for this to be taken seriously?

Alternatively, I think pidgin could build and ship the required GTK libraries. Is the full build process for the required libraries documented somewhere?

That's a question for the GTK+ folks, but as I said, I'd rather not go down this path.

Huh? GTK+ folks don't actually know if pidgin can build and ship GTK. That question is squarely for pidgin developers. Is the build process documented somewhere? Or has pidgin never built the win32 gtk libs, never tried, and they won't start now?

If GTK won't fix it and you guys won't fix it - it seems unreasonable to ship it.

comment:31 follow-up: Changed 4 years ago by datallah

Replying to ioerror:

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.

You haven't had to deal with the regressions that we've had almost every time we've updated GTK+ or you wouldn't be advocating that path.

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.

Not isn't, it mostly works, but there are issues with focus and the system tray icon IIRC.

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.

I didn't ask you to provide an exploit for the libpng thing - from the start, I acknowledged that we were probably vulnerable. I don't think it's necessary to provide exploits - from the type of CVE we should be able to tell if it is a problem for us or not.

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. If it were easy to just update everything, then sure, that would be the easy fix - however, since that isn't the situation, we can examine the vulnerabilities and make an evaluation of whether or not it's going to be a problem for how we use it.

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?

I pointed you to the script that "builds" the gtk.zip we distribute in one of the comments on this ticket - it is just a repackaging of the binaries from gtk.org.

As far as how the gtk.org binaries are built, I don't offhand know how they're built.

comment:32 in reply to: ↑ 31 ; follow-up: Changed 4 years ago by ioerror

Replying to datallah:

Replying to ioerror:

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.

You haven't had to deal with the regressions that we've had almost every time we've updated GTK+ or you wouldn't be advocating that path.

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.

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.

Not isn't, it mostly works, but there are issues with focus and the system tray icon IIRC.

If the current code allows users to be exploited, which it appears is the case, it is broken *now* and should be motivation enough for change. That GTK updates andins't backport security fixes isn't pidgin's fault but it sure is still a problem. That's why it's broken.

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.

I didn't ask you to provide an exploit for the libpng thing - from the start, I acknowledged that we were probably vulnerable. I don't think it's necessary to provide exploits - from the type of CVE we should be able to tell if it is a problem for us or not.

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.

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

If it were easy to just update everything, then sure, that would be the easy fix - however, since that isn't the situation, we can examine the vulnerabilities and make an evaluation of whether or not it's going to be a problem for how we use it.

This was already settled - libpng is remotely reachable and it is known to be vulnerable. No one has produced information on how hard or easy it is to update everything, so while I believe you when you state that it isn't easy, it's not easy to help solve those issues either.

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?

I pointed you to the script that "builds" the gtk.zip we distribute in one of the comments on this ticket - it is just a repackaging of the binaries from gtk.org.

I understand. That's not going to get us a safe set of gtk libraries at the moment.

I did however file this bug with Gnome: https://bugzilla.gnome.org/show_bug.cgi?id=682642

This bug is also relevant and should similarly be solved by pidgin for the gtk downloads, regardless of patch version: https://bugzilla.gnome.org/show_bug.cgi?id=682641

As far as how the gtk.org binaries are built, I don't offhand know how they're built.

That seems like the next thing to figure out - if we can build it with mingw, we can probably produce the win32 library code easily on a free platform and iron out any Pidgin bugs that will pop up.

comment:33 Changed 4 years ago by ioerror

To give you an idea of why I think it is important to stay up on fixing any possible remote code execution path, I give you exhibit A of jerks trying to own pidgin users: http://www.peoplesliberationfront.net/anonpaste/?dfd1d4c70447af71#rrYmMIV1Jl51veVGA2P8oz5pNfCDlgzwWQUPjgHmyms=

Sadly, we're in a race with people who have more money, more time and more motivation.

comment:34 in reply to: ↑ 32 ; follow-up: Changed 4 years ago by datallah

Replying to ioerror:

*SIGH* this is more painful than it should be. I feel like I've wasted far too much time replying to this ticket that I could have used for something useful.

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.

With the exception of CVE-2010-4831, which is not a problem for us (whether you believe that or not), 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+.

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. Let's limit the scope of this to talk of updating *SPECIFIC* problematic libraries (currently only libpng), and not the whole stack.

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

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.

comment:35 in reply to: ↑ 34 ; follow-up: Changed 4 years ago 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 datallah:

Replying to 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!

comment:36 in reply to: ↑ 35 ; follow-up: Changed 4 years ago by datallah

Replying to 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 too, so much the better).

If that doesn't seem to be happening in the next few weeks, then we can think 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.

comment:37 in reply to: ↑ 36 Changed 4 years ago by ioerror

Replying to datallah:

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

comment:38 Changed 4 years ago by ioerror

I've also opened #15284

comment:39 Changed 4 years ago by ioerror

I've also opened #15285

comment:40 Changed 4 years ago by ioerror

I realized that I would quickly add too many comments here, so I have created a different master bug (#15286) to look at all the seemingly vulnerable shared libraries in the least Pidgin Windows release.

comment:41 Changed 4 years ago by Daniel Atallah <datallah@…>

  • Milestone changed from 3.0.0 to 2.10.7
  • Resolution set to fixed
  • Status changed from new to closed

(In [8e037a7b4ccd]):
Update various win32 dependencies - the new GTK+ bundle will be called 2.16.6.1 Thanks goes to Dieter Verfaillie for helping get the GTK+ dependencies updated. Fixes #14571, #15285, #15286

  • ATK 1.32.0-2
  • expat 2.1.0-1
  • freetype 2.4.10-1
  • gettext 0.18.1.1-2
  • Glib 2.28.8-1
  • libpng 1.4.12-1
  • Pango 1.29.4-1
  • libxml2 2.9.0-1
  • zlib 1.2.5-2
Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!