CVE-2009-1364 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-1364): Use-after-free vulnerability in the embedded GD library in libwmf 0.2.8.4 allows context-dependent attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted WMF file.
Created attachment 190066 [details, diff] CVE-2009-1364.patch That GD copy should be removed. If that should take too long, I'm adding the patch found in Debian's bugtracker.
Since perusal of the sources indicate that use of the internal gd seems to offer little benefit, I just dropped the gd use-flag, since libwmf seems unmaintained and maintaining an internal copy in this package is unattractive. Gd is no longer built. +*libwmf-0.2.8.4-r3 (10 May 2009) + + 10 May 2009; Peter Alfredsen <loki_val@gentoo.org> + +libwmf-0.2.8.4-r3.ebuild, +files/libwmf-0.2.8.4-pngfix.patch: + Drop use of internal gd w.r.t. bug 268161. Add fix for bug 269324, include + order bug, possibly triggered by gcc-4.4.0. +
Arches, please test and mark stable: =media-libs/libwmf-0.2.8.4-r3 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"
x86 stable
Stable for HPPA.
Sparc stable.
alpha/arm/ia64/s390/sh stable
amd64 stable
ppc64 done
ppc done
GLSA request filed.
(In reply to comment #2) > Since perusal of the sources indicate that use of the internal gd seems to > offer little benefit, I just dropped the gd use-flag, since libwmf seems > unmaintained and maintaining an internal copy in this package is unattractive. > Gd is no longer built. Does this mean that libwmf does not have any gd support at all now, not even with the system gd, or does it build against the system gd? The situation is currently unclear to me and the GLSA draft says "All libwmf users should upgrade to the latest version, which now builds against a current version from portage". Is this correct?
It does not build the internal copy and does not link against the system copy: $ diff -u libwmf-0.2.8.4-r2.ebuild libwmf-0.2.8.4-r3.ebuild --- libwmf-0.2.8.4-r2.ebuild 2009-03-06 06:18:15.000000000 +0100 +++ libwmf-0.2.8.4-r3.ebuild 2009-05-25 21:05:12.000000000 +0200 ... -IUSE="X expat xml debug doc gtk gd" +IUSE="X expat xml debug doc gtk" RDEPEND="virtual/ghostscript xml? ( !expat? ( dev-libs/libxml2 ) ) expat? ( dev-libs/expat ) - gd? ( media-libs/gd ) >=media-libs/freetype-2.0.1 sys-libs/zlib media-libs/libpng ... @@ -65,10 +65,13 @@ myconf="${myconf} $(use_with expat) $(use_with xml libxml2)" fi + # NOTE: The gd that is included is gd-2.0.0. Even with --with-sys-gd, that gd is built + # and included in libwmf. Since nothing in-tree seems to use media-libs/libwmf[gd], + # we're explicitly disabling gd use w.r.t. bug 268161 econf \ $(use_enable debug) \ $(use_with X x) \ - $(use_enable gd) \ + --disable-gd \ --with-sys-gd \ ${myconf} \ --with-gsfontdir=/usr/share/ghostscript/fonts \ $ ./configure --help | grep gd --disable-gd don't build GD, don't look for it, don't require it --with-sys-gd=DIR use system GD in DIR (if compatible) $ ldd /var/tmp/portage/media-libs/libwmf-0.2.8.4-r3/image/usr/lib64/libwmf.so linux-vdso.so.1 => (0x00007fff4bbfe000) libwmflite-0.2.so.7 => /usr/lib/libwmflite-0.2.so.7 (0x00007f724364a000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f72433b1000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f72430a2000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00007f7242d43000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00007f7242b1c000) libz.so.1 => /lib/libz.so.1 (0x00007f7242905000) libm.so.6 => /lib/libm.so.6 (0x00007f7242681000) libc.so.6 => /lib/libc.so.6 (0x00007f7242310000) libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x00007f724210c000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f7241eee000) libdl.so.2 => /lib/libdl.so.2 (0x00007f7241cea000) /lib64/ld-linux-x86-64.so.2 (0x00007f7243aba000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f7241ae6000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f72418e0000)
GLSA 200907-01
