Bug 26551 - openexr new security issues CVE-2020-1175[89] and CVE-2020-1176[0-5]
Summary: openexr new security issues CVE-2020-1175[89] and CVE-2020-1176[0-5]
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: MGA7-64-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2020-04-28 02:59 CEST by David Walser
Modified: 2020-05-05 14:22 CEST (History)
5 users (show)

See Also:
Source RPM: openexr-2.3.0-2.1.mga7.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2020-04-28 02:59:04 CEST
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.
David Walser 2020-04-28 02:59:19 CEST

Status comment: (none) => Fixed upstream in 2.4.1
Whiteboard: (none) => MGA7TOO

Comment 1 Lewis Smith 2020-04-28 20:55:17 CEST
In the absence of a registered or evident maintainer, no choice but to assign this globally.

Assignee: bugsquad => pkg-bugs

Comment 2 Nicolas Salguero 2020-04-29 11:19:41 CEST
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.salguero
Whiteboard: MGA7TOO => (none)
Status comment: Fixed upstream in 2.4.1 => (none)
Status: NEW => ASSIGNED
Assignee: pkg-bugs => qa-bugs
Source RPM: openexr-2.3.0-4.mga8.src.rpm => openexr-2.3.0-2.1.mga7.src.rpm
Version: Cauldron => 7

Comment 3 Len Lawrence 2020-04-29 18:12:05 CEST
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

Comment 4 Len Lawrence 2020-04-29 19:22:53 CEST
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.
Comment 5 Len Lawrence 2020-04-29 19:41:58 CEST
Ach!  Just discovered that openexr was not installed.  Back later.
Comment 6 Len Lawrence 2020-04-29 21:29:03 CEST
$ 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

Comment 7 Thomas Andrews 2020-04-30 18:12:32 CEST
A herculean effort, Len. Much appreciated.

Validating. Advisory in Comment 2.

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

Thomas Backlund 2020-05-05 10:14:37 CEST

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

Comment 8 Mageia Robot 2020-05-05 14:22:32 CEST
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2020-0189.html

Resolution: (none) => FIXED
Status: ASSIGNED => RESOLVED


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