Bugzilla Bug 153538

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 an attachment (id=101987) [details]
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 an attachment (id=101988) [details]
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 an attachment (id=101998) [details]
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.