Bug 12747

Summary:	libpng (1.5.x) and libpng12 new security issue CVE-2013-6954
Product:	Mageia	Reporter:	David Walser <luigiwalser>
Component:	Security	Assignee:	QA Team <qa-bugs>
Status:	RESOLVED FIXED	QA Contact:	Sec team <security>
Severity:	normal
Priority:	Normal	CC:	cmrisolde, mageia, rverschelde, stormi-mageia, sysadmin-bugs, tmb
Version:	4	Keywords:	validated_update
Target Milestone:	---
Hardware:	i586
OS:	Linux
URL:	http://lwn.net/Vulnerabilities/581308/
Whiteboard:	MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok advisory
Source RPM:	libpng12-1.2.50-3.mga3.src.rpm, libpng-1.5.13-2.mga3.src.rpm	CVE:
Status comment:

Description David Walser 2014-02-12 20:54:43 CET

We previously fixed this issue in pre-Mageia 4 Cauldron's libpng 1.6.x in Bug 12077.  At the time, it wasn't apparent that the issue also affects libpng 1.5.x (libpng SRPM in Mageia 3) and libpng 1.2.x (libpng12 SRPM in Mageia 3, Mageia 4, and Cauldron).  In fact, the upstream website indicated that only 1.6.1 through 1.6.7 were affected.

Fedora has issued advisories for this on January 30:
https://lists.fedoraproject.org/pipermail/package-announce/2014-February/128098.html
https://lists.fedoraproject.org/pipermail/package-announce/2014-February/128099.html

Patched packages uploaded for Mageia 3, Mageia 4, and Cauldron.

Advisory (Mageia 3):
========================

Updated libpng and libpng12 packages fix security vulnerability:

The png_do_expand_palette function in libpng before 1.6.8 allows remote
attackers to cause a denial of service (NULL pointer dereference and
application crash) via a PLTE chunk of zero bytes or a NULL palette, related
to pngrtran.c and pngset.c (CVE-2013-6954).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6954
https://lists.fedoraproject.org/pipermail/package-announce/2014-February/128098.html
https://lists.fedoraproject.org/pipermail/package-announce/2014-February/128099.html
========================

Updated packages in core/updates_testing:
========================
libpng15_15-1.5.13-2.1.mga3
libpng-devel-1.5.13-2.1.mga3
libpng12_0-1.2.50-3.1.mga3
libpng12-devel-1.2.50-3.1.mga3

from SRPMS:
libpng-1.5.13-2.1.mga3.src.rpm
libpng12-1.2.50-3.1.mga3.src.rpm


Advisory (Mageia 4):
========================

Updated libpng12 packages fix security vulnerability:

The png_do_expand_palette function in libpng before 1.6.8 allows remote
attackers to cause a denial of service (NULL pointer dereference and
application crash) via a PLTE chunk of zero bytes or a NULL palette, related
to pngrtran.c and pngset.c (CVE-2013-6954).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6954
https://lists.fedoraproject.org/pipermail/package-announce/2014-February/128099.html
========================

Updated packages in core/updates_testing:
========================
libpng12_0-1.2.50-4.1.mga4
libpng12-devel-1.2.50-4.1.mga4

from libpng12-1.2.50-4.1.mga4.src.rpm

Reproducible: 

Steps to Reproduce:

David Walser 2014-02-12 20:54:55 CET

Whiteboard: (none) => MGA3TOO

Comment 1 Samuel Verschelde 2014-02-15 14:32:36 CET

Testing procedure, feel free to add to it.

If using it in the future, check that it's still valid with urpmq --whatrequires-recursive name_of_the_lib, especially for libpng12_0 because more and more packages switch to a newer libpng.

For libpng12, usually we test by opening some png files with xv, which depends on lib(64)png12_0. gcompris uses it too, indirectly, so try it.

For libpng15_15, lots of packages depend on it, including lots of games and viewers. Example : check that warmux and smc work well. Check that firefox can open a png file (don't forget to restart it after installing the update). 

We also need to test png transformations, so use graphicsmagick to perform some transformations. 1Testing procedure for graphicsmagick : https://wiki.mageia.org/en/QA_procedure:GraphicsMagick

CC: (none) => stormi
Whiteboard: MGA3TOO => MGA3TOO has_procedure

Comment 2 Colin Guthrie 2014-02-15 14:34:08 CET

Used sam2p (which links against libpng12_0) to convert a png to a PDF on M4-64. Worked fine for me.

Comment 3 Samuel Verschelde 2014-02-15 14:36:17 CET

(In reply to Colin Guthrie from comment #2)
> Used sam2p (which links against libpng12_0) to convert a png to a PDF on
> M4-64. Worked fine for me.

Good addition to the procedure, it lacked transformations using libpng12_0

Comment 4 Colin Guthrie 2014-02-15 14:39:56 CET

Did the same test in M3-64 for libpng12 part and looked at some pngs in firefox for the libpng15 part. (also adding tag for the m4-64 test from previous comment)

CC: (none) => mageia
Whiteboard: MGA3TOO has_procedure => MGA3TOO has_procedure mga3-64-ok mga4-64-ok

Comment 5 Carolyn Rowse 2014-02-15 18:27:44 CET

Tested on Mga 32-bit - opening png images in firefox, xv, gwenview, ristretto; transformations using graphicsmagick as per procedure page and using sam2p as done by Colin.

No regressions found after update.

CC: (none) => isolde
Whiteboard: MGA3TOO has_procedure mga3-64-ok mga4-64-ok => MGA3TOO has_procedure mga3-64-ok mga4-64-ok mga3-32-ok

Comment 6 Rémi Verschelde 2014-02-16 12:50:47 CET

Testing complete on Mageia 4 i586.

--

Validating update, both advisories (mga3 and mga4) have been uploaded. Please push to 3 & 4 core/updates.

Keywords: (none) => validated_update
Whiteboard: MGA3TOO has_procedure mga3-64-ok mga4-64-ok mga3-32-ok => MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok advisory
CC: (none) => remi, sysadmin-bugs

Comment 7 Thomas Backlund 2014-02-16 14:48:39 CET

Mga3 update pushed:
http://advisories.mageia.org/MGASA-2014-0075.html

Mga4 update pushed:
http://advisories.mageia.org/MGASA-2014-0076.html

Status: NEW => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED