| Summary: | openjpeg2 new security issue CVE-2018-14423 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | David Walser <luigiwalser> |
| Component: | Security | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Sec team <security> |
| Severity: | major | ||
| Priority: | Normal | CC: | geiger.david68210, herman.viaene, marja11, nicolas.salguero, sysadmin-bugs, tarazed25, tmb |
| Version: | 6 | Keywords: | advisory, validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | MGA6-64-OK | ||
| Source RPM: | openjpeg2-2.3.0-3.mga7.src.rpm | CVE: | |
| Status comment: | |||
|
Description
David Walser
2019-03-13 19:58:13 CET
David Walser
2019-03-13 19:58:21 CET
Whiteboard:
(none) =>
MGA6TOO 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 Fixed both mga6 and Cauldron! Advisory: ======================== 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). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14423 https://www.debian.org/security/2019/dsa-4405 ======================== Updated packages in core/updates_testing: ======================== openjpeg2-2.2.0-1.4.mga6 lib64openjp2_7-2.2.0-1.4.mga6 lib64openjpeg2-devel-2.2.0-1.4.mga6 from openjpeg2-2.2.0-1.4.mga6.src.rpm Assignee:
pkg-bugs =>
qa-bugs 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 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:
PBM|PGM|PPM|PNM|PAM|PGX|PNG|BMP|TIF|RAW|RAWL|TGA.
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
!OK
$ 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
!OK
$ 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
!OK
$ 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
!OK
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 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 @Herman: are you abandoning the 32-bit tests? If so I shall go ahead and validate. @ 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. Thanks Herman. Letting it go. Keywords:
(none) =>
validated_update
Thomas Backlund
2019-03-29 16:10:18 CET
Keywords:
(none) =>
advisory An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2019-0119.html Resolution:
(none) =>
FIXED |