openSUSE has issued an advisory on May 23: https://lists.opensuse.org/opensuse-updates/2018-05/msg00086.html Mageia 5 and Mageia 6 are also affected.
Whiteboard: (none) => MGA6TOO
Assigning to the registered maintainer.
CC: (none) => marja11Assignee: bugsquad => rverschelde
Fedora has issued an advisory on October 8: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/HKAGXKPJ2Z4TMUR3TVLTQ7SMTTIYGJKK/ It fixes one new security issue.
Summary: openjpeg2 new security issues CVE-2015-1239, CVE-2017-17479, and CVE-2017-17480 => openjpeg2 new security issues CVE-2015-1239, CVE-2017-17479, CVE-2017-17480, CVE-2018-5785
Fedora has issued an advisory on December 24: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/JAZ5ZQP5XJ23SE3ECBP4QQF2CGMK6USD/ It fixes two new issues.
Summary: openjpeg2 new security issues CVE-2015-1239, CVE-2017-17479, CVE-2017-17480, CVE-2018-5785 => openjpeg2 new security issues CVE-2015-1239, CVE-2017-17479, CVE-2017-17480, CVE-2018-5785, CVE-2018-6616, CVE-2018-18088
2.3.0 came well after the commit for CVE-2015-1239: https://github.com/uclouvain/openjpeg/commit/2d24b6000d5611615e3e6d799e20d5fdbe4e2a1e CVE-2017-17479 and CVE-2017-17480 fixes are included in CVE-2018-18088.patch from Fedora. Latest Fedora patches included in openjpeg2-2.3.0-3.mga7 for Cauldron.
Version: Cauldron => 6Whiteboard: MGA6TOO => (none)
CVE-2015-1239 commit also predates 2.2.0 in Mageia 6. Advisory: ======================== Updated openjpeg2 packages fix security vulnerabilities: A stack-based buffer overflow in the pgxtoimage function in jpwl/convert.c could crash the converter (CVE-2017-17479). A stack-based buffer overflow in the pgxtovolume function in jp3d/convert.c could crash the converter (CVE-2017-17480). A flaw was found in OpenJPEG 2.3.0, there is an integer overflow caused by an out-of-bounds left shift in the opj_j2k_setup_encoder function (openjp2/j2k.c). Remote attackers could leverage this vulnerability to cause a denial of service via a crafted bmp file (CVE-2018-5785). In OpenJPEG 2.3.0, there is excessive iteration in the opj_t1_encode_cblks function of openjp2/t1.c. Attackers could leverage this vulnerability to cause a denial of service via a crafted bmp file (CVE-2018-6616). A flaw was found in OpenJPEG 2.3.0. A NULL pointer dereference for "red" in the imagetopnm function of jp2/convert.c (CVE-2018-18088). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17479 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17480 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5785 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6616 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18088 https://lists.opensuse.org/opensuse-updates/2018-05/msg00086.html https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/HKAGXKPJ2Z4TMUR3TVLTQ7SMTTIYGJKK/ https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/JAZ5ZQP5XJ23SE3ECBP4QQF2CGMK6USD/ ======================== Updated packages in core/updates_testing: ======================== openjpeg2-2.2.0-1.3.mga6 libopenjp2_7-2.2.0-1.3.mga6 libopenjpeg2-devel-2.2.0-1.3.mga6 from openjpeg2-2.2.0-1.3.mga6.src.rpm
Assignee: rverschelde => qa-bugsSummary: openjpeg2 new security issues CVE-2015-1239, CVE-2017-17479, CVE-2017-17480, CVE-2018-5785, CVE-2018-6616, CVE-2018-18088 => openjpeg2 new security issues CVE-2017-17479, CVE-2017-17480, CVE-2018-5785, CVE-2018-6616, CVE-2018-18088
Mageia 6, x86_64 CVE-2017-17479 No reproducer CVE-2017-17480 No PoC found CVE-2018-5785 https://github.com/ProbeFuzzer/poc/blob/master/openjpeg/openjpeg_2-3_opj_compress_integer-overflow_opj_j2k_setup_encoder.bmp $ opj_compress -n 1 -i $POC -o OUTPUT CVE-2018-6616 https://github.com/ProbeFuzzer/poc/blob/master/openjpeg/openjpeg_2-3_opj_compress_excessive-iteration_opj_t1_encode_cblks.bmp $ opj_compress -n 1 -i $POC -o /tmp/null.j2k CVE-2018-18088 A PoC file can be requested by email. See https://github.com/uclouvain/openjpeg/issues/1152 There is what looks like an interactive test which precipitates a segfault. It uses the pwndbg tool. ------------------------------------------------------------------------------- *Before update* CVE-2018-5785 $ opj_compress -n 1 -i openjpeg_2-3_opj_compress_integer-overflow_opj_j2k_setup_encoder.bmp -o test.j2k [INFO] tile number 1 / 1 [INFO] Generated outfile test.j2k encode time: 0 ms $ file test.j2k test.j2k: JPEG 2000 codestream < No problems, so it may have been fixed earlier > CVE-2018-6616 $ opj_compress -n 1 -i openjpeg_2-3_opj_compress_excessive-iteration_opj_t1_encode_cblks.bmp -o /tmp/null.j2k [INFO] tile number 1 / 1 [INFO] Generated outfile /tmp/null.j2k encode time: 30876 ms < This may be OK although the source file is only 144 bytes in size > ------------------------------------------------------------------------------- *After update* CVE-2018-5785 Same output as before. CVE-2018-6616 $ opj_compress -n 1 -i openjpeg_2-3_opj_compress_excessive-iteration_opj_t1_encode_cblks.bmp -o /tmp/null.j2k warning, image's actual size does not match advertized one Unable to load bmp file That looks like a good result - issue fixed with this release. Utility tests later.
CC: (none) => tarazed25
Image file tests. IM display to render output images. $ opj_compress -i jessica.pnm -o jessica.jp2 [INFO] tile number 1 / 1 [INFO] Generated outfile jessica.jp2 encode time: 69 ms $ display jessica.jp2 !good $ opj_dump -i lochavon.jp2 [INFO] Start to read j2k main header (85). [INFO] Main header has been correctly decoded. Image info { x0=0, y0=0 x1=1331, y1=998 numcomps=3 [...] !good $ opj_decompress -i piuva.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: 25 ms good Could find only one targa image on this system. It does not seem to be acceptable. $ opj_compress -i hori.tga -o spectrum.j2k Sorry, compressed tga files are not currently supported. Unable to load tga file !bad ? $ convert hori.tga hori.png $ opj_compress -i hori.png -o spectrum.jp2 Unable to load file: got no image !? Imported a targa image from another machine. $ opj_compress -i maple.tga -o maple.jp2 [INFO] tile number 1 / 1 [INFO] Generated outfile maple.jp2 encode time: 74 ms !good but it seems not all targa images are equal. $ opj_compress -i macbethcolourscan.tif -o macbeth.jp2 Unable to load file: got no image $ opj_compress -i ikapati.png -o ikapati.jp2 Unable to load file: got no image $ opj_compress -i cmyk.pnm -o cmyk.jp2 read_pnm_header:PNM:magic P missing Unable to load pnm file Some images produce: Known file formats are *.pnm, *.pgm, *.ppm, *.pgx, *png, *.bmp, *.tif, *.raw or *.tga after an error. It may be that input formats need to be "well-behaved" and can cause problems if the headers do not match the templates precisely. That is a pure guess. $ opj_dump -i ikapati.png [ERROR] Unknown input file format: ikapati.png Known file formats are *.j2k, *.jp2, *.jpc or *.jpt $ file ikapati.png ikapati.png: PNG image data, 1229 x 819, 8-bit grayscale, non-interlaced So dump supports only the openjpeg2 formats. Fair enough. $ hexdump maple.tga | head -6 0000000 0000 0002 0000 0000 0000 0000 0200 0200 0000010 0820 7814 00ec 7814 00ec 7814 00ec 7814 0000020 00ec 7814 00ec 7814 00ec 7814 00ec 7814 * 0026200 00ec 7814 00ec 7814 00ec 9c1e ffe7 7814 0026210 00ec 7814 00ec 7814 00ec 7814 00ec 7814 $ hexdump hori.tga | head -6 0000000 0000 000a 0000 0000 0000 0000 0052 000c 0000010 2018 dfd1 dfdb df00 dfdb 0089 0000 ff88 0000020 ffff 0000 0000 0088 ff00 0000 0000 0088 0000030 00ff 0000 0000 ff88 0000 0000 0000 ff88 0000040 00ff 0000 0000 ff88 ff00 0000 0000 0088 0000050 ffff 0001 0000 dbdf 00df dbdf 89df 0000 So if the input files use different magic numbers we can expect trouble. Can't blame openjpeg2 for the data. Giving this an OK.
Whiteboard: (none) => MGA6-64-OK
Further to the diagnoses in comment 7, http://www.paulbourke.net/dataformats/tga/ provides information on the targa specification which vindicates openjpeg2. <quote> All Targa formats are identified by a Data Type field, which is a one byte binary integer located in byte three of the file. These data types are: 0 - No image data included. 1 - Uncompressed, color-mapped images. 2 - Uncompressed, RGB images. 3 - Uncompressed, black and white images. 9 - Runlength encoded color-mapped images. 10 - Runlength encoded RGB images. 11 - Compressed, black and white images. 32 - Compressed color-mapped data, using Huffman, Delta, and runlength encoding. 33 - Compressed color-mapped data, using Huffman, Delta, and runlength encoding. 4-pass quadtree-type process. </unquote> The compression utility expects uncompressed data. It was correct in accepting maple.tga with a magicnumber 2 == uncompressed RGB. hori,tga with 10 means RLE encoded aka compressed so it was bound to fail. Some of the other failures may be contingent with this conclusion.
Sorry. s/contingent with this conclusion/contingent on similar factors/.
Keywords: (none) => advisory, validated_updateCC: (none) => lewyssmith, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2019-0004.html
Status: NEW => RESOLVEDResolution: (none) => FIXED