Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 324153 - <media-libs/libpng-{1.2.44,1.4.3}: Privilege escalation (CVE-2010-1205)
Summary: <media-libs/libpng-{1.2.44,1.4.3}: Privilege escalation (CVE-2010-1205)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo Security
URL:
Whiteboard: A2 [glsa]
Keywords:
Depends on: 305053 libpng-1.4 319505 319509 319515 319517 319541 319551 320665 322741 322745 322843 322907 324155 325569
Blocks: 325503 325819 325847
  Show dependency tree
 
Reported: 2010-06-15 16:11 UTC by Samuli Suominen (RETIRED)
Modified: 2010-10-06 07:11 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Samuli Suominen (RETIRED) gentoo-dev 2010-06-15 16:11:55 UTC
should be fine, see the blocking bugs.

=media-libs/libpng-1.2.43-r3 "amd64 x86"
=media-libs/libpng-1.4.2     "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"

amd64 needs also latest emul- packages, and they just got added, so i'd wait few weeks before cc'ing archteams here...
Comment 1 Samuli Suominen (RETIRED) gentoo-dev 2010-06-27 09:48:59 UTC
test & stabilize:

=media-libs/libpng-1.2.44 (amd64 and x86 should be enough for this version)

=media-libs/libpng-1.4.2 (everyone)
Comment 2 Samuli Suominen (RETIRED) gentoo-dev 2010-06-27 12:49:50 UTC
And the target keeps changing :-)

Stabilize:

=media-libs/libpng-1.2.44 (amd64 and x86 should be enough for this version)
=media-libs/libpng-1.4.3 (everyone)

<snip>

Several versions of libpng through 1.4.2 (and through 1.2.43 in the older series) contain a bug whereby progressive applications such as web browsers (or the rpng2 demo app included in libpng) could receive an extra row of image data beyond the height reported in the header, potentially leading to an out-of-bounds write to memory (depending on how the application is written) and the possibility of execution of an attacker's code with the privileges of the libpng user (including remote compromise in the case of a libpng-based browser visiting a hostile web site). This vulnerability has been assigned ID CVE-2010-1205  (via Mozilla).

An additional memory-leak bug, involving images with malformed sCAL chunks, is also present; it could lead to an application crash (denial of service) when viewing such images.

Both bugs are fixed in versions 1.4.3 and 1.2.44, released 25 June 2010. 

</snip>
Comment 3 Samuli Suominen (RETIRED) gentoo-dev 2010-06-27 13:27:01 UTC
amd64 stable
Comment 4 Jeroen Roovers (RETIRED) gentoo-dev 2010-06-28 10:53:24 UTC
Stable for HPPA.
Comment 5 Florian Berger 2010-06-28 17:33:35 UTC
It's probably just me, but the current 1.2.44 ebuild does not work for me on x86.

It says "this ebuild is only for the libpng12.so.0 SONAME for ABI compat" and installs a libpng12.so.0 file only - no headers, no symlinks, nothing else. libpng-dependent applications won't compile with that.

To reproduce:

$ emerge --unmerge libpng
$ emerge "=libpng-1.2.44"
$ equery files libpng

Is that an intended behaviour?
Comment 6 Samuli Suominen (RETIRED) gentoo-dev 2010-06-28 17:40:02 UTC
(In reply to comment #5)
> Is that an intended behaviour?

Yes, you get the headers/symlink/... from 1.4.3 (which is pulled in by the upgrade). 1.2.44 is only for binary apps, like vmware-server.
Comment 7 Thomas Kahle (RETIRED) gentoo-dev 2010-06-29 05:44:14 UTC
Archtested on x86: The rebuild went OK. I ran into a couple of already fixed issues and bug 320669, which is probably unrelated.
Comment 8 Florian Berger 2010-06-29 11:31:13 UTC
(In reply to comment #6)
> Yes, you get the headers/symlink/... from 1.4.3 (which is pulled in by the
> upgrade). 1.2.44 is only for binary apps, like vmware-server.

To me this is a disappointing solution. I mean, if I

$ emerge "=libpng-1.2.44"

I expect to get the whole thing. Especially if it's a critical bugfix release.

In my mind, if I for some reason do not want to upgrade to 1.4 now then Gentoo shouldn't get in my way.

As a personal solution I've cooked my own 1.2.44 ebuild from the 1.2.43-r2 ebuild, and it works fine. But this is a bit odd.

Florian
Comment 9 Samuli Suominen (RETIRED) gentoo-dev 2010-06-29 11:40:21 UTC
There is no reason to not upgrade to 1.4.3.
Comment 10 Florian Berger 2010-06-29 12:43:58 UTC
Well. In my case I just wanted a quick bugfix and postpone a possible thorough revdep-rebuild until later.

In the long run you are of course right.
Comment 11 Christian Faulhammer (RETIRED) gentoo-dev 2010-06-30 14:45:27 UTC
x86 stable, thanks Thomas, my rebuilts also went fine
Comment 12 Dominik Kozaczko 2010-07-01 07:21:03 UTC
In my case revdep-rebuild showed only some non-critical packages depending on libpng12 (like obex). I still can't compile new packages. Using trial-and-error I figured to remerge cairo and pango but still lots of packages can't be merged. Then I made my own libpng:1.2 ebuild which has libpng12.so and libpng12.la and all problems went away.

I want to stress this once again: revdep-rebuild showed none critical packages.
Comment 13 Stefan Behte (RETIRED) gentoo-dev Security 2010-07-01 18:21:00 UTC
I've had similar problems and reverted. I didn't have enough time to look at it, though.
Comment 14 Samuli Suominen (RETIRED) gentoo-dev 2010-07-04 00:37:21 UTC
ppc64 stable
Comment 15 Tobias Klausmann (RETIRED) gentoo-dev 2010-07-11 10:17:41 UTC
Stable on alpha.
Comment 16 Raúl Porcel (RETIRED) gentoo-dev 2010-07-11 17:38:02 UTC
arm/ia64/m68k/s390/sh/sparc stable
Comment 17 Joe Jezak (RETIRED) gentoo-dev 2010-07-19 01:06:30 UTC
Marked ppc stable.
Comment 18 Stefan Behte (RETIRED) gentoo-dev Security 2010-07-26 16:08:28 UTC
CVE-2010-1205 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-1205):
  Buffer overflow in pngpread.c in libpng before 1.2.44 and 1.4.x
  before 1.4.3, as used in progressive applications, might allow remote
  attackers to execute arbitrary code via a PNG image that triggers an
  additional data row.

Comment 19 Stefan Behte (RETIRED) gentoo-dev Security 2010-08-01 12:51:57 UTC
Samuli: only change the whiteboard to glsa, after it was filed in our glsamaker tool. As only the security team adds glsas there, it's safe to say that you should never change the whiteboard to [glsa].
Comment 20 Pierre-Yves Rofes (RETIRED) gentoo-dev 2010-10-06 07:11:56 UTC
GLSA 201010-01