Bug 18183 - imlib2 new security issues CVE-2016-3993, CVE-2016-3994, and CVE-2011-5326
Summary: imlib2 new security issues CVE-2016-3993, CVE-2016-3994, and CVE-2011-5326
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 5
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: has_procedure advisory MGA5-64-OK MGA...
Keywords: validated_update
Depends on:
Blocks:
 
Reported: 2016-04-11 16:02 CEST by David Walser
Modified: 2016-04-14 18:09 CEST (History)
2 users (show)

See Also:
Source RPM: imlib2-1.4.7-1.mga5.src.rpm
CVE:
Status comment:


Attachments
Tar file containing test files for imlib2 (460.00 KB, application/octet-stream)
2016-04-12 22:26 CEST, Len Lawrence
Details

Description David Walser 2016-04-11 16:02:25 CEST
CVEs have been assigned for issues fixed recently in imlib2 git:
http://openwall.com/lists/oss-security/2016/04/10/3
http://openwall.com/lists/oss-security/2016/04/10/4
http://openwall.com/lists/oss-security/2016/04/11/1

Updated (to 1.4.8) and patched packages uploaded for Mageia 5 and Cauldron.

Advisory:
========================

Updated imlib2 packages fix security vulnerabilities:

An out-of-bounds read caused by an off-by-one error in __imlib_MergeUpdate()
in src/lib/updates.c in imlib2 1.4.8 and earlier (CVE-2016-3993).

An out-of-bounds read from colormap in the GIF loader in imlib2 1.4.8 and
earlier can result in denial of service and potential host memory exposure
(CVE-2016-3994).

Attempting to draw a 2x1 ellipse with e.g. imlib_image_draw_ellipse(x, y, 2, 1)
causes a divide-by-zero in imlib2 1.4.8 and earlier, resulting in a denial of
service if an application uses the draw command with untrusted input
(CVE-2011-5326).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-5326
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3993
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3994
http://openwall.com/lists/oss-security/2016/04/10/3
http://openwall.com/lists/oss-security/2016/04/10/4
http://openwall.com/lists/oss-security/2016/04/11/1
========================

Updated packages in core/updates_testing:
========================
libimlib2_1-1.4.8-1.mga5
libimlib2-devel-1.4.8-1.mga5
libimlib2_1-filters-1.4.8-1.mga5
libimlib2_1-loaders-1.4.8-1.mga5
imlib2-data-1.4.8-1.mga5

from imlib2-1.4.8-1.mga5.src.rpm
Comment 1 Len Lawrence 2016-04-12 10:44:51 CEST
Trying this one.  The documentation site provides two test programs, one a simple image converter and the other an interactive one which could be adapted to provide a PoC.  The degenerate ellipse code above could be inserted easily but the problem is the program does not compile here - a couple of missing symbols.  The image converter works fine though.

I may have to extract the tarball from git but I don't actually know how to handle git.  Probably need an account for a start.

CC: (none) => tarazed25

Comment 2 Len Lawrence 2016-04-12 22:24:09 CEST
x86_64  Mate

Documentation for imlib2 at http://alien.cern.ch/cache/imlib2-1.0.6/doc/

Extracted the image converter code and compiled it and tested it by converting a JPEG image to PNG format.  Compiled a more complex program from the same source and ran that.  It was a bit buggy but worked, basically.  These two are enough to show that the package works but I cannot see how to provide a PoC for them.  Tried inserting a 2x1 ellipse into the code and expected an exception to be raised (divide by zero) but did not see one.  It did issue a warning about trying to draw an ellipse with a null image.

Attaching the two C scripts and image and font directories as a tar file.  Compile and run the object files at the point of installation.

Updated imlib2 and recompiled the test program.  This no longer issued the warning about a null image when drawing the ellipse.  Could be significant.
Comment 3 Len Lawrence 2016-04-12 22:26:36 CEST
Created attachment 7660 [details]
Tar file containing test files for imlib2

The binary files were compiled after the update.
Comment 4 Len Lawrence 2016-04-12 22:31:58 CEST
Since I can see no way to test the three vulnerabilities this test will have to do I think; i.e. the library works without obvious regressions.

Giving this a hesitant OK.
Len Lawrence 2016-04-12 22:32:29 CEST

Whiteboard: (none) => MGA5-64-OK

Comment 5 Len Lawrence 2016-04-13 12:30:55 CEST
i586 virtualbox

Ran the same set of tests before and after the update with same results as for 64-bits.

Adding the OK but shall leave validation for a wee while to allow for feedback.
Len Lawrence 2016-04-13 12:31:16 CEST

Whiteboard: MGA5-64-OK => MGA5-64-OK MGA5-32-OK

Comment 6 claire robinson 2016-04-13 18:00:20 CEST
Simpler way to test would be with any from..

$ urpmq --whatrequires lib64imlib2_1

eg. deadbeef, qiv, scrott

Validating. Advisory uploaded,

Keywords: (none) => validated_update
Whiteboard: MGA5-64-OK MGA5-32-OK => has_procedure advisory MGA5-64-OK MGA5-32-OK
CC: (none) => sysadmin-bugs

Comment 7 Mageia Robot 2016-04-13 19:40:09 CEST
An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2016-0140.html

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

Comment 8 David Walser 2016-04-14 18:09:48 CEST
LWN reference for CVE-2016-3993:
http://lwn.net/Vulnerabilities/683843/

Note You need to log in before you can comment on or make changes to this bug.