Ubuntu has issued an advisory today (April 27): https://usn.ubuntu.com/4339-1/ The issues are fixed upstream in 2.4.1. Mageia 7 is also affected.
Status comment: (none) => Fixed upstream in 2.4.1Whiteboard: (none) => MGA7TOO
In the absence of a registered or evident maintainer, no choice but to assign this globally.
Assignee: bugsquad => pkg-bugs
Suggested advisory: ======================== The updated packages fix security vulnerabilities: An issue was discovered in OpenEXR before 2.4.1. There is an out-of-bounds read in ImfOptimizedPixelReading.h. (CVE-2020-11758) An issue was discovered in OpenEXR before 2.4.1. Because of integer overflows in CompositeDeepScanLine::Data::handleDeepFrameBuffer and readSampleCountForLineBlock, an attacker can write to an out-of-bounds pointer. (CVE-2020-11759) An issue was discovered in OpenEXR before 2.4.1. There is an out-of-bounds read during RLE uncompression in rleUncompress in ImfRle.cpp. (CVE-2020-11760) An issue was discovered in OpenEXR before 2.4.1. There is an out-of-bounds read during Huffman uncompression, as demonstrated by FastHufDecoder::refill in ImfFastHuf.cpp. (CVE-2020-11761) An issue was discovered in OpenEXR before 2.4.1. There is an out-of-bounds read and write in DwaCompressor::uncompress in ImfDwaCompressor.cpp when handling the UNKNOWN compression case. (CVE-2020-11762) An issue was discovered in OpenEXR before 2.4.1. There is an std::vector out-of-bounds read and write, as demonstrated by ImfTileOffsets.cpp. (CVE-2020-11763) An issue was discovered in OpenEXR before 2.4.1. There is an out-of-bounds write in copyIntoFrameBuffer in ImfMisc.cpp. (CVE-2020-11764) An issue was discovered in OpenEXR before 2.4.1. There is an off-by-one error in use of the ImfXdr.h read function by DwaCompressor::Classifier::Classifier, leading to an out-of-bounds read. (CVE-2020-11765) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11758 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11759 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11760 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11761 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11762 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11763 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11764 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11765 https://usn.ubuntu.com/4339-1/ ======================== Updated packages in core/updates_testing: ======================== openexr-2.3.0-2.2.mga7 lib(64)ilmimf2_3_24-2.3.0-2.2.mga7 lib(64)openexr-devel-2.3.0-2.2.mga7 from SRPMS: openexr-2.3.0-2.2.mga7.src.rpm
CC: (none) => nicolas.salgueroWhiteboard: MGA7TOO => (none)Status comment: Fixed upstream in 2.4.1 => (none)Status: NEW => ASSIGNEDAssignee: pkg-bugs => qa-bugsSource RPM: openexr-2.3.0-4.mga8.src.rpm => openexr-2.3.0-2.1.mga7.src.rpmVersion: Cauldron => 7
Checking this out by reference to https://bugs.mageia.org/show_bug.cgi?id=24759 and chasing PoC. Installed the development package pre-update.
CC: (none) => tarazed25
CVE-2020-11758 https://bugs.chromium.org/p/project-zero/issues/detail?id=1987 $ git clone https://github.com/AcademySoftwareFoundation/openexr.git $ cd openexr $ mkdir build && cd build $ sudo urpmi libasan $ CFLAGS="-g -fsanitize=address" CXXFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" cmake .. -DCMAKE_BUILD_TYPE=Debug ... /usr/bin/ld: cannot find -lasan ... -- Configuring incomplete, errors occurred! $ less CMakeFiles/CMakeError.log ... /usr/bin/ld: cannot find libasan_preinit.o: No such file or directory /usr/bin/ld: cannot find -lasan collect2: error: ld returned 1 exit status This is to compile an asan enabled version of exrmakepreview. Giving up on that. The other CVEs involve tests with the same framework. http://www.openexr.com/downloads.html provides viewers but they need to be built from source. A number of test images had been pulled from GitHub in a previous test, dated to 2014. The following link points to the source for a display utility but I am at a loss how to build it. https://github.com/AcademySoftwareFoundation/openexr/OpenEXR_Viewers/exrdisplay The previous bug lists these: " exrenvmap exrheader exrmakepreview exrmaketiled exrmultipart exrmultiview exrstdattr " in /usr/bin but they do not exist here. All that can be found on this sytem are source files in my qa test directory, e.g. $ locate exrmultiview /data/qa/openexr/openexr/OpenEXR/exrmultiview /data/qa/openexr/openexr/OpenEXR/exrmultiview/CMakeLists.txt /data/qa/openexr/openexr/OpenEXR/exrmultiview/Image.cpp /data/qa/openexr/openexr/OpenEXR/exrmultiview/Image.h /data/qa/openexr/openexr/OpenEXR/exrmultiview/Makefile.am /data/qa/openexr/openexr/OpenEXR/exrmultiview/main.cpp /data/qa/openexr/openexr/OpenEXR/exrmultiview/makeMultiView.cpp /data/qa/openexr/openexr/OpenEXR/exrmultiview/makeMultiView.h /data/qa/openexr/openexr/OpenEXR/exrmultiview/namespaceAlias.h Without experience with automake this is a dead end. Running out of ideas about how to test this package. Still at the pre-update stage.
Ach! Just discovered that openexr was not installed. Back later.
$ exrheader 'id^%000001,sig^%06,src^%000522,op^%ext_AO,pos^%109' file id^%000001,sig^%06,src^%000522,op^%ext_AO,pos^%109: file format version: 2, flags 0x0 channels (type chlist): Y, 16-bit floating-point, sampling 1 25 compression (type compression): pxr24 dataWindow (type box2i): (0 0) - (799 224) displayWindow (type box2i): (0 0) - (799 799) lineOrder (type lineOrder): decreasing y pixelAspectRatio (type float): 1 screenWindowCenter (type v2f): (0 0) screenWindowWidth (type float): 1 type (type string): "scanlineimage" $ exrmakepreview 'id^%000001,sig^%06,src^%000522,op^%ext_AO,pos^%109' out X and/or y subsampling factors of "Y" channel of input file "id^%000001,sig^%06,src^%000522,op^%ext_AO,pos^%109" are not compatible with the frame buffer's subsampling factors. $ exrheader AllHalfValues.exr file AllHalfValues.exr: file format version: 2, flags 0x0 channels (type chlist): B, 16-bit floating-point, sampling 1 1 G, 16-bit floating-point, sampling 1 1 R, 16-bit floating-point, sampling 1 1 compression (type compression): piz dataWindow (type box2i): (0 0) - (255 255) displayWindow (type box2i): (0 0) - (255 255) lineOrder (type lineOrder): increasing y pixelAspectRatio (type float): 1 screenWindowCenter (type v2f): (0 0) screenWindowWidth (type float): 1 type (type string): "scanlineimage" $ exrmakepreview AllHalfValues.exr output.exr $ ll output -rw-r--r-- 1 lcl lcl 110797 Apr 29 18:53 output.exr $ file output output: OpenEXR image data, version 2, storage: scanline, compression: piz, dataWindow: (0 0)-(255 255), displayWindow: (0 0)-(255 255), lineOrder: increasing y $ display output.exr That seems to work and looks identical to the source image, which is smaller on disk. -rw-r--r-- 1 lcl lcl 70769 Apr 23 2014 AllHalfValues.exr ------------------------------------------------------------------------------- Updated the three packages. No difference in the outputs from exrheader and exrpreview for the poc file which could mean either that the issues had been fixed or more likely that they are not being tested properly. Better to forget the proofs of concept. Tested AllHalfValues.exr as before. No regressions. $ exrmultipart -combine -i Trunks.exr Leaves.exr Ground.exr -o new.exr input: Trunks.exr Leaves.exr Ground.exr output: new.exr override:0 -combine multipart input part 0: deepscanlineimage part 1: deepscanlineimage part 2: deepscanlineimage part 3: deepscanlineimage part 4: deepscanlineimage part 5: deepscanlineimage Combine Success $ ll -rw-r--r-- 1 lcl lcl 32009045 Apr 23 2014 Ground.exr -rw-r--r-- 1 lcl lcl 16503998 Apr 23 2014 Leaves.exr -rw-r--r-- 1 lcl lcl 52371793 Apr 29 19:24 new.exr -rw-r--r-- 1 lcl lcl 3858752 Apr 23 2014 Trunks.exr IM's display shows only the first layer (Trunks) for new.exr. $ exrheader new.exr file new.exr: file format version: 2, flags 0x1800 part 0: channels (type chlist): A, 16-bit floating-point, sampling 1 1 B, 16-bit floating-point, sampling 1 1 G, 16-bit floating-point, sampling 1 1 R, 16-bit floating-point, sampling 1 1 Z, 32-bit floating-point, sampling 1 1 chunkCount (type int): 814 compression (type compression): zip, individual scanlines dataWindow (type box2i): (0 266) - (1919 1079) displayWindow (type box2i): (0 0) - (1919 1079) lineOrder (type lineOrder): increasing y name (type string): "rgba.left" [...] part 5: channels (type chlist): A, 16-bit floating-point, sampling 1 1 B, 16-bit floating-point, sampling 1 1 G, 16-bit floating-point, sampling 1 1 R, 16-bit floating-point, sampling 1 1 Z, 32-bit floating-point, sampling 1 1 chunkCount (type int): 741 compression (type compression): zip, individual scanlines dataWindow (type box2i): (0 339) - (1919 1079) displayWindow (type box2i): (0 0) - (1919 1079) lineOrder (type lineOrder): increasing y name (type string): "rgba.right_5_1" .... The GIMP sees only one layer in new.exr as well. The documentation in /usr/share/doc does not help much - far too technical to help for a quick test so I am abandoning this and passing it on the strength of the exrheader program working.
Whiteboard: (none) => MGA7-64-OK
A herculean effort, Len. Much appreciated. Validating. Advisory in Comment 2.
CC: (none) => andrewsfarm, sysadmin-bugsKeywords: (none) => validated_update
Keywords: (none) => advisoryCC: (none) => tmb
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0189.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED