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

[Tobias C. Berner]

Hi Matthias

Thanks for the heads-up, we'll make OpenEXR an option soon for the kde@
ports, so that
we can easily get rid of it when its fate is decided.

mfg Tobias

On 22 October 2017 at 16:05, Matthias Andree <mandree at freebsd.org> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-freebsd/attachments/20171110/3d3177d8/attachment-0001.html>