Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#15285 closed defect (fixed)

libxml2 library out of date

Reported by: ioerror Owned by: datallah
Milestone: 2.10.7 Component: winpidgin (gtk)
Version: 2.10.6 Keywords: security
Cc:

Description

It appears that the pidgin libxml2 library shipped with the Windows release is old and vulnerable:

% objdump -d -p libxml2-2.dll|head

libxml2-2.dll:     file format pei-i386

Characteristics 0x2106
	executable
	line numbers stripped
	32 bit words
	DLL

Time/Date		Mon Sep 14 09:05:21 2009

I noticed that the Windows Build ( http://developer.pidgin.im/wiki/BuildingWinPidgin ) page suggests the following:

Libxml2
Download libxml2-dev_2.7.4-1_win32.zip and libxml2_2.7.4-1_win32.zip. Extract both to $PIDGIN_DEV_ROOT/win32-dev/libxml2-2.7.4 (you'll need to create this directory).

That isn't the correct version used in builds nor the most recent version of libxml2.

When I look at the GTK website where those files live, I don't see a libxml2 build produced after 07-Apr-2010. It appears that the hash of the libxml2 shipped with pidgin is:

% sha1sum libxml2-2.dll 
6f3b13168336aa531e019b7dd237ed51c2992511  libxml2-2.dll

That appears to be the same as the file available ( http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/libxml2_2.7.4-1_win32.zip ) from gnome as libxml2_2.7.4-1_win32.zip:

unzip libxml2_2.7.4-1_win32.zip
Archive:  libxml2_2.7.4-1_win32.zip
  inflating: bin/libxml2-2.dll       
  inflating: manifest/libxml2_2.7.4-1_win32.mft  
% sha1sum bin/libxml2-2.dll
6f3b13168336aa531e019b7dd237ed51c2992511  bin/libxml2-2.dll

So GTK's website actually has a newer, but still vulnerable libxml2-2.dll library and appears to pidgin ship one built on 14-Sep-2009. It appears that CVE-2010-4008 applies to this library: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-4008

Change History (5)

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

  • Milestone set 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

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

If a vulnerability was found tomorrow in any or all of those libraries - how would these get updated?

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

Replying to ioerror:

If a vulnerability was found tomorrow in any or all of those libraries - how would these get updated?

I worked with Dieter to figure out how this stuff is built, and I was able to build these myself (I did end up using Dieter's binaries though).

The build process is documented at https://github.com/dieterv/legacynativebuilds/ (it does require jumping through some hoops to get the initial setup).

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

Replying to datallah:

Replying to ioerror:

If a vulnerability was found tomorrow in any or all of those libraries - how would these get updated?

I worked with Dieter to figure out how this stuff is built, and I was able to build these myself (I did end up using Dieter's binaries though).

Wouldn't it be best if Pidgin offered them from the source forge mirror directly?

It would be pretty great if building pidgin for any platform was a single checkout, a single tar.gz or some hybrid of source/binary components only from the pidgin team.

The build process is documented at https://github.com/dieterv/legacynativebuilds/ (it does require jumping through some hoops to get the initial setup).

Heh. I'm not sure that I'd call that documented but I appreciate that it seems to be collected in one place. Looking at that git repo, I have no idea where to start - a README would probably be orienting. :)

It would be interesting if dieterv hosted the built files on gnome.org, so we'd know the genesis of the hashes in pidgin.

comment:5 in reply to: ↑ 4 Changed 4 years ago by datallah

Replying to ioerror:

Replying to datallah:

Replying to ioerror:

If a vulnerability was found tomorrow in any or all of those libraries - how would these get updated?

I worked with Dieter to figure out how this stuff is built, and I was able to build these myself (I did end up using Dieter's binaries though).

Wouldn't it be best if Pidgin offered them from the source forge mirror directly?

We could host them ourselves; we wouldn't put them on SF, I think we could just serve them from developer.pidgin.im (these aren't downloaded all that much). The gnome server has been reliable, so it hasn't been necessary. I do keep a backup copy of everything we've used in case the gnome site were to go down.

It would be pretty great if building pidgin for any platform was a single checkout, a single tar.gz or some hybrid of source/binary components only from the pidgin team.

There used to be a "Build Environment Fetcher" script that would set up a working build environment in an automated fashion, but it got out of date and nobody stepped up to maintain it. One of the complications is that these days Apple makes it a huge pain to download the Bonjour SDK installer (even though the stuff in it is 3-clause BSD licensed).

I'm certainly not opposed to making it easier for people to build pidgin on Windows, but it is possible to do relatively easily if you follow the instructions, so changing it is low on my priority list.

In a related matter, one of the things I'm working on is making it so that the dependency downloads can be verified to some extent (either with a GPG signature where possible, or at least with a sha1sum when no signature is available).

The build process is documented at https://github.com/dieterv/legacynativebuilds/ (it does require jumping through some hoops to get the initial setup).

Heh. I'm not sure that I'd call that documented but I appreciate that it seems to be collected in one place. Looking at that git repo, I have no idea where to start - a README would probably be orienting. :)

Yeah, it isn't easy to follow - it's mostly just a commit of the former maintainer's development environment. The text files in the root directory are emails between Dieter and the original maintainer and contain enough information to get it working.

It would be interesting if dieterv hosted the built files on gnome.org, so we'd know the genesis of the hashes in pidgin.

The latest files are actually hosted on gnome org along with their signatures (Dieter's key hash (0x71D4DDE53F188CBE) isn't posted anywhere publicly yet - he's planning to do so on the gtk download page when he finishes his set of updates): http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/?C=M;O=D

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!