Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 127008 - media-gfx/xzgv,media-gfx/zgv: heap overflow (CVE-2006-1060)
Summary: media-gfx/xzgv,media-gfx/zgv: heap overflow (CVE-2006-1060)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B2 [glsa] jaervosz
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-20 13:20 UTC by Andrea Barisani (RETIRED)
Modified: 2007-05-31 10:55 UTC (History)
5 users (show)

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


Attachments
test jpeg (test.jpg,20.25 KB, image/jpeg)
2006-03-20 13:21 UTC, Andrea Barisani (RETIRED)
no flags Details
zgv-5.9-cmyk-ycck-fix.diff (zgv-5.9-cmyk-ycck-fix.diff,1.52 KB, patch)
2006-03-24 04:08 UTC, Andrea Barisani (RETIRED)
no flags Details | Diff
xzgv-0.8-patched-cmyk-ycck-fix.diff (xzgv-0.8-patched-cmyk-ycck-fix.diff,1.80 KB, patch)
2006-03-24 04:08 UTC, Andrea Barisani (RETIRED)
no flags Details | Diff
xzgv-0.8-r1.ebuild.patch (xzgv-0.8-r1.ebuild.patch,326 bytes, patch)
2006-03-31 11:42 UTC, Jonathan Smith (RETIRED)
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrea Barisani (RETIRED) gentoo-dev 2006-03-20 13:20:04 UTC
This is the copy of the message I just sent to v-s and zgv/xzgv maintainer.
Our zgv/xzgv are affectecd by this.

---------------------------------------------------------------------------

Hi folks,

I found out that zgv and xzgv (latest versions) segfaults with something like
the attached jpg.

Tavis (taviso@gentoo.org) and Solar (solar@gentoo.org) from the 
Gentoo Security Team had time to take a closer look and it looks like an
improper use of the jpeg library. 

quoting Tavis:

"The author makes the assumption that output data is either in rgb or greyscale 
format, rgb requires 3 * w * h bytes to decompress, and grayscale needs 2 * w * h, 
the author always allocates 3 * w * h, and just tweaks the arrangement if it's 
grayscale. In libjpeg terms the `output_components` is assumed to be 3, but in the
case of Andrea's test image is actually 4.

The fix is either to convert from cmyk (or whatever) to rgb within
xzgv's jpeg decompression routines, change those rgb assumptions, or to
just bail out if output_components > 3.

I dont know if this mistake/unchecked condition/whatever is exploitable
within xzgv, but I wouldnt rule it out."

It's a off-by-one heap overflow.

Here's the relevant backtrace:

#0  0x40394f0b in free_pool (cinfo=0x80b49c0, pool_id=0x1) at jmemmgr.c:971
	next_lhdr_ptr = (large_pool_ptr) 0xffffffff
	mem = (my_mem_ptr) 0x8101b18
	shdr_ptr = (small_pool_ptr) 0x4038aaaa
	lhdr_ptr = (large_pool_ptr) 0xffffffff
	space_freed = 0xa
#1  0x403937f6 in jpeg_abort (cinfo=0x80b49c0) at jcomapi.c:41
	pool = 0x1
#2  0x40382b96 in jpeg_finish_decompress (cinfo=0x80b49c0) at jdapimin.c:393
No locals.
#3  0x08060dbe in read_jpeg_file (filename=0x811c058 "./Untitled-1.jpg", imagep=0xbfffe704, wp=0xbfffe700, hp=0xbfffe6fc, origwp=0xbfffe6e4, orighp=0xbfffe6e0, for_tn=0x0) at readjpeg.c:296
	in = (FILE *) 0x81019a8
	jerr = {pub = {error_ex...
	lineptrs = (unsigned char **) 0x0
	have_image = 0x1
	width = 0xc2
	height = 0x47
	image = (unsigned char *) 0x81298b0 'ÿ' <repeats 200 times>...
	ptr = (unsigned char *) 0x8133a1a 'ÿ' <repeats 194 times>
	ptr2 = (unsigned char *) 0x20000 <Address 0x20000 out of bounds>
	chkw = 0x404a5a23
	chkh = 0x404a69d4
	f = 0x1
	rec = 0x1
	greyscale = 0x0
#4  0x080506b4 in load_image (file=0x811c058 "./Untitled-1.jpg", for_thumbnail=0x0, origwp=0x0, orighp=0x0) at main.c:441
	bmap = (unsigned char *) 0x81298b0 'ÿ' <repeats 200 times>...
	w = 0xc2
	h = 0x47
	ret = (xzgv_image *) 0x80576f4
	buf = "ÿØÿá"
	in = (FILE *) 0x81019a8
	iret = 0x4
	make_image = 0x0
	origw = 0xc2
	origh = 0x47
Comment 1 Andrea Barisani (RETIRED) gentoo-dev 2006-03-20 13:20:04 UTC
This is the copy of the message I just sent to v-s and zgv/xzgv maintainer.
Our zgv/xzgv are affectecd by this.

---------------------------------------------------------------------------

Hi folks,

I found out that zgv and xzgv (latest versions) segfaults with something like
the attached jpg.

Tavis (taviso@gentoo.org) and Solar (solar@gentoo.org) from the 
Gentoo Security Team had time to take a closer look and it looks like an
improper use of the jpeg library. 

quoting Tavis:

"The author makes the assumption that output data is either in rgb or greyscale 
format, rgb requires 3 * w * h bytes to decompress, and grayscale needs 2 * w * h, 
the author always allocates 3 * w * h, and just tweaks the arrangement if it's 
grayscale. In libjpeg terms the `output_components` is assumed to be 3, but in the
case of Andrea's test image is actually 4.

The fix is either to convert from cmyk (or whatever) to rgb within
xzgv's jpeg decompression routines, change those rgb assumptions, or to
just bail out if output_components > 3.

I dont know if this mistake/unchecked condition/whatever is exploitable
within xzgv, but I wouldnt rule it out."

It's a off-by-one heap overflow.

Here's the relevant backtrace:

#0  0x40394f0b in free_pool (cinfo=0x80b49c0, pool_id=0x1) at jmemmgr.c:971
	next_lhdr_ptr = (large_pool_ptr) 0xffffffff
	mem = (my_mem_ptr) 0x8101b18
	shdr_ptr = (small_pool_ptr) 0x4038aaaa
	lhdr_ptr = (large_pool_ptr) 0xffffffff
	space_freed = 0xa
#1  0x403937f6 in jpeg_abort (cinfo=0x80b49c0) at jcomapi.c:41
	pool = 0x1
#2  0x40382b96 in jpeg_finish_decompress (cinfo=0x80b49c0) at jdapimin.c:393
No locals.
#3  0x08060dbe in read_jpeg_file (filename=0x811c058 "./Untitled-1.jpg", imagep=0xbfffe704, wp=0xbfffe700, hp=0xbfffe6fc, origwp=0xbfffe6e4, orighp=0xbfffe6e0, for_tn=0x0) at readjpeg.c:296
	in = (FILE *) 0x81019a8
	jerr = {pub = {error_ex...
	lineptrs = (unsigned char **) 0x0
	have_image = 0x1
	width = 0xc2
	height = 0x47
	image = (unsigned char *) 0x81298b0 'ÿ' <repeats 200 times>...
	ptr = (unsigned char *) 0x8133a1a 'ÿ' <repeats 194 times>
	ptr2 = (unsigned char *) 0x20000 <Address 0x20000 out of bounds>
	chkw = 0x404a5a23
	chkh = 0x404a69d4
	f = 0x1
	rec = 0x1
	greyscale = 0x0
#4  0x080506b4 in load_image (file=0x811c058 "./Untitled-1.jpg", for_thumbnail=0x0, origwp=0x0, orighp=0x0) at main.c:441
	bmap = (unsigned char *) 0x81298b0 'ÿ' <repeats 200 times>...
	w = 0xc2
	h = 0x47
	ret = (xzgv_image *) 0x80576f4
	buf = "ÿÃÿá"
	in = (FILE *) 0x81019a8
	iret = 0x4
	make_image = 0x0
	origw = 0xc2
	origh = 0x47
Comment 2 Andrea Barisani (RETIRED) gentoo-dev 2006-03-20 13:21:11 UTC
Created attachment 82711 [details]
test jpeg

attached test jpeg image
Comment 3 Andrea Barisani (RETIRED) gentoo-dev 2006-03-24 04:08:17 UTC
Created attachment 82997 [details, diff]
zgv-5.9-cmyk-ycck-fix.diff

patch from zgv author
Comment 4 Andrea Barisani (RETIRED) gentoo-dev 2006-03-24 04:08:56 UTC
Created attachment 82998 [details, diff]
xzgv-0.8-patched-cmyk-ycck-fix.diff

patch from zgv author (this is the xzgv one)
Comment 5 Tavis Ormandy (RETIRED) gentoo-dev 2006-03-27 07:43:41 UTC
smithj: you're listed as maintainer of xzgv, this issue is still confidential, so please do not commit anything to portage yet. Please check the attached patch and attach an updated ebuild to this bug.
Comment 6 Jonathan Smith (RETIRED) gentoo-dev 2006-03-31 11:42:46 UTC
Created attachment 83537 [details, diff]
xzgv-0.8-r1.ebuild.patch

sorry for the delay. the patch seems to work fine. here's an ebuild diff (pretty simple, but either way...)
Comment 7 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-03-31 22:28:14 UTC
Calling Arch Sec Liaisons

x86 -> halcy0n

Please test and report back on this bug, do NOT mark stable at this time.
Comment 8 Mark Loeser (RETIRED) gentoo-dev 2006-04-03 05:46:45 UTC
Looks fine to me.
Comment 9 Mark Loeser (RETIRED) gentoo-dev 2006-04-04 09:21:10 UTC
If anything else is needed from x86, please contact tsunam.  I'll be gone until Friday.
Comment 10 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-04-07 07:47:11 UTC
Jonathan, this is about to go public, marking it as SEMI-PUBLIC for now. Please commit the updated ebuild with correct keywords asap.
Comment 11 Jonathan Smith (RETIRED) gentoo-dev 2006-04-07 10:59:18 UTC
done
Comment 12 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-04-07 23:25:42 UTC
This one is ready for GLSA publication. Security please draft.
Comment 13 Jonathan Smith (RETIRED) gentoo-dev 2006-04-07 23:53:24 UTC
what about non-x86 archs?
Comment 14 Thierry Carrez (RETIRED) gentoo-dev 2006-04-08 03:04:58 UTC
Apparently some arches were forgotten on xzgv.
Adding kloeri (alpha) blubb (amd64) dertobi123 (ppc) and gustavoz (sparc)
Please test and mark stable xzgv-0.8-r2
Comment 15 Tobias Scherbaum (RETIRED) gentoo-dev 2006-04-08 06:18:59 UTC
ppc stable
Comment 16 Bryan Østergaard (RETIRED) gentoo-dev 2006-04-08 09:32:46 UTC
Stable on alpha + ia64.
Comment 17 Simon Stelling (RETIRED) gentoo-dev 2006-04-09 12:53:32 UTC
xzgv now with all its amd64 goodness
Comment 18 Stefan Cornelius (RETIRED) gentoo-dev 2006-04-10 05:29:21 UTC
public now
Comment 19 Gustavo Zacarias (RETIRED) gentoo-dev 2006-04-10 07:21:33 UTC
sparc stable.
Comment 20 Thierry Carrez (RETIRED) gentoo-dev 2006-04-14 13:38:32 UTC
Ready for GLSA
Comment 21 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-04-20 21:53:57 UTC
Thx everyone.

GLSA 200604-10
Comment 22 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-06-11 12:32:51 UTC
[ERRATA UPDATE]        GLSA 200604-10:02 issued (bug #134839)