Bug 24511 - openjpeg2 new security issue CVE-2018-14423
Summary: openjpeg2 new security issue CVE-2018-14423
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
Whiteboard: MGA6-64-OK
Keywords: advisory, validated_update
Depends on:
Reported: 2019-03-13 19:58 CET by David Walser
Modified: 2019-03-29 16:52 CET (History)
7 users (show)

See Also:
Source RPM: openjpeg2-2.3.0-3.mga7.src.rpm
Status comment:


Description David Walser 2019-03-13 19:58:13 CET
Debian has issued an advisory on March 10:

We fixed the other issues in Bug 23147.

Mageia 6 is also affected.
David Walser 2019-03-13 19:58:21 CET

Whiteboard: (none) => MGA6TOO
Severity: normal => major

Comment 1 Marja Van Waes 2019-03-14 16:14:27 CET
Assigning to all packagers collectively, since there is no registered maintainer for this package.

CC'ing two submitters.

CC: (none) => geiger.david68210, marja11, nicolas.salguero
Assignee: bugsquad => pkg-bugs

Comment 2 David GEIGER 2019-03-14 16:42:44 CET
Fixed both mga6 and Cauldron!
Comment 3 David Walser 2019-03-16 16:47:22 CET

Updated openjpeg2 packages fix security vulnerability:

Division-by-zero vulnerabilities in the functions pi_next_pcrl, pi_next_cprl,
and pi_next_rpcl in lib/openjp3d/pi.c in OpenJPEG through 2.3.0 allow remote
attackers to cause a denial of service (CVE-2018-14423).


Updated packages in core/updates_testing:

from openjpeg2-2.2.0-1.4.mga6.src.rpm

Assignee: pkg-bugs => qa-bugs
Version: Cauldron => 6
Whiteboard: MGA6TOO => (none)

Comment 4 Herman Viaene 2019-03-17 10:56:14 CET
MGA6-32 MATE on IBM Thinkpad R50e
No installation issues.
Tried opj_compress command, but whatever I throw at it I allways get:
$ opj_compress -i  gray1.tif  -o gray1.jp2

Unable to load file: got no image
Files I used were tif from Olympus E500 camera and png and tif files converted from jpegs in previous update tests.

CC: (none) => herman.viaene

Comment 5 Len Lawrence 2019-03-17 12:16:26 CET
mga6, x86_64

No POC found for CVE-2018-14423.

The previous versions were already installed.  Ran the update.
- lib64openjp2_7-2.2.0-1.4.mga6.x86_64
- lib64openjpeg2-devel-2.2.0-1.4.mga6.x86_64
- openjpeg2-2.2.0-1.4.mga6.x86_64

Used the compress and decompress utilities to test the packages.
Input image formats supported are listed in the help for opj_compress as:
Output formats are J2K|J2C|JP2.

opj_compress fails to read PNG files as input.  Some formats can be processed and can be examined using ImageMagick display.
$ opj_compress -i jessica.pnm -o jessica.jp2
[INFO] tile number 1 / 1
[INFO] Generated outfile jessica.jp2
encode time: 63 ms 

Other formats also fail.
$ opj_compress -i hori.tga -o spectrum.j2k
Sorry, compressed tga files are not currently supported.
Unable to load tga file
$ opj_compress -i lena_color.tif -o lena.jp2
Unable to load file: got no image
These sorts of problems have been encountered before with this package.  PNG files in particular can be generated in various forms and that probably also applies to the other input types which fail.  It seems that only particular species of designated formats are acceptable.  One needs check the image headers against to the original specifications for those file formats to see if images fit the openjpeg2 rules.

In the current tests failures will be silently ignored.  AFAIKS the various fine-grained command-line options apply to the output only.  Nothing comparable for input except for RAW* files where the characteristics of the image need to be described.

$ opj_dump -i jessica.jp2
[INFO] Start to read j2k main header (85).
[INFO] Main header has been correctly decoded.
Image info {
	 x0=0, y0=0
	 x1=600, y1=448
Codestream index from main header: {
	 Main header start position=85
	 Main header end position=210
	 Marker list: {
		 type=0xff4f, pos=85, len=2

$ opj_compress -i Ikapati.pgm -o Ikapati.jp2
[INFO] tile number 1 / 1
[INFO] Generated outfile Ikapati.jp2
encode time: 55 ms 
$ display Ikapati.jp2

$ opj_compress -i maple.tga -o maple.jp2
[INFO] tile number 1 / 1
[INFO] Generated outfile maple.jp2
encode time: 68 ms 
$ display maple.jp2
!A maple leaf on transparent background.

$ opj_compress -i cmyk.pnm -o cmyk.jp2
read_pnm_header:PNM:magic P missing
Unable to load pnm file
! That seems to fit in with what was said earlier.

$ opj_decompress -i jessica.jp2 -o jessica.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 jessica.pnm
decode time: 37 ms
$ display jessica.pnm

$ opj_decompress -i piuva.jp2 -o piuva.pgx
[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 piuva.pgx
decode time: 34 ms
!Could not display this.  Tried nomacs; did not work.

$ opj_decompress -i lochavon.jp2 -o lochavon.bmp
[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 lochavon.bmp
decode time: 337 ms
$ display lochavon.bmp

$ opj_decompress -i piuva.jp2 -o piuva.ppm
[INFO] Start to read j2k main header (85).
[INFO] Generated Outfile piuva.ppm
decode time: 22 ms
$ display piuva.ppm

Passing this as OK for 64-bits on the basis of the successful operations and on the assumption that those that failed did so because the test images did not fit the OpenJPEG template.  A package for experts.

CC: (none) => tarazed25

Comment 6 Len Lawrence 2019-03-17 12:23:37 CET
Note for Herman, re comment 4:
Yeah, this is a difficult one to test because as I say it is definitely one for the experts.  On a previous bug I researched the PNG format and discovered that there are several levels of compression, which result in different magic numbers.
I would guess that PNG files need to be in the rawest state to be valid for openjpeg, uncompressed maybe.  It is all speculation though.
Len Lawrence 2019-03-18 16:41:11 CET

Whiteboard: (none) => MGA6-64-OK

Comment 7 Len Lawrence 2019-03-21 22:07:13 CET
@Herman: are you abandoning the 32-bit tests?  If so I shall go ahead and validate.
Comment 8 Herman Viaene 2019-03-22 08:37:56 CET
@ Len,
I have no idea why my tests fail, and the files I use open without problems in ristretto and gimp etc..... So, I will not object if your tests are OK, go on.
Comment 9 Len Lawrence 2019-03-22 10:17:52 CET
Thanks Herman.  Letting it go.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Thomas Backlund 2019-03-29 16:10:18 CET

Keywords: (none) => advisory
CC: (none) => tmb

Comment 10 Mageia Robot 2019-03-29 16:52:12 CET
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.