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.
Status comment: (none) => Patch available from upstreamWhiteboard: (none) => MGA8TOO, MGA7TOO
Assigning to DavidG, the current active maintainer.
Assignee: bugsquad => geiger.david68210
Done for Cauldron, mga8 and mga7!
assigning to QA
CC: (none) => mageiaWhiteboard: MGA8TOO, MGA7TOO => MGA7TOOVersion: Cauldron => 8Assignee: geiger.david68210 => qa-bugs
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.
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
As there are no comments against giving this an OK so be it.
Whiteboard: MGA7TOO => MGA7TOO MGA8-64-OK
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-OKKeywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
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.
CC: (none) => ouaurelienWhiteboard: MGA7TOO MGA7-64-OK MGA8-64-OK => MGA7TOOSource RPM: openjpeg2 => mingw-openjpeg2-2.4.0-1.mga8.src.rpmKeywords: validated_update => (none)Status comment: Patch available from upstream => (none)CVE: (none) => CVE-2021-29338Assignee: qa-bugs => geiger.david68210
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
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.
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.
Done for Cauldron, mga8 and mga7! mingw-openjpeg2-2.4.0-2.mga9 mingw-openjpeg2-2.4.0-1.1.mga8 mingw-openjpeg2-2.4.0-1.mga7
Assignee: geiger.david68210 => qa-bugs
Full RPMs list for mingw-openjpeg2 (SRPMS in Comment 12): mingw32-openjpeg2-2.4.0-1.mga7 mingw32-openjpeg2-tools-2.4.0-1.mga7 mingw64-openjpeg2-2.4.0-1.mga7 mingw64-openjpeg2-tools-2.4.0-1.mga7 mingw32-openjpeg2-2.4.0-1.1.mga8 mingw32-openjpeg2-tools-2.4.0-1.1.mga8 mingw64-openjpeg2-tools-2.4.0-1.1.mga8 mingw64-openjpeg2-2.4.0-1.1.mga8
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 ======================== 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 mingw32-openjpeg2-2.4.0-1.1.mga8 mingw32-openjpeg2-tools-2.4.0-1.1.mga8 mingw64-openjpeg2-tools-2.4.0-1.1.mga8 mingw64-openjpeg2-2.4.0-1.1.mga8 from SRPM: ======================== openjpeg2-2.4.0-1.1.mga8 mingw-openjpeg2-2.4.0-1.1.mga8 For Mageia 7.1: 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 mingw32-openjpeg2-2.4.0-1.mga7 mingw32-openjpeg2-tools-2.4.0-1.mga7 mingw64-openjpeg2-2.4.0-1.mga7 mingw64-openjpeg2-tools-2.4.0-1.mga7 from SRPM: ======================== openjpeg2-2.4.0-1.1.mga7 mingw-openjpeg2-2.4.0-1.mga7 Validating.
Keywords: (none) => advisory, validated_updateWhiteboard: MGA7TOO => MGA7TOO MGA7-64-OK MGA8-64-OK
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0216.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
Source RPM: mingw-openjpeg2-2.4.0-1.mga8.src.rpm => openjpeg2-2.4.0-1.mga8.src.rpm