Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 576872 (CVE-2016-1577) - <media-libs/jasper-1.900.6: double free and memory leak
Summary: <media-libs/jasper-1.900.6: double free and memory leak
Status: RESOLVED FIXED
Alias: CVE-2016-1577
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL: http://www.openwall.com/lists/oss-sec...
Whiteboard: B3 [noglsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-09 15:23 UTC by Agostino Sarubbo
Modified: 2016-11-11 12:19 UTC (History)
1 user (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 Agostino Sarubbo gentoo-dev 2016-03-09 15:23:33 UTC
From ${URL} :

-------------
CVE-2016-1577
-------------

Jacob Baines discovered[1] that a double free vulnerability in the
jas_iccattrval_destroy function in JasPer 1.900.1 and earlier allows
remote attackers to cause a denial of service (crash) or possibly
execute arbitrary code via a crafted ICC color profile in a JPEG 2000
image file, a different vulnerability than CVE-2014-8137. This double
free issue was assigned CVE-2016-1577.

In the code snippet below, attrval variable is assigned on line 298 and freed
with the call to jas_iccattrval_destroy() on line 302. If the tests on lines
312, 321, or 324 are true, the same pointer will be passed a second time
to jas_iccattrval_destroy() on line 357.

src/libjasper/base/jas_icc.c:
258	jas_iccprof_t *jas_iccprof_load(jas_stream_t *in)
259	{
...
294		for (i = 0; i < numtags; ++i) {
295			tagtabent = &prof->tagtab.ents[i];
296			if (tagtabent->off == JAS_CAST(jas_iccuint32_t, prevoff)) {
297				if (prevattrval) {
298					if (!(attrval = jas_iccattrval_clone(prevattrval)))
299						goto error;
300					if (jas_iccprof_setattr(prof, tagtabent->tag, attrval))
301						goto error;
302					jas_iccattrval_destroy(attrval);
303				} else {
304	#if 0
305					jas_eprintf("warning: skipping unknown tag type\n");
306	#endif
307				}
308				continue;
309			}
310			reloff = tagtabent->off - curoff;
311			if (reloff > 0) {
312				if (jas_stream_gobble(in, reloff) != reloff)
313					goto error;
314				curoff += reloff;
315			} else if (reloff < 0) {
316				/* This should never happen since we read the tagged
317				element data in a single pass. */
318				abort();
319			}
320			prevoff = curoff;
321			if (jas_iccgetuint32(in, &type)) {
322				goto error;
323			}
324			if (jas_stream_gobble(in, 4) != 4) {
325				goto error;
326			}
327			curoff += 8;
328			if (!(attrvalinfo = jas_iccattrvalinfo_lookup(type))) {
329	#if 0
330				jas_eprintf("warning: skipping unknown tag type\n");
331	#endif
332				prevattrval = 0;
333				continue;
334			}
335			if (!(attrval = jas_iccattrval_create(type))) {
336				goto error;
337			}
...
353	error:
354		if (prof)
355			jas_iccprof_destroy(prof);
356		if (attrval)
357			jas_iccattrval_destroy(attrval);
358		return 0;
359	}

I've attached a patch to fix the issue by setting the attrval variable
to NULL after it is initially freed. See the original bug report[1] for
an image file to reproduce this issue.

-------------
CVE-2016-2116
-------------

While testing the fix for the issue above, I discovered that a memory
leak in the jas_iccprof_createfrombuf function in JasPer 1.900.1 and
earlier allows remote attackers to cause a denial of service (memory
consumption) via a crafted ICC color profile in a JPEG 2000 image file.
This memory leak issue was assigned CVE-2016-2116. 

Valgrind says 8,352 bytes are leaked per call to jas_image_decode():

$ valgrind --leak-check=full imginfo -f bad.jp2 
==3131== Memcheck, a memory error detector
==3131== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==3131== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==3131== Command: imginfo -f bad.jp2
==3131== 
error: failed to parse ICC profile
cannot load image
==3131== 
==3131== HEAP SUMMARY:
==3131==     in use at exit: 20,772 bytes in 6 blocks
==3131==   total heap usage: 1,116 allocs, 1,110 frees, 502,815 bytes allocated
==3131== 
==3131== 8,352 (104 direct, 8,248 indirect) bytes in 1 blocks are definitely lost in loss record 5 of 6
==3131==    at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3131==    by 0x4E4AF0D: ??? (in /usr/lib/x86_64-linux-gnu/libjasper.so.1.0.0)
==3131==    by 0x4E4BFF4: jas_stream_memopen (in /usr/lib/x86_64-linux-gnu/libjasper.so.1.0.0)
==3131==    by 0x4E49E7A: jas_iccprof_createfrombuf (in /usr/lib/x86_64-linux-gnu/libjasper.so.1.0.0)
==3131==    by 0x4E50571: jp2_decode (in /usr/lib/x86_64-linux-gnu/libjasper.so.1.0.0)
==3131==    by 0x4E44EAC: jas_image_decode (in /usr/lib/x86_64-linux-gnu/libjasper.so.1.0.0)
==3131==    by 0x400C71: ??? (in /usr/bin/imginfo)
==3131==    by 0x50AF9FF: (below main) (libc-start.c:289)
==3131== 
==3131== 12,420 (104 direct, 12,316 indirect) bytes in 1 blocks are definitely lost in loss record 6 of 6
==3131==    at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3131==    by 0x4E4AF0D: ??? (in /usr/lib/x86_64-linux-gnu/libjasper.so.1.0.0)
==3131==    by 0x4E4B384: jas_stream_fopen (in /usr/lib/x86_64-linux-gnu/libjasper.so.1.0.0)
==3131==    by 0x400C47: ??? (in /usr/bin/imginfo)
==3131==    by 0x50AF9FF: (below main) (libc-start.c:289)
==3131== 
==3131== LEAK SUMMARY:
==3131==    definitely lost: 208 bytes in 2 blocks
==3131==    indirectly lost: 20,564 bytes in 4 blocks
==3131==      possibly lost: 0 bytes in 0 blocks
==3131==    still reachable: 0 bytes in 0 blocks
==3131==         suppressed: 0 bytes in 0 blocks
==3131== 
==3131== For counts of detected and suppressed errors, rerun with: -v
==3131== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

Ignore the second memory leak (12,420 bytes) as it is a leak in imginfo and not
libjasper.

In the following snippet, the jas_stream_t allocated by the call to
jas_stream_memopen() is leaked if jas_iccprof_load() fails on line 1691.

src/libjasper/base/jas_icc.c:
1685	jas_iccprof_t *jas_iccprof_createfrombuf(uchar *buf, int len)
1686	{
1687		jas_stream_t *in;
1688		jas_iccprof_t *prof;
1689		if (!(in = jas_stream_memopen(JAS_CAST(char *, buf), len)))
1690			goto error;
1691		if (!(prof = jas_iccprof_load(in)))
1692			goto error;
1693		jas_stream_close(in);
1694		return prof;
1695	error:
1696		return 0;
1697	}

I've attached a patch that fixes the issue by closing the jas_stream_t
in the error path.

[1] https://launchpad.net/bugs/1547865

Tyler

Description: CVE-2016-1577: Prevent double-free in jas_iccattrval_destroy()
Author: Tyler Hicks <tyhicks@...onical.com>
Bug-Ubuntu: https://launchpad.net/bugs/1547865

--- jasper-1.900.1-debian1.orig/src/libjasper/base/jas_icc.c
+++ jasper-1.900.1-debian1/src/libjasper/base/jas_icc.c
@@ -300,6 +300,7 @@ jas_iccprof_t *jas_iccprof_load(jas_stre
 				if (jas_iccprof_setattr(prof, tagtabent->tag, attrval))
 					goto error;
 				jas_iccattrval_destroy(attrval);
+				attrval = 0;
 			} else {
 #if 0
 				jas_eprintf("warning: skipping unknown tag type\n");

Description: Prevent jas_stream_t memory leak in jas_iccprof_createfrombuf()
Author: Tyler Hicks <tyhicks@...onical.com>

--- jasper-1.900.1-debian1.orig/src/libjasper/base/jas_icc.c
+++ jasper-1.900.1-debian1/src/libjasper/base/jas_icc.c
@@ -1693,6 +1693,8 @@ jas_iccprof_t *jas_iccprof_createfrombuf
 	jas_stream_close(in);
 	return prof;
 error:
+	if (in)
+		jas_stream_close(in);
 	return 0;
 }



@maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Comment 1 Agostino Sarubbo gentoo-dev 2016-10-19 09:42:12 UTC
Arches, please test and mark stable:
=media-libs/jasper-1.900.6
Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 sparc x86"
Comment 2 Agostino Sarubbo gentoo-dev 2016-10-19 10:27:05 UTC
amd64 stable
Comment 3 Agostino Sarubbo gentoo-dev 2016-10-19 10:28:28 UTC
x86 stable
Comment 4 Agostino Sarubbo gentoo-dev 2016-10-20 11:00:33 UTC
ia64 stable
Comment 5 Agostino Sarubbo gentoo-dev 2016-10-20 11:01:00 UTC
sparc stable
Comment 6 Agostino Sarubbo gentoo-dev 2016-10-21 10:52:21 UTC
ppc stable
Comment 7 Agostino Sarubbo gentoo-dev 2016-10-21 10:52:48 UTC
alpha stable
Comment 8 Jeroen Roovers (RETIRED) gentoo-dev 2016-10-22 09:58:48 UTC
Stable for HPPA PPC64.
Comment 9 Agostino Sarubbo gentoo-dev 2016-10-22 15:34:49 UTC
arm stable.

Maintainer(s), please cleanup.
Security, please vote.
Comment 10 Aaron Bauman (RETIRED) gentoo-dev 2016-11-11 12:19:44 UTC
GLSA Vote: No