Multiple segmentation faults CVE-2017-9110 to CVE-2017-9116

[rhertzog]

Brandon Perry provided multiple images that can crash OpenEXR: http://www.openwall.com/lists/oss-security/2017/05/12/5

The files he sent are here (along with the output of valgrind apparently)
openexr.zip

Mitre assigned the following CVE to those issues:
CVE-2017-9116
CVE-2017-9115
CVE-2017-9114
CVE-2017-9113
CVE-2017-9112
CVE-2017-9111
CVE-2017-9110

[binarycrusader]

CVE	Test Data
CVE-2017-9110	id:000012,sig:11,src:000328+001154,op:splice,rep:16
CVE-2017-9111	id:000087,sig:11,src:000562+000300,op:splice,rep:2
CVE-2017-9112	id:000103,sig:11,src:002037+004745,op:splice,rep:2
CVE-2017-9113	id:000131,sig:11,src:000514+002831,op:splice,rep:16
CVE-2017-9114	id:000132,sig:11,src:000895,op:havoc,rep:32
CVE-2017-9115	id:000104,sig:11,src:001329+000334,op:splice,rep:2
CVE-2017-9116	id:000077,sig:11,src:002575,op:havoc,rep:4

[olalundqvist]

Hi

I have tried to reproduce the crash but so far I have failed to do so.
I have tried with exrtopng, exrstats and exrmakepreview on 1.6.1 and 2.2.0.

I fail to see any crashes. Have anyone else been able to reproduce the problem and in that case how?

I can see that a test has been proposed above. Do this mean that the library have to be used in order to reproduce the crash or have anyone seen the problem using any tools?

Best regards

// Ola

[olalundqvist]

@binarycrusader binarycrusader

Hi

I have started to look at the proposed patch. Is that proposed patch the final patch or are you planning to do more work on it?

I'm asking as I do not see that all CVEs are handled in this proposed patch:
CVE-2017-9110 and CVE-2017-9112 mentions ImfHuf.cpp so this may be covered.
CVE-2017-9111 mentions ImfOptimizedPixelReading.h but this file has not been patched. Is this covered by changes in some other file?
CVE-2017-9113 mentions ImfInputFile.cpp but that file has not been patched. Is this covered by changes in some other file?
CVE-2017-9114 mentions ImfFastHuf.cpp but that file has not been patched. Is this covered by changes in some other file?
CVE-2017-9115 mentions half.h but that file has not been patched. Is this covered by changes in some other file?
CVE-2017-9116 mentions ImfZip.cpp but that file has not been patched. Is this covered by changes in some other file?

Best regards

// Ola

[binarycrusader]

I have tried to reproduce the crash but so far I have failed to do so.
I have tried with exrtopng, exrstats and exrmakepreview on 1.6.1 and 2.2.0.

I fail to see any crashes. Have anyone else been able to reproduce the problem and in that case how?

This is subtle, but if you look at the .valgrind files that were provided in the openexr.zip linked in the first comment of the bug, you'll see that exr2aces is the program that was used to reproduce these errors.

That's important and subtle because exr2aces isn't built by default, and is therefore not shipped by many Linux distributions either.

I can see that a test has been proposed above. Do this mean that the library have to be used in order to reproduce the crash or have anyone seen the problem using any tools?

These CVEs apply generally to the library but can be easily reproduced by using exr2aces on the corresponding input files:

CVE-2017-9110, CVE-2017-9112, CVE-2017-9116

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:

CVE-2017-9111, CVE-2017-9113, CVE-2017-9114, CVE-2017-9115

My pull request detailed this:

#233

[binarycrusader]

I have started to look at the proposed patch. Is that proposed patch the final patch or are you planning to do more work on it?

Absent review feedback, I am not planning to do any more work on pull request #233.

I'm asking as I do not see that all CVEs are handled in this proposed patch:
CVE-2017-9110 and CVE-2017-9112 mentions ImfHuf.cpp so this may be covered.
CVE-2017-9116 mentions ImfZip.cpp but that file has not been patched. Is this covered by changes in some other file?

The above are covered by my proposed change as far as I can reproduce/determine. You can't match source files here for expected changes. The root cause of these failures is not necessarily in the same file.

The three failures addressed by the patch are: the input buffer size check is subject to integer overflow, the huffman decoder doesn't check for end of input buffer before each read, and the high level piz uncompress routine doesn't ensure that the size of the data array specified in the header does not exceed the size of the input.

CVE-2017-9111 mentions ImfOptimizedPixelReading.h but this file has not been patched. Is this covered by changes in some other file?
CVE-2017-9113 mentions ImfInputFile.cpp but that file has not been patched. Is this covered by changes in some other file?
CVE-2017-9114 mentions ImfFastHuf.cpp but that file has not been patched. Is this covered by changes in some other file?
CVE-2017-9115 mentions half.h but that file has not been patched. Is this covered by changes in some other file?

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.

As far as I can tell, exr2aces is passing an invalid pointer to an out-of-bounds memory location to use as a framebuffer, and then the library fails trying to write to it. The library can't possibly guard against an invalid framebuffer pointer being passed to it.

Since exr2aces is not built by default (at least for the regular ./configure; Make build), I don't intend to address those CVEs. In particular, it isn't clear to me how to fix exr2aces. If we create a framebuffer suitable for the size of what the input files suggest, that's effectively the program asking for 500GB of memory. While this is technically allowed by the OpenEXR specification (as far as I can tell), obviously I can't add any meaningful test for that.

As such, since image processing is not my domain of expertise, and it appears to be the result of bad usage of the library, rather than a problem in the library itself, I have opted to not attempt to resolve them.

[jgoffredo]

FreeBSD don't like any security issues. This happens compiling Luminance-HDR:

"
===> luminance-hdr-qt5-2.5.1 depends on shared library: libIlmImf-2_2.so - not found
===> OpenEXR-2.2.0_7 has known vulnerabilities:
OpenEXR-2.2.0_7 is vulnerable:
OpenEXR -- multiple remote code execution and denial of service vulnerabilities
CVE: CVE-2017-9116
CVE: CVE-2017-9115
CVE: CVE-2017-9114
CVE: CVE-2017-9113
CVE: CVE-2017-9112
CVE: CVE-2017-9111
CVE: CVE-2017-9110
WWW: https://vuxml.FreeBSD.org/freebsd/803879e9-4195-11e7-9b08-080027ef73ec.html

1 problem(s) in the installed packages found.
=> Please update your ports tree and try again.
=> Note: Vulnerable ports are marked as such even if there is no update available.
=> If you wish to ignore this vulnerability rebuild with 'make DISABLE_VULNERABILITIES=yes'
*** Error code 1

Stop.
make[3]: stopped in /usr/ports/graphics/OpenEXR
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/graphics/OpenEXR
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/graphics/luminance-qt5
*** Error code 1

Stop.
make: stopped in /usr/ports/graphics/luminance-qt5
"

[kdt3rd]

more complete fixes are on development master and cherry-picked to release/2.3 pending validation

[kdt3rd]

The remaining CVE that were not addressed previously have been addressed both on master and on release/2.3:

• CVE-2018-18444
• CVE-2017-9111
• CVE-2017-9113
• CVE-2017-9115

and will be in the next release made