New openjpeg package fixes this 3 security issues: https://blogs.gentoo.org/ago/2017/08/16/openjpeg-heap-based-buffer-overflow-in-opj_write_bytes_le-cio-c/ https://blogs.gentoo.org/ago/2017/08/14/openjpeg-memory-allocation-failure-in-opj_aligned_alloc_n-opj_malloc-c/ https://blogs.gentoo.org/ago/2017/08/16/openjpeg-heap-based-buffer-overflow-in-opj_mqc_flush-mqc-c/ pushed updates_testing src.rpm: openjpeg2-2.2.0-1.1.mga6 openjpeg2-2.2.0-1.1.mga5
CC: (none) => davidwhodginsSummary: 3 security issues fixed => openjpeg2 - 3 security issues fixed
Advisory: ======================== Updated openjpeg2 packages fix security vulnerabilities: Patches from upstream have been added to fix two heap-based buffer overflows and a memory allocation failure. References: https://blogs.gentoo.org/ago/2017/08/16/openjpeg-heap-based-buffer-overflow-in-opj_write_bytes_le-cio-c/ https://blogs.gentoo.org/ago/2017/08/14/openjpeg-memory-allocation-failure-in-opj_aligned_alloc_n-opj_malloc-c/ https://blogs.gentoo.org/ago/2017/08/16/openjpeg-heap-based-buffer-overflow-in-opj_mqc_flush-mqc-c/ ======================== Updated packages in core/updates_testing: ======================== openjpeg2-2.2.0-1.1.mga5 libopenjp2_7-2.2.0-1.1.mga5 libopenjpeg2-devel-2.2.0-1.1.mga5 openjpeg2-2.2.0-1.1.mga6 libopenjp2_7-2.2.0-1.1.mga6 libopenjpeg2-devel-2.2.0-1.1.mga6 from SRPMS: openjpeg2-2.2.0-1.1.mga5.src.rpm openjpeg2-2.2.0-1.1.mga6.src.rpm
Summary: openjpeg2 - 3 security issues fixed => openjpeg2: 3 new security issues fixed upstreamQA Contact: (none) => securityWhiteboard: (none) => MGA5TOOComponent: RPM Packages => Security
CVE-2017-12982 has been assigned for the second issue.
Testing on mga6::x86_64 Downloaded the two PoC files and ran the recommended commands. The first problem was that the files could not be identified as valid input. Adding the bmp extension persuaded the utility to read the files but they were rejected at that stage. So it looks like the reproducers cannot be tested. Shall see what happens after the update. $ opj_compress -I -cinema4K -n 1 -i 00317-openjpeg-heapoverflow-opj_write_bytes_LE.bmp -o null.jp2 CINEMA 4K profile activated Other options specified could be overridden Error, not a BMP file! Unable to load bmp file $ opj_compress -n 1 -i 00317-openjpeg-heapoverflow-opj_write_bytes_LE.bmp -o null.j2c Error, not a BMP file! Unable to load bmp file $ opj_compress -n 1 -i 00315-openjpeg-memallocfailure-opj_aligned_alloc_n.bmp -o null.j2c Unable to load bmp file
CC: (none) => tarazed25
Apropos of comment 3: $ file *.bmp 00315-openjpeg-memallocfailure-opj_aligned_alloc_n.bmp: PC bitmap, Windows 95/NT4 and newer format, -385941503 x 26 x 0 00317-openjpeg-heapoverflow-opj_write_bytes_LE.bmp: data $ identify *.bmp identify: length and filesize do not match `00315-openjpeg-memallocfailure-opj_aligned_alloc_n.bmp' @ error/bmp.c/ReadBMPImage/825. identify: negative or zero image size `00315-openjpeg-memallocfailure-opj_aligned_alloc_n.bmp' @ error/bmp.c/ReadBMPImage/833. identify: improper image header `00317-openjpeg-heapoverflow-opj_write_bytes_LE.bmp' @ error/bmp.c/ReadBMPImage/606.
Repeated the tests of the PoC files after the update and saw the same failures to load the files so we cannot draw any conclusions. Meanwhile, putting the utilities through their paces... $ opj_compress -i balloon.pgm -o balloon.jp2 [INFO] tile number 1 / 1 [INFO] Generated outfile b $ opj_dump -i balloon.jp2 [INFO] Start to read j2k main header (85). [INFO] Main header has been correctly decoded. Image info { x0=0, y0=0 x1=2717, y1=3701 .............................. $ display balloon.jp2 worked fine. $ opj_compress -i balloon.pgm -o ballon.jp2 [INFO] tile number 1 / 1 [INFO] Generated outfile ballon.jp2 encode time: 1252 ms $ opj_decompress -i ballon.jp2 -o balloon.ppm [INFO] Start to read j2k main header (85). [INFO] Main header has been correctly decoded. [INFO] No decoded area parameters, set the decoded area to the whole image [INFO] Header of tile 1 / 1 has been read. [INFO] Stream reached its end ! [INFO] Generated Outfile balloon.ppm decode time: 622 ms $ opj_compress -i maple.tga -o maple.j2k [INFO] tile number 1 / 1 [INFO] Generated outfile maple.j2k encode time: 83 ms $ opj_dump -i piuva.jp2 [INFO] Start to read j2k main header (85). [INFO] Main header has been correctly decoded. Image info { x0=0, y0=0 ........................... type=0xff5d, pos=208, len=22 type=0xff5d, pos=230, len=22 } } $ opj_decompress -i squashedballoon.jp2 -o test.pnm [INFO] Start to read j2k main header (85). [INFO] Main header has been correctly decoded. [INFO] No decoded area parameters, set the decoded area to the whole image [INFO] Header of tile 1 / 1 has been read. [INFO] Stream reached its end ! [INFO] Generated Outfile test.pnm decode time: 1792 ms Output images all display correctly. It looks like the compress utility has trouble with BMP, PNG and TIFF as input formats. This behaviour had been observed before the updates also. $ opj_compress -i fatbot.tif -o fatbot.j2k Unable to load file: got no image $ file fatbot.tif fatbot.tif: TIFF image data, little-endian, direntries=18, height=32, bps=8, compression=deflate, PhotometricIntepretation=BlackIsZero, orientation=upper-left, width=32 $ identify fatbot.tif fatbot.tif TIFF 32x32 32x32+0+0 8-bit Grayscale Gray 904B 0.000u 0:00.000 PIA13706_fig1.tif is a 13MB TIFF image which displays without a problem using ImageMagick. $ opj_compress -i PIA13706_fig1.tif -o mars.j2k Unable to load file: got no image $ file PIA13706_fig1.tif PIA13706_fig1.tif: TIFF image data, little-endian, direntries=19, height=7051, bps=242, compression=LZW, PhotometricIntepretation=RGB, description=IDL TIFF file, width=8192 $ identify PIA13706_fig1.tif PIA13706_fig1.tif TIFF 8192x7051 8192x7051+0+0 8-bit sRGB 12.9884MiB 0.000u 0:00.000 Withholding the OK on this to allow other testers to check the software with their own specimen images. It may be that there are missing support packages on this system but that is a long shot given that ImageMagick can deal with the recalcitrant images perfectly well.
Re comment 2. 00315-openjpeg-memallocfailure-opj_aligned_alloc_n goes with CVE-2017-12982.
MGA5-32 on Asus A6000VM Xfce No installation issues. Less than satisfying results. At CLI: $ opj_compress -i 1973.pnm -o 1973.j2k [INFO] tile number 1 / 1 [INFO] Generated outfile 1973.j2k encode time: 10998 ms The resulting file is 8.7Mb vs the original 36.7Mb, but the j2k opens allright in Gimp, but throws an error in ristretto"could not allocate memory for stream". Up to now had never problems with ristretto. Tried two tif files which show OK in ristretto: $ opj_compress -i 001.tif -o 001.j2k Unable to load file: got no image and $ opj_compress -i 1973-024.tif -o 1973-024.j2k Unable to load file: got no image I get the feeling that this program does not perform very well, but under the circumstances we cannot get rid of it, so we might as well accept the new version. Just my 2c.
CC: (none) => herman.viaene
You are probably right Herman. Since these failures are not demonstrably the fault of the patches maybe we should just pass it and raise another bug on the deficiencies. Adding the feedback marker to see if other parties agree. Thanks
Whiteboard: MGA5TOO => MGA5TOO feedback
If these are not regressions, a new bug report seems reasonable. I would guess that this package is mainly used for decoding jpeg images and that the tools are lightly used, but I suppose these issues could be limiting the functionality of programs using this library.
Whiteboard: MGA5TOO feedback => MGA5TOO
Please do check that the issues aren't regressions if you haven't yet. We not only patched it but also upgraded it to 2.2.0.
There may actually be more security fixes in 2.2.0 itself that we didn't know about: http://openwall.com/lists/oss-security/2017/08/22/1
Looking at the TIFFs on mga5 before the update and it does appear that the package already had a problem reading TIFF files which are correctly interpreted by identify. The compress utility is also a bit pernickety about extensions - it does not like .tiff. It ought to use the magic number rather than the extension. Seems a bit un-UNIX-like. Not our problem. So no regression in mga5. Shall have a closer look at all this tomorrow/today.
Apropos file extensions; the man page lists acceptable extensions, not types, so they must be important, perhaps as a way to promote OS independence.
<noise> And of course the type of the output file is determined from the output file extension. </noise>
Tested opj_compress on mga6 before the update and found the same problem; not able to convert TIFF files. This applies to both little-endian and big-endian files (as reported by file). Thus, no regression for TIFF files, which does make this a candidate for upstream debugging. lib64tiff5-4.0.8-3.mga6 is installed. The fault applies to PNG files as well. Not sure how closely related that is because libpng is required and that is not linked to this update. lib64png16_16-1.6.29-1.mga6 lib64png12_0-1.2.57-2.mga6 are installed. No, I don't really think that the libraries have anything to do with it. Managed to convert a couple of BMP icons to J2K format, so these need to be double-checked after the update.
Done that. BMP is OK after the update. So we should push this one along. And when I have time (?) there will be a bug report for upstream.
Whiteboard: MGA5TOO => MGA5TOO MGA6-64-OK
Testing this on mga5::x86_64 Running the PoC files against opj_compress after the updates gave the same results as before - could not load bmp file. $ opj_compress -i balloon.pgm -o balloon.jp2 [INFO] tile number 1 / 1 [INFO] Generated outfile balloon.jp2 encode time: 949 ms $ opj_compress -i maple.tga -o maple.j2k [INFO] tile number 1 / 1 [INFO] Generated outfile maple.j2k encode time: 56 ms Test conversions on other types of file worked fine and in all cases the resultant files displayed as the correct images. $ opj_dump -i piuva.jp2 Standard dump of the structure of the image file - OK. $ opj_decompress -i squashedballoon.jp2 -o test.pnm [INFO] Start to read j2k main header (85). [INFO] Main header has been correctly decoded. [INFO] No decoded area parameters, set the decoded area to the whole image [INFO] Header of tile 1 / 1 has been read. [INFO] Stream reached its end ! [INFO] Generated Outfile test.pnm decode time: 1454 ms test.pnm displayed perfectly. TIFF files seem to be invisible. $ opj_compress -i tag.tif -o test.j2k Unable to load file: got no image $ opj_compress -i fig1.tif -o fig1.j2k Unable to load file: got no image $ file fig1.tif fig1.tif: TIFF image data, little-endian The same is true of PNG. $ opj_compress -i relax-orig.png -o relax.jp2 Unable to load file: got no image BMP files are OK. $ opj_compress -i piuva.bmp -o piuva.j2k [INFO] tile number 1 / 1 [INFO] Generated outfile piuva.j2k encode time: 1 ms So the updated openjpeg2 is good in parts. Giving this an OK on the understanding that the failures are reported on a new bug.
Whiteboard: MGA5TOO MGA6-64-OK => MGA5TOO MGA6-64-OK MGA5-64-OK
Sterling work again Len. Advisory from Comment 1. Validating as it has a good OK for each architecture. I seem to remember that this package duplicates functionality of another JPEG 2000 one.
Whiteboard: MGA5TOO MGA6-64-OK MGA5-64-OK => MGA5TOO MGA6-64-OK MGA5-64-OK advisoryKeywords: (none) => validated_updateCC: (none) => lewyssmith, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2017-0299.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
CVE-2016-1050[4-7] fixed in 2.2.0, which we updated to with this update: http://www.openwall.com/lists/oss-security/2017/08/30/2
CC: (none) => luigiwalser
CVE-2016-1626, CVE-2016-1628, CVE-2016-5152 also fixed in 2.2.0: https://www.debian.org/security/2017/dsa-4013
One of the patches added post-2.2.0 in this update fixed CVE-2017-12982.
The other two patches fixed CVE-2017-1415[12].