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
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
Created attachment 82711 [details] test jpeg attached test jpeg image
Created attachment 82997 [details, diff] zgv-5.9-cmyk-ycck-fix.diff patch from zgv author
Created attachment 82998 [details, diff] xzgv-0.8-patched-cmyk-ycck-fix.diff patch from zgv author (this is the xzgv one)
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.
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...)
Calling Arch Sec Liaisons x86 -> halcy0n Please test and report back on this bug, do NOT mark stable at this time.
Looks fine to me.
If anything else is needed from x86, please contact tsunam. I'll be gone until Friday.
Jonathan, this is about to go public, marking it as SEMI-PUBLIC for now. Please commit the updated ebuild with correct keywords asap.
done
This one is ready for GLSA publication. Security please draft.
what about non-x86 archs?
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
ppc stable
Stable on alpha + ia64.
xzgv now with all its amd64 goodness
public now
sparc stable.
Ready for GLSA
Thx everyone. GLSA 200604-10
[ERRATA UPDATE] GLSA 200604-10:02 issued (bug #134839)