Bug 23147

Assigning to the registered maintainer.

CC: (none) => marja11
Assignee: 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 => 6
Whiteboard: 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-bugs
Summary: 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/.

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2019-0004.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED