HEADS UP: OpenEXR vulnerability and deprecation, call for assistance/input

[Matthias Andree]

Greetings,

[not yet Cc:d to ports@]

I am the graphics/OpenEXR maintainer, and as some of you may already
know, OpenEXR has been vulnerable for quite a while, including "execute
arbitrary code" attacks.  I don't have patches I dare apply, so OpenEXR
is currently marked vulnerable and I intend to tighten things up and
mark FORBIDDEN soon.

Tech high-level detail, I wrote, in
<http://vuxml.freebsd.org/freebsd/803879e9-4195-11e7-9b08-080027ef73ec.html>:

> Brandon Perry reports:
> 
> [There] is a zip file of EXR images that cause segmentation faults in the OpenEXR library (tested against 2.2.0).
> 
> 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.

The upstream has been informed [1], and there is a proposed unreviewed
patch[2], but the upstream hasn't yet accepted responsibility, only
responded in a non-constructive way that patch, asking for a
contributors license agreement and adjourning to later "see what we can
do" or something, to which the contributor of the fixes answered he's
not doing any further work for lack of progress.[2]

[1]: <https://github.com/openexr/openexr/issues/232>

[2]: <https://github.com/openexr/openexr/pull/233>

Bottom line, to me, OpenEXR looks abandonware and we need to prepare for
getting rid of it, but I don't want to pull the rug from underneath your
feet without advance warning.


I have written to Ed Hanway of IL&M today to ask about the support
status, and have recently committed a DEPRECATED with an EXPIRATION_TIME
of EOY which I am willing to extend to 2018-03-31 for any straw or
halfway reasonable cause that either of you is going to present, after
which I suggest we nuke OpenEXR support in the ports tree for good, and
I intend to mark the port FORBIDDEN soon enough.


How should we proceed?

- are all of your ports good without OpenEXR, and support, for instance,
16-bit TIFF?

- are there OpenEXR alternatives that your ports could use and that we
could move

- is either of your ports dependent on OpenEXR to be useful?

- is anyone aware of another vendor auditing patches or actively
distributing patches for OpenEXR, or a patched version, that they are
supporting, and that we could rely on?
I am loathe to use unaudited third party patches.

This is a list generated from http://freshports.org/graphics/OpenEXR,
sorted by maintainer - to me this appears to be the list of
maintainer/port_origin pairs of ports that require OpenEXR by default.

Thanks for your time.

Regards,
Matthias

> FreeBSD at Shaneware.biz: graphics/blender
> FreeBSD at Shaneware.biz: graphics/openimageio
> FreeBSD at Shaneware.biz: graphics/openshadinglanguage
> FreeBSD at Shaneware.biz: graphics/py-openimageio
> amdmi3 at FreeBSD.org: graphics/nvidia-texture-tools
> danfe at FreeBSD.org: graphics/appleseed
> danfe at FreeBSD.org: graphics/hdr_tools
> danfe at FreeBSD.org: graphics/mitsuba
> danilo at FreeBSD.org: graphics/vips
> dumbbell at FreeBSD.org: graphics/darktable
> ehaupt at FreeBSD.org: graphics/exrtools
> gnome at FreeBSD.org: graphics/gegl
> gnome at FreeBSD.org: graphics/gegl3
> grog at FreeBSD.org: graphics/enblend
> grog at FreeBSD.org: graphics/hugin
> h2+fbsdports at fsfe.org: graphics/luminance
> h2+fbsdports at fsfe.org: graphics/luminance-qt5
> jamesb-bsd at excamera.com: graphics/py-openexr
> kde at FreeBSD.org: editors/calligra
> kde at FreeBSD.org: graphics/kf5-kimageformats
> kde at FreeBSD.org: graphics/krita
> kde at FreeBSD.org: x11/kde4-runtime
> kde at FreeBSD.org: x11/kdelibs4
> multimedia at FreeBSD.org: graphics/gstreamer1-plugins-openexr
> ports at FreeBSD.org: graphics/ampasCTL
> ports at FreeBSD.org: graphics/aqsis
> ports at FreeBSD.org: graphics/cinepaint
> ports at FreeBSD.org: graphics/exact-image
> ports at FreeBSD.org: graphics/fyre
> ports at FreeBSD.org: graphics/pixie
> ports at FreeBSD.org: graphics/simpleviewer
> ports at FreeBSD.org: graphics/vigra
> ports at FreeBSD.org: science/gwyddion
> rm at FreeBSD.org: graphics/gimp-gmic-plugin
> thierry at FreeBSD.org: graphics/cimg
> woodsb02 at FreeBSD.org: devel/synfig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-freebsd/attachments/20171022/fced9cf7/attachment.sig>