Assigning to the registered maintainer.

Assignee: bugsquad => shlomif
CC: (none) => marja11

There's a (yet unmerged) upstream PR that should address some of the CVEs (CVE-2017-911[026]).

For the CVE-2017-911[1345], the contributor states that [0]:

> These CVEs appear to be bugs in exr2aces and are not generally reproducible
> in the library itself, only with bad input to the library via a program such
> as exr2aces.

https://github.com/openexr/openexr/issues/232#issuecomment-307245652

So I guess that as long as we don't build exr2aces, we don't need to care about those and could ship an update for CVE-2017-911[026] - that is if we're to trust this contributor's analysis, but so far it hasn't been challenged.

I've added the current pending patch to our Mageia 6 package in openexr-2.2.0-10.mga6:
- PR: https://github.com/openexr/openexr/pull/233
- Current commit: https://github.com/openexr/openexr/commit/749193265ac99956f01a2dd9b20f124f2f7859d0

If I read the author's analysis correctly in PR 233 and issue 232, it should fix CVE-2017-911[026] but not CVE-2017-911[1345], but as mentioned above those would be bugs in the exr2aces tool that we do not package.

So my call would be that it should be enough for us; on the other hand I haven't tested the patched package yet to see if the issues are properly fixed.

Source RPM: openexr-2.2.0-9.mga6.src.rpm => OpenEXR-2.2.0-4.mga5, openexr-2.2.0-9.mga6

Advisory:
========================

Updated OpenEXR packages fix security vulnerabilities:

In OpenEXR 2.2.0, an invalid read of size 2 in the hufDecode function in
ImfHuf.cpp could cause the application to crash (CVE-2017-9110).

In OpenEXR 2.2.0, an invalid read of size 1 in the getBits function in
ImfHuf.cpp could cause the application to crash (CVE-2017-9112).

In OpenEXR 2.2.0, an invalid read of size 1 in the uncompress function in
ImfZip.cpp could cause the application to crash (CVE-2017-9116).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9110
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9112
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9116
http://seclists.org/oss-sec/2017/q2/308
========================

Updated packages in core/updates_testing:
========================
OpenEXR-2.2.0-4.1.mga5
libOpenEXR22-2.2.0-4.1.mga5
libOpenEXR-devel-2.2.0-4.1.mga5

from OpenEXR-2.2.0-4.1.mga5.src.rpm

Assignee: shlomif => qa-bugs

MGA5-32 on Dell Latitude D600 Xfce
No installation issues
I don't know what to do with this.
at CLI:
$ exrheader 
usage: exrheader imagefile [imagefile ...]
I tried jpg, orf, tif,ppm but each time I get:
 File is not an image file.
Sites refer to EXR image files, but I have been hunting in vain. I get jpg samples  from these sites, which present the same problem.

CC: (none) => herman.viaene

@Herman re comment 5.
madb states that the package deals with:
A high dynamic-range (HDR) image file format 

I guess EXR images are colour images with a greater depth than normally found.  You see HDR mentioned in connection with the new 4K TV screens and having bought one recently I can attest to the greater colour depth, particularly in the "blacks".  No idea how to find examples of static images with this format but shall poke around and let you know if any are to be found.

CC: (none) => tarazed25

@Herman re EXR images.  I found exactly what you did but there are hints on some sites about "images distributed with the release" so there might be some already in the system.  I shall experiment with locate and if that fails try downloading a package from some PhotoShop orientated site.

No luck so far.  Nothing with .EXR extension on the system. 
Found a set of POC files and at least one of them opens with exrheader.
$ exrheader id:000077,sig:11,src:002575,op:havoc,rep:4

file id:000077,sig:11,src:002575,op:havoc,rep:4:

file format version: 2, flags 0x0
channels (type chlist):
    BY, 16-bit floating-point, sampling 2 2, plinear
    RY, 16-bit floating-point, sampling 2 2, plinear
    o, 16-bit floating-point, sampling 1 1
compression (type compression): dwa, medium scanline blocks
dataWindow (type box2i): (0 0) - (609 405)
displayWindow (type box2i): (0 -8448) - (608 405)
lineOrder (type lineOrder): increasing y
owner (type string): "Co�yright 2006 Industrial Light & aagic"
pixelAspectRatio (type float): 1
pxelAspectRatio (type float): 1
screenWindowCenter (type v2f): (0 0)
screenWindowWidth (type float): 1
type (type string): "scanlineimage"

That means nothing though; there cannot be much of a payload because the file weighs only 786 bytes.

Success!  http://www.openexr.com/downloads.html
Look for OpenEXR sample images:
and download the .tar.gz bundle and unzip it.
e.g. $ tar xzf openexr-images-1.4.0.tar.gz

Over to you Herman.

Downloaded sample files - tx Len
Now I get:
$ exrheader t01.exr 

file t01.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) - (399 299)
displayWindow (type box2i): (0 0) - (399 299)
lineOrder (type lineOrder): increasing y
pixelAspectRatio (type float): 1
screenWindowCenter (type v2f): (0 0)
screenWindowWidth (type float): 1
type (type string): "scanlineimage"

The problem still left is that these files are not viewable by ristretto or GIMP. The sites and the README file refer to a command exrdisplay, but this one is not installed with the update packages and
# urpmf --verbose exrdisplay
using fast algorithm
getting lock on urpmi
using mirror http://mirror.netcologne.de/mageia/distrib/5/i586
getting information from /var/lib/urpmi/Core Release (distrib1)/files.xml.lzma
$MIRRORLIST media/core/updates media_info/MD5SUM opgehaald
    $MIRRORLIST: media/core/updates/media_info/20180102-160922-files.xml.lzma
$MIRRORLIST media/core/updates media_info/20180102-160922-files.xml.lzma opgehaald                     
getting information from /var/lib/urpmi/Core Updates (distrib3)/files.xml.lzma
getting information from /var/lib/urpmi/Core Updates Testing (distrib5)/files.xml.lzma
getting information from /var/lib/urpmi/Nonfree Release (distrib11)/files.xml.lzma
getting information from /var/lib/urpmi/Nonfree Updates (distrib13)/files.xml.lzma
getting information from /var/lib/urpmi/Tainted Release (distrib21)/files.xml.lzma
getting information from /var/lib/urpmi/Tainted Updates (distrib23)/files.xml.lzma
unlocking urpmi database
is not very helpfull either.

Re comment 10

It is possible that special plugins are needed for some display packages.  I think I saw somesuch mentioned with respect to ImageMagick (display).  Various plugins are mentioned on the web but most of these would apply to Windows, probably.

Validating the update just based on the update installing cleanly.

Keywords: (none) => validated_update
Whiteboard: (none) => MGA5-64-OK
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2018-0032.html

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

*** Bug 22691 has been marked as a duplicate of this bug. ***

This update also fixed CVE-2017-12596.