Bug 28851 - openjpeg2 new security issue CVE-2021-29338
Summary: openjpeg2 new security issue CVE-2021-29338
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 8
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: David GEIGER
QA Contact: Sec team
URL:
Whiteboard: MGA7TOO
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-28 16:38 CEST by David Walser
Modified: 2021-05-10 17:33 CEST (History)
5 users (show)

See Also:
Source RPM: mingw-openjpeg2-2.4.0-1.mga8.src.rpm
CVE: CVE-2021-29338
Status comment:


Attachments

Description David Walser 2021-04-28 16:38:30 CEST
A security issue has been fixed upstream in openjpeg2:
https://github.com/uclouvain/openjpeg/commit/b4700bc09d55ac17ff6bef9b0a867f6de527be17.patch

Hopefully there's details somewhere.

Mageia 7 and Mageia 8 are also affected.
David Walser 2021-04-28 16:38:42 CEST

Status comment: (none) => Patch available from upstream
Whiteboard: (none) => MGA8TOO, MGA7TOO

Comment 1 Lewis Smith 2021-04-28 20:04:25 CEST
Assigning to DavidG, the current active maintainer.

Assignee: bugsquad => geiger.david68210

Comment 2 David GEIGER 2021-04-29 07:27:47 CEST
Done for Cauldron, mga8 and mga7!
Comment 3 Nicolas Lécureuil 2021-05-01 15:39:59 CEST
assigning to QA

Whiteboard: MGA8TOO, MGA7TOO => MGA7TOO
Version: Cauldron => 8
CC: (none) => mageia
Assignee: geiger.david68210 => qa-bugs

Comment 4 David Walser 2021-05-03 01:06:25 CEST
Apparently this issue only affects the opj2_compress program, and not the library itself:
https://bugzilla.redhat.com/show_bug.cgi?id=1950101

It doesn't appear that we actually even package this program.
Comment 5 Len Lawrence 2021-05-03 17:30:49 CEST
mga8, x64

Referring to the package list from bug 27986, installed three files from Core Release.

Thanks David for the link. 
CVE-2021-29338
The PoC test is intended to be run in conjunction with asan.
Created directories testcase and outcase and ran the shell script to populate testcase with 1048576 invalid BMP files.  That took a while, like 3 hours.
$ ./loop_file.sh
$ opj_compress -ImgDir testcase -OutFor outcase/test.jp2
Folder opened successfully
Segmentation fault (core dumped)

The asan upstream test triggered an ABORT.

Enabled Core Updates Testing and installed the three packages.
$ rpm -qa | grep openjp
lib64openjpeg2-devel-2.4.0-1.1.mga8
lib64openjp2_7-2.4.0-1.1.mga8
openjpeg2-2.4.0-1.1.mga8

$ opj_compress -ImgDir testcase -OutFor outcase/test.jp2
Folder opened successfully
File Number 0 "os2-invalid-bpp_1.bmp"
Unable to load bmp file
$
A clean exit but it fails as might be expected on the first invalid file so it is not clear what this demonstrates.  It would help towards an advisory if there were a clearer exposition of what exactly is being fixed.  There is an indication that replacing malloc by calloc restricts the number of files to 10.  That being so we could simply test that restriction.

Copied 11 bitmap icons into directory newcase.
$ opj_compress -ImgDir newcase -OutFor outcase/test.jp2
Folder opened successfully
File Number 0 "arraydemo.bmp"

Directory outcase remains empty.
Removed one file from newcase.
$ opj_compress -ImgDir newcase -OutFor outcase/test.jp2
Folder opened successfully
File Number 0 "arraydemo.bmp"

Directory outcase remains empty.

Reserving judgement on this one.  Meanwhile,
$ opj_compress -i liquid.bmp -o liquid.jp2
Other system than 24 bits/pixels or 8 bits (no RLE coding) is not yet implemented [4]
Unable to load bmp file

Trying another image format:
$ opj_compress -i mandrill.pgm -o test.jp2
[INFO] tile number 1 / 1
[INFO] Generated outfile test.jp2
encode time: 29 ms 

Tried several different TIFF files but all failed to convert.  There are many optional parameters and switches for this command but -i and -o are clear enough. 
$ opj_compress -i macbeth_rgba.tif -o macbeth.jp2
Unable to load file: got no image

$ opj_compress -i RAW_FUJI_X-T10.raw -o raw.jp2 -F 512,512,3,8,u
 Warning. End of raw file not reached... processing anyway
[INFO] tile number 1 / 1
[INFO] Generated outfile raw.jp2
encode time: 204 ms 

This file had a RAF extension originally, which displays perfectly using nomacs but ImageMagick does not make much sense of raw.jp2.

It is hard to tell if there are any regressions with this command.  As has been noted before, openjpeg2 appears to be a project still in development but could be useful to users who understand the command parameters.  Taking a back seat on this - let others decide whether to release it.

CC: (none) => tarazed25

Comment 6 Len Lawrence 2021-05-07 08:27:48 CEST
As there are no comments against giving this an OK so be it.

Whiteboard: MGA7TOO => MGA7TOO MGA8-64-OK

Comment 7 Thomas Andrews 2021-05-08 17:21:56 CEST
MGA7-64 Plasma guest in VirtualBox.

The library was already installed, as was imagemagick, so I installed openjpeg2_7 and then used qarepo to update them. No installation issues.

Downloaded a sample .jp2 file, then displayed it with imagemagick. No issues. Since this is the same version as for MGA8, I'm calling that good enough for MGA7, too.

Validating.

Whiteboard: MGA7TOO MGA8-64-OK => MGA7TOO MGA7-64-OK MGA8-64-OK
CC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => validated_update

Comment 8 Aurelien Oudelet 2021-05-10 11:17:43 CEST
Advisory:
========================

There is a flaw in the opj2_compress program in openjpeg2. An attacker who is able to submit a large number of image files to be processed in a directory by opj2_compress, could trigger a heap out-of-bounds write due to an integer overflow, which is caused by the large number of image files. The greatest threat posed by this flaw is to confidentiality, integrity, and availability.
Statement

This flaw affects the opj2_compress utility but is not in the openjpeg2 library. Therefore, the attack vector is local to the opj2_compress utility and would require an attacker to convince a user to open a directory with an extremely large number of files using opj2_compress, or a script to be feeding such arbitrary, untrusted files to opj2_compress (CVE-2021-29338).

references:
- https://github.com/uclouvain/openjpeg/commit/b4700bc09d55ac17ff6bef9b0a867f6de527be17.patch
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29338
- https://access.redhat.com/security/cve/CVE-2021-29338
- https://bugzilla.redhat.com/show_bug.cgi?id=1950101
========================

(In reply to David Walser from comment #4)
> Apparently this issue only affects the opj2_compress program, and not the
> library itself:
> https://bugzilla.redhat.com/show_bug.cgi?id=1950101
> 
> It doesn't appear that we actually even package this program.

Yes, in facts, we do provide opj2_compress tool in these packages:

$ urpmf -f opj2_compress       
mingw64-openjpeg2-tools-2.4.0-1.mga8.noarch
mingw32-openjpeg2-tools-2.4.0-1.mga8.noarch

from SRPM: mingw-openjpeg2-2.4.0-1.mga8.src.rpm

This bug report does not provide updated package for this SRPM in 8/SRPMS/core/updates_testing/

Rejecting sorry.

Assigning back to committer with corrected SRPM.

Whiteboard: MGA7TOO MGA7-64-OK MGA8-64-OK => MGA7TOO
CC: (none) => ouaurelien
Assignee: qa-bugs => geiger.david68210
CVE: (none) => CVE-2021-29338
Status comment: Patch available from upstream => (none)
Keywords: validated_update => (none)
Source RPM: openjpeg2 => mingw-openjpeg2-2.4.0-1.mga8.src.rpm

Comment 9 Aurelien Oudelet 2021-05-10 13:02:39 CEST
Hum, we DO have this:

$ urpmf openjpeg2
openjpeg2:/usr/bin/opj_compress
openjpeg2:/usr/bin/opj_decompress
openjpeg2:/usr/bin/opj_dump
openjpeg2:/usr/lib/.build-id
openjpeg2:/usr/lib/.build-id/27
openjpeg2:/usr/lib/.build-id/27/71b5b96ca0789401aa43daa75fcb67b5d1d465
openjpeg2:/usr/lib/.build-id/e0
openjpeg2:/usr/lib/.build-id/e0/42332d4720b382639ba6acfd3d409f1103fbee
openjpeg2:/usr/lib/.build-id/e5
openjpeg2:/usr/lib/.build-id/e5/33792075160a0b24e18c57ffda209687cce69e
openjpeg2:/usr/share/doc/openjpeg2
<snip>

Note that it is named 'opj_compress' on Linux and 'opj2_compress' in the mingw-openjpeg2 RPM.

So, basically, is this possibly a mistake naming for the Linux binary?

Can packager tell us about this: opj_compress = opj2_compress?


I do think mingw-openjpeg2 should be patched also.

Meanwhile, openjpeg2 is patched in 8/SRPMS/core/updates_testing/openjpeg2-2.4.0-1.1.mga8.src.rpm and packages list is:

Preliminary updated packages from 8/core/updates_testing:
========================
lib(64)openjp2_7-2.4.0-1.1.mga8
lib(64)openjpeg2-devel-2.4.0-1.1.mga8
openjpeg2-2.4.0-1.1.mga8

from SRPM:
========================
openjpeg2-2.4.0-1.1.mga8.src.rpm



For Mageia 7.1:

Preliminary updated packages from 7/core/updates_testing:
========================
lib(64)openjp2_7-2.4.0-1.1.mga7
lib(64)openjpeg2-devel-2.4.0-1.1.mga7
openjpeg2-2.4.0-1.1.mga7

from SRPM:
========================
openjpeg2-2.4.0-1.1.mga7.src.rpm
Comment 10 Len Lawrence 2021-05-10 17:19:13 CEST
The advisory in comment 8 does make it clearer what the actual problem is.
The fact that the directory containing one million files is opened successfully before and after the update would indicate that the patch has not fixed the issue for Mageia 8.  Our stdlib does contain calloc and strings finds it in the binary.
$ grep calloc /usr/include/stdlib.h
extern void *calloc (size_t __nmemb, size_t __size)

It looks like the range of file types it supports can be successfully compressed by the utility so my advice would be to let it go and let upstream know that it is still vulnerable.
Comment 11 Len Lawrence 2021-05-10 17:33:52 CEST
Continuing comment 10....
Unless, noting Aurelien's distinction between opj_compress and opj2_compress, it affects only the latter.  In which case we do need to patch the mingw2 version and test that.

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