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 > free...@shaneware.biz: graphics/blender > free...@shaneware.biz: graphics/openimageio > free...@shaneware.biz: graphics/openshadinglanguage > free...@shaneware.biz: graphics/py-openimageio > amd...@freebsd.org: graphics/nvidia-texture-tools > da...@freebsd.org: graphics/appleseed > da...@freebsd.org: graphics/hdr_tools > da...@freebsd.org: graphics/mitsuba > dan...@freebsd.org: graphics/vips > dumbb...@freebsd.org: graphics/darktable > eha...@freebsd.org: graphics/exrtools > gn...@freebsd.org: graphics/gegl > gn...@freebsd.org: graphics/gegl3 > g...@freebsd.org: graphics/enblend > g...@freebsd.org: graphics/hugin > h2+fbsdpo...@fsfe.org: graphics/luminance > h2+fbsdpo...@fsfe.org: graphics/luminance-qt5 > jamesb-...@excamera.com: graphics/py-openexr > k...@freebsd.org: editors/calligra > k...@freebsd.org: graphics/kf5-kimageformats > k...@freebsd.org: graphics/krita > k...@freebsd.org: x11/kde4-runtime > k...@freebsd.org: x11/kdelibs4 > multime...@freebsd.org: graphics/gstreamer1-plugins-openexr > po...@freebsd.org: graphics/ampasCTL > po...@freebsd.org: graphics/aqsis > po...@freebsd.org: graphics/cinepaint > po...@freebsd.org: graphics/exact-image > po...@freebsd.org: graphics/fyre > po...@freebsd.org: graphics/pixie > po...@freebsd.org: graphics/simpleviewer > po...@freebsd.org: graphics/vigra > po...@freebsd.org: science/gwyddion > r...@freebsd.org: graphics/gimp-gmic-plugin > thie...@freebsd.org: graphics/cimg > woods...@freebsd.org: devel/synfig
signature.asc
Description: OpenPGP digital signature
