I was investigating this package for a possible security problem after a report that it statically linked libpng. There's no security problem, as it only produces image output, it doesn't interpret image files. however I noticed that the build/configure script did not statically link the libpng present on the system - I'm not sure why. # equery list libpng [ Searching for package 'libpng' in all categories among: ] * installed packages [I--] [ ] media-libs/libpng-1.2.12-r1 (1.2) # povray -v <snip> Support libraries used by POV-Ray: ZLib 1.2.3, Copyright 1995-1998 Jean-loup Gailly and Mark Adler LibPNG 1.2.5, Copyright 1998-2002 Glenn Randers-Pehrson LibJPEG 6b, Copyright 1998 Thomas G. Lane LibTIFF 3.8.2, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI <snip> emerge --info: Portage 2.1.1-r1 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r8 i686) ================================================================= System uname: 2.6.17-gentoo-r8 i686 AMD Athlon(tm) XP 2000+ Gentoo Base System version 1.12.5 Last Sync: Mon, 30 Oct 2006 10:30:03 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: [Not Present] dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=athlon-xp -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X berkdb bitmap-fonts cli cracklib crypt cups dlloader dri elibc_glibc gdbm gtk iconv input_devices_keyboard input_devices_mouse isdnlog jpeg kernel_linux libg++ ncurses nls nptl nptlonly pam pcre perl png ppds pppd python readline reflection samba session spl ssl tiff truetype-fonts type1-fonts udev unicode userland_GNU video_cards_nv xorg zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Created attachment 101987 [details, diff] patch The problem is that it compares the wanted version and the system version using strcmp, which makes 1.2.12 look less than 1.2.5.
Created attachment 101988 [details, diff] ebuild patch First patch changes acinclude.m4, so need to run eaclocal.
Seems I spoke too soon - I now get this error: x86_64-pc-linux-gnu-g++ -pipe -Wno-multichar -O3 -msse -mfpmath=sse -msse2 -march=k8 -mtune=k8 -minline-all-stringops -march=athlon64 -msse3 -pipe -O2 -L/usr/lib64 -o povray svga.o unix.o xwin.o ../source/libpovray.a ../source/base/libbase.a ../source/frontend/libfrontend.a -ltiff -ljpeg -lpng12 -lz -lXpm -lSM -lICE -lX11 -lm ../source/libpovray.a(png_pov.o): In function `pov::PNG_Image::~PNG_Image()': png_pov.cpp:(.text+0x25fc): undefined reference to `png_write_finish_row' ../source/libpovray.a(png_pov.o): In function `pov::PNG_Image::~PNG_Image()': png_pov.cpp:(.text+0x3272): undefined reference to `png_write_finish_row' ../source/libpovray.a(png_pov.o): In function `pov::PNG_Image::~PNG_Image()': png_pov.cpp:(.text+0x344c): undefined reference to `png_write_finish_row' collect2: ld returned 1 exit status make[2]: *** [povray] Error 1 make[2]: Leaving directory `/var/tmp/portage/povray-3.6.1-r1/work/povray-3.6.1/unix' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/povray-3.6.1-r1/work/povray-3.6.1' make: *** [all] Error 2 Indeed, the png_write_finish_row function doesn't seem to be present in libpng. I'm currently investigating.
Created attachment 101998 [details, diff] working patch New patch removes the need to use the missing function. It seems said function is only used when POV-Ray is aborted before the render finishes, and it tries to leave the partial image at least somewhat usable. That still works for me with the patch: SeaMonkey can display the part of the image that's been rendered. ImageMagick can't, but the same happens without patching POV-Ray in the first place, so I assume that just means ImageMagick is more picky.
Worked for me, in with #142498 -- Support libraries used by POV-Ray: ZLib 1.2.3, Copyright 1995-1998 Jean-loup Gailly and Mark Adler LibPNG 1.2.16, Copyright 1998-2002 Glenn Randers-Pehrson LibJPEG 6b, Copyright 1998 Thomas G. Lane LibTIFF 3.8.2, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
closing then, as that version has been stabilized. Thanks guys.
(In reply to comment #6) > closing then, as that version has been stabilized. Thanks guys. I don't think this patch made it in; I get Support libraries used by POV-Ray: ZLib 1.2.3, Copyright 1995-1998 Jean-loup Gailly and Mark Adler LibPNG 1.2.5, Copyright 1998-2002 Glenn Randers-Pehrson LibJPEG 6b, Copyright 1998 Thomas G. Lane LibTIFF 3.8.2, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI with 3.6.1-r2 from the tree.
*** Bug 184474 has been marked as a duplicate of this bug. ***
Reopen, not fixed.
This patch seems to work for me, I simply added it in ebuild as the last epatch line.
Probably vulnerable to CVE-2008-1382, bug 217047.
Carlo: Following Matt's analysis in the initial post, I would assume linking in old libpng does not pose a security threat. Did this change?
(In reply to comment #12) > Carlo: Following Matt's analysis in the initial post, I would assume linking in > old libpng does not pose a security threat. Did this change? > I'm not sure the initial analysis was correct. see http://tag.povray.org/povQandT/languageQandT.html#imagemapping. From what I understand, one can import image file as textures, so it could be vulnerable as well...
All, upstream seems to have fixed this whole "bundled static lib" thing in 3.7.0, which is now in beta. But since it could be some time before it is released, I went ahead and applied these patches to 3.6.1-r4. Also, I remove the bundled libs from the build dir to ensure they cannot be used. Note that I just recently submitted -r3 for stablization, which does not include this fix. If security thinks this is important enough, we can push to forget that and stabilize the new -r4 now, or we can wait 30 days. Please advise...
I'd play rather safe than sorry and ask for stabilization of a version which is known to use a safe version of libpng, especially after the information from p-y. So, arches, please test and stabilize: =media-gfx/povray-3.6.1-r4 Target keywords: alpha amd64 hppa ia64 ppc ppc64 sparc x86 Testing instructions can be found in bug 245981 (I guess they still apply for -r4). Sorry for the stabilization spam, didn't get down to reply to this bug earlier. :/
(In reply to comment #15) > So, arches, please test and stabilize: > =media-gfx/povray-3.6.1-r4 > > Target keywords: alpha amd64 hppa ia64 ppc ppc64 sparc x86 > > Testing instructions can be found in bug 245981 (I guess they still apply for > -r4). Sorry for the stabilization spam, didn't get down to reply to this bug > earlier. :/ Yes, those testing instructions are still valid. Aches, it was unfortunate timing on the recent stable request for -r3, but I agree with security's decision to go ahead with -r4, so if you can all do that test again for -r4, it will be much appreciated. Note, I added the STABLEREQ keyword to this bug...
Sparc stable: 1) Links libpng12.so.0 => /usr/lib/libpng12.so.0 2) Internal test does render a nice picture; 3) sphere.pov example from Bug #245981 renders a nice red ball with reflections.
Stable for HPPA.
ppc64 stable
Stabling done. Do we agree on B2? That'd mean we need a GLSA.
Some more info to help in deciding the severity of this one (and whether it might need a glsa): If any static libs are linked in during build, they will be the ones bundled with povray 3.6.1, and therefore they will be these specific versions: zlib 1.2.1 png 1.2.5 jpeg 6b tiff 3.6.1 The bundled version will be used if the installed system version of that lib is older than the above. However, there is a problem with the logic (which dleverton fixed in the patch above) that caused multiple digit version parts to compare incorrectly. That's why libpng stood out (1.2.12, e.g., was deemed older than 1.2.5 by configure). Therefore, the severity depends on whether the above versions have security problems (I don't know off-hand) and (esp. for other than libpng) how long ago the user emerged povray 3.6.
I will draft a glsa for this issue. Need some exercise... Updating the whiteboard to reflect the change.
GLSA 200812-15, sorry for the delay.
