To answer the narrow question about OIIO: I think that it would be fairly easy to add a build-time switch to disable the use of the OpenEXR file format (and the IlmImf library). That would make it all but useful to professional VFX, where OpenEXR is the dominant format for rendered output, but if particular uses of OIIO didn't care about that, it would work. I would certainly do that if the alternative is that OIIO in turn is in danger of being "forbidden." (It would be much harder to eliminate use of the Ilmbase package -- which is part of the OpenEXR project but usually packaged separately in distributions, and does not appear to be implicated in the security bugs.)
Now, as for the OpenEXR situation: The good news is that there appears to be a PR that purports to solve these security issues: https://github.com/openexr/openexr/pull/233 <https://github.com/openexr/openexr/pull/233> The bad news is that this PR has been sitting idle for months, and it appears that it's just waiting for the author to return a CLA to the project. I don't know what attempts have been made to push that along. > On Oct 22, 2017, at 10:32 PM, Shane Ambler <[email protected]> wrote: > > > Currently oiio relies on openexr and there is no option to disable it's > use. > > Seems there are several security reports related to openexr and there > appears to be some lack of interest in repairing the issues, at least on > github, contact has been attempted directly to ILM. > > Today a discussion was started about changing the status of the openexr > libraries from vulnerable to forbidden, not sure if it will get support. > This is in the freebsd ports, which could be the first/one of many. > > This sounds like a very damaging step to me. > > If openexr is removed as an available dependency can oiio still be > built? Could an option be added instead of multiple patches being made > for each system package? > > OpenEXR is a bsd licensed project. Anyone interested in forking it? > > The list of vulnerabilities in the discussion - > > CVE-2017-9110 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-9111 In OpenEXR 2.2.0, an invalid write of size 8 in the > storeSSE function in ImfOptimizedPixelReading.h could cause the > application to crash or execute arbitrary code. > CVE-2017-9112 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-9113 In OpenEXR 2.2.0, an invalid write of size 1 in the > bufferedReadPixels function in ImfInputFile.cpp could cause the > application to crash or execute arbitrary code. > CVE-2017-9114 In OpenEXR 2.2.0, an invalid read of size 1 in the refill > function in ImfFastHuf.cpp could cause the application to crash. > CVE-2017-9115 In OpenEXR 2.2.0, an invalid write of size 2 in the = > operator function in half.h could cause the application to crash or > execute arbitrary code. > CVE-2017-9116 In OpenEXR 2.2.0, an invalid read of size 1 in the > uncompress function in ImfZip.cpp could cause the application to crash. > > > -- > FreeBSD - the place to B...Software Developing > > Shane Ambler > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
